Cryptography Series: Online Certificate Status Protocol OCSP Detailed Explanation

Introduction

When we visit web pages, we will deal with various certificates. For example, when visiting https web pages, we need to check the validity of the certificates of https websites.

OCSP is a verification protocol used to obtain the revocation status of an X.509 digital certificate. It appeared to replace CRL.

This article will detail the implementation and advantages of OCSP.

CRL in PKI

We know that in the PKI architecture, the CA certificate is a very important component, and the client uses the CA certificate to verify the reliability of the service. For the CA certificate itself, the expiration time can be specified when it is created. In this way, the certificate cannot be used after it expires, and a new certificate needs to be applied for.

However, it is not enough to specify an expiration time for the certificate. For example, what if we need to revoke the certificate due to business needs?

A mechanism called CRL (certificate revocation list) is provided in PKI to maintain a list of revoked certificates.

This CRL is issued by the CA and is generally generated before the certificate expires. Because if the certificate has expired, then this CRL is meaningless.

For the CRL itself, it is a list of certificates, and the format of the certificates is usually X.509.

The CRL is generally maintained and issued by the CA that issues the certificate. The component that issues the CRL is called the CRL issuer. Generally speaking, the CRL issuer and the CA are the same service, but you can also split the CRL issuer and the CA as needed.

CRLs are issued regularly by the CA. Of course, you can re-issue CRLs when you need to revoke a CA certificate as needed. All CRLs have an expiration time. Within this expiration time, the client can go to the CA to verify the validity of the CRL according to the signature in the CRL, thereby preventing the forgery of the CRL.

Disadvantages of CRL

So what are the disadvantages of CRL?

First of all, the CRL maintains a list of revoked certificates. In order to ensure the validity of the system, the client needs to obtain the CRL from the CA server every time the client verifies the validity of the CA certificate. Then use the CRL to verify the status of the corresponding CA certificate.

If you go to get this CRL every time, you may have the following problems.

The first problem is that if the CRL is unavailable, the client will not be able to get the CRL, and will not be able to verify the status of the CA certificate, making the service unavailable.

Another problem is that if there are many certificates to be revoked, the CRL may be large, resulting in a waste of network resources.

The last problem is that the purpose of the PKI certificate system itself is to establish a security system that can be verified by itself and does not depend on online services. If you need to obtain CRL online every time, you will take advantage of the PKI.

Status of CRL

Although the CRL maintains a list of revoked certificates, the status of certificates in this list varies.

There are two states of the certificate in the CRL. The first is that the certificate has been revoked. For example, the certificate issuing authority CA finds that the previously issued certificate is wrong, or the original certificate is not secure enough due to other reasons such as private key leakage. , the certificate needs to be revoked. Or the certificate authority is revoked due to failure to comply with certain policies, etc., the previous certificate needs to be set to the revoked state.

There is also a state of temporary revocation, called the Hold state here, which indicates that the certificate is temporarily invalid, for example, in the case that the user does not determine whether the private key is lost. When the user finally retrieves the private key, the certificate can still be recovered.

OCSP Workflow

Since CRL has so many shortcomings, an OCSP protocol to replace CRL has emerged.

Let's first look at the workflow of OCSP.

Suppose A and B want to communicate using PKI. In order to ensure the security of communication, A sends its own public key to B, and tells B that this is my public key, and you can use this public key to verify the message I sent to you.

After B receives A's public key, it cannot be sure that A's public key is correct and has not been tampered with. So the serial number is extracted from A's public key, and it is encapsulated into an 'OCSP request' and sent to the CA server.

The OCSP responder in the CA server reads the 'OCSP request' request and extracts the serial number of A's public key. The OCSP responder queries the CA server's database to see if the serial number is on the revoked list in this database.

If it is found not, it means that A's public key is still valid, and the OCSP responder will send a signed OCSP response to B.

B uses the CA server's public key to verify the validity of the OCSP response, thereby confirming that A's public key is still valid.

Finally, B uses A's public key to communicate with A.

Advantages of OCSP

From the above OCSP workflow, we can roughly summarize the following advantages of OCSP over CRL.

First of all, the amount of data responded by OCSP is smaller than that of CRL, so there is less requirement and pressure on the network.

