PingFederate also checks to see whether a certificate has been revoked, using either certificate revocation lists (CRLs) or the online certificate status protocol (OSCP). Depending on the content of the certificate in question and your requirements, the server will perform either of these checks during single sign-on (SSO) or single log-out (SLO) processing for the following cases:

  • Signature verification
  • Validation of a client certificate used for authentication to PingFederate when the server is handling direct client requests
  • Validation of the server SSL certificate when PingFederate acts as the client making an HTTPS request to a separate server

If the system encounters an expired or revoked certificate, the associated SSO or SLO transaction fails at runtime and writes an error to the transaction log. In the administrative console, the Status column of the respective Certificate Management list identifies the expired or revoked certificate.

In PingFederate, by default, OCSP revocation checking is enabled and CRL revocation checking is disabled. However, you can configure PingFederate to use only CRL checking or as a backup to OCSP checking.

For more information, see Configuring certificate revocation.

CRL revocation checking

CRL revocation checking involves querying a CRL distribution-point URL and ensuring that a certificate is not on the returned revocation list maintained at the site. The certificate specifies the URL.

OCSP revocation checking

OCSP revocation checking provides a more centralized and potentially more reliable means of checking certificate status than CRL revocation checking provides. In this scenario, the incoming certificate embeds an OCSP Responder URL or a configured default URL to query the certificate status.

The primary difference between OCSP and CRL checking is how the verification occurs. CRL checking requires the requesting client to determine if the certificate has been revoked, or if any of the certificates in the chain of issuer certificates has been revoked, based on the returned CRL. With OCSP, the client sends the certificate itself, and the Responder server handles revocation checking to return the certificate status.

For more information about OCSP, see tools.ietf.org/html/rfc2560.