Question regarding CRL and Caching

[jpecarski]

I have  customer which is having intermittent login issues with AnyConnect. Customer is using digital certificates to authenticate. From the logs I see the message:

"ASA-3-717027": Certificate chain failed validation. Recovation status check polling failed for certificate .........."

I see this consistently but not for every connection attempt. Also in the traffic logs I see TCP-Resets coming from the CA directory which means there are load or application issues on the directory when performing CRL validation. 

Question #1 - Does the Cisco ASA validate the CRL for every certificate used to authenticate using a remote call to the directory?

Question #2 - Does it use the CRL DP defined in the certificate?

Question #3 - If the ASA checks the certificate for each connection, what is the point of the CRL cache? My client is wondering, if the CA is unreachable, why didn't it allow connection if the cache was still valid.

Configuration snippet (ASA code 9.2(4)14)...

crypto ca trustpoint trustpoint1

 revocation-check crl

 keypair keypair1

 crl configure

policy both

url 1 ldap://1.2.3.4:389/

cache-time 240

ldap-defaults 1.2.3.4

[Rahul Govindan · Accepted solution]

Hopefully these provide answers to your questions:

1) Yes, every client cert is authenticated with CRL, but if the CRL is already cached, it does not request the CA for a CRL until the cache time expires.

2) Yes. You have policy set to both, so it will first check CDP from cert. If it not reachable, it will check static CRL url defined in the trustpoint.

3) If CRL cache is obtained from the same CDP as the client cert , the ASA should use the cache and not request the CDP for a new CRL. 

Do all the certs have the same CDP? It may be that the ASA is unable to download from the CDP at some point after the CRL expires and keeps trying to download new CRL's during that period.

[jpecarski]

Thank you Rahul. 

They do have separate CDP's. The problem appears to be load. 

With mandatory CRL checking enabled, and a low cache time, our morning busy time appears to be putting heavy load on the directory. 

Two recommendation I may make to the client if they want to alleviate load... 1) Treat certificates as valid, if the directory is unreachable 2) increase the cache time. 

Thx for your help. 

[Rahul Govindan]

Yeah, your cache time seems to be very low. By default MS CA's update their CRL every 24 hours and keeps the expiry of an existing CRL at 48 hours. So you should be able to keep the cache time as 24 hours if your CA has a similar setting.

[j.a.m.e.s]

I just found something very nice on the ASA trustpoints, which allows the CRL (or OCSP) check to "fail open":

crypto ca trustpoint TP-AUTH-MYINTERNALCA
revocation-check crl none

 In the above example, a CRL will be checked. If this fails, the system will skip the CRL check. i.e. fail open. This is handy in case of a corrupted CRL / DNS unavailable / server unreachable issue.

A debug crypto ca 14 will show this:

PKI[5]: session: 0x2adb3005, error during revocation check of certificate 0 but ALLOWED BY CONFIGURED POLICY
PKI[7]: session 0x2adb3005, Revocation check complete with errors, Allowing based on configured policy