In this post I’m going to explain two of the openssl options to perform a certificate validation and determine whether it is revoked or not.
But before jumping to the topic, let’s briefly review some PKI (Public Key Infrastructure) fundamentals.
What is certificate revocation?
Certificate Revocation is a mechanism that a CA (Certificate Authority), one of the components of the PKI ecosystem, may perform in order to remove the validity of a certificate before it reaches the expiration date.
The reason behind revoking a certificate is that the organisation, which holds a certificate on its premises issued by a CA, has deemed the associated private key to be compromised and it is no longer trusted, because it was disclosed to any unauthorised party or a malicious actor.
Since this disclosure would mean that there’s somebody, that could use this private key to eavesdrop successfully a TLS connection or could perform digital signatures impersonating the affected party, then it is not a good practice to continue using this private key, thus, the certificate associated as well.
Therefore, one of the incident response steps for such situations is that the organisation should request the issuing CA the certificate revocation, and start over again with a newly key pair and a certificate issued by the same CA.
Next, the CA will do the revoke operation, and update the CRL information and also the OCSP database. This implies that if the former compromised private key is used again, it would not be valid since it should be rejected by the applications that will check the CRL or OCSP information from the CA.
What are CRL and OCSP?
There are two different ways that CA can publish the revocation status of the certificates: CRL and OCSP.
The CRL stands for Certificate Revocation List and consists of a list of certificate serial numbers that are currently revoked by the CA. Since the list can only increase, the CRL are used for revocation status of the CA certificate itself, but not the ones issued for the clients, and OCSP is used instead.
OCSP stands for Online Certificate Status Protocol and it is a more real time service than the CRL. This means that if the CA revokes a certificate, the OCSP should respond with this status update immediately. With CRL, there might be a gap of time when the certificate status is not updated yet so the CA could respond with incorrect information. Moreover, the OCSP service replies only with the single certificate status instead of the full list of revoked certificates.
Obtain the certificate that you want to validate with CRL or OCSP
First, before validating a certificate with any method, you’ll need to download the certificate, the certificate full chain and verify if they are correct. To describe the use cases, site google.com certificate will be used:
$ openssl s_client -showcerts -connect google.com:443 2>/dev/null < /dev/null | sed -n '/^-----BEGIN/,/^-----END/p' > google.chain.pem
The above command will obtain all the certificates available when visiting the site google.com. Bear in mind that, in some sites, there could be only the server certificate, but not the root and the intermediate CA. In this case, you’ll need to download it separately from the CA website.
After obtaining the certificates, let’s separate them in different files with the following script:
$ i=2; while read line; do echo $line >> $i.pem; if [ "$line" == "-----END CERTIFICATE-----" ]; then ((i--)); fi ; done < google.chain.pem
The previous script will drop the root certificate CA as 0.pem, the intermediate CA as 1.pem and the server certificate as 2.pem:
As you can see in the previous picture, the google root CA certificate was issued by another CA named GlobalSign. Then, we need to download it separately, convert it to PEM format and append it to the certificate chain file to complete the certificate chain:
$ wget -q https://secure.globalsign.net/cacert/Root-R1.crt
$ openssl x509 -inform der -in Root-R1.crt -out globalsign.pem
$ cat globalsign.pem >> google.chain.pem
Finally, validate the google.com site certificate (previously named in this example as 2.pem) with the resulting certificate chain to confirm that everything is correctly set:
$ openssl verify -CAfile google.chain.pem 2.pem
If the verification of the certificate chain is correct then it will show the “OK” message. Otherwise, it will show an error message similar to:
error 2 at 2 depth lookup:unable to get issuer certificate
Ensure that all the certificates are present in the chain file and that they are appended in the correct order. In other words, the site certificate first, next the intermediate CA and then the root CA, and all of them delimited correctly with “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–“
Validate a certificate through CRL by using openssl
After preparing the certificate chain, before executing the CRL validation, we will need to download the CRL first from the site google.com certificate obtained previously (file 2.pem):
$ openssl x509 -noout -text -in 2.pem | grep -A 6 "X509v3 CRL Distribution Points" | grep "URI:" | cut -d':' -f2-
Then, the URL obtained can be used to get the CRL, convert it to PEM format and append it to the certificate chain because it will be needed for CRL validation.
$ wget http://crls.pki.goog/gts1c3/QOvJ0N1sT2A.crl -q -O google.crl.der
$ openssl crl -inform DER -in google.crl.der -outform PEM -out google.crl.pem
$ cat google.chain.pem google.crl.pem > google.chain.crl.pem
$ openssl verify -crl_check -CAfile google.chain.crl.pem 2.pem
If the certificate is still valid then the message obtained should be “OK”. Otherwise, the message should be “Certificate Revoked”.
Execute openssl to validate a certificate with OCSP
In order to check the certificate validity through OCSP, it is needed to get the OCSP responder URL from the site google.com certificate obtained previously (file 2.pem), and then execute the OCSP request with the certificate chain.
$ openssl x509 -noout -ocsp_uri -in 2.pem
$ openssl ocsp -issuer google.chain.pem -cert 2.pem -text -url http://ocsp.pki.goog/gts1c3 -header "HOST" "ocsp.pki.goog"
If the certificate is still valid then the message obtained should be “Response verify OK” otherwise the message should be “Revoked”.