CommonCryptoLib: Certificate Revocation List validation

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 SNC with SSO based on X.509 client certificates for SAP GUI with 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


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:

A X.509 client certificate – as every 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 would be 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.

There exist basically 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 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.

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.

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 <url> -f <file>. 

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!

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. Since CRLs are signed by the Issuing CA, they are deemed to be safe from tampering.

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.

Configure pkix profiles

Enable CRL check in general

To make sure the CRL check is enabled for all CAs, a set of profile parameters – known as the default pkix 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

Many Root CAs as well as some issuing CAs do not offer a CRL. With the default pkix profile created before such connections would fail during the handshake. For those, we have to create additional custom pkix profiles to disable the CRL check.

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 profiles as required for your environment!

Trust certificates based on Issuing CAs and OIDs

Pkix 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 OIDs of an end-entity certificate issued by the Issuing CA the pkix profile is intended for by adding the CCL parameter  ccl/pkix/profile/<custom>/certificate_policies = <OID_1>[:<OID_n>] to the relevant set.

Please note: Each certificate not matching the list of OIDs would then no longer be trusted.

Certificate revocation check for SNC

To enable the CRL check in general the profile parameter ccl/snc/pkix_revocation_check = 1 has to be set.

Certificate revocation check for TLS

To enable the CRL check in general 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 in general the profile parameter ccl/ssf/pkix_revocation_check = 1 has to be set.