Certificate revocation lists

From time to time, Certificate Authorities (CAs) issue certificate revocation lists (CRLs). CRLs contain information about certificates that can no longer be trusted. For example, suppose Ann leaves XYZ Corporation. The company can place Ann’s certificate on a CRL to prevent her from signing messages with that key.

Similarly, you can revoke a certificate if a private key is compromised or if that certificate expired and a new one is in use. Before you trust a public key, make sure that the certificate does not appear on a CRL.

NetScaler Gateway supports the following two CRL types:

• CRLs that list the certificates that are revoked or are no longer valid
• Online Certificate Status Protocol (OSCP), an Internet protocol used for obtaining the revocation status of X.509 certificates

To add a CRL:

Before you configure the CRL on the NetScaler Gateway appliance, make sure that the CRL file is stored locally on the appliance. In the case of a high availability setup, the CRL file must be present on both NetScaler Gateway appliances, and the directory path to the file must be the same on both appliances.

If you need to refresh the CRL, you can use the following parameters:

• CRL Name: The name of the CRL being added on the NetScaler. Maximum 31 characters.
• CRL File: The name of the CRL file being added on the NetScaler. The NetScaler looks for the CRL file in the /var/netscaler/ssl directory by default. Maximum 63 characters.
• URL: Maximum 127 characters
• Base DN: Maximum 127 characters
• Bind DN: Maximum 127 characters
• Password: Maximum 31 characters
• Days: Maximum 31

1. In the configuration utility, on the Configuration tab, expand SSL and then click CRL.
2. In the details pane, click Add.
3. In the Add CRL dialog box, specify the values for the following:
   • CRL Name
   • CRL File
   • Format (optional)
   • CA Certificate (optional)
4. Click Create and then click Close. In the CRL details pane, select the CRL that you configured and verify that the settings that appear at the bottom of the screen are correct.

To configure CRL autorefresh by using LDAP or HTTP in the GUI:

A CRL is generated and published by a CA periodically or, sometimes, immediately after a particular certificate is revoked. Citrix recommends that you update CRLs on the NetScaler Gateway appliance regularly for protection against clients trying to connect with certificates that are not valid.

The NetScaler Gateway appliance can refresh CRLs from a web location or an LDAP directory. When you specify refresh parameters and a web location or an LDAP server, the CRL does not have to be present on the local hard disk drive at the time you run the command. The first refresh stores a copy on the local hard disk drive, in the path specified by the CRL File parameter. The default path for storing the CRL is /var/netscaler/ssl.

CRL refresh parameters

• CRL Name

  The name of the CRL being refreshed on the NetScaler Gateway.

• Enable CRL Auto Refresh

  Enable or disable CRL auto refresh.

• CA Certificate

  The certificate of the CA that has issued the CRL. This CA certificate must be installed on the appliance. The NetScaler can update CRLs only from CAs whose certificates are installed on it.

• Method

  Protocol in which to obtain the CRL refresh from a web server (HTTP) or an LDAP server. Possible Values: HTTP, LDAP. Default: HTTP.

• Scope

  The extent of the search operation on the LDAP server. If the scope specified is Base, the search is at the same level as the base DN. If the scope specified is One, the search extends to one level below the base DN.

• Server IP

  The IP address of the LDAP server from which the CRL is retrieved. Select IPv6 to use an IPv6 IP address.

• Port

  The port number on which the LDAP or the HTTP server communicates.

• URL

  The URL for the web location from which the CRL is retrieved.

• Base DN

  The base DN used by the LDAP server to search for the CRL attribute. Note: Citrix recommends using the base DN attribute instead of the Issuer-Name from the CA certificate to search for the CRL in the LDAP server. The Issuer-Name field may not exactly match the LDAP directory structure’s DN.

• Bind DN

  The bind DN attribute is used to access the CRL object in the LDAP repository. The bind DN attributes are the administrator credentials for the LDAP server. Configure this parameter to restrict unauthorized access to the LDAP servers.

• Password

  The administrator password used to access the CRL object in the LDAP repository. Password is required if the access to the LDAP repository is restricted, that is, anonymous access is not allowed.

• Interval

  The interval at which the CRL refresh must be carried out. For an instantaneous CRL refresh, specify the interval as NOW. Possible values: MONTHLY, DAILY, WEEKLY, NOW, NONE.

• Days

  The day on which the CRL refresh must be performed. The option is not available if the interval is set to DAILY.

• Time

  The exact time in 24-hour format when the CRL refresh must be performed.

• Binary

  Set the LDAP-based CRL retrieval mode to binary. Possible values: YES, NO. Default: NO.

