Adding OCSPs

FortiADC supports the validation of client digital certificates using Online Certificate Status Protocol (OCSP). In such a configuration, FortiADC contacts the OCSP Responder (i.e., the certificate management system), which maintains the current revocation status information of client certificates or backend server certificates, to determine the current status of digital certificate presented to it. It can then decide whether to allow or block the TLS/SSL connections, based on the status of the client certificates provided by the OCSP Responder.

OCSP enables you to validate certificate status by real-time online query, rather than by importing certificate revocation list (CRL) files. Since distributing and installing CRL files can be a considerable burden in large organizations, and because delay between the release and install of the CRL represents a vulnerability window, this can often be preferable.

During the process of TLS/SSL handshake, FortiADC will send an OCSP status request for the client certificate or backend server certificate to the OCSP Responder. The OCSP Responder then verifies whether the status request contains the information required to identify the certificate and returns a signed response with the status of the inquired certificate, which could be one of the following:

• Good = The certificate has not yet been revoked.
• Revoked = The certificate has been revoked.
• Unknown = The OCSP Responder has no information about the requested certificate, and therefore is able to determine its status.

Note: FortiADC only accepts client certificates in"Good" status as determined by the OCSP Responder as valid.

To use OCSP queries, you must first install the certificates of trusted OCSP servers.

Before you begin, you must:

• Have Read-Write permission for System settings.
• Know the URL of an OCSP server
• Have downloaded the certificate and key files and be able to browse to them so that you can upload them.
• Have already imported the OCSP signing certificates into FortiADC. See Importing remote certificates and Creating a CA group.

To add an OCSP verify object:

1. Go to System > OCSP.
2. Click the OCSP tab.
3. Click Create New to display the OCSP configuration editor.
4. Complete the configuration as described in OCSP certificate configuration.
5. Click Save when done.
6. Repeat Steps 3 through 5 to add as many OCSP verify objects as needed.

OCSP certificate configuration

Settings	Guidelines
Name	Enter a unique name for the client certificate validation object that uses OCSP. Valid characters are A-Z, a-z, 0-9, _, and -. The maximum length is 35 characters. No space is allowed.
OCSP URL	Specify the URL of the OCSP Responder.
Verify Others	Upon receiving the OCSP response from the OCSP server, FortiADC first performs OCSP basic verify to validate the OCSP responder's signature. Enable (default)—When Verify Others is enabled, you must select a OCSP Signing Certificate (see OCSP Signing Certificates below). The OCSP basic verify succeeds when the selected OCSP signing certificate matches the OCSP response signature. Otherwise, the OCSP basic verify will fail and the TLS/SSL connection will be terminated. Disable—When Verify Others is disabled, you must select a CA chain. The OCSP basic verify will be carried out in the following sequence: The OCSP response signing certificate must be one of the certificates in the CA group or a certificate issued by one of the certificates in the CA group. Also, the certificates must form a chain from the OCSP signing certificate all the way to a self-signed root CA. Otherwise, the OCSP basic verify will fail. If Step 1 (above) is successful, the validation will proceed like this: If the Issuer Criteria Check field is selected (enabled by default), then the OCSP signing certificate can be either the issuing CA of the certificate whose status FortiADC must validate, or a dedicated OCSP signing certificate issued by this issuing CA. The validation succeeds if this criterion is met. Otherwise, the validation process will move onto Step 3 (below). If the OCSP signing certificate is issued by one of the certificates in the CA group, but is not a dedicated OCSP signing certificate, then the validation will proceed like this: If the root CA of this OCSP signing certificate is a trusted self-signed root CA and the "Accept Trusted Root CA" field is selected (enabled by default), then the validation will succeed. Otherwise, the validation will fail.
OCSP Signing Certificates	Select the client certificate of which you'd like to verify the signature of the OCSP Responder that signs it. Note: This option is applicable only when Verify Others is enabled. You MUST select a OCSP signing certificate which must have been imported into FortiADC in advance. See .
CA Chain	Click the down arrow and select a CA group from the list menu. Note: This becomes available only when Verify Others is disabled. In that case, you must select a CA chain (i.e., CA group). It's highly recommended that you have CA groups configured in advance to use this option. See Creating a CA group.
Issuer Criteria Check	Enable/Disable issuer-criteria check. Note: This option comes in hand in hand with CA Chain, and is only available when Verify Others is disabled (see Verify Others above). It is enabled by default, but you can uncheck it if you do not want to validate the certificate issuer's identity.
Accept Trusted Root CA	Enable/Disable accept trusted root CA. Note: This option becomes available only when Criteria Check is enabled (see Criteria Check above). It is enabled by default, in which case FortiADC will accept trusted root CA in the validation process. Uncheck it if you do not want to use this feature.
Timeout	Specify the amount of time in milliseconds (from 1 to 2147483647) the OCSP responder must wait before it times out. The default is 200.
Max age	Specify the maximum amount of time in seconds (from -1 to 214748364) the OCSP responder must check. Note: Setting it to -1 disables max-age check.
Host Header	Specify the host name (Optional).
Reject OCSP Response with Missing Nextupdate	By default, this option is disabled (unselected). In that case, FortiADC accepts all OCSP responses, including those without the nextupdate field. This may have some potential security repercussions, especially if the max-age filed in the OCSP response is not set. To minimize the security risk, you can enable this option so that FortiADC will automatically reject OCSP responses that do not have the nextupdate field. Note: As a good practice, we recommend that, if this option is enabled, you should set an acceptable max-age value (see above) as well so that FortiADC can also check the max-age of the OCSP response. It must be noted that max-age check is an extra, user-enforeced check, and that it has nothing to do with the OCSP server's behavior. In other words, once a max-age is set, then FortiADC will enforce the max-age check no matter whether or not the SCSP server sets the nextupdate field in OCSP response.
Caching	Enable or disable OCSP caching. Note: Enabled by default. For a detailed discussion about the function of OCSP caching, see OCSP caching.
Caching Thisupd Extra Maxage	Specify the number of seconds before the this-update-time. The cache will be discarded if the current timestamp is behind the this-update-time in OCSP response. Note: The default is -1, which means that the existing cache will always be used. The smaller value will be used if the max-age and the caching-thisupd-extra-maxage both exist. If one of them is -1, the other one will be used.
Caching Nextupd Ahead Time	Specify the number of seconds before the next-update-time.The cache will be discarded when the current timestamp is ahead of the next-update-time in OCSP response. Note: The default is -1, which means that the existing cache will always be used. Setting the value to 0 means that the cache will expire after the next-update-time, and setting it to 2147483647 makes the cache always expired so that FortiADC always needs to get the latest result from an OCSP server. Warning: There is a default leeway of 60 seconds. So when you set "Caching Nextupd Ahead Time" to x, it means the cache will expire at "x" before "next-update-time", plus 60 seconds.
Nonce Check	Enable or disable nonce check. Note: This option is enabled by default.
Tunneling	Click the button to enable or disable tunneling. If enabled, you must configure all the settings for the tunneling function. See below. Note: Tunneling, or port forwarding, is a way of transmitting private (usually corporate) data through a public network in a disguised way — the routing nodes in the public network are unaware that the transmission is part of a private network.
Tunneling Address	Enter the Tunneling Address that was provided to you.
Tunneling Port	Enter the Tunneling Port number that was provided to you.
Tunneling Password	Specify your password for the tunneling configuration.
Tunneling Username	Specify your user name for the tunneling configuration.
Save	Click the Save button to save your OCSP service configuration.

