OCSP stapling

Last published : Sep 24, 2026
NetScaler implementation of CRL and OCSP reports the revocation status of client certificates only. To check the revocation status of a server certificate received during an SSL handshake, a client must send a request to a certificate authority.
For websites with heavy traffic, many clients receive the same server certificate. If each client sent a query for the revocation status of the server certificate, the certificate authority would be inundated with OCSP requests to check the validity of the certificate.
Related information

OCSP stapling solution

To avoid unnecessary congestion, NetScaler supports OCSP stapling. That is, at the time of the SSL handshake, the appliance can now send the status of a server certificate to a client after validating the response from an OCSP responder. The status of a server certificate is "stapled" to the certificate that the appliance sends to the client as part of the SSL handshake. To use the OCSP stapling feature, you must enable it on an SSL virtual server and add an OCSP responder on the appliance.
Notes:
  • All the intermediate certificates include the OCSP response extension when the following conditions are met:
    • TLS 1.3 protocol is used
    • Client sends a status request
    Earlier, only the server certificate included this extension in the response to the status request from the client.
  • With the other protocols (including TLS 1.2), the server sends the OCSP response for only the server certificate. That is, RFC 6961 is not supported with the TLS 1.2 protocol.
  • NetScaler support OCSP stapling as defined in RFC 6066.
  • OCSP stapling is supported only on the front-end of NetScaler.
  • NetScaler behaves as follows when TLS 1.3 protocol is used: If the cached OCSP response is invalid (empty or expired), a request is sent to the OCSP responder but the SSL handshake is completed without waiting for the response. When the response is received, it is cached and is available for future status requests from clients.
    Notes:
    Starting from release 14.1 build 38.x, front-end virtual servers send the requested OCSP status during TLS handshakes when OCSP stapling is enabled. This happens regardless of whether the status is cached or the cache is disabled.
  • NetScaler support for OCSP stapling is limited to handshakes using TLS protocol version 1.0 or higher.

OCSP response caching of server certificates

Note
When the TLS 1.3 protocol is used, the OCSP response is cached for the server certificate and all the intermediate certificates.
During the SSL handshake, when a client requests the revocation status of the server certificate, the appliance first checks its local cache for an entry for this certificate. If a valid entry is found, it is evaluated and the server certificate and its status are presented to the client. If a revocation status entry is not found, the appliance sends a request for the revocation status of the server certificate to the OCSP responder. If it receives a response, it sends the certificate and the revocation status to the client. If the next update field is present in the OCSP response, the response is cached for the configured length of time (value specified in the timeout field.)
Note:
You can clear the cached response, of the server certificate, from the OCSP responder even before the timeout expires. In release 12.1 build 49.x and earlier, it was not possible to discard the cached status in the certificate-key pair until the configured timeout was over.
To clear the cached status by using the CLI, at the command prompt, type:
clear ssl certKey <certkey name> -ocspstaplingCache
Example:
clear ssl certKey s1 -ocspstaplingCache
To clear the cached status by using the GUI
  1. In the GUI, navigate to Traffic Management > SSL > Certificates > CA Certificates.
  2. In the details pane, select a certificate.
  3. In the Select Action list, select Clear. When prompted to confirm, click Yes.

OCSP stapling configuration

Configuring OCSP stapling involves enabling the feature and configuring OCSP. To configure OCSP, you must add an OCSP responder, bind the OCSP responder to a CA certificate, and bind the certificate to an SSL virtual server.
Note:
OCSP responders with only HTTP based URL are supported.

Enable OCSP stapling by using the CLI

At the command prompt, type:
set ssl vserver <name> -ocspstapling [ENABLED | DISABLED]
Example:
set ssl vserver vip1 -ocspStapling ENABLED
Done