1. In the navigation pane, expand SSL and then click CRL.
2. Select the configured CRL for which you want to update refresh parameters and then click Open.
3. Select the Enable CRL Auto Refresh option.
4. In the CRL Auto Refresh Parameters group, specify values for the following parameters: Note: An asterisk (*) indicates a required parameter.
   • Method
   • Binary
   • Scope
   • Server IP
   • Port*
   • URL
   • Base DN*
   • Bind DN
   • Password
   • Interval
   • Days
   • Time
5. Click Create. In the CRL pane, select the CRL that you configured and verify that the settings that appear at the bottom of the screen are correct.

Monitor certificate status with OCSP

Online Certificate Status Protocol (OCSP) is an Internet protocol that is used to determine the status of a client SSL certificate. NetScaler Gateway supports OCSP as defined in RFC 2560. OCSP offers significant advantages over certificate revocation lists (CRLs) in terms of timely information. Up-to-date revocation status of a client certificate is especially useful in transactions involving large sums of money and high-value stock trades. It also uses fewer system and network resources. NetScaler Gateway implementation of OCSP includes request batching and response caching.

NetScaler Gateway implementation of OCSP

OCSP validation on a NetScaler Gateway appliance begins when NetScaler Gateway receives a client certificate during an SSL handshake. To validate the certificate, NetScaler Gateway creates an OCSP request and forwards it to the OCSP responder. To do so, NetScaler Gateway either extracts the URL for the OCSP responder from the client certificate or uses a locally configured URL. The transaction is in a suspended state until NetScaler Gateway evaluates the response from the server and determines whether to allow the transaction or to reject it. If the response from the server is delayed beyond the configured time and no other responders are configured, NetScaler Gateway allows the transaction or displays an error, depending on whether you set the OCSP check to optional or mandatory. NetScaler Gateway supports batching of OCSP requests and caching of OCSP responses to reduce the load on the OCSP responder and provide faster responses.

OCSP request batching

Each time NetScaler Gateway receives a client certificate, it sends a request to the OCSP responder. To help avoid overloading the OCSP responder, NetScaler Gateway can query the status of more than one client certificate in the same request. For request batching to work efficiently, you need to define a time-out so that processing of a single certificate is not delayed while waiting to form a batch.

OCSP response caching

Caching of responses received from the OCSP responder enables faster responses to the user and reduces the load on the OCSP responder. Upon receiving the revocation status of a client certificate from the OCSP responder, NetScaler Gateway caches the response locally for a predefined length of time. When a client certificate is received during an SSL handshake, NetScaler Gateway first checks its local cache for an entry for this certificate. If an entry is found that is still valid (within the cache time-out limit), the entry is evaluated and the client certificate is accepted or rejected. If a certificate is not found, NetScaler Gateway sends a request to the OCSP responder and stores the response in its local cache for a configured length of time.

Configure OCSP certificate status

Configuring an Online Certificate Status Protocol (OCSP) involves adding an OCSP responder, binding the OCSP responder to a signed certificate from a Certificate Authority (CA), and binding the certificate and private key to a Secure Sockets Layer (SSL) virtual server. If you need to bind a different certificate and private key to an OCSP responder that you already configured, you need to first unbind the responder and then bind the responder to a different certificate.

To configure OCSP

1. On the Configuration tab, in the navigation pane, expand SSL and then click OCSP Responder.

2. In the details pane, click Add.

3. In Name, type a name for the profile.

4. In URL, type the web address of the OCSP responder.

   This field is mandatory. The Web address cannot exceed 32 characters.

5. To cache the OCSP responses, click Cache and in Time-out, type the number of minutes that NetScaler Gateway holds the response.

6. Under Request Batching, click Enable.

7. In Batching Delay, specify the time, in milliseconds, allowed for batching a group of OCSP requests.

   The values can be from 0 through 10000. The default is 1.

8. In Produced At Time Skew, type the amount of time NetScaler Gateway can use when the appliance must check or accept the response.

9. Under Response Verification, select Trust Responses if you want to disable signature checks by the OCSP responder.

   If you enable Trust Responses, skip Step 8 and Step 9.

10. In Certificate, select the certificate that is used to sign the OCSP responses.

    If a certificate is not selected, the CA that the OCSP responder is bound to is used to verify responses.

11. In Request Time-out, type the number of milliseconds to wait for an OCSP response.

    This time includes the Batching Delay time. The values can be from 0 through 120000. The default is 2000.

12. In Signing Certificate, select the certificate and private key used to sign OCSP requests. If you do not specify a certificate and private key, the requests are not signed.

13. To enable the number used once (nonce) extension, select Nonce.

14. To use a client certificate, click Client Certificate Insertion.

15. Click Create and then click Close.