Squoggle

Mac's tech blog

Monthly Archives: December 2022

Online Certificate Status Protocol (OCSP)

Online Certificate Status Protocol (OCSP) is an alternative method to Certificate Revocation Lists (CRLs) used to check the validity of digital certificates in a public key infrastructure (PKI).

When a user encounters a digital certificate, their software can use OCSP to send a request to the certificate authority (CA) to check the current status of the certificate. The CA responds to the request with one of three responses: “good”, “revoked”, or “unknown”.

If the response is “good”, the user’s software can proceed with the transaction or access to the resource protected by the certificate. If the response is “revoked”, the software rejects the certificate as invalid. If the response is “unknown”, the software may require additional steps to verify the validity of the certificate.

Unlike CRLs, which can become large and unwieldy as the number of revoked certificates increases, OCSP allows for more efficient and timely checking of individual certificates. However, it requires a constant connection to the CA to receive real-time status updates and can be subject to performance and privacy concerns.

The Good about OCSP

  • Real-time validation: OCSP provides real-time validation of certificates, so users can immediately determine whether a certificate is valid or not.
  • Smaller and more efficient: OCSP responses are typically smaller and more efficient than certificate revocation lists (CRLs), especially for large PKIs with many revoked certificates.
  • Reduced latency: OCSP can reduce latency by eliminating the need for users to download and parse large CRL files.
  • More privacy-friendly: OCSP can be more privacy-friendly than CRLs, as it doesn’t require users to download a complete list of revoked certificates and associated information.

The Bad about OCSP

  • Increased network traffic: OCSP requires users to contact the certificate authority (CA) server each time a certificate is validated, which can increase network traffic and cause performance issues.
  • Single point of failure: OCSP relies on a single CA server for validation, so if the server goes down or experiences issues, users may be unable to validate certificates.
  • Reduced reliability: OCSP may be less reliable than CRLs in certain situations, such as when there are issues with the CA’s OCSP server or network connectivity.
  • Potential privacy concerns: While OCSP can be more privacy-friendly than CRLs, it still allows the CA to track which certificates are being validated and when, which may be a concern for some users.

Check the OCSP status of a Certificate

You can check an Online Certificate Status Protocol (OCSP) response with OpenSSL using the openssl ocsp command. Here is an example command:

openssl ocsp -issuer issuer_cert.pem -cert certificate.pem -url http://ocsp.server.com -text

This command checks the status of the certificate in certificate.pem by sending an OCSP request to the server at http://ocsp.server.com. The issuer_cert.pem file is the certificate of the issuer that signed the certificate.pem file. The -text option displays the response in human-readable text.

After running the command, you will receive an OCSP response that includes the status of the certificate. If the status is “good”, the certificate is valid. If the status is “revoked”, the certificate has been revoked by the issuer. If the status is “unknown”, the server was unable to provide a definitive response for the certificate.

Get the Certificate from a Site:

Lets use google.com as an example.

Get the Certificate for google.com and save it to a file named certificate.pem:

openssl s_client -connect google.com:443 -showcerts /dev/null | sed -n '/Certificate/,/-----END CERTIFICATE-----/p' | tail -n +3 > certificate.pem

Get the Issuing Cert from a Site:

Get the issuing certificate for google.com and save it to a file named issuer.pem:

openssl s_client -connect google.com:443 -showcerts /dev/null | sed -n '/1 s:/,/-----END CERTIFICATE-----/p' | tail -n +3 > issuer.pem

Extract the OCSP URL from the Certificate:

Use OpenSSL to get the OCSP URL from the Certificate and save it to a variable name ocspurl:

ocspurl=$(openssl x509 -in certificate.pem -noout -text | grep "OCSP" | cut -f2,3 -d:)

Test the OCSP Status of the Certificate:

Check the status of the OCSP status of the certificate using the ocsp flag to OpenSSL like this:

openssl ocsp -issuer issuer.pem -cert certificate.pem -url $ocspurl -text

You should get a response that looks something like this:

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 12D78B402C356206FA827F8ED8922411B4ACF504
          Issuer Key Hash: A5CE37EAEBB0750E946788B445FAD9241087961F
          Serial Number: 0CD04791FC985ABB27E20A42A232FDF5
    Request Extensions:
        OCSP Nonce: 
            0410CD24FED402FF2B1D2331485C81AD1C21
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: A5CE37EAEBB0750E946788B445FAD9241087961F
    Produced At: Apr 26 00:54:27 2023 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 12D78B402C356206FA827F8ED8922411B4ACF504
      Issuer Key Hash: A5CE37EAEBB0750E946788B445FAD9241087961F
      Serial Number: 0CD04791FC985ABB27E20A42A232FDF5
    Cert Status: good
    This Update: Apr 26 00:39:01 2023 GMT
    Next Update: May  2 23:54:01 2023 GMT

    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:20:45:c2:eb:e2:54:23:2a:c5:49:47:c2:f0:0b:cf:
         8d:06:6d:17:62:26:2e:4a:ba:8e:cd:61:bf:dd:af:e8:ea:cb:
         02:21:00:94:bd:5c:33:e7:ac:20:50:d4:15:45:9e:d8:8d:75:
         1a:fb:c5:95:5f:11:c7:b2:88:47:0a:5b:56:d0:3c:89:b5
WARNING: no nonce in response
Response verify OK
certificate.pem: good
	This Update: Apr 26 00:39:01 2023 GMT
	Next Update: May  2 23:54:01 2023 GMT

OpenSSL OCSP Commands Documentation

Online Certificate Status Protocol command

https://www.openssl.org/docs/man3.0/man1/openssl-ocsp.html

Certificate Revocation List (CRL)

