Certificate Revocation

ESF Http Service and SSL Manager Service can be configured to check the revocation status of client/server certificates using the following methods:

• OCSP: The revocation check is performed using the OCSP protocol. The OCSP responder URL must be encoded using the corresponding extension in the certificate to be verified.
• CRLDP: The revocation check is performed by downloading a CRL list from the distribution points URLs encoded using the corresponding extension in the certificate to be verified.
• Cached CRL lists: ESF also supports managing a local CRL cache that is considered along with OCSP and CRLDP. See below for more details.

These Http Service and SSL Manager Service provide the following configuration options related to certificate revocation check:

• Revocation Check Enabled: Allows to enable/disable the revocation check.

• Revocation Check Mode:

  • Prefer OCSP: The verification check will be performed using OCSP, and if this fails, using CRLs.
  • Prefer CRL: The verification check will be performed using CRLs, and if this fails, using OCSP.
  • CRL Only: The verification check will be performed only using CRLs.

  During CRL check, both CRLDP and the CRLs cached using ESF are considered.

• Revocation Soft-Fail Enabled: If this is set to true, the gateway will accept client certificates also in the case when it is not able to verify the revocation status due to a network error (for example because the OCSP server or the CRL distribution points are not reachable).

📘

Note

The soft fail mechanism is applied only in case of network error. If the gateway is not able to determine revocation status for other reasons, the validation will still fail even if Revocation Soft-Fail Enabled is set to true. This happens for example in the case when a client certificate does not have a OCSP or CRLDP URL set and a CRL for its issuer is not available in the cache.

CRL Cache

ESF KeyStore service allows to maintain a local cache by periodically downloading and storing CRLs from a configurable set of HTTP URLs.

This service provides the following CRL related options:

The Enabled: Allows to enable or disable CRL caching for the specified keystore

The CRL URLs: Allows to specify a set of HTTP URLs to download CRLs from. Apart from these URLs, the KeyStore Service will also download the CRLs specified as distribution points by the certificates in the keystore. LDAP distribution points are not supported.

The service attempts to download a CRL from a distribution point at most every CRL Check Interval, in the following cases:

• After the Keystore Service starts or when its configuration has been modified
• If no CRL has been downloaded yet from the distribution point.
• If the nextUpdate field of the CRL is set and is in the past.
• The last successful download attempt since FilesystemKeystoreService activation or update is in greater than the value specified by the CRL Force Update Interval.

If the Enable CRL Verification parameter is set to true, then the service will check whether the downloaded CRLs are signed by a trusted certificate contained in the managed keystore. If this condition is not satisfied, the CRL will be discarded.

Revocation Check behaviour with Expired CRL

This section describes the behaviour of the revocation check when a device has an expired CRL in its cache (the nextUpdate field is in the past) and is unable to retrieve a new CRL or contact the OCSP server. The result of the revocation check depends on the following factors:

• The status of the certificate: valid or revoked.
• The values of the configuration parameters in the HttpService configuration:
• Revocation Check Mode, which can be set to one of the following values:
  • PREFER_OCSP
  • PREFER_CRL
  • CRL_ONLY
• Revocation Soft-Fail Enabled, a boolean value.
• The presence of the OCSP URL in the certificate.

If the cached CRL is current, a valid (non-revoked) certificate is always accepted, while a revoked certificate is always denied. If the CRL is expired, the behaviour is as described below:

OCSP URL Not Present in the Certificate

The revocation check will always fail, except when Revocation Soft-Fail Enabled is set to true and Revocation Check Mode is set to CRL_ONLY. In this scenario, the check will always succeed (even with a revoked certificate).

OCSP URL Present in the Certificate

The revocation check will consistently fail if Revocation Soft-Fail Enabled is false, while it will succeed if the parameter is true (again, succeeding even with a revoked certificate).

Implementation Details

The revocation check utilizes the Java PKIXRevocationChecker. The Revocation Check Mode and the Revocation Soft-Fail Enabled parameters affect the option set passed to the Java PKIXRevocationChecker (https://docs.oracle.com/javase/8/docs/api/java/security/cert/PKIXRevocationChecker.Option.html) in the following manner:

The behaviour of the soft fail mechanism is described here.

• If soft fail is enabled, Java appears to ignore the expired CRL instead of utilizing it, allowing login with a revoked certificate to succeed.

• The influence of whether the OCSP URL is included in the certificate may stem from the fact that the revocation check is allowed to succeed only if both mechanisms fail under the specified conditions. If the OCSP URL is absent, the OCSP check may fail for a different reason (e.g., revocation status cannot be determined), leading to login failure. However, when CRL_ONLY is set, OCSP is disabled, enabling successful login.