Forum Discussion
AltocumulusCRL Validator
Employee
_JOHN_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
