Manage Certificate Validation

The  will verify whether certificates used for authentication and/or authorization are valid; the  can also perform revocation checking for certificates. To enable revocation checking, use the Manage Certificate Validation dialog to define one or more revocation checking policies. These policies describe the strategies employed by  to determine the revocation status of a certificate:
gateway92
The 
API Gateway
 will verify whether certificates used for authentication and/or authorization are valid; the 
API Gateway
 can also perform revocation checking for certificates. To enable revocation checking, use the Manage Certificate Validation dialog to define one or more 
revocation checking policies
. These policies describe the strategies employed by 
API Gateway
 to determine the revocation status of a certificate:
  • by checking Certificate Revocation List (CRL)
  • using Online Certificate Status Protocol (OCSP)
In either case, the URL for the CRL data or OCSP responder can be extracted from the certificate's URL or it can be a predefined URL. 
Every certificate in the trust store can have its own revocation checking policy, or more simply, you can designate a default revocation checking policy that will be used for all trusted certificates. 
Technical note:
The 
API Gateway
 will cache Certificate Revocation Lists for improved performance. It will try to fetch a fresh CRL one minute before the old one expires. The 
pkix.*
 cluster properties can be used to configure the caching behavior. The cache is configured to use a stale CRL indefinitely while trying to get a new one. The initial attempt to load a CRL that has not yet been cached will block the caller. Subsequent attempts will use the cached value, even if it is stale.
If you do not intend to use the cached value when stale, set the
pkix.crl.invalidateCrlCacheOnNextUpdate
property to
true
.
If a new CRL needs to be downloaded, one of the request threads will be used to do this, possibly increasing latency. The other threads will continue to use the old value without waiting. It is not possible to configure a local copy of the CRL or to manually prepopulate the download cache. 
The Manage Certificate Validation dialog also lets you select the validation option for the following types of certificate usage:
  • Identity Providers:
     For validation of users' certificates during authentication using the identity provider
  • Routing
    : For validation of certificates presented by a server during request routing (i.e., HTTPS, FTPS)
  • Other
    : For validating any other certificates (for example, LDAPS or non-routing assertions)
If mutual certificate security is required between the
API Gateway
and the CRL host, you need to ensure that the
API Gateway
SSL certificate is trusted by the CRL host.
Trust Anchors
In order for the 
API Gateway
 to validate certificate paths and check for revocation, it is necessary to have a starting point from which trust is established. This starting point is known as a 
trust anchor
. The 
API Gateway
 recognizes the following as trust anchors:
  • Trusted certificates that have the [
    Certificate is a trust anchor
    ] setting selected. This is located in the [Validation] tab of the certificate's properties. For more information on certificate properties, see  Edit a Certificate. A certificate can also be flagged as a trust anchor when it is imported.
  • The CA certificate belonging to the 
    API Gateway
    .
  • Certificates located in the JDK trust store.
To manage certificate validation
:
  1. In the Policy Manager, select 
    [Tasks] > Certificates, Keys, and Secrets > Manage Certificates 
    from the Main Menu. 
    The Manage Certificates dialog appears.
  2. Click [
    Certificate Validation
    ]. 
    The Manage Certificate Validation dialog appears.
  3. Configure the dialog as follows:
    Setting
    Description
    Certificate Validation Options
    Define how the
    API Gateway
    will perform validation for different types of certificate usage. Changes take effect immediately.
    1. Select a certificate type.
      For Identity Providers, the option specified here will be used only if the Identity Provider properties is set to "Use Default" for certificate validation
    2. Click [
      Properties
      ].
    3. Choose how that certificate type should be validated:
      • Validate
        : Ensure that the certificate is valid and trusted.
      • Validate Certificate Path
        : Ensure that the certificate path is valid to a trust anchor.  
      • Revocation Checking
        : Validate the certificate path and perform revocation checking according to the revocation checking policy.
        The validation options can also be accessed or set using these cluster properties:
        pkix.validation.identityProvider, pkix.validation.routing, pkix.validation.other
        .
    Revocation Checking Policies
    By default, the
    Layer7 API Gateway
    does not check for certificate revocation. To enable revocation checking, define a revocation checking policy. You can create separate policies based on a variety of criteria, including the signing authority certificate, URL from the certificate for CRL/OCSP based on URL Regex matching, and Static URL manually entered for CRL/OCSP.
    • To add a new policy, click [
      Add
      ] and then complete the Edit Revocation Checking Policy dialog. For
    • To remove a policy from the list, select it and then click [
      Remove
      ]. You cannot delete a policy if any trusted certificate is using that policy.  
    • To view or edit a policy, select it and then click [
      Properties
      ]. For more information, see Edit a Revocation Checking Policy.
     
  4. Click [
    Close
    ] when done.