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

[gaowen]

So where does the public certificate come into this authentication (IKEv2 or SSL)?

You've got an offline root (local), with a sub-CA (local) that issued your ASA certificate which is the certificate private key that signs the authentication data returned to the client in IKE_AUTH (assuming IKEv2, but the process is similar in TLS).

How do you think the public certificate is used in authentication?

[Henrik Meyer]

ASDM_TrustPoint2 the public certificate is not used in the validation of the AnyConnect VPN Client Machine certificate. (I have never statet this either) It is used, so the AnyConnect Client is not getting an "SSL error" due to a self-sign local ASA certificate.

And I do not even need ASDM_TrustPoint3 the local Issued ASA certificate, to get the AnyConnect VPN Clients to connect.

I only need ASDM_TrustPoint0 The local Issuing CA.

[gaowen]

So the ASA is sending:

the certificate from a totally separate PKI which has then been signed by the COMONDO

The client is is sending:

"Offline Root CA" -> "Issuing CA" -> "Client Machine Certificate" signed by the ASA issuing cert.

OK, I now understand your PKI structure.

I'm reading your original question in a new light.

The ASA will check the CRL in its device certificate as this is the PKI the client is using - the device certificate should be an indeed is issued by the issuer CA. The issuing CA is revoked but the device certificate isn't, and the ASA should be using the device certificate (which it is?) and not the issuing CA (even though in this instance it has the private key to the issuing CA, which is a poor implementation choice for any non-lab environment)

what happens if you revoke the ASA device certificate? same result?

[Henrik Meyer]

I have cleared up in the Certificates on the ASA.

The ASA is not holding the Private Key for the local Issuing CA - it is only the public key for the local Issuing CA.

Now there is only the Public ASA cert vpn.domain.com and the local Issuing CA. ca01.int.domain.com

I have just tested the AnyConenct Client and it can connect.

When I revoke the Issuing CA, the AnyConnect Client still connects:

(I need to leave for today)

###########

ASAv01# sh cry ca certificates
CA Certificate
Status: Available
Certificate Serial Number: xxxxxxxxxxxxxxxxxxxxxxxx
Certificate Usage: Signature
Public Key Type: RSA (4096 bits)
Signature Algorithm: SHA256 with RSA Encryption
Issuer Name:
cn=rootCA
Subject Name:
cn=CA01
dc=int
dc=domain
dc=com
CRL Distribution Points:
[1] ldap:///CN=rootCA,CN=rootCA,CN=CDPxxxxxxxx
Validity Date:
start date: 13:52:26 CEST Dec 16 2016
end date: 13:04:28 CEST Dec 16 2036
Associated Trustpoints: ASDM_TrustPoint0

Certificate
Status: Available
Certificate Serial Number: xxxxxxxxxxxxxxxxxxxxxxxx
Certificate Usage: General Purpose
Public Key Type: RSA (2048 bits)
Signature Algorithm: SHA256 with RSA Encryption
Issuer Name:
cn=COMODO RSA Domain Validation Secure Server CA
o=COMODO CA Limited
l=Salford
st=Greater Manchester
c=GB
Subject Name:
cn=vpn.domain.com
ou=Free SSL
ou=Domain Control Validated
OCSP AIA:
URL: http://ocsp.comodoca.com
CRL Distribution Points:
[1] http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl
Validity Date:
start date: 01:00:00 CEST Dec 16 2016
end date: 00:59:59 CEST Mar 15 2017
Associated Trustpoints: ASDM_TrustPoint2

ASAv01#

[gaowen]

OK good luck tomorrow.