Cisco ASA with revoked Issuing CA still authenticates AnyConnect VPN clients

[Henrik Meyer]

Hi,

I am trying to LAB my way trough how Certificate based VPN is working.

• I have one "offline" root CA (Trust Anchor) and one "online" Issuing CA/SubCA
• My AnyConnect client authenticates perfect with certificate based VPN
• If I revoke the client certificate, the AnyConnect client is denied VPN access (both CRL over LDAP and OCSP over HTTP works like a charm)

Now I want to test what happens if I revoke my Issuing CA/SubCA.

• I turn on my "offline" root CA and revoke the Issung CA certificate
• I copy the CRL to my domain and publish the CRL in Active Directory
• "certutil -verify CA.cer" says: "certificate is REVOKED"

Until now - everything is just perfect.

Now I try to connect my AnyConnect client once more - and the client still connects.. DAMN..

How can the ASA let a Revoked Issuing CA certificate authenticate clients issued by the CA itself?

Please enlighten me :)

Thanks

Regards

Henrik Meyer, Denmark

[Mohammad Alhyari]

Hi ,

In this setup, You would have two trustpoints :

crypto ca trustpoint root_cert
Where we have the cert issuing the sub ca.

crypto ca trustpoint sub_ca

where we have the issued cert.

What CRL settings did you have under the Root trustpoint ? that one will control the revocation of the sub-ca. The second trustpoint controls the revocation of the identity cert.

Moh,

[Henrik Meyer]

Hi Mohammed,

Thanks for your feedback.

Just to followup - the CDP/CRL for a specific Certificate is found in the certificate it self.

Therefor a "Root CA" has no CDP/CRL in its own certificate, the "Sub/Issuing CA" points to the CDP/CRL from the "Root CA" and the Client Certificate points to the CDP/CRL from the "Sub/Issuing CA"

regards

Henrik

[Luis Heredia]

If you are just trying to verify that a revoked cert cannot be used to connect to the VPN, try this:

1- The CA server on which you revoked the cert has a CRL published schedule. If you want to hurry that up, just get on that CA and re-publish the new CRL that will contain your revoked cert

2- Go to the ASA and clear out the CRL. CRLs have a lifetime and by default are refreshed every 15 minutes.

3- Force the ASA to reload the new CRL

4- Disconnect the client and attempt to reconnect 

5- Put the ASDM in Debug mode and look for the "revoked" message.

--Luis

[Henrik Meyer]

I opened a ticket at Cisco TAC and got the following answer.

"Cisco ASA does not support Revocation check of Root CA nor Issuing CA certificates. Only Client Certificates.

If a Issuing CA certificate is revoked, all issued clients certificates from that Issuing CA must manually be Revoked."

As I see it, this is a major security risk.

If you need to revoke a Issuing CA certificate, it is because you have lost control of the Issuing CA it self, and thereby no longer can Revoke the Client Certificates issued by the Issuing CA.

[gaowen]

The clients should be using the CDP from the root CA, which is offline for this purpose. If the sub-CA key material is compromised then the root CA needs to revoke the sub-CA, which the clients will then respect. This is why the root CA is offline.

revoking a sub CA using its own key material is a poor architecture, and it's that which is the security issue, not the operation of the ASA.

The architecture you are looking for is to enforce CRL checking on the client. No CRL check, no connection.

Hope this helps.

[Henrik Meyer]

Hi Gaowen,

Thanks for your answer.

I am not sure I follow.

In my case/LAB, the Issuing CA is revoked from the "offline" Root CA.

[gaowen]

Yes, that's right.

Before the clients connect to the VPN, they should perform a CRL check based on the CDP in the certificate they hold from the root CA in their 'Trusted Root Certification Authorites' (Windows).

This CRL is signed by the offline root, which has revoked the sub-CA certificate so the client should see that in the revoked certificate list and refuse to connect to the sub-CA.

Gareth

[Henrik Meyer]

Hi Gareth,

Thanks for quick reply.

I will investigate in the Client check of the CRL from the certificate chain. (My client apparently does not do this - so I was looking to have the ASA to do this check instead)

[Henrik Meyer]

Hi Gareth,

I have thought of your suggestion - but the more I think, the less it makes sense.

The security/validation should never depend on the client it self.

Scenario:

• The Internal Clients Certificate Issuing CA is compromised, and the "attacker" have signed "false" certificates for them self
• The "attacker" is now able to logon Cisco ASA certificate based Remote Access VPN
• This is descovered by the Internal IT department - the internal IP department is unable to logon to the internal Issuing CA, so they Revoke the Internal Issung CA Certificate from the "offline" Root CA
• The "attacker" is still able to logon Cisco ASA certificate based Remote Access VPN because the security is depentend on the Client it self and not the Head-end ASA

Does this make sense or is it just me overlook something?

[gaowen]

"The security/validation should never depend on the client it self."

HTTPS site revocations are not uncommon and rely on the client to perform a CRL lookup, e.g. the recent GlobalSign issue.

The CRL check is to prevent a MiTM attack, if someone is pretending to be the gateway in order to get access to your traffic. If you have no CRL check on the client and your key material is compromised, then your clients have no way of knowing if they are connecting to a revoked certificate.

In your example an entire sub-CA is compromised, in that instance you need to remove the sub-CA from all trustpoints everywhere anyway as no clients should be connecting to your service as the whole thing is tainted. At that point you've got big problems and they can't be solved by revoking a cert.

Also in your example if the key is kept on an HSM then the sub-CA key material might not have been ex-filtrated meaning theoretically if you can get back control of your server you only need to revoke the certs it issued and not the whole sub-CA (probably not a good practice though). In the mean time you can disable the VPN and the compromised VPN service is down.

Gareth

[Henrik Meyer]

Hi Gareth,

Thanks for your indepth answer.

I know the best way would just to manually remove the revoked Issuing CA certificate from the Head-end ASA VPN appliance or temp disable VPN - but imagine if you have hundreds or thoundstands devices with the revoked certificate installed on - it would be nice to have the "automatic revoke check for CA's" in place - just like Client Certificate rovocations check, until you have time to manually remove the revoked certificate from all the units.

I know that this might be a bit of a theoretical issue - but it is still a very valid issue though.

(This issue is not about Public Signed Certificates from i.e. GlobalSign - but only regarding locally/internal PKI)

Not to talk about - if the person revocing the Issuing CA certificate, not telling all other departments of doing so - there clearly should be an automated check - just like the Client Certificate Check.

[gaowen]

Well if your sub-CA has been owned then you won't be able to revoke the VPN gateway certificate anyway, the best thing to do in this case is simply switch off the CRL server/service and the ASA will stop accepting client certificates as it won't be able to perform a CRL lookup on any of them, so the issue I don't think is valid.

The paradox you find yourself in is if you lose control of your sub-CA you won't be able to revoke the ASA certificate in any case, so your situation of the ASA not respecting CRL lookup for itself isn't going to happen.

[Henrik Meyer]

The ASA does not need a certificate to "serve" VPN clients. (only a public signed cert, so the client does not get a certificate error when connecting)

The ASA only relie on the Internal Issuing CA Certificate to authenticate VPN clients.

I might think you have missed the original issue here?

[gaowen]

The ASA does need a certificate, whether it is signed by a public CA or your own internal sub-CA makes no difference to the operation of the PKI.

If either your issuing CA or public CA is captured by an unwelcome 3rd party and you no longer have access to it, it will not be able to issue a CRL for the ASA's certificate.

Remember the ASA has a cert signed by the issuing CA