The OCSP (Online Certificate Status Protocol) is one of the two ways for obtaining the revocation status of X.509 digital certificate (e.g. SSL & code-signing certificates) and hence maintains the security of a server or other network resource. The other older mechanism, which OCSP has superseded, is known as “CRL (Certificate Revocation List).”
OCSP overcomes the chief limitation of CRL: the fact that updates must be frequently downloaded to keep the list current at the client end. When a user attempts to access a server, the OCSP sends a request for certificate status information. The server sends back a response of "Success", “Unauthorized”, "Malformed Request” or "Try Later". The protocol specifies the syntax for communication between the server (which contains the certificate status) and the client application (which is informed of that status. OCSP responses contain less information than a CRL so it puts less burden on the network and the calling resources.
An OCSP request is a signed message. It consists mainly of two components: a request body, and an optional signature block. The request body contains one or multiple certificate status requests. The body consists of the following fields:
Version – OCSP Request version number. It is default to v1.
Requestor name – optional field
One or more requests – web server only include one certificate status request per OCSP request message.
Extensions – This optional field to include extra information which may be communicated between the client and the OCSP server, such as the expected OCSP response message type from the client, nonce, or archive cutoff date, etc.
Of all these components, the most important component is the certificate status request structure. It consists of the following:
HashAlgorithm – this field specifies the digest algorithm, which is used to digest the CA, subject DN or CA key.
IssuerNameHash – digest of the EE’s CA subject DN
IssuerKeyHash – digest of the EE’s CA public key or a unique key identifier
SerialNumber – EE certificate serial number
The combination of the SerialNumber and the IssuerNameHash or the SerialNumber and the IssuerKeyHash uniquely identifier the EE certificate signed by the CA.
How did Symantec improve OCSP Performance?
Origin Server: Symantec built a highly efficient and responsive OCSP infrastructure.
CDN: Symantec worked with a CDN to make their EdgeServer OCSP aware and able to read the ASN.1 request and response package.
If the response for a requested cert is found in CDN cache, it'll be returned from the cache.
If a response can't be found in cache, a request will be sent to origin server (Symantec OCSP responder) to retrieve the response and stored in cache for later lookup.
Symantec built an OCSP responder to handle any cache miss requests.
What is the Net Result?
The result of our work is that we have become the fastest within the industry. When one adds together the average speeds of our competitors you can see how fast Symantec really is. The other thing to note is not only is there a massive difference in speed but also a difference in regularity. Certain days will have more or less demand on the OCSP infrastructure than others, but ultimately, Symantec’s speed is far more consistent that the wild ups and downs of other CAs trying to keep pace with the demands of a modern internet.
Do you want to go faster?
If speed is important to your organization then why not consider using ECC SSL certificates? The majority of SSL certificates used today are based on RSA, an aging algorithm. ECC is the next generation; it uses tighter math and therefore runs more efficiently than RSA. This allows a server to run more sessions with one company reporting a 46% drop in CPU utilization and a 7% improvement in server response times.