sh ssl vserver vip1

     Advanced SSL configuration for VServer vip1:
     DH: DISABLED
     DH Private-Key Exponent Size Limit: DISABLED Ephemeral RSA: ENABLED Refresh Count: 0
     Session Reuse: ENABLED Timeout: 120 seconds
     Cipher Redirect: DISABLED
     SSLv2 Redirect: DISABLED
     ClearText Port: 0
     Client Auth: DISABLED
     SSL Redirect: DISABLED
     Non FIPS Ciphers: DISABLED
     SNI: ENABLED
     OCSP Stapling: ENABLED
     SSLv2: DISABLED SSLv3: DISABLED TLSv1.0: ENABLED  TLSv1.1: ENABLED  TLSv1.2: ENABLED
     Push Encryption Trigger: Always
     Send Close-Notify: YES

     ECC Curve: P_256, P_384, P_224, P_521

    1) CertKey Name: server_certificate1 Server Certificate

    1) Cipher Name: DEFAULT
     Description: Default cipher list with encryption strength >= 128bit
Done
Note: If the default (enhanced) profile is enabled, use the set ssl profile <profile name> -ocspStapling [ENABLED | DISABLED] command to enable or disable OCSP.

Enable OCSP stapling by using the GUI

  1. Navigate to Traffic Management > SSL > Virtual Server.
  2. Open a virtual server and, in SSL Parameters, select OCSP Stapling.

OCSP configuration

An OCSP responder is added dynamically or manually to send OCSP stapling requests. An internal responder is dynamically added when you add a server certificate and its issuer certificate based on the OCSP URL in the server certificate. A manual OCSP responder is added from the CLI or GUI. To send an OCSP request for a server certificate, NetScaler selects an OCSP responder based on the priority assigned to it when binding it to an issuer certificate. If a responder fails to send an OCSP stapling request, the responder with the next highest priority is selected for sending the request. For example, if only one responder is manually configured and it fails and a dynamically bound responder exists, it is selected for sending the OCSP request.
If the OCSP URL is other than HTTP, an internal OCSP responder is not created.
Notes:
  • A manually added OCSP responder takes precedence over a dynamically added responder.
  • NetScaler uses the SNIP to communicate with the OCSP server.

Difference between a manually created OCSP responder and an internally created OCSP responder
Manually created OCSP responder Internally (dynamically) created OCSP responder
Created manually and explicitly bound to the issuer certificate with a priority. Created and bound by default, while adding a server certificate and its issuer certificate (CA certificate). Name starts with “ns_internal_”.
Priority between 1 and 127 is reserved for a configured responder. Priority is automatically assigned from 128 onwards.
URL and batching depth can be changed. URL and batching depth cannot be changed.
Deleted directly. Deleted only when you delete the server certificate or the CA certificate.
Can be bound to any CA certificate. Bound by default to one CA certificate. Cannot be bound to any other CA certificate.
Saved in the configuration (ns.conf). Add commands are not saved in the configuration. Only set commands are saved.
If you bind three OCSP responders to the same issuer certificate with priorities 1, 2, and 3 respectively, and later unbind priority 2, the other priorities are not affected. Three OCSP responders are automatically bound to an issuer certificate with priorities 128, 129, and 130 respectively. If you remove the server certificate that was used to create a responder bound with priority 129, then that responder is deleted. Also, the priority for the next responder (priority 130) is automatically changed to 129.
Example of request handling:
  1. Add a virtual server (VIP1).
  2. Add issuer certificate (CA1) and bind it to VIP1.
  3. Add three certificates S1, S2, and S3. Internal responders resp1, resp2, and resp3 respectively are created by default.
  4. Bind S3 to VIP1.
  5. A request comes to VIP1. Responder resp3 is selected.
To create an internal OCSP responder dynamically, the appliance needs the following:
  • Certificate of the issuer of the server certificate (usually the CA certificate).
  • Certificate-key pair of the server certificate. This certificate must contain the OCSP URL provided by the certificate authority. The URL is used as the name of the dynamically added internal responder.
An internal OCSP responder has the same default values as a manually configured responder.
Note:
Caching is disabled by default on an internal responder. Use the set ssl ocspResponder command to enable caching.

Configure OCSP by using the CLI

