Symptom
When the ASA does not have the CRL cached, the first client authentication/certificate validation will trigger a CRL download, although if the CRL retrieval is a bit delayed [~600ms], CRL retrieval goes to the background, and the revocation-check falls back to none. i.e. a revoked certificate is allowed if the ASA does not have the CRL cached. The CRL retrieval succeeds in the background, and the CRL is cached. And this blocks the subsequent certificates that are already revoked.
This symptom repeats when the CRL validity/cache expires.
Conditions
ASA acting as SSLVPN or IPSec Server, where the peer/client is authenticated using certificates.
Client CA trust-point on the ASA has ''revocation-check crl none''
Workaround
1. Configure "revocation-check crl" under the trustpoint and make sure that the CDP is always reachable.
or
2. If "revocation-check crl none" is the preferred configuration, then deploy the CDP as close to the ASA as possible:
- If the CDP is far off, deploy an HTTP server as close to the ASA as possible, and on this server, have a script that downloads the CRL file from the official CDP on a periodic basis.
- Use this CDP instead of the embedded CDP from the certificate:
Ex:
crypto pki trustpoi TP
crl configure
policy static
url 1
Further Problem Description
Caching the CRL for the shorter duration increases the risk of allowing clients with revoked certificates.
