Skip to Content
Technical Articles
Author's profile photo Johannes Goerlich

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 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:

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:

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.

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 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.

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 <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

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

In addition to that, as in some scenarios it may not be wanted to enable it for each CA. And furthermore, many Root CAs as well as some issuing CAs do not offer a CRL at all.

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 profile to enable the CRL check in general and how to setup custom pkix profiles to disable it 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 profile and enable it for certain CAs.

Please note: Be aware, the pkix 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 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 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 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 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.

 


<–Previous

Assigned Tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Daniel Huber
      Daniel Huber

      Dear Johannes,

      i really like your articel, it adds some more information to note 2338952 - CCL 8.5: Configuration Profile Parameters!

      We are heavily consuming CRLs for SNC and SSL/TLS, but for today there is no easy "out-of-the-box" solution available. A customer is required to setup a complex automation to process valid CRLs (and even prevent system outages based on CRL!). Maybe Delta+Base CRL is also something important to mention.

      Important to note, that every encrypted connection will fail, if a CRL check is not returning success.

      Means: If a CRL is outdated(Delta or Base), encrypted communication will not work anymore immediately - fortunately the ccl parameters are dynamically switchable.

       

      We would really appreciate to see OCSP in the future of CCL or any intelligent CRL automation.

      Best regards,

      Daniel

       

       

      Author's profile photo Johannes Goerlich
      Johannes Goerlich
      Blog Post Author

      Thanks, Daniel Huber!

      Indeed the automation for updating CRLs and monitoring is a critical thing. Failed updates of CRLs will strongly affect the availability, if they keep unrecognized.

      We preserve for example a pkix profile for emergencies. With this, we can switch off the CRL check for the affected CA if technical issues arise. To create such an emergency pkix profile one must be aware that the pkix profiles are processed in alphanumeric order and the default pkix profile is applied last.

      An emergency pkix profile may look like

      ccl/pkix/profile/00_EMERGENCY/issuer = CN=dummy
      ccl/pkix/profile/00_EMERGENCY/revocation_check = NO
      ccl/pkix/profile/00_EMERGENCY/certificate_policies = noCheck

      To switch the CRL check off, one just has to replace the CN=dummy.

      In the parameter monitoring, this set can be used to identify non compliant settings which will show systems using the emergency mode. Sometimes the issue is fixed but the CRL check is not enabled again.

       

      Best regards,

      Joe

       

      Author's profile photo Daniel Huber
      Daniel Huber

      Thanks, Johannes!

      one last thing to mention: A automatic cleanup of dbcrls-directory is also required, otherwise you will may end up with  500MB CRL cache and CCL always reads each file in dbcrls - even when they are already out of date. This creates a huge impact on performance, because the cache needs to be read for every SNC handshake.

      best regards,

      Daniel