ASA 5510 Base 7.2 CRL cache problem

Unanswered Question
Aug 4th, 2010
User Badges:

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.

however it looks like it isn't even trying to retrieve it.
To clarify - I can retrieve a crl by using the crypto ca crl request TRUSTPOINT command with no problems and show the crl exists but it doesn't replace it.
It could a: be a license issue although I can't see any way around it?
b: something missing from my configuration somewhere else?
Thanks in advance!   


Edit: unsure how to close! :p

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
sam mackenzie Fri, 08/13/2010 - 06:12
User Badges:

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

Actions

This Discussion