At the command prompt, type the following commands to configure OCSP and verify the configuration:
add ssl certKey <certkeyName> (-cert <string> [-password]) [-key <string> | -fipsKey <string> | -hsmKey <string>] [-inform <inform>] [-expiryMonitor ( ENABLED | DISABLED ) [-notificationPeriod <positive_integer>]] [-bundle ( YES | NO )]

add ssl ocspResponder <name> -url <URL> [-cache ( ENABLED | DISABLED )[-cacheTimeout <positive_integer>]] [-resptimeout <positive_integer>] [-responderCert <string> | -trustResponder] [-producedAtTimeSkew <positive_integer>][-signingCert <string>][-useNonce ( YES | NO )][ -insertClientCert ( YES | NO )]

bind ssl certKey [<certkeyName>] [-ocspResponder <string>] [-priority <positive_integer>]

show ssl ocspResponder [<name>]
Parameters:
httpMethod:
HTTP method used to send OCSP requests. For requests, less than 255 bytes long, you can configure the HTTP GET method for queries to an OCSP server. If you specify the GET method but the length is greater than 255 bytes, the appliance uses the default method (POST).
Possible values: GET, POST
Default value: POST
ocspUrlResolveTimeout:
Time, in milliseconds, to wait for an OCSP URL resolution. After this time elapses, the responder with the next higher priority is selected. If all the responders fail, an error message appears or the connection is dropped, depending on the settings on the virtual server.
Minimum value: 100
Maximum value: 2000
Example:
add ssl certkey root_ca1 –cert root_cacert.pem
add ssl ocspResponder ocsp_responder1 -url "http:// www.myCA.org:80/ocsp/" -cache ENABLED -cacheTimeout 30  -resptimeout 100 -responderCert responder_cert -producedAtTimeSkew 300 -signingCert sign_cert  -insertClientCert YES
bind ssl certKey root_ca1 -ocspResponder ocsp_responder1 -priority 1
sh ocspResponder ocsp_responder1
    1)Name: ocsp_responder1
    URL: http://www.myCA.org:80/ocsp/, IP: 192.128.22.22
    Caching: Enabled        Timeout: 30 minutes
    Batching: 8 Timeout: 100 mS
    HTTP Request Timeout: 100mS
    Request Signing Certificate: sign_cert
    Response Verification: Full, Certificate: responder_cert
    ProducedAt Time Skew: 300 s
    Nonce Extension: Enabled
     Client Cert Insertion: Enabled
    Done

show certkey root_ca1
    Name: root_ca1     Status: Valid,   Days to expiration:8907
    Version: 3
    …
    1)  OCSP Responder name: ocsp_responder1     Priority: 1
    Done

Modify OCSP by using the CLI

You cannot modify the name of an OCSP responder, but you can use the set ssl ocspResponder command to change any of the other parameters.
At the command prompt, type the following commands to set the parameters and verify the configuration:
set ssl ocspResponder <name> [-url <URL>] [-cache ( ENABLED | DISABLED)] [-cacheTimeout <positive_integer>]  [-resptimeout <positive_integer>] [ -responderCert <string> | -trustResponder][-producedAtTimeSkew <positive_integer>][-signingCert <string>] [-useNonce ( YES | NO )]

unbind ssl certKey [<certkeyName>] [-ocspResponder <string>]

bind ssl certKey [<certkeyName>] [-ocspResponder <string>] [-priority <positive_integer>]

show ssl ocspResponder [<name>]

Configure OCSP by using the GUI

  1. Navigate to Traffic Management > SSL > OCSP Responder, and configure an OCSP responder.
  2. Navigate to Traffic Management > SSL > Certificates, select a certificate, and in the Action list, select OCSP Bindings. Bind an OCSP responder.
  3. Navigate to Traffic Management > Load Balancing > Virtual Servers, open a virtual server, and click in the Certificates section to bind a CA certificate.
  4. Optionally, select OCSP Mandatory.
Note:
The insert client certificate parameter in the add ssl ocspResponder and the set ssl ocspResponder commands is no longer valid. That is, the parameter is ignored during configuration.