08-04-2010 01:16 AM
Hiho there!
I've got a problem where our ASA 5510s are not replacing their CRLs when they become stale. I've set the timeout at 5 minutes to test and requested a new CRL which is successful: as soon as the CRL times out it doesn't attempt to get another; just times out the current CRL and reports "No CRLs are currently cached."
Its running Base license. Our 5540 is fine and is able to retrieve new CRLs when timed out.
For info:
5540 is running VPN Premium license and uses the same trustpoint as the 5510. All our ASAs are running 7.2(3) software with no way to move away from 7.2 version unfortunately.
config as follows
5540:
crypto ca trustpoint TRUSTPOINTNAME
revocation-check crl none
enrollment url http://X.X.X.X:80/certsrv/mscep/mscep.dll
keypair KEYPAIRNAME
crl configure
policy static
url 1 http://X.X.X.X/CertEnroll/network.crl
no protocol ldap
5510:
crypto ca trustpoint TRUSTPOINTNAME
revocation-check crl none
enrollment url http://X.X.X.X:80/certsrv/mscep/mscep.dll
keypair KEYPAIRNAME
crl configure
policy static
url 1 http://X.X.X.X/CertEnroll/network.crl
cache-time 5
no protocol ldap
I've been running crypto debugs without showing why this should be happening.
I've also checked the config guide and searched release notes for open caveats but found none so far.
this is from http://cisco.biz/en/US/docs/security/asa/asa72/configuration/guide/certs.html
When the security appliance has cached a CRL for more than the length of time it is configured to cache CRLs, the security appliance considers the CRL too old to be reliable, or "stale". The security appliance attempts to retrieve a newer version of the CRL the next time a certificate authentication requires checking the stale CRL.
Edit: unsure how to close! :p
08-13-2010 06:12 AM
Ahem.
I feel rather silly, it turns out that it is working exactly as expected. Not as I expected, but as the device expected.
When the security appliance has cached a CRL for more than the length of time it is configured to cache CRLs, the security appliance considers the CRL too old to be reliable, or "stale". The security appliance attempts to retrieve a newer version of the CRL the next time a certificate authentication requires checking the stale CRL.
I read the above as "when the CRL grows stale the appliance attempts to retrieve a newer version". It waits until it needs the certificate then goes and gets one. In fact because I was diagnosing it, I limited the time to 5 mins so i was less likely to stumble on this since less people use certs on this device.
I feel silly! but this is not a problem, it works as designed just a PICNIF.
(problem in chair not in Firewall)
Thanks to anyone who looked anyway
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide