Certificate based authentication and revoking access

[MikeM-2468]

I'm testing certificate based VPN authentication with the ASA and AnyConnect.  Things work as I expect for the most part.  One question concerns revocation of the certificates.  What's the best practice for deploying this type of setup and making sure that if the situation changes that users can't get in via their certificate if I don't want them to?  Revoking the cert at the CA doesn't do anything.

[Marcin Latosiewicz]

Mike,

When CA revokes certificate it will also update CRL/OCSP.

When you connect via SSL/IPsec you are presented with certificate, that certificate has to be trusted and should contains CRL URL.

You should fetch the CRL and check if certificate presented is not among the list of revoked ones.

For the best part you can open the CRL file on almost all operating systems yourself and check what's there.

Certain implmentations keep CRL cached and will not get new one until current CRL lifetime expires.

Marcin

[MikeM-2468]

Where would I get the CRL file from - the ASA or the CA?  Is the ASA communicating with the CA to check for revoked certs?

[Marcin Latosiewicz]

Mike,

Check the cert itself to know the CRL URL.

You can configure ASA not to check CRL:

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/qr.html#wp1792002

"show run crypto ca trustpoint"

Marcin

[Marcin Latosiewicz]

Mike,

Just to be clear. The certificate you can also see by doing "show crypto ca cert" on ASA/IOS.

Marcin

[MikeM-2468]

Maybe I'm confusing things.  When I authenticate to the ASA via the AnyConnect client, I'm using a user certificate.  That certificate isn't on the ASA.  How does the ASA know that the user cert has been revoked?  So far, revoking the cert on the CA doesn't stop it from being used to authenticate to the ASA.

[Marcin Latosiewicz]

Mike,

Taking a step back.

PKI needs a concept of trusted third party to make it work - it's usually a CA. Both ASA and client should be enrolled to same CA (typical case that we see) to perform mutual autentication you need to present your certificate to ASA and ASA needs to perform to you.

When you present certificate to ASA your certificate "lands" on a particular trustpoint (container for certificate).

Within the certificate more often than not you should have a CRL.

Certificates enrolled to same CA will very often be structured the same. In this particular case,  will (or will not) have same CRL/OCSP location.

Ok that might have been a long way around to ask. Do you have CRL in the client cert and/or do you have CDP URL configured on ASA? :-)

Marcin

[MikeM-2468]

I don't know the answer to either of those questions.  How can I find out?

[Marcin Latosiewicz]

Mike,

Let's check "show crypto ca cert" and "show run ssl" from ASA for starters.

If you can also attach the cert from client ... (we don't need pkcs12, so there shoul not be any security risk involved)

Marcin

[MikeM-2468]

Thank you for helping, but I can't post any of that information in a public forum due to company security policies.  If that creates a road block to troubleshooting, I'll have to go the route of a TAC case. Thanks.

[MikeM-2468]

I found two places that I think will help.  In the ASA there is an option for CRL handling.  On the CA, there is an option for CRL publication interval.  I'll see if changing those works.

[Marcin Latosiewicz]

Mike,

Good call. I would also check the URL the CA is publishing the CRL under.

Regarding:

 In the ASA there is an option for CRL handling.

There's the revocation-check CLI I pointed out before which can override settings from certificate.

Marcin

[MikeM-2468]

I didn't need to specify the CRL URL.  It looks like it's getting it from the certificate.  One thing that I'm finding is that the CRL updates aren't being properly applied in all cases.  The CA is set to apply updates every hour.  The ASA is set to cache updates for an hour.  A cert that I revoked 2 hours ago is still accepted by the ASA.

[Marcin Latosiewicz]

Mike,

Odd indeed.

Can you fetch the CRL from it's URL and check if the certs is among revoked ones (you can do it on your PC in cert manager in windows)?

Also If you're suspecting ASA not refreshing the CRLs, you can manually tweak it.  (of course you'd need to change the "TEST" to your trustpoint name ;])

crypto ca trustpoint TEST
 crl configure
  cache-time 20

Regarding CRLs already cached you can view more info in here:

show crypto ca crls

I'd also check if time is accurate on the ASA .. just for sake of checking the basics.

Marcin

[MikeM-2468]

For some unknown reason it was having intermittent trouble retreiving the CRL using the DP from the certificate.  Using a static URL seems to work better, but will require a little more manual intervention.