Anyconnect Remote Access with User Certificates - OCSP Not Working on Revoked Certs

bfbcnet · ‎03-29-2017

Hello,

We are currently in the process of testing Anyconnect remote access to a Cisco ASA 5506 with AAA and certificate authentication (using user certificates). The issue we have is that OCSP does not seem to be working for revoked certificates and allows us to connect still.

We have a Windows 2012 R2 PKI server issuing the user certificates. The ASA has the CA and OCSP Responder Certificates installed and they are valid.

There seems to be very limited information on the web on the debug messages, so we are struggling to understand exactly what is going on. The debug output we get is as follows:

CERT_API: PKI session 0x0bcc97b3 open Successful with type SSL
CERT_API: Authenticate session 0x0bcc97b3, non-blocking cb=0x00000000019926e0
CERT API thread wakes up!
CERT_API: process msg cmd=0, session=0x0bcc97b3
CERT_API: Async locked for session 0x0bcc97b3

CRYPTO_PKI: Checking to see if an identical cert is
already in the database...

CRYPTO_PKI: looking for cert in handle=0x00007fffdd484a10, digest=
ce 79 da 3f 42 b7 4c e7 aa 63 68 d8 a3 3e 15 bc | .y.?B.L..ch..>..

CRYPTO_PKI: Found cert in database.

CRYPTO_PKI: Checking to see if an identical cert is
already in the database...

CRYPTO_PKI: looking for cert in handle=0x00007fffdd484a10, digest=
1f 69 49 38 6b 82 95 e7 e7 85 7f 03 7a 4b bc 54 | .iI8k.....zK.T

CRYPTO_PKI: Cert record not found, returning E_NOT_FOUND
CRYPTO_PKI: Cert not found in database.

CRYPTO_PKI: Looking for suitable trustpoints for connection type SSL

CRYPTO_PKI: Found suitable tp: BFC-Enterprise-SubB
CRYPTO_PKI: Found suitable tp: ASDM_TrustPoint2
CRYPTO_PKI: Storage context locked by thread CERT API

CRYPTO_PKI: Found a suitable authenticated trustpoint BFC-Enterprise-SubB.

CRYPTO_PKI(make trustedCerts list)
CRYPTO_PKI: Allocated OCSP data handle 0x00007fffdef71680
CRYPTO_PKI:check_key_usage: ExtendedKeyUsage OID = 1.3.6.1.4.1.311.10.3.4
CRYPTO_PKI:check_key_usage: ExtendedKeyUsage OID = 1.3.6.1.4.1.311.10.3.4, NOT acceptable
CRYPTO_PKI:check_key_usage: ExtendedKeyUsage OID = 1.3.6.1.5.5.7.3.4
CRYPTO_PKI:check_key_usage: ExtendedKeyUsage OID = 1.3.6.1.5.5.7.3.4, NOT acceptable
CRYPTO_PKI:check_key_usage: ExtendedKeyUsage OID = 1.3.6.1.5.5.7.3.2
CRYPTO_PKI:check_key_usage:Key Usage check OK

CRYPTO_PKI: Certificate validation: Successful, status: 0
CRYPTO_PKI: Attempting to retrieve revocation status
CRYPTO_PKI: OCSP status is being checked for certificate. serial number: XXXXXXXXXXXXXXXXXX, subject name: e=XXXX@XXXXXXXXXXXXXXXXXX,cn=XXX,ou=XXX,ou=XXX,ou=XXX,dc=XXX,dc=XXX.
crypto_pki_req(0x00007fffde2a1ab0, 26, ...)
CRYPTO_PKI: Crypto CA req queue size = 1.

CRYPTO_PKI: status = 0: poll revocation status

CRYPTO_PKI: Storage context released by thread CERT API
Crypto CA thread wakes up!

CRYPTO_PKI: Attempting to find OCSP override for peer cert: serial number: XXXXXXXXXXXXXXXXXX, subject name: e=subject name: XXXX@XXXXXXXXXXXXXXXXXX,cn=XXX,ou=XXX,ou=XXX,ou=XXX,dc=XXX,dc=XXX, issuer_name: cn=BFC-Enterprise-SubB,dc=XXX,dc=XXX.
CRYPTO_PKI: No OCSP override via cert maps found. Override was found in trustpoint: BFC-Enterprise-SubB, URL found: http://ca2.domain.local/OCSP.

