CommonCryptoLib: Certificate Revocation List validation

[JoeGoerlich]

The CommonCryptoLib (CCL) performs the validation of X.509 certificates.

Certificate validation consists of three basic steps:

1. verify the certificates' integrity (Construct the Chain and Validate Signatures)


2. verify the validity, (Check Validity Dates, Policy and Key Usage) and


3. verify the revocation status (Consult Revocation Authorities).

For the third step, the CCL comes with an optional, built-in functionality for Certificate Revocation List (CRL) validation which can be enabled for TLS, SNC, or SSF separately.

A common use case for this would be the validation of X.509 client certificates used for SSO with SAP GUI and SAP Secure Login Client 3.0 (SLC).

Please also read the other blogposts of this series:

CommonCryptoLib: TLS protocol versions and cipher suites
CommonCryptoLib: SNC protocol versions and cipher suites
CommonCryptoLib: Manage PSE files and SSO Credentials (cred_v2)
CommonCryptoLib: Certificate Revocation List validation

Updates:
2023-09-12: Added some notes about Delta CRL and CRL sharding. Added some more details about retrieving and adding CRLs to the cache.
2023-01-10: Backlink https://protect4s.com/2022/12/06/how-certificate-management-sap-security/

---

Certificate Revocation List (CRL)

While certificates' integrity and validity are checked in most cases, the revocation status is often considered as an optional step. In many cases it is not enabled.

Let's have a look at an example:

An X.509 client certificate - as every certificate - has a certain lifetime. The valid-to date may keep a certificate valid even if this is no longer wanted. To make sure certificates which have been compromised can no longer be used, a certificate can be revoked by its issuing CA. Imagine a user leaves the company before his authentication certificate expires. If she still have possession of the certificate she still is able to use it for authentication purposes. To fix the situation the X.509 client certificate has to be revoked. In consequence a server has to check the certificates' revocation status in addition to its integrity and validity.

Basically, there are two methods to do this:

1. query the CRL which is maintained by the Issuing CA.


2. perform an online check for the certificates status using the Online Certificate Status Protocol (OCSP).

Please note: At time of writing, the CommonCryptoLib supports only CRL checking. In other words, as the Online Certificate Status Protocol (OCSP) is not supported, we will focus on CRL.

The certificate in our example will be revoked by the Issuing CA. All revoked certificates will be added to the CRL of the Issuing CA. The CRL will be published by a CRL distribution point (CRL DP) which is listed in the Issuing CA certificates' attributes. With all this, the server is able to validate if a certificate is revoked by querying the previously downloaded (cached) CRL.

Excursus:

If the CA is issuing many many certificates, the CRL might grow very large. In this case, the CA can decide to additionally publish a so-called delta CRL. The delta CRL includes all certificates which are revoked since the last full CRL was published.The delta CRL is published more frequently as the full CRL, but it is smaller in size. The CRL has to be published from time to time to get rid of the listed certificates which are meanwhile expired.

For very large CAs the full CRL might grow even larger. In these cases, the CA can decide to make use of CRL sharding. And for each shard also a delta CRL might be published. The CRL shard is indicated by the URL listed as CRL DP in the end entity certificate.

In general, CRL checking is a subject of controversial discussions when it comes to server certificates, especially for TLS. It is said, it comes with an huge performance impact (depending on the size of the CRL) and its error prone. This is why browsers do not support this method. They offer at most the checking of CRLSets and OCSP with soft-fail. A mitigation measure which gets more and more common, is to issue very short living (14 days or less) server certificates instead.

When it comes to CRL checks for client certificates, the picture is a bit different:

Since X.509 certificates on a smart card are typically valid for up to 3 years and since the re-keying of a smart card is a manual time consuming effort, we do not see any other solutions then validating the CRL. Therefore, it is strongly recommended to enable CRL checking, at minimum if long living client certificates are used for authentication. A common use case for this would be SNC with SSO based on X.509 client certificates for SAP GUI with the SAP Secure Login Client 3.0 (SLC).

Please note: The CRL check of the CCL does not distinguish between server certificates and client certificates. Once the check was activated the CRL of each certificate will be validated - be it the server certificate used during the handshake or be it the client certificate used later on for authentication, which may for example for SNC be also the case if a client is based on SAP JCo. But the CRL check can be enabled/disabled at least based on the Issuing CA and/or on the Policy IDs of the certificates.

How to configure CRL validation

Retrieve and cache the CRL

Before enabling the revocation check, the CRLs must be retrieved and cached. This can be done with the command sapgenpse get_crl get -u <CRL-DP-URL> store -u <CRL-DP-URL>.

Please note: This is a single point of failure! In case the CRL has not been updated for more than 5 days all certificates will be considered as invalid. Make sure to monitor the successful update of the CRL cache!
In this command, the -u which follows the store  indicates a search key. This search key is used by sapgenpse to determine which CRL has to be updated, if a previous version is already in the cache. If the search key is not set, you may end up with an ever growing pki cache directory which may lead to a huge performance impact.

 

The CRLs are typically publicly available. This means in most cases they have to be downloaded from the internet. Internal PKI may deviate.