Also, because OCSP responses have less data to parse, OCSP client implementations are simpler than CRLs.

Although CRL is no longer used in the web environment due to various shortcomings, but replaced by the more efficient OCSP, CRL is still used in other environments of CA.

Details of the OCSP protocol

The OCSP protocol is defined in RFC 6960.

The OCSP protocol can be divided into two parts: a request protocol and a response protocol, which will be introduced separately next.

OCSP request

An OCSP request needs to contain the protocol version number, the requested service, the certificate identifier to be verified and optional extensions.

After receiving the OCSP request, the OCSP responder will verify the validity of the OCSP message. If there is a problem with the message, it will return an exception. Otherwise, it will be processed according to the requested service.

If an OCSP request is marked with the ASN.1 (Abstract Syntax Notation One) abstract syntax this can be represented as follows:

 OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

   TBSRequest      ::=     SEQUENCE {
       version             [0]     EXPLICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }
          Signature       ::=     SEQUENCE {
            signatureAlgorithm      AlgorithmIdentifier,
            signature               BIT STRING,
            certs               [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL}

   Version         ::=             INTEGER  {  v1(0) }

   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of issuer's public key
       serialNumber        CertificateSerialNumber }

ASN.1 is an interface description language. Through ASN.1, we can clearly describe the format information of data.

An OCSPRequest consists of an optional signature OCSP request tbsRequest and a corresponding signature optionalSignature.

The TBSRequest contains the version number, the name of the OCSP requestor, the status list requestList of the certificate, and optional extended data.

OCSP response

For the OCSP response, its structure is different depending on the transport protocol. But all responses SHOULD contain a responseStatus field indicating the processing status of the request.

OCSP responses are represented in ASN.1 format as follows:

 OCSPResponse ::= SEQUENCE {
      responseStatus         OCSPResponseStatus,
      responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

   OCSPResponseStatus ::= ENUMERATED {
       successful            (0),  -- Response has valid confirmations
       malformedRequest      (1),  -- Illegal confirmation request
       internalError         (2),  -- Internal error in issuer
       tryLater              (3),  -- Try again later
                                   -- (4) is not used
       sigRequired           (5),  -- Must sign the request
       unauthorized          (6)   -- Request unauthorized
   }

      ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       OCTET STRING }

responseStatus is the status of the response, and responseBytes is an optional response result.

The response here is the DER encoding of a BasicOCSPResponse object:

 BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs            [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

OCSP stapling

It can be seen that OCSP requires the client to request the OCSP responder to confirm the validity of the certificate when it needs to check whether the certificate is revoked.

But this method actually leaks the user's private information, because the OCSP responder knows the certificate that the client needs to verify, and it knows the website the client is visiting.

So OCSP stapling was introduced to solve this problem.

So what is OCSP stapling?

OCSP stapling is to directly put the OCSP certificate on the web server to be accessed by the client. Because the OCSP certificate is timestamped and digitally signed, its correctness can be guaranteed.

These OCSP certificates are included in the OCSP response when the client and the web side establish the SSL handshake.

In this way, the client does not need to establish an additional connection with the CA separately, thereby improving performance.

OCSP stapling needs to be actively enabled on the server side.

If you are using an apache server, first you need a version greater than 2.3.3.

Then you need to add it outside the <VirtualHost></VirtualHost> block in the .conf file:

 SSLStaplingCahe shmcb: /tmp/stapling_cache(128000)

Then inside the <VirtualHost></VirtualHost> block add:

 SSLUseStapling On

If you are using nginx, first you need a version greater than 1.3.7.

Then add in the nginx configuration file server {} block:

 ssl_stapling on;
ssl_stapling_verify on;

If you want to verify whether a website has OCSP stapling enabled, you can check it at https://entrust.ssllabs.com/ :

In this website, you can enter any website address you want to query, and then you can get the following information:

You can see that this website has OCSP stapling enabled.

Summarize

OCSP and OCSP stapling are very useful certificate revocation verification protocols that are widely used. You can check to see if your website is useful.

For more information, please refer to http://www.flydean.com/43-pki-ocsp/

The most popular interpretation, the most profound dry goods, the most concise tutorials, and many tricks you don't know are waiting for you to discover!

Welcome to pay attention to my official account: "Program those things", understand technology, understand you better!