10-Aug-2022 16:29 - edited 10-Aug-2022 16:36
From v15.1 onwards client SSL profiles support CRL validator objects as per this bug report:
I have no experience of CRL Validator. I have just started to read about it, but I haven't found much info and would appreciate input from those who already have experience to help me properly understand its operation and benefits/limiataions.
The following devcentral post discusses it:
Support dynamic CRL check for clientSSL profile (B... - DevCentral (f5.com)
The F5 client SSL overview pages don't look to cover it, but the following describes it from the server SSL profile point of view (heading "Create a custom Server SSL profile that supports CRL"):
So first off let me just make sure I have understood the basic setup (please correct anything I have wrong):
1) Client SSL profile set up as normal for client authentication e.g. require a cert, and attached to relevant VS.
2) Internal proxy created referencing a DNS resolver. The DNS resolver is used to map any of the expected DNS zones referenced in CRLDPs to DNS servers that can perform the name resolution.
3) CRL object created referencing internal proxy.
4) CRL object attached to client SSL profile mentioned in point 1.
In this setup the F5 will examine the CRLDP contained within the client cert, perform a DNS lookup for it, and then progress to download the CRL to use for checking the client cert. So I have the following pieces I want to understand (answers for any appreciated :-)......
> How are different methods e.g. LDAP/HTTP handled?
> What is the approach if multiple CRLDPs are specified in the cert?
> What happens if the CRLDP isn't covered by the DNS zones in the DNS resolver?
> 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?)
> 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?
> 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?
> The CRL is cached - is that governed by the contents of the CRL itself, e.g. nextupdate filed, or is it configurable?
> 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?
The last query is the main reason I am looking into the CRL Validator setup in the first place. I have a use case whereby client certs can be presented which will be signed by a few different CAs, and therefore multiple CRLs need to be checked not just one. I have seen comments that this can be achieved by downloading the different CRLs (the CRLDPs are already known) and simply concatenating them (in PEM format) - e.g. done periodically by iCall or bash script and the concatenated 'bundle' is then specified as the crl-file on the client SSL profile. However I raised an F5 support request to check if the F5 does definitely support concatenated CRL files in the client SSL profile and unfortunately the answer was no 😞
15-Aug-2022 09:14
@_JOHN_ - thanks for the context and effort you've put into this question - I will see if I can find someone who knows about this to take a look.
22-Aug-2022 05:42
06-Sep-2022 08:11 - edited 06-Sep-2022 08:18
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:
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
22-Aug-2022 06:03
Forgot to mention, that while it isn't technically "supported", concatenated CRLs can work in some scenarios.
06-Sep-2022 10:13
OCSP does indeed have a few advantages over CRL:
As to the CRL refresh script option, the more I think about it, this probably wouldn't work in your scenario. The idea would be to have a script that perdiodically queries the site and passes a client cert, forcing the client SSL profile to fetch the CRL if it's not in cache. The issue here is that your script would need a client cert for each respective CRL. I imagine you could spoof this, but I'd have to test that to know for sure.
15-Sep-2022 06:46
Cheers again for the reply 😊
I agree in ‘normal’ operation OCSP has clear benefits over CRL. However in my scenario I see clear advantages to pre-fetching the CRLs. I can’t go into the finer specifics of my scenario, but I know it will apply to many others. The key general concepts are:
Unfortunately there doesn’t seem to be an option to pre-fetch the files natively in the F5 arsenal. APM comes closest in that you can use an ‘Update Interval’ so as to continually refresh CRLs based on a timeframe of your choosing (unlike CRL Validator which relies on the nextupdate filed), but APM has downsides:
Regarding expired CRL – the SSL profiles allow for that option, but it is on a single CRL (unless trying to use concatenated CRLs).
Local OCSP responder sounds interesting, but it will still hold up connections rather than just making a check against a local file. A local OCSP connection should be very quick, but surely it would still be longer than a local compare on the F5 against a CRL? You then also have to manage something separate to the F5, which is a headache for companies when they have bought the F5 to do all of this work (e.g. keeping on top of security issues and applying patches, more devices to bring under a support model and to manage alerts from etc. etc.).
Regarding forcing a refresh by presenting various client certs (one per CRL) - having the certs to present would be no problem at all in my scenario – test certs are available and constantly refreshed. However it wouldn’t really do what I need – I want the CRL to be refreshed in the background. There is sufficient load that real traffic would likely trigger a CRL download long before the automated script did.
Unfortunately there just doesn’t appear to be a method to do what I need (other than possibly concatenated CRL if we can get round the support issues) so I will look into the alternatives. CRL Validator won’t be one of them based on the cache being for nextupdate (would be simply too long between refreshes). APM is a potential but with those downsides I mentioned.
15-Sep-2022 07:02
Just a few additional points, don't really want to belabor the OCSP topic.