X.500 Standard status
(Implementors' Guide)

X.509 Related activities

How to be involved

More Information

Tutorial section 1
X.500 General

Tutorial section 2
X.509 specific

Other PKI organizations

edit SideBar


Online Certificate Status Protocol (OCSP)

The Online Certificate Status Protocol (OCSP) is specified in RFC 2560. It is part of the work performed by the PKIX group. A Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments is defined in RFC 5019.

OCSP may be used to retrieve revocation status of one or more certificates. This is an alternative to retrieving Certificate Revocation Lists (CRLs).

OCSP request/response flow
Figure 1 - OCSP request/response flow

An entity that relies on the content of a certificate (a relying party) needs to do some checking before possibly accepting the certificate as being valid. One check is to verify that the certificate has not been revoked. OCSP is a request/response protocol where an OCSP client retrieves certificate revocation status from an OSCP responder.

Figure 1 illustrates such retrieval. For example, the OCSP client may be a Web browser that needs to check the validity of a certificated provided by a Web server. This will typically be a certificated issued to use by the Transport Layer Security (TLS).

The responder may be the CA that have issued certificates or the CA may have delegated the responsibility to some other entity. In this case, the Extended key usage extension shall be included in a public-key certificate issued by the CA to that entity. The object identifier:

 {iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) keyPurpose(3) ocspSigning(9)}

shall be specified in the extension.

The private key associated with that public-key certificate shall be used for signing the OCSP response.

When a CA in this way supports OCSP access to certificate status, it must include the Authority Information Access extension in the certificates it issues.


OCSP request
Figure 2 - OCSP request

An OCSP request consists of some general components and some components repeated for each certificate for which status is requested.



So far, only one version has been defined. It is called version 1 and it is also the default if the component is not included.

Requestor name

The name of the requestor is a so-called GeneralName. It can be either of the name forms listed in the Subject alternative name extension on the X.509 Extensions page.

Request extensions

The nonce extension and the acceptableResponses are candidates here.

Requestor's signature

The requestor may choose to sign the request. The signature consists of the signature algorithm, the signature itself, and optionally certificates necessary to verify the signature.


Hashed CA information

This part consists of the following three mandatory components:

  • A hashing algorithm identifier to be used for the following two component.
  • A hash of the issuer's directory distinguished name.
  • A hash of the issuer's public key.

Serial number

This is the serial number of the certificate for which status information is requested.

Single request extensions

Any of the CRL entry extensions listed on the X.509 Extensions page may be included here. In addition, the serviceLocator extension may also be included.


OCSP response
Figure 3 - OCSP response


Response status

This component indicates whether the request was accepted or not. If not, the result of retrieval is an error message. The requestor may not be authorised to make the request, the request may be badly formatted, the request should be signed, etc. In this case, only the response status component is returned, while the reaming components in figure 3 are absent.

Response type

The OCSP allows for several different response types. However, the Basic Response Type is the only response type presently defined. It is this response type that is reflected here.


Version 1 is specified here or assumed by default.

Responder ID

The responder ID may either be a directory distinguished name or it may the SHA-1 hash value of the responder's public key.

Production time

The production time is the time when the response was prepared and signed by the responder.

Response extensions

The nonce extension may be included here.

Responder's digital signature

The response shall be signed by the responder.


Hashed CA information

This part consists of the same three mandatory components as required in the request.

Serial number

This is the serial number of the certificate for which status information is returned.

Certificate status

The status component may take one of three values:

  • good - This status indicates the certificate has not been revoked.
  • revoked - This status indicates that the certificate has been revoked. This status is follow with information about the time of the revocation. The reason for the revocation may also be indicated.
  • unknown - This status indicates that the certificate is unknown to the OCSP responder.

Update time(s)

There two update times defined:

  • thisUpdate - This is the time where the status is known to be correct. A responder may not hold its information continuously updated. It may at time intervals retrieve updated status information from relevant CRLs.
  • nextUpdate - This is the time where the responder will retrieve updated status information. If this component is not present, it indicates that the responder always holds up-to-date status information.

Single response extensions

Any of the CRL entry extensions listed on the X.509 Extensions page may be included here. In addition, archiveCutoff may be included.


Nonce extension

The nonce extension allows the requestor to place some arbitrary information in this extension. The responder use the same value in a nonce extension in the response. The word "nonce", which seems to be some form of "once", indicates that the same arbitrary value shall only be used once. The purpose is to allow replay attack to be detected.

CRL References extension

This extension allows a responder to specify the location of the CRL, from where the status information is obtained. Such an extension would be part of the single response extensions.

Acceptable response types

This is an extension type to be included in the request extensions. As there is only one response type currently defined, this extension is mostly here for possible future use.

Archive cutoff extension

If a responder retains status information for a retention period after a certificate has expired, it can still tell whether a certificate was revoked during its lifetime if that retention period has not expired.

The cutoff extension is a time value telling how far back from the production time status information is retained. If a digital signature being checked is from before this cutoff value, then the returned status information cannot be used for verifying the signature.

Such an extension, when present, will be a single response extension.

Service locator extension

A requestor may send a request to an OCSP server that the routes the request further on the appropriate OCSP server. The information about this server is provided in this extension.

Such an extension, when present, will be a single request extension.

Page Actions

Recent Changes

Group & Page

Back Links