PKI: Certificate Revocation process explained
To establish a secure connection website require a certificate. Basically, these certificates have a Public key certificate which has a digital signature for them so that it can be trusted for the name, address, organization it has in the certificate by the client.
In a typical public-key infrastructure (PKI) scheme, the signer is a certificate authority (CA), usually a company which charges customers to issue certificates for them. Browsers ensure user safety by requesting certificate information from the vendor instead of from the web application server.
The job of a CA who issues the certificate is not to just issue the new certificate requests. It needs to provide the certificate revocation information for all the requests it is receiving from the clients.
In this article, we will have a look at how certificate revocation works.
Below are the types of certificate revocation check that can be configured
- CRL Distribution. - Certificate Revocation List.
- OCSP - Online Certificate Status Protocol.
- OCSP Staple.
Both the configuration (CRL & OCSP) needs to be done on the certificate authority properties extension tab as shown below
https://exchangequery.files.wordpress.com/2016/04/crll.png
CRL distribution is the core component of the certificate revocation check.so the latter two options are indirectly and totally dependent on the CRL.
The CRL configuration has components:
Base CRL - This will contain the whole complete list of revoked certificates (non-expired). so whatever the revoked certificates we have will be present here.
An example below of how it will show in the CRL and will show all the revoked certificates.
https://exchangequery.files.wordpress.com/2016/04/c.png Delta CRL - This will contain only the list of revoked certificates which got from the last CRL distribution points. So this will not have all the revoked certificates.
An example of delta CRL
https://exchangequery.files.wordpress.com/2016/04/c11.png
CDP(CRL distribution points) - This CRL distribution point is the place where the Certificate Authority publishes all the certificate information. So the base CRL and the delta CRL gets information from this place only.
A real-time example of CRL distribution point when seen from the client side.
https://exchangequery.files.wordpress.com/2016/04/rt.png
There are two types of CRL distribution points which can be configured:
LDAP - Not firewall friendly and complicated. We also need to allow LDAP port for this verification which is normally not feasible. Personally, we don't feel to allow my LDAP port accessed externally for this revocation process.
HTTP - This is easily accessible by all clients. It's very good if configured properly without exposing the internal namespace. So basically we need to create DNS records for the HTTP URL to publish, create a virtual directory for the CRL distribution points and configure a file server.
The disadvantage of CRL's is that the client has to search through the complete revocation list. Moreover, they are updated periodically and chances are there the client might get wrong information until the next update happens on the CDP. Usually, the browsers take more time to load all these certificates and then check the revocation for its required certificate.
OCSP: Online Certificate Status Protocol
With the OCSP the job has become very simple and easier. This removes the major disadvantage of CRL by allowing the client to check the certificate status of its only one which it owns by providing a serial number to the responder.
OCSP Client - This is the client responsible for querying the certificate check. This OCSP client is available from Windows Vista and later versions of operating systems. Operating systems prior to these versions will be using the normal CRL check to validate the certificates. This client is responsible for providing a serial number to the responder.
OCSP responder (web proxy) - This component is available from Windows 2008 server CA. Servers holding CA prior to this versions will be using the CRL to respond the requestors. This will check the certificate status of the serial number provided by the client. Then it holds a cache entry of the requests that came so that it would be easier to provide them in future.
The OCSP client request process in shown below:
1) Client access the website via browser. 2) The client sends OCSP Request to an OCSP Responder (over HTTP) with the certificates serial number for which it requires verification. 3) OCSP Responder replies with a certificate status of either Good, Revoked or Unknown.
https://exchangequery.files.wordpress.com/2016/04/certificate.png?w=680
Two important things for OCSP configuration
1) The Online Responder service runs under the Network Service account. So we need to make sure it Network service has read permission. 2) we need to enable the value id-pkix-ocsp-nocheck extension for the OCSP by running the below command.
certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK
This extension is to avoid the circular revocation checking so that it will not verify the signing certificate from the OCSP requestor.
OCSP stapling:
With OCSP stapling, the web server downloads a copy of the vendor’s response which it can deliver directly to the browser. So the browser does not need to contact the CA separately rather it will contact the application directly and get the certificate.
With OCSP stapling, the application periodically queries CA and caches a response which is then provided to the browser. By default, this setting is configured when we configure OCSP.
The registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\ controls this behavior.
If we want to disable stapling then all we need to do is create a DWORD called RequestOCSP in the same location and set it to value 0.
A real-time example of OCSP distribution point when seen from the client side
