The Citrix ADC 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 web sites 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.
OCSP stapling solution
To avoid unnecessary congestion, the Citrix ADC appliance now supports OCSP stapling. That is, the appliance can now send the revocation status of a server certificate to a client, at the time of the SSL handshake, after validating the certificate status from an OCSP responder. The revocation status of a server certificate is “stapled” to the response 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.
Citrix ADC appliances support OCSP stapling as defined in RFC 6066.
OCSP stapling is supported only on the front-end of Citrix ADC appliances.
Citrix ADC support for OCSP stapling is limited to handshakes using TLS protocol version 1.0 or higher.
OCSP response caching of server 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 timeout field.)
Note: From release 12.1 build 49.x, you can clear the cached response, of the server certificate, from the OCSP responder even before the timeout expires. Earlier, you could not 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
clear ssl certKey s1 -ocspstaplingCache
To clear the cached status by using the GUI
- In the GUI, navigate to Traffic Management > SSL > Certificates > CA Certificates.
- In the details pane, select a certificate.
- In the Select Action list, select Clear. If 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.
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]
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
Enable OCSP stapling by using the GUI
- Navigate to Traffic Management > SSL > Virtual Server.
- Open a virtual server and, in SSL Parameters, select OCSP Stapling.
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, the Citrix ADC appliance 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.
A manually added OCSP responder takes precedence over a dynamically added responder.
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 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:
- Add a virtual server (VIP1).
- Add issuer certificate (CA1) and bind it to VIP1.
- Add three certificates S1, S2, and S3. Internal responders resp1, resp2, and resp3 respectively are created by default.
- Bind S3 to VIP1.
- 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 CA. 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.
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>]
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
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
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: 22.214.171.124 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
- Navigate to Traffic Management > SSL > OCSP Responder, and configure an OCSP responder.
- Navigate to Traffic Management > SSL > Certificates, select a certificate, and in the Action list, select OCSP Bindings. Bind an OCSP responder.
- Navigate to Traffic Management > Load Balancing > Virtual Servers, open a virtual server, and click in the Certificates section to bind a CA certificate.
- Optionally, select select OCSP Mandatory.
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.