Skip to content

Certificate Revocation Checking

Endi S. Dewata edited this page Sep 9, 2023 · 7 revisions

Overview

This document describes the procedure to enable certificate revocation checking.

Internal Certificate Revocation Checking

The CA subsystem has an internal certificate revocation checking functionality which is enabled by default.

To configure the internal certificate revocation checking, edit /var/lib/pki/pki-tomcat/ca/conf/CS.cfg:

auths.revocationChecking.enabled=true
auths.revocationChecking.ca=ca
auths.revocationChecking.bufferSize=50
auths.revocationChecking.unknownStateInterval=0
auths.revocationChecking.validityInterval=120

If necessary (e.g. for testing), the cache can be disabled:

auths.revocationChecking.bufferSize=0

Then restart the server.

External Certificate Revocation Checking

Subsystems other than CA can utilize an external certificate revocation checking. This functionality is disabled by default.

Note: This functionality is currently not working and will be fixed in Ticket #1764.

To enable the external certificate revocation checking, edit the subsystem’s CS.cfg:

auths.revocationChecking.enabled=true
auths.revocationChecking.kra=kra
auths.revocationChecking.bufferSize=50
auths.revocationChecking.unknownStateInterval=0
auths.revocationChecking.validityInterval=120
auths.revocationChecking.url=http://pki.example.com:8080/ca/ocsp

If necessary (e.g. for testing), the cache can be disabled:

auths.revocationChecking.validityInterval=1

Then restart the server.

Global Certificate Revocation Checking

Each PKI instance can be configured to use a global certificate revocation checking. The configuration is located in /var/lib/pki/pki-tomcat/conf/server.xml. See Tomcat JSS. This functionality requires a separate OCSP responder.

When the global certificate revocation checking is enabled all certificate validations in the server instance will be performed against the specified OCSP responder. This includes system certificate validations during server startup and client certificate validations on incoming SSL connections.

Note:

  • The OCSP responder URL cannot point to the CA running on the same instance. The server will fail to start. The default OCSP responder URL does point to the same server, so it needs to be changed to work properly.

  • The OCSP responder URL must use a plain HTTP protocol.

Installing OCSP signing certificate

If the OCSP signing certificate is already trusted by the instance (e.g. issued by the same CA), this step is optional.

Otherwise, the OCSP signing certificate needs to be exported from the OCSP responder and imported into the NSS database.

To export OCSP signing certificate from PKI 10.2.x or earlier:

$ certutil -L -d /var/lib/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-tomcat CA" -a > ocsp_signing.crt

To export OCSP signing certificate from PKI 10.3.x or later:

$ pki-server subsystem-cert-export ca ocsp_signing --cert-file ocsp_signing.crt

To import the OCSP signing certificate into the instance:

$ certutil -A -d /var/lib/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-tomcat CA" -t "C,," -i ocsp_signing.crt

Verify the import with the following command:

$ certutil -L -d /var/lib/pki/pki-tomcat/alias

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

ocspSigningCert cert-pki-tomcat CA                           C,,

Enabling global certificate revocation checking

To enable global certificate revocation checking, edit /var/lib/pki/pki-tomcat/conf/server.xml and configure the parameters in the Secure Connector:

<Connector name="Secure"
   ...
    enableOCSP="true"
    ocspResponderURL="http://another-pki.example.com:8080/ca/ocsp"
    ocspResponderCertNickname="ocspSigningCert cert-pki-tomcat CA"
    ...>

</Connector>

The ocspResponderURL must point to the OCSP responder running on a separate server.

The ocspResponderCertNickname must point to the CA signing certificate or the imported OCSP signing certificate.

If necessary (e.g. for testing) the cache can be disabled:

    ocspMinCacheEntryDuration="0"
    ocspMaxCacheEntryDuration="0"

Then restart the server.

Verification

CA subsystem verification

These verification steps assume that a CA is running with revocation checking enabled and a test user has been created with admin privileges and a certificate has been issued for the user. See Adding CA Admin.

Execute a test command authenticated with the test user’s certificate:

$ pki -c Secret.123 -n testuser ca-user-find
-----------------
4 entries matched
-----------------
  User ID: CA-pki.example.com-8443
  Full name: CA-pki.example.com-8443

  User ID: caadmin
  Full name: caadmin

  User ID: pkidbuser
  Full name: pkidbuser

  User ID: testuser
  Full name: Test User
----------------------------
Number of entries returned 4
----------------------------

As the default CA admin revoke the test user’s certificate using its serial number:

$ pki -n caadmin ca-cert-hold 0x1a --force
---------------------------------
Placed certificate "0x1a" on-hold
---------------------------------
  Serial Number: 0x1a
  Issuer: CN=CA Signing Certificate,O=EXAMPLE
  Subject: UID=testuser
  Status: REVOKED
  Not Before: Thu Jun 23 05:18:02 CEST 2016
  Not After: Tue Dec 20 05:18:02 CET 2016
  Revoked On: Thu Jun 23 05:41:19 CEST 2016
  Revoked By: caadmin

Re-run the test command, it should no longer work:

$ pki -c Secret.123 -n testuser ca-user-find
PKIException: Unauthorized

Unrevoke the test user’s certificate:

$ pki -n caadmin ca-cert-release-hold 0x1a --force
----------------------------------
Placed certificate "0x1a" off-hold
----------------------------------
  Serial Number: 0x1a
  Issuer: CN=CA Signing Certificate,O=EXAMPLE
  Subject: UID=testuser
  Status: VALID
  Not Before: Thu Jun 23 05:18:02 CEST 2016
  Not After: Tue Dec 20 05:18:02 CET 2016

Re-run the test command, it should work again.

Finally, restore the validity interval to the original value and restart the server.

Other subsystem verification

These verification steps assume that a CA is running on one instance with revocation checking enabled and another subsystem, for example KRA, is running on a separate instance with external/global certificate revocation checking pointing to the CA.

On the KRA execute a test command using client certificate authentication:

$ pki -d ~/.dogtag/pki-tomcat/kra/alias -c Secret.123 -n kraadmin kra-user-find
-----------------
3 entries matched
-----------------
  User ID: kraadmin
  Full name: kraadmin

  User ID: pkidbuser
  Full name: pkidbuser

  User ID: CA-pki.example.com-8443
  Full name: CA-pki.example.com-8443
----------------------------
Number of entries returned 3
----------------------------

On the CA revoke the client certificate using its serial number:

$ pki -n caadmin ca-cert-hold 0x18 --force
---------------------------------
Placed certificate "0x18" on-hold
---------------------------------
  Serial Number: 0x18
  Issuer: CN=CA Signing Certificate,O=EXAMPLE
  Subject: CN=PKI Administrator,[email protected],O=EXAMPLE
  Status: REVOKED
  Not Before: Thu Jun 23 00:14:19 CEST 2016
  Not After: Fri Jun 23 00:14:19 CEST 2017
  Revoked On: Thu Jun 23 04:11:07 CEST 2016
  Revoked By: caadmin

Re-run the test command on the KRA, it should no longer work:

$ pki -d ~/.dogtag/pki-tomcat/kra/alias -c Secret.123 -n kraadmin kra-user-find
IOException: SocketException cannot write on socket

Unrevoke the client certificate on the CA:

$ pki -n caadmin ca-cert-release-hold 0x18 --force
----------------------------------
Placed certificate "0x18" off-hold
----------------------------------
  Serial Number: 0x18
  Issuer: CN=CA Signing Certificate,O=EXAMPLE
  Subject: CN=PKI Administrator,[email protected],O=EXAMPLE
  Status: VALID
  Not Before: Thu Jun 23 00:14:19 CEST 2016
  Not After: Fri Jun 23 00:14:19 CEST 2017

Re-run the test command on the KRA, it should work again.

See Also

Clone this wiki locally