Enabling OCSP server stapling

System SSL allows server applications the ability to supply the OCSP response for the server's end entity certificate or the server's certificate chain if the client indicates support for this capability during the TLS handshake. This is commonly referred to as OCSP stapling as the OCSP responses for the server's end entity certificate or server's certificate chain are attached to a handshake message. The client then parses the OCSP responses to determine the revocation status of the server's certificates to determine if the handshake should continue.

The GSK_SERVER_OCSP_STAPLING attribute type or environment variable on the gsk_attribute_set_enum() routine enables the OCSP stapling support in the server. When enabled, OCSP stapling support allows the server to query the OCSP responder for the revocation status of the server's end entity certificate or the server's certificate chain. See the description of the GSK_SERVER_OCSP_STAPLING attribute type in gsk_attribute_set_enum() or the environment variable in Environment variables.

If the server application is enabled for OCSP stapling, OCSP support must be enabled with the GSK_OCSP_URL or the GSK_OCSP_ENABLE environment variables or attribute types so that certificate revocation information can be retrieved from the OCSP responder.

All existing OCSP-related configuration options play a role in the OCSP stapling support. For example, the GSK_OCSP_CLIENT_CACHE_SIZE attribute type or environment variable indicates the size of the OCSP cache for the OCSP responses for the server's end entity certificate or the server's certificate chain and also any client certificates that are received during the TLS handshake. The OCSP response that is retrieved for the server's end entity certificate or the server's certificate chain when OCSP stapling is enabled follows the same basic expiration rules that are described in OCSP response caching

System SSL accepts the following OCSP-related options on the server side when enabled for OCSP stapling:
  • GSK_MAX_SOURCE_REV_EXT_LOC_VALUES
  • GSK_MAX_VALIDATION_REV_EXT_LOC_VALUES
  • GSK_OCSP_CLIENT_CACHE_ENTRY_MAXSIZE
  • GSK_OCSP_CLIENT_CACHE_SIZE
  • GSK_OCSP_ENABLE
  • GSK_OCSP_PROXY_SERVER_NAME
  • GSK_OCSP_PROXY_SERVER_PORT
  • GSK_OCSP_REQUEST_SIGALG
  • GSK_OCSP_REQUEST_SIGKEYLABEL
  • GSK_OCSP_RESPONSE_TIMEOUT
  • GSK_OCSP_RETRIEVE_VIA_GET
  • GSK_OCSP_URL
  • GSK_OCSP_URL_PRIORITY

For example, the GSK_OCSP_CLIENT_CACHE_SIZE setting indicates the total number of cached entries that can be stored in the OCSP cache on the server side. In other words, the OCSP cache can contain the OCSP responses for the server's certificate chain and the OCSP responses for the client's certificates if enabled for client authentication.

The following OCSP-related options are ignored when OCSP stapling is enabled:
  • GSK_OCSP_MAX_RESPONSE_SIZE
  • GSK_OCSP_NONCE_CHECK_ENABLE
  • GSK_OCSP_NONCE_GENERATION_ENABLE
  • GSK_OCSP_NONCE_SIZE
  • GSK_OCSP_RESPONSE_SIGALG_PAIRS
  • GSK_REVOCATION_SECURITY_LEVEL

System SSL applications can query the GSK_TLSEXT_SERVER_OCSP_STAPLING attribute type on the gsk_attribute_get_enum() routine to determine if OCSP stapling support has been negotiated between the client and server. For more information, see GSK_TLSEXT_SERVER_OCSP_STAPLING.

Start of changeIf a TLS V1.2 and earlier handshake is negotiated, theEnd of change OCSP response for the server's end entity certificate and the OCSP responses for the server's certificate chain are sent from the server to the client in the CERTIFICATE-STATUS message. If the server is unable to retrieve a valid OCSP response for the server's certificate from the OCSP responder, the OCSP response in the CERTIFICATE-STATUS message is empty. In this case, it is up to the client to determine whether to continue the handshake or not.

Start of changeIf a TLS V1.3 handshake is negotiated, the OCSP response for the server’s end entity certificate is sent from the server to the client in the Certificate Status Request extension in the server’s CERTIFICATE message. If the server is unable to retrieve a valid OCSP response for the server's certificate from the OCSP responder, the Certificate Status Request extension is not sent for the server’s end entity certificate.End of change

For OCSP server stapling, System SSL will not query an OCSP responder in the following cases:

  • Start of changeThe server's certificate is a self-signed certificate. If the negotiated protocol is TLS V1.2 and earlier, a CERTIFICATE-STATUS message is not sent to the client. If the negotiated protocol is TLS V1.3, the Certificate Status Request extension is not sent for that certificate.End of change
  • The key repository does not contain the issuing certificate.
  • Start of changeIf the negotiated protocol is TLS V1.2 and earlier and the server's key repository does not have the issuing certificate for the end entity certificate, the CERTIFICATE-STATUS message is not sent to the client. If the intermediate certificate authority's issuing certificate is missing, the OCSP responder is not contacted and the CERTIFICATE-STATUS message contains an empty OCSP response for that certificate.End of change
  • Start of changeIf the negotiated protocol is TLS V1.3 and the server's key repository does not have the issuing certificate for the end entity certificate, the Certificate Status Request extension is not sent for that certificate.End of change

System SSL applications can query the GSK_SERVER_OCSP_STAPLING_CERTSTATUS attribute type on the gsk_attribute_get_enum() routine to determine whether a CERTIFICATE-STATUS message Start of changeor a Certificate Status Request extension in the CERTIFICATE message containing the OCSP responseEnd of change is sent to the client. For more information, see GSK_SERVER_OCSP_STAPLING_CERTSTATUS.