OCSP caching

OCSP cachig is a technique used to speed up OCSP checking. When a client accesses FortiADC or FortiADC accesses a real server for the first time, it (FortiADC) queries the certificate’s status using OCSP and caches the response. In subsequent accesses, the same client or real server will get verified directly from cache, if available.

OCSP caching essentially caches the result of an OCSP verification, not the whole OCSP response. It keeps the certificate status in the buffer for a specified period of time. OCSP verification results can be either obtained by querying an OCSP server or from an OCSP stapling response received from backend real servers.

It must be noted that configuration of OCSP caching is done on a per-VDOM basis and in rlimit.

Each OCSP configuration has a flag to let you decide whether to enable OCSP caching or not. Each haproxy process has one and only one OCSP cache which is shared among all OCSP servers.

If OCSP caching is enabled, FortiADC will search its cache first. If no OCSP response result is found in the cache or the cached result has expired (expired OCSP result will be removed from cache), it will query the OCSP server for an updated one FortiADC uses issuer and serial number hash as key, and also store some extra information (e.g., subject name hash) as extra key. It also implements LRU (least recently used) caching policy. It forms two links: one is to search using key (as an eb-tree) and the other is to implement the LRU caching scheme. You can configure how much memory to use and the maximum period of time to cache (which is useful if the next-update is missing) and cache the nextupd ahead time.

Implementation of the LRU caching scheme means that frequently used cache would not expire because it will get updated itself upon expiration (replacing itself with a new one) and the least recently used cache may be removed even though it is far from expiration.

When system configuration has changed, FortiADC either restarts the process of haproxy, or performs dynamic reload. In case of a restart, the cache is cleared. In case of dynamic reload, the cache is kept. Modification of cache memory size will restart the haproxy process. Changing other OCSP parameters will trigger dynamic reload.

You can use the existing OCSP max-age to control the lifespan of a cached item, or the "cache-thisupd-extra-maxage" and the "cache-nextupd-ahead-time" to manipulate the caching behavior.

Configure OCSP caching from the Console

Config system certificate ocsp

Edit “ocsp”

Set caching-flag enable/disable

Set caching-thisupd-extra-maxage 2

Set caching-nextupd-ahead-time 10

End

Config system vdom

Edit “root”

Set OCSP-caching-maximum-memory 4M

End