Forum Discussion

_JOHN_'s avatar
_JOHN_
Icon for Altocumulus rankAltocumulus
Aug 10, 2022

CRL Validator

From v15.1 onwards client SSL profiles support CRL validator objects as per this bug report: Bug ID 743758 (f5.com) I have no experience of CRL Validator.  I have just started to read about it, but...
application delivery
security
Kevin_Stewart's avatar
Kevin_Stewart
Icon for Employee rankEmployee
Aug 22, 2022
> How are different methods e.g. LDAP/HTTP handled?
[Answer] I'm pretty sure this supports both.

> What is the approach if multiple CRLDPs are specified in the cert?
[Answer] Does that ever happen? But if so, it would attempt process the first one.

> What happens if the CRLDP isn't covered by the DNS zones in the DNS resolver?
[Answer] The DNS resolver is intended to provide local DNS resolution for the CRLDP URL. You can simply create a DNS resolver that uses "." as the name (no quotes) to cover all URLs.

> Is there any mechanism to restrict the set of CRLDPs that this download and cert check will operate for, i.e. only perform the operation if the CRLDP in the cert matches a specific set of known CRLDPs (I assume not in the normal setup, it would need to be performed via the likes of an iRule instead?)
[Answer] You should be able to point the "Internal Proxy Name" at a local VIP and process the requests with an iRule.

> The CRL object has a setting "Strict Revocation Check". The operation of this isn't clear to me - it seems like if it is set the client connection is paused until the CRL is downloaded and checked, or if not set the F5 starts the download but returns 'unkown' for the cert revocation check - if that is the case will the SSL connection be allowed to establish anyway or how is the unkown status handled?
[Answer] This basically boils down to timing. CRLs are binary files that have to be downloaded in full and then parsed, and CRLs can be large. It's likely in some circumstances that a CRL file could be so large that it could delays requests for an unacceptable amount of time. So this option basically says, if the file is big, trigger the download, and while it's downloading return an unknown (revocation) response. That unknown will probably cause the first or first set of responses to fail depending on how you've configured things, so ultimately you have to wait for the CRL to finish downloading anyway. The CRL is cached so that subsequent requests don't have this issue.

> What sort of error handling is used, e.g. what if the F5 can't connect to the CRLDP - is there a timeout value used? What if it does connect but is taking a long time to download - will the SSL handshake be paused indefinitely (I assume based on the setting of Strict Revocation Check?) - if so have folks needed to increase the SSL handshake timeout setting in the SSL profile?
[Answer] If DNS resolution fails, it returns an error response immediately. If DNS succeeds but the request fails, it'll make a small series of attempts (3 or 5 I believe), then return an error response.

> The CRL is cached - is that governed by the contents of the CRL itself, e.g. nextupdate filed, or is it configurable?
[Answer] I'm not entirely certain if it's configurable, but I believe the cache timeout is based on the CRL's original nextupdate value.

> Is there any way to manually specify specific CRLDPs that will be downloaded and constantly refreshed whether certificates which reference them are received or not?
[Answer] You could always run a script to periodically issue a request that triggers a CRL download. But honestly, that's what OCSP is for. 😉
_JOHN_'s avatar
_JOHN_
Icon for Altocumulus rankAltocumulus
Sep 06, 2022

Firstly – sorry for the delay in replying, I was away for a while.

Secondly – thank you very much for the in depth reply, much appreciated 😊

Regarding the last point:

> Is there any way to manually specify specific CRLDPs that will be downloaded and constantly refreshed whether certificates which reference them are received or not?

[Answer] You could always run a script to periodically issue a request that triggers a CRL download. But honestly, that's what OCSP is for. 

I don't really get the reference to OCSP here.  In my scenario the F5 is the server end of the communication receiving a client certificate during mutual authentication, and I know all of the CAs that client certs align to (plus their CRLDPs).  OCSP would let me check on an individual cert by cert basis, but it would therefore hold up every SSL handshake while the revocation check occurs.  CRL however seems much more suited to this type of server setup and provides benefits over OCSP – client certs are compared against a local copy of the CRL file, so the time to check will be quicker than OCSP (providing you have a cached copy of the CRL).  The downside is that CRLs may be cached for a long time which could mean revocation status is missed.  However if you actively download the CRLs continually in the background (e.g. every 15 minutes) then there would be many benefits over OCSP as I see it:

  • Other than maybe on the first ‘run’, you don't hold up the client connection while an outbound call is made to a revocation checking service – so client connection time is much better.
  • Any issues with the CRLDPs, or the network connectivity to them, will not cause immediate problems for the client connection – it will continue to be checked against the latest copy of the relevant CRL, which will be updated when the CRLDP issue recovers (would likely want to be able to collate logs to pick up on any long lived problems).  However if instead using OCSP the connections would be blocked until the responder becomes available again.
  • Assuming the CAs publish new CRLs when certs are revoked then by continually downloading them on your own schedule rather than waiting for the nextupdate time you will have a very up to date mechanism for checking revocation.
    For Example:  Reading the second ‘Note’ on this AWS documentation page:
    Setting up a certificate revocation method - AWS Certificate Manager Private Certificate Authority (amazon.com)
    I would presume that if one of the CAs in question is the AWS certificate manager then using continually downloaded CRLs would actually pick up on revoked certs quicker than using OCSP.  It would obviously depend on the specific CAs in operation, but in my scenario (which I expect will be a common one) when you know the CAs then you can determine their method of operation and I find it likely that CRL may come out as being much better than OCSP providing it can be used appropriately.

Unfortunately I don’t see a way to specify the likes of an ‘update interval’ with CRL validator, so I am assuming there isn’t a way to keep the CRL fresh and you have to just rely on the cache expiring (likely based on CRL nextupdate field) and then a new download being triggered by the next incoming client connection that references that CRL.  This wouldn't really suit in my scenario because each time the CRL expires I will potentially drop some connections while a new CRL is downloaded, plus there would be too long a period during which revoked certificates may end up being trusted - not to mention the potential problems if the CRLDPs couldn't be reached for some reason.  Hence my question about the ability to use some form of background download of the CRLs to keep them fresh and avoid the need to repeatedly hold up client connections to download a new CRL.

Regarding the statement “You could always run a script to periodically issue a request that triggers a CRL download” – do you mean there would be a way to tie this in with CRL Validator to essentially provide the functionality I have described, i.e. CRL Validator is deployed against the VS, but then some form of script (iCall maybe?) keeps the downloaded CRLs ‘fresh’ in the background?

Also thank you for the second reply with info on concatenated CRLs – I have tested this and found it to work, however I would need it to actually be an approved F5 approach or otherwise I can’t rely on it.

BTW – I have definitely seen cases where more than one CRLDP is specified in a client cert.  Sometimes this provides both LDAP and HTTP DPs.  Sometimes it just provides redundant DPs using the same protocol – e.g. the current amazon.com cert (presented to UK users anyway) is signed by DigiCert and contains:

[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://crl3.digicert.com/DigiCertGlobalCAG2.crl

[2]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://crl4.digicert.com/DigiCertGlobalCAG2.crl