Certificate Verification: Exploring OCSP, CRL, and Revocation

In our previous article titled "Demystifying Digital Certificates for Enhanced Trust and Security," we explored the fundamental concepts of digital certificates and the role of Certificate Authorities (CAs) in establishing trust in the digital world. Building upon that knowledge, this article aims to take a deeper dive into the critical process of verifying certificates. We will unravel the significance of OCSP (Online Certificate Status Protocol), CRL (Certificate Revocation List), the concept of revocation, and the pivotal role played by Validation Authorities (VAs).

Certificate Revocation

Revocation of a certificate refers to the act of declaring a previously issued certificate as invalid or no longer trusted before its scheduled expiration date. When a certificate is revoked, it means that it should no longer be relied upon for cryptographic operations or as proof of identity. Using OpenSSL lets create CRL on behalf of our previously made CA in this previous article

openssl ca -config ca.cnf -gencrl -out ca.crl

When to revoke a certificate?

Imagine this: you wake up one morning to realize that your certificate, the bedrock of trust on which your online identity stands, has been compromised. What's your next move? It's a no-brainer: you need to revoke that certificate pronto! But why should you revoke it and under which criteria? Let's delve into that.

Certificate revocation is necessary under particular circumstances. It's like a cease-and-desist order for your digital ID. But when is it necessary to pull the plug?

1. Key Compromise: This is the most common reason for certificate revocation. If you suspect or confirm that your certificate's private key is in the hands of someone else, then hit the revoke button immediately.

2. Certificate Hold: Say, you have temporarily lost control over your private key, but you're sure it hasn’t been compromised. You can put your certificate on 'hold.' Note, though, that this action is reversible, unlike revocation.

3. Information Change: If your certificate includes outdated information — for example, your company moved offices or changed its name — you’ll need to revoke the certificate and get reissued with an updated one.

How to ask CA to revoke a certificate?

Alright, so you've figured out that you need to revoke your certificate. Now, the question stands - how exactly do you go about asking a Certificate Authority (CA) to revoke your certificate? Let's break it down, shall we?

Step 1: Contact Certificate Authority

Visit your CA's website, find the 'support' or 'certificate services' and ask for certificate revocation.

Step 2: Follow Revocation Instructions

Your CA may ask you to complete a form or email explaining why you need the revocation and provide certificate details. You might need to verify your identity.

Step 3: Await Confirmation

Wait for your CA to process your request. Stay updated with any emails or communication from CA confirming revocation and guiding to get new certificate if needed.

Contact your CA if you need further assistance.

Verification Authority

The Verification Authority (VA) serves as an intermediary between verifiers and the Certificate Authority (CA), enabling the verification of the revocation status of certificates. It facilitates the use of tools such as Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP) for this purpose.

Certificate Verification

To verify Ahmed's certificate, Eman can follow a series of steps known as certificate validation. These steps include the following:

1- Obtain the Certificate: Eman needs to acquire Ahmed's certificate.

2- Verify the Certificate Chain: Eman checks if the certificate was issued by a trusted Certificate Authority (CA). She does this by verifying the digital signature on Ahmed's certificate using the CA's public key. If the signature is valid, it confirms that the certificate was indeed issued by a trusted CA.

3- Compare Thumbprint and Hash: Eman extracts the thumbprint value from Ahmed's certificate and creates a hash value by hashing the certificate attributes (excluding the thumbprint and the signature). She then compares the thumbprint and the hash. If they match, it indicates that the certificate attributes have not been tampered with.

4- Decrypt the Signature: Eman extracts the signature value from Ahmed's certificate and decrypts it using the CA's public key. The result of the decryption should match the thumbprint value.

5- Check Not Before, Not After, and Revocation Status: Eman verifies that the current time falls within the validity period specified by the "Not Before" and "Not After" attributes of the certificate. Additionally, she checks the revocation status of the certificate using a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP) service.

Well, this seems complicated! Luckily, The OpenSSL library provides a convenient command-line tool, openssl verify, that automates these steps for certificate verification. In our previous article, Ahmed submitted his Certificate Signing Request (CSR) to the CA, which issued a certificate to him. Now, let's simulate Eman's perspective and verify Ahmed's certificate using the CA certificate file (ca.pem) and Ahmed's certificate file (ahmed_cert.pem).

Run the following command on behalf of Eman:

openssl verify -crl_check -CAfile ca.pem -CRLfile cacrl.crl  ahmed_cert.pem

If the certificate is verified, then the output should be:

ahmed_cert.pem: OK

Different Verification Error Cases:

In certain scenarios, the certificate verification process may fail, resulting in different output. Here are a few examples:

Case: Certificate Expired

To test this case, we can create a new certificate called shortTimeCert with a short validity period. First, create a file named "shortTimeCert.cnf" with the following content:

HOME            = .
RANDFILE        = $ENV::HOME/.rnd

[req]
prompt                 = no
distinguished_name     = req_distinguished_name
req_extensions         = v3_req