In a high secure environment systems may have no direct access to the internet, if any. It may be cumbersome to maintain the firewall settings for all systems which have to download CRLs. For example, the Issuing CAs of Google, Amazon and alike may offered the CRL via a distribution point farm which uses a lot of IP addresses. One solution for this could be to use a kind of proxy which retrieves the CRLs from their origin and publishes them towards internal systems. This can be done with the command sapgenpse get_crl get -u <CRL-DP-URL> -f </path/to/file.crl>. Since CRLs are signed by the Issuing CA, they are deemed to be safe from tampering.

The CRL has then to read from the file and be stored in the PKI cache with the command sapgenpse get_crl store -f </path/to/file.crl> -u <CRL-DP-URL>.

 

Please note: sapgenpse does not provide any downgrade protection for CRLs. If you load an older CRL to the cache, it will overwrite a more recent CRL in the cache without notification.

Specify CRL cache directory

The location of the CRL cache used by the CCL is defined by the CCL parameter ccl/pkix/cache_directory.

Please note: For an ABAP system with multiple application servers, it may be considered to store the CRL cache centrally. In this case it must be ensured that the update procedure is not scheduled on a single application server only (this would be a single point of failure). Instead of using cronjobs, this could be achieved for example by scheduling the command as a batchjob (SM37) while making sure it is not bound to a specific application server or a batchjob server group holding a limited set of application servers.

 

Certificate revocation check for SNC

To enable the CRL check module for SNC, the profile parameter ccl/snc/pkix_revocation_check = 1 has to be set.

 

Certificate revocation check for TLS

To enable the CRL check module for TLS, the profile parameter ccl/ssl/pkix_revocation_check = 1 has to be set.

Please note: As stated in the beginning, the CRL check affects also the server certificates used for the handshake. If the system initiates outgoing connections using TLS, the CRL would be checked for the communication partners' server certificate.

 

Certificate revocation check for SSF

To enable the CRL check module for SSF, the profile parameter ccl/ssf/pkix_revocation_check = 1 has to be set.

PKIX certificate verification profiles

The CCL offers switches to enable the CRL check depending on the use case: for TLS, SNC, and SSF.

While enabling the CRL check modules in general, there may be some scenarios for wich it may not be wanted to enable the CRL check. For example, many Root CAs as well as some issuing CAs do not publish a CRL.

There are different approaches how to enable/disable the CRL check for individual CAs. In the following it is described how to configure the default PKIX certificate verification profile to enable the CRL check in general and how to setup custom PKIX certificate verification profiles to disable the CRL check for individual CAs.

Please note: This approach could also be inverted based on your scenario or risk appetite. Meaning disable the CRL check in the default PKIX certificate verification profile and enable it for certain CAs.

Please note: Be aware, the PKIX certificate verification profiles apply for all enabled use cases (TLS, SNC, and SSF).

 

Enable CRL check for all CAs

To make sure the CRL check is enabled for all CAs, a set of profile parameters - known as the default PKIX certificate verification profile - has to be configured:

ccl/pkix/profile/default/accept_no_basic_constraints = no
ccl/pkix/profile/default/revocation_check = CRL
ccl/pkix/profile/default/certificate policies  = noCheck

 

Disable CRL check for defined Issuing CAs as required

With the default PKIX certificate verification profile created before connections would fail during the handshake if the relevant CA does not offer a CRL. For those, we have to create additional custom PKIX certificate verification profiles to disable the CRL check. The CCL parameter for the Issuer works as a filter to specify on which CAs the set will be applied. The value is applied as a 'begins with' pattern.

For example, for the certificates issued by the 'System PKI' we can create:

ccl/pkix/profile/01_systemPKI/issuer = CN=root_
ccl/pkix/profile/01_systemPKI/revocation_check = NO
ccl/pkix/profile/01_systemPKI/certificate_policies = noCheck

or for the 'SAPSUPPORT Root CA' and 'SAPSUPPORT User Sub CA' which is issuing the certificates used by SAP Active Global Support during remote support sessions (type 'R/3 with SNC'):

ccl/pkix/profile/02_SAPSUPPORT/issuer = CN=SAPSUPPORT
ccl/pkix/profile/02_SAPSUPPORT/revocation_check = NO
ccl/pkix/profile/02_SAPSUPPORT/certificate_policies = noCheck

Please note: Add further custom PKIX certificate verification profiles as required for your environment!

 

Trust certificates based on Issuing CAs and OIDs

PKIX certificate verification profiles can also be used to limit which end entity certificates (also known as leaf certificates) issued by a certain Issuing CA shall be trusted. This makes sense if an Issuing CA issues various certificates with different usage types - indicated by the certificates OIDs - but not all of them shall be usable for client authentication.

This can be achieved by adding a filter to define the trusted certificate Policy IDs of an end entity certificate issued by the Issuing CA the PKIX certificate verification profile is intended for by adding the CCL parameter  ccl/pkix/profile/<custom>/certificate_policies = <PIDs_1>[:<PID_n>] to the relevant set.

Please note: Each certificate not matching the list of certificate Policy IDs would then no longer be trusted. If a certificate has more than one certificate Policy IDs all of them have to be listed.

 

---

<--Previous