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

[Henrik Meyer]

My issue is not about the ASA's certificate Issuing CA.

My issue is about the VPN Client Certificates Issung CA. (that is the Certificate on the ASA that authenticat the VPN Client)

[gaowen]

The ASA gets a certificate signed by the sub-CA

The ASA uses that certificate to authenticate itself to the VPN clients

They are the same thing

[gaowen]

I can't figure out if you're an expert driving at something that is large scale and something I've not seen before or if you are new to this and are mis-understanding some basic concepts!

[Henrik Meyer]

thanks for your input.

I will stick to the Cisco TAC answer, that this is an unsupported feature.

Else this thread can go on forever.

(need to focus on my CCIE Security written tomorrow)

[gaowen]

OK but please answer me, who in your example is signing the client's certificates (their issuing CA)?

[Henrik Meyer]

• COMONDO is signing the Public Certificate for the ASA (vpn.domain.com)
• Internal Issuing CA is signing the VPN Clients Certificate (ca01.int.domain.com)
• Internal Issuing CA is imported on the ASA VPN head-end and is authenticating the VPN Client (client01.int.domain.com)

[gaowen]

I'm now pretty sure you're confused and it's a common one with PKI, you've said that you've imported the Internal Issuing CA on the ASA and that it is authenticating clients - unless you've got a poor architecture and exported the private key from your issuing, that's not correct.

Can you issue a 'show crypto ca certificate' on the ASA please? There will be 2 certificates of interest- one is the imported Issuing CA (public part only, issuer: COMONDO) and one is the ASA device cert (you have the private key for this, issuer: issuing CA).

[Henrik Meyer]

sure thing (please don't mind the dates and naming rewrites)

ASAv01# show crypto ca certificate
CA Certificate
Status: Available
Certificate Serial Number: 56ae2b7c592b0fxxxx27d9427b5a9630
Certificate Usage: Signature
Public Key Type: RSA (4096 bits)
Signature Algorithm: SHA256 with RSA Encryption
Issuer Name:
cn=rootCA
Subject Name:
cn=rootCA
Validity Date:
start date: 12:54:29 CEST Dec 16 2016
end date: 13:04:28 CEST Dec 16 2036
Associated Trustpoints: ASDM_TrustPoint1

CA Certificate
Status: Available
Certificate Serial Number: 1700000002c9a34xxxxa5ff1b6000000000002
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: 5a0000001bcbd9afxxxx33790300000000001b
Certificate Usage: General Purpose
Public Key Type: RSA (2048 bits)
Signature Algorithm: SHA256 with RSA Encryption
Issuer Name:
cn=CA01
dc=int
dc=domain
dc=com
Subject Name:
cn=vpn.int.domain.com
CRL Distribution Points:
[1] ldap:///CN=CA01,CN=CA01,CN=CDPxxxxxxxx
Validity Date:
start date: 15:12:03 CEST Dec 17 2016
end date: 15:12:03 CEST Dec 17 2018
Associated Trustpoints: ASDM_TrustPoint3

Certificate
Status: Available
Certificate Serial Number: 09588eafa6ddexxxx02961723465a11c
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

[gaowen]

ASDM_TrustPoint2: this is your issuing CA cert, signed by COMONDO

ASDM_TrustPoint3: this is your ASA device cert, signed by your issuing CA

ASDM_TrustPoint1: looks like a self signed CA, I guess you were playing around here

ASDM_TrustPoint0: signed by your self signed CA.

Only the first 2 are relevant as the certs associated with TP1 and 0 are from another setup

If you re-read the comments hopefully it will now start to make sense? The ASA device cert (ASDM_TrustPoint3) is signed by your issuing CA cert (ASDM_TrustPoint2). They are not the same thing!!!

[gaowen]

If I can make this crystal clear for you.

In your example you would have lost the issuing CA access, which is what signed the ASA device cert and also the CRL that the ASA uses. Without access to the issuing CA server, you are unable to publish the CRL which the ASA needs to check to revoke its own certificate (even if that process worked, which you found out that it doesn't). This is the paradox I was talking about.

[Henrik Meyer]

In my example, I do not even need the ASA Device cert issued from the Internal Issuing CA.

The VPN clients certificates are validated against the "Issuing CA Trust Point"

[Henrik Meyer]

My original issue/question was also related to CRL check of the "Issuing CA" CDP. (The CRL from the "offline" Root CA)

So that all certificates issued from a revoked Issuing CA, would not get validated.

[Henrik Meyer]

• ASDM_TrustPoint0 = My "Internal Issuing CA for VPN Client Certificates", without this one, the Remote Access VPN Clients cannot connect/their client machine certificate be validated

• ASDM_TrustPoint1 = My "Internal Offline Root CA" (This can be deleted from the ASA reposetory - I was playing arround)

• ASDM_TrustPoint2 = My ASA public certificate, so the Remote Access VPN Clients don't get an "untrusted connection error" when connecting their AnyConnect Client

• ASDM_TrustPoint3 = My ASA internal certificate (This is not used for Anything, and VPN Clients can connect even without this one imported/installed)

[gaowen]

Why is the issuer name in your ASDM_TrustPoint0 "cn=rootCA"? This is the subject-name from your ASDM_TrustPoint1! It should be the subject-name from ASDM_TrustPoint2!

[Henrik Meyer]

ASDM_TrustPoint0 = Internal Issuing CA/Sub CA (Server: "rootCA" is the "Offline Root CA" that issued the certificate for the Internal "Issuing CA" named CA01.int.domain.com)

My Internal PKI infrastructure:

"Offline Root CA" -> "Issuing CA" -> "Client Machine Certificate"