CRYPTO_PKI: Storage context locked by thread Crypto CA

CRYPTO_PKI: Attempting to find OCSP override for peer cert: serial number: XXXXXXXXXXXXXXXXXX, subject name: e=subject name: XXXX@XXXXXXXXXXXXXXXXXX,cn=XXX,ou=XXX,ou=XXX,ou=XXX,dc=XXX,dc=XXX, issuer_name: cn=BFC-Enterprise-SubB,dc=XXX,dc=XXX.
CRYPTO_PKI: No OCSP override via cert maps found. Override was found in trustpoint: BFC-Enterprise-SubB, URL found: http://ca2.domain.local/OCSP.

CRYPTO_PKI: crypto_pki_get_cert_record_by_subject()
CRYPTO_PKI: Found a subject match
CERT API thread sleeps!

CRYPTO_PKI: Storage context released by thread Crypto CA

CRYPTO_PKI: Blocking chain callback called for OCSP response (trustpoint: BFC-Enterprise-SubB, status: 0)

CRYPTO_PKI: Destroying OCSP data handle 0x00007fffdef71680
CERT_API: PKI Validation callback: status=1 cert_status=0
CERT_API: PKI Validation callback: calling user callback=0x00000000019926e0 with status=0
CERT_API: Close session 0x0bcc97b3 asynchronously
CERT_API: Async unlocked for session 0x0bcc97b3
Crypto CA thread sleeps!
CERT API thread wakes up!
CERT_API: process msg cmd=1, session=0x0bcc97b3
CERT_API: Async locked for session 0x0bcc97b3
CERT_API: Async unlocked for session 0x0bcc97b3
CERT API thread sleeps!

CRYPTO_PKI: Attempting to find tunnel group for cert with serial number: XXXXXXXXXXXXXXXXXX, subject name: e=subject name: XXXX@XXXXXXXXXXXXXXXXXX,cn=XXX,ou=XXX,ou=XXX,ou=XXX,dc=XXX,dc=XXX, issuer_name: cn=BFC-Enterprise-SubB,dc=XXX,dc=XXX.
CRYPTO_PKI: No Tunnel Group Match for peer certificate.
CERT_API: Unable to find tunnel group for cert using rules (SSL)

Is anyone able to help explain what might be happening, please?

Many thanks.

Rahul Govindan · ‎03-30-2017

The OCSP responder on an MS CA is usually picking up its information from its own CDP. The default time that it updates this CDP is 24 hours from what I remember. You might have to manually update your CRL if you are testing this out.

Also, try running the debugs provided in this doc to see if you are seeing the OSCP transactions correctly:

http://www.cisco.com/c/en/us/support/docs/security/adaptive-security-appliance-asa-software/116720-config-asa-ocsp-00.html#anc19

bfbcnet · ‎04-03-2017

Thank you for your reply, Rahul. I tried again the following day and I was then seeing a debug message that said the certificate had been revoked and I was unable to connect to the VPN, so it looked as though it was working but we had not waited long enough.

However, I enrolled for a new user cert on 30/03/17, it was revoked later that day, yet I am still able to successfully connect to the VPN. We have tried publishing the CRL on the server but this has made no difference.

The strange thing is, on the ASA, if I request a CRL from the server, it doesn't show up as a cached CRL.

I don't understand why it seemed to work after a couple of days with one certificate, yet the next certificate was revoked 3 days ago and I am still able to use it.

Rahul Govindan · ‎04-03-2017

That is strange. After you revoked then certificate and updated the CRL on the CA, did you see the certificate serial number in the CRL list? I would run the OSCP debugs again on the ASA to see what response we are getting back from the CA.

Another thought is if you have multiple OSCP responder locations. What does your trustpoint configuration look like? Is the OSCP url in the trustpoint the same as the one present on the user cert?

bfbcnet · ‎04-10-2017

Hi Rahul,

Thank you again for your response, and apologies for the delay in replying. We have had success by just publishing the CRLs on the cert servers - so the ASA was configured correctly all along, it just needs the CRLs to be manually updated. (Unfortunately I am unable to do this myself - it is looked after by another team, so I am unsure exactly what they did to get it to work.)

Many thanks again for your help.