6.5. Enabling Revocation Checking

Revocation checking means that a Certificate System subsystem verifies that a certificate is both valid and not revoked when an agent or administrator attempts to access the instance's secure interfaces. This leverages a local OCSP service (either a CA's internal OCSP service or a separate OCSP responder) to check the revocation status of the certificate.

6.5.1. Enabling Automatic Revocation Checking on the CA

The CA can be configured to check the revocation status of any certificate (including agent, administrator, and enrollment) the server receives during authentication of an SSL/TLS client. This means that when the CA receives any client authentication request, it automatically checks an OCSP. (For information about setting up an OCSP responder, see Section 6.6, “Using the Online Certificate Status Protocol (OCSP) Responder”.)
As part of revocation checking, the CA has the ability to cache client authentication so that it keeps a list of verified certificates. This allows the CA to check its cached results before checking its internal database or an OCSP, which improves the overall operation performance. Automatic revocation checking is enabled in the revocationChecking.enabled parameter.
The revocation status results are only valid for a certain, specified period of time (revocationChecking.validityInterval). If the CA has no way to re-verify a certificate status that is in cache, then there is a grace interval (revocationChecking.unknownStateInterval) where the previously-cached status is still considered valid, even if it is outside the validity interval.


The cached certificates are kept in a buffer (revocationChecking.bufferSize). If the buffer setting is missing or is set to zero, then no buffer is kept, which means that the results of revocation checks are not cached. In that case, all revocation checks are performed directly against the CA's internal database.


The subsystem CS.cfg configuration file includes a parameter, jss.ocspcheck.enable, which sets whether a Certificate Manager should use an OCSP to verify the revocation status of the certificate it receives as a part of SSL/TLS client or server authentication. Changing the value of this parameter to true means the Certificate Manager reads the Authority Information Access extension in the certificate and verifies the revocation status of the certificate from the OCSP responder specified in the extension.
  1. Stop the subsystem instance.
    ]# systemctl stop pki-tomcatd@instance_name.service
  2. Open the CS.cfg file.
    vim /var/lib/pki/instance-name/ca/conf/CS.cfg
  3. Edit the revocation-related parameters.
    • revocationChecking.ca. Sets which service is providing the OCSP respsonse, a CA or an OCSP responder.
    • revocationChecking.enabled. Sets revocation checking. true enables checking; false disables checking. By default, the feature is enabled.
    • revocationChecking.bufferSize. Sets the total number of last-checked certificates the server should maintain in its cache. For example, if the buffer size is 2, the server retains the last two certificates checked in its cache. By default, the server caches the last 50 certificates.
    • revocationChecking.unknownStateInterval. Sets how frequently the server checks the revocation status. The default interval is 0 seconds. unknownStateInterval is a grace period in which cache result will be assumed to be true if CA has no means (no access to information allowing) to verify certificate status
    • revocationChecking.validityInterval. Sets how long the cached certificates are considered valid. Be judicious when choosing the interval. For example, if the validity period is 60 seconds, the server discards the certificates in its cache every minute and attempts to retrieve them from their source. The Certificate Manager uses its internal database to retrieve and verify the revocation status of the certificates. The default validity period is 120 seconds (2 minutes).
  4. Start the Certificate System instance.
    ]# systemctl start pki-tomcatd@instance_name.service

6.5.2. Enabling Certificate Revocation Checking for Subsystems

The Certificate System subsystems do not have OCSP checking enabled, by default, to validate subsystem certificates. This means it is possible for someone to log into the administrative or agent interfaces with a revoked certificate.
OCSP checking can be enabled for all subsystems by editing the server.xml file. The agent interface and the admin interface are configured separately, so both sections in the configuration should be edited.


