Importance of certificate whitelist checking

Posted by Liaquat Khan on Aug 3, 2013 2:24:00 PM

Using PKI-based digital certificates has become a widely accepted means of electronic identity authentication for all kinds of purposes, from logical/physical access control to document signing, server authentication for e-commerce sites and software code authentication.

Before relying on a digital certificate it’s important to check its current status to ensure it’s not revoked (e.g. security compromise, lost keys, cessation of operations etc.). The Online Certificate Status Protocol (OCSP, RFC 6960) is the most accepted approach for efficiently checking a certificate’s revocation status. OCSP client-side functionality is widely implemented in browsers, operating systems, networking devices and document software like Adobe Reader. Many vendors, including Ascertia, provide OCSP responders.

Attack Vector

However traditional use of OCSP has an issue – it normally uses Certificate Revocation Lists (CRLs) to determine if a certificate is revoked or not. CRLs are a black-list of revoked certificates, i.e. only identify those certificates which are known to have been revoked.

Recent attacks on well-known public CAs have resulted in fake certificates being issued by bypassing the normal CA software access control rules (i.e. directly accessing the CA’s private signing key inside an HSM without being subjected to normal identification, authentication, access control and logging features of the CA software). In such cases the CA is not even aware that a fake certificate has been issued. As a result such fake certificates can’t even be put on a CRL to indicate they have been revoked.

An OCSP responder which gets its input feed from CRLs can therefore not help to recover from such attacks. A traditional OCSP responder will return “Good” status for such fake certificates.


To overcome the above attack an OCSP responder should not just check whether or not a certificate is included on a CRL, but determine if the certificate was actually issued by the CA by looking at the CA’s database of issued certificates. This is referred to as white-list checking. If the certificate is not found in the CA database of issued certificate, then the OCSP server should respond with a “revoked” status to prevent the certificate from being used (i.e. a fail-safe scenario).

The CA/Browser (CAB) Forum Baseline Requirements have also been updated to make this a formal requirement from 1st August 2013:

13.2.6 Response for non-issued certificates

If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status. The CA SHOULD monitor the responder for such requests as part of its security response procedures.

Effective 1 August 2013, OCSP responders MUST NOT respond with a "good" status for such certificates.

A new version of the OCSP specification has been released to cater for this, see RFC 6960. This formally defines the extended use of the “revoked” status to cover non-issued certificates. It also allows the OCSP responder to inform client applications that it supports this extended use by inserting a special extension in the OCSP response message.

Ascertia ADSS OCSP Server is one of the first OCSP responders globally to support this RFC 6960 whitelist checking mechanism and extension. Not only does ADSS OCSP Server return revoked status for such non-issued certificates but it also allows real-time alerts to be generated and sent to configured administrators when such a non-issued certificate is encountered. This will help to quickly detect, analyse and resolve a potentially disastrous situation for a CA service provider!