Certificate Revocation Lists (CRLs) are used in public key infrastructure (PKI) to identify digital certificates that have been revoked by the certificate authority (CA) before their expiration date.

When a CA revokes a digital certificate, it adds the certificate’s serial number to the CRL. The CRL is then distributed to users who rely on the PKI, such as web browsers and other software that verify digital certificates.

When a user encounters a digital certificate that has been revoked, their software checks the CRL to confirm that the certificate is no longer valid. If the certificate’s serial number is listed on the CRL, the software will reject the certificate and prevent the user from accessing the website or resource protected by the certificate.

CRL Expiration

The client typically gets a new Certificate Revocation List (CRL) from the Certificate Authority (CA) when the existing CRL expires or when there have been changes to the status of certificates that have been revoked.

When a CA revokes a digital certificate, it adds the certificate’s serial number to the CRL. The CRL contains a list of all the revoked certificates, along with their revocation status and the reason for revocation.

The CRL has an expiration date and time, after which it is no longer considered valid. The expiration date is typically set by the CA when the CRL is issued, and it is usually a few days to a few weeks after the issue date. When the CRL is about to expire, the client will check with the CA to obtain a new CRL that is valid for the next period.

In addition to the expiration date, the client may also obtain a new CRL if there are changes to the revocation status of certificates that have been previously listed in the CRL. This can happen if a certificate that was previously revoked is now reinstated, or if a certificate that was previously valid is now revoked.

The client can obtain a new CRL from the CA via various means, such as through online updates or downloads. Some PKIs also use alternative methods of certificate revocation, such as Online Certificate Status Protocol (OCSP), which can provide real-time updates on the status of certificates.

The Good about CRL

  • Offline validation: CRLs can be downloaded and stored offline, allowing users to validate certificates even when they are not connected to the network.
  • No single point of failure: Unlike OCSP, CRLs don’t rely on a single server for validation, so they are less susceptible to single points of failure.
  • Better reliability: CRLs may be more reliable than OCSP in certain situations, such as when the CA’s OCSP server or network connectivity is experiencing issues.
  • Can cover multiple certificates: A single CRL can cover multiple certificates, reducing the amount of data that needs to be downloaded and parsed.

The Bad about CRL

  • Larger size: CRLs can become large and unwieldy as the number of revoked certificates increases, leading to longer download times and increased storage requirements.
  • Increased latency: CRLs can introduce latency into the certificate validation process, as users must download and parse the entire CRL before they can validate a certificate.
  • May be outdated: CRLs are typically updated on a periodic basis, so there is a risk that a certificate may have been revoked between updates and the user may not be aware of it.
  • May present a privacy risk: CRLs can potentially expose information about revoked certificates, which could be used by attackers to gather information about a PKI.

Overall, CRLs can be an effective means of validating certificates in a PKI, especially in situations where offline validation is important or when the number of revoked certificates is relatively small. However, they also have some drawbacks that should be considered, such as larger size, increased latency, and potential privacy risks.

Delta CRL

A Delta Certificate Revocation List (CRL) is a type of CRL that contains only the revoked certificates that have been added or changed since the previous CRL was issued. The Delta CRL is meant to be used in conjunction with the base CRL, which contains the complete list of revoked certificates.

The Delta CRL is a more efficient way of distributing certificate revocation information, as it contains only the changes to the previous CRL, rather than the entire list of revoked certificates. This can significantly reduce the size of the CRL and the time it takes to download and process it.

To use a Delta CRL, the client first downloads the base CRL, which contains the complete list of revoked certificates. The client then downloads the Delta CRL, which contains only the changes since the previous CRL. The client then merges the Delta CRL with the base CRL to obtain a complete and up-to-date list of revoked certificates.

The use of Delta CRLs can help to improve the efficiency of certificate revocation in large PKIs, especially when the number of revoked certificates is high and changes occur frequently. However, the use of Delta CRLs also requires additional management and coordination between the CA and the client, as both parties must ensure that the Delta CRL is properly applied and merged with the base CRL.

Troubleshooting CRL

Sometimes you may need to troubleshoot certificate issues by examining a CRL (Certificate Revocation List)

Download a CRL

These instructions show how you can easily download a CRL from a website. I’ll use https://duckduckgo.com/ in this example.

  1. Open Google Chrome. Navigate to https://duckduckgo.com/. Notice the padlock in the address bar.
  2. Right click on the padlock in the address bar. Click Connection is secure to see the connection details.
  3. Click Certificate is valid to open the certificate details box. Click the Details tab.
  4. In the Certificate Fields box, scroll down and click on CRL Distribution Points. In the Field Value box you will see any URLs associated with the CRL for the Certificate Authority or the Signing Certificate.
  5. Copy and paste the URL into a new window of the browser. You will be prompted to save the file. In my case I downloaded a file named DigiCertTLSRSASHA2562020CA1-4.crl.

Parse the CRL

  1. Open a terminal in the directory where you saved the CRL.
  2. Check to see if the CRL is in DER format or PEM format. Most CRLs are in DER format. If you do a simple head command on the CRL file you will see if it is a DER (binary) file or a PEM file. If it is binary you will see gibberish. If it is a PEM formatted file you will see ,“BEGIN X509 CRL—–”.
  3. Parse the CRL. If the CRL is in DER format use this syntax:
    openssl crl -inform DER -text -noout -in [crl-file] | less
    If the CRL is in PEM format use this syntax:
    openssl crl -inform PEM -text -noout -in [crl-file] | less
  4. You will see a list of all the revoked certificates that were issued by the Issuing Certificate.

OpenSSL CRL Commands Documentation

The OpenSSL CRL commands official documentation:

https://www.openssl.org/docs/man3.0/man1/openssl-crl.html