_JOHN_
Aug 10, 2022Altocumulus
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...
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