If the subsystem has been configured to use an SSL/TLS connection with its internal database, then the SSL/TLS server certificate of the LDAP internal database must be recognized by the OCSP responder. If the OCSP responder does not recognize the LDAP server certificate, then the subsystem will not start properly. This configuration is covered in the Red Hat Certificate System 9 Planning, Installation, and Deployment Guide, since subsystem-LDAP SSL/TLS server connections are configured as part of the subsystem setup.
  1. Get the name of the OCSP signing certificate for the OCSP or CA which will be used to check certificate status. For example:
    ]# certutil -L -d /etc/pki/instance-name/alias
    Certificate Nickname                                         Trust Attributes
    Certificate Authority - Example Domain                       CT,c,
    ocspSigningCert cert-pki-ocsp CTu,Cu,Cu
    subsystemCert cert-pki-ocsp                                  u,u,u
    Server-Cert cert-pki-ocsp                                    u,u,u
    auditSigningCert cert-pki-ocsp                               u,u,Pu
  2. Open the server.xml file for the subsystem. For example:
    vim /etc/pki/instance-name/server.xml
  3. If the OCSP signing certificate is not present in the instance's security database, import it:
    ]# certutil -d /etc/pki/instance-name/alias -A -n "ocspSigningCert cert-pki-ca" -t "C,," -a -i ocspCert.b64
  4. There are three critical parameters to enable OCSP checking:
    • enableOCSP, which must be set to true to enable OCSP checking.
      This is a global setting; if it is set for one interface, then it applies to every interface for the instance. However, it must be set on the first interface listed in the server.xml file, which is usually the agent interface. Any setting on another interface is ignored.
    • ocspResponderURL, which gives the URL of the OCSP responder to send the OCSP requests.
      For an OCSP Manager, this can be another OCSP service in another OCSP or in a CA. For other subsystems, this always points to an external OCSP service in an OCSP or a CA.
    • ocspResponderCertNickname, which gives the signing certificate to use to sign the response; for a CA OCSP service, this is the CA's OCSP signing certificate, and for an OCSP responder, it is an OCSP signing certificate.
    Other parameters can be used to define the OCSP communication. All of the OCSP checking parameters are listed in Table 6.2, “OCSP Parameters for server.xml”.
    There are two different sections in the file for the agent and administrator interfaces. The OCSP parameters need to be added to both sections to enable and configure OCSP checking. For example:

    Example 6.1. OCSP Settings for an Agent Interface

    <Connector name="Agent" port="8443" maxHttpHeaderSize="8192"
            maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
            enableLookups="false" disableUploadTimeout="true"
            acceptCount="100" scheme="https" secure="true"
            clientAuth="true" sslProtocol="SSL"
    ssl3Ciphers="-SSL3_FORTEZZA_DMS_WITH_NULL_SHA, ..."
    tls3Ciphers="-SSL3_FORTEZZA_DMS_WITH_NULL_SHA, ..."
            ocspResponderCertNickname="ocspSigningCert cert-pki-ca 102409a"  
  5. If the given OCSP service is not the CA, then the OCSP service's signing certificate must be imported into the subsystem's NSS database. This can be done in the console or using certutil; both options are covered in Section 16.6.1, “Installing Certificates in the Certificate System Database”.
  6. Restart the subsystem.
    ]# systemctl restart pki-tomcatd@instance_name.service

Table 6.2. OCSP Parameters for server.xml

Parameter Description
enableOCSP Enables (or disables) OCSP checking for the subsystem.
ocspResponderURL Sets the URL where the OCSP requests are sent.
For an OCSP Manager, this can be another OCSP service in another OCSP or in a CA. For a TKS or KRA, this always points to an external OCSP service in an OCSP or a CA.
ocspResponderCertNickname Sets the nickname of the signing certificate for the responder, either the OCSP signing certificate or the CA's OCSP signing certificate. The certificate must be imported into the subsystem's NSS database and have the appropriate trust settings set.
ocspCacheSize Sets the maximum number of cache entries.
ocspMinCacheEntryDuration Sets minimum seconds before another fetch attempt can be made. For example, if this is set to 120, then the validity of a certificate cannot be checked again until at least 2 minutes after the last validity check.
ocspMaxCacheEntryDuration Sets the maximum number of seconds to wait before making the next fetch attempt. This prevents having too large a window between validity checks.
ocspTimeout Sets the timeout period, in seconds, for the OCSP request.