[req_distinguished_name]
countryName            = SA
stateOrProvinceName    = RUH
localityName           = RUH
commonName             = shortTimeCert

[v3_req]
basicConstraints       = CA:false
extendedKeyUsage       = clientAuth
subjectAltName         = @sans

[sans]
DNS.0 = localhost

Note that the "days" attribute is not included in this configuration file.

Next, generate the private key and certificate signing request (CSR) using the following commands:

openssl genpkey -algorithm RSA -out shortTimeCertTest_privatekey.pem -aes256
openssl rsa -pubout -in shortTimeCertTest_privatekey.pem -out shortTimeCertTest_publickey.pem
openssl req -new -key shortTimeCertTest_privatekey.pem -out shortTimeCertTest_csr.pem -outform PEM -config shortTimeCert.cnf

Now, let the certificate authority (CA) issue the certificate by specifying the start and end dates:

set startdate $(date -u +"%y%m%d%H%M%SZ")
set enddate $(date -u -v+1M +"%y%m%d%H%M%SZ")
openssl ca -config ca.cnf -policy signing_policy -extensions signing_req -startdate "$startdate" -enddate "$enddate" -out shortTimeCertTest_cert.pem -infiles shortTimeCertTest_csr.pem

After waiting for one minute, you can verify the certificate's validity. Here is an example output you might encounter:

C = SA, ST = RUH, L = RUH, CN = shortTimeCert
error 10 at 0 depth lookup: certificate has expired
error shortTimeCertTest_cert.pem: verification failed

This error indicates that the certificate has expired.

Case: Certificate Revoked

To simulate a revoked certificate, make sure that you generate a Certificate Revocation List (CRL) file using OpenSSL that we mentioned <here>

Since there are no revoked certificates on the list currently, let's proceed to revoke Ahmed's certificate and update the Certificate Revocation List (CRL) file. Here's the modified section:

# Revoke Ahmed's certificate
openssl ca -config ca.cnf -revoke ahmed_cert.pem

# Update the CRL file
openssl ca -config ca.cnf -gencrl -out ca.crl

When Eman verifies Ahmed's certificate afterwards, she should expect to receive the following result:

C = SA, ST = RUH, L = RUH, O = AhmedOrg, OU = AhmedOu, CN = Ahmed Abdullah
error 23 at 0 depth lookup: certificate revoked
error ahmed_cert.pem: verification failed

Case: Certificate Signed with Untrusted CA

In this case, a bad actor creates their own CA with the same information as the trusted CA but a different key pair. When Eman verifies the certificate using the trusted CA certificate (ca.pem), a verification error occurs. This error arises because the public key in the rogue CA's certificate does not match the public key in the trusted CA's certificate.

Case: Certificate Attribute Tampering

In a scenario where a malicious actor wants to misuse Ahmed's certificate, they replace Ahmed's public key with their own in the certificate. This manipulation would result in the hash of the certificate being different from the thumbprint value. OpenSSL commands are not provided for this case as it is intended for illustrative purposes only.

OCSP

OCSP (Online Certificate Status Protocol) is indeed a protocol used for obtaining the revocation status of digital certificates in real-time. It operates as a client-server protocol, where the client (such as a web browser or application) sends a request to an OCSP responder server to verify the validity and revocation status of a certificate.

The OCSP protocol provides a more efficient and timely method for certificate validation compared to traditional methods like Certificate Revocation Lists (CRLs). Instead of downloading and parsing potentially large CRL files, OCSP allows for on-demand checking of a certificate's status. This real-time approach minimizes the risk of accepting revoked or compromised certificates, enhancing the overall security of digital communications.

When a client sends an OCSP request, it includes the certificate in question and identifies the OCSP responder server to contact. The OCSP responder then checks its database or consults an authoritative source to determine the status of the certificate. The response from the OCSP server indicates whether the certificate is valid, revoked, or unknown.

OCSP responses can include various information, such as the certificate status, the time of the response, and the responder's digital signature to ensure integrity and authenticity. The client can interpret the response to make informed decisions about the trustworthiness of the certificate.

Let's review the SSL certificate for our blog (norateck blog). When you access the website using a browser, you will observe a secure padlock or lock icon, indicating that the website has SSL protection (HTTPS). In the certificate details, you will find the Authority Information Access section, which includes the OCSP responder URL.

To begin, copy the CA issuer URI:

http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt. Next, locate the export button in the provided image, which enables you to download the background certificate. Once downloaded, you can proceed with executing the OpenSSL command for further actions.

openssl ocsp -issuer http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt -cert noratech.blog.cer -url http://ocsp.sectigo.com -resp_text

The output shows some information along with :

Response verify OK

That's it!

In conclusion, the process of verifying certificates is crucial for maintaining a secure and trustworthy digital environment. By understanding the significance of OCSP, CRL, and the concept of certificate revocation, as well as the role of Validation Authorities, we can enhance our ability to validate certificates effectively. Leveraging the capabilities of OpenSSL, a powerful and widely-used open-source tool, further empowers us to perform certificate verification using OCSP and CRL.