OCSP issue Anyconnect VPN and ISE as CA+OCSP responder

[mamckenn]

Hi,


My Anyconnect clients are successfully doing cert based authentication to my ASA, and handing off Authorization to ISE. I'm using ISE as the CA and issuer for the client cert, and all is working fine.

I have 4 nodes, 2 PAN/MnT, 2 PSNs.

ISE is 2.2 patch 5, ASA is 9.2(3)


Problem is I cannot get the OCSP responder on ISE working.


On the ASA I have added all ISE's Node, CA-root, endpoint-sub-CA and OCSP responder certs to the Trusted certificate pool, which means I now have 11 Trustpoints on the ASA

I've configured all the endpoint-sub-CA trustpoints to do OCSP revocation checks, pointing to the URL of one of the ISE PSNs.


On ISE i've configured the OCSP Client profile to match the server URL configured above in the ASA's trustpoints.

On the ASA debug I can see the revocation check being attempted against the server I've configured, but keep getting 'Failed to retrieve OCSP for trustpoint' so the revocation check doesn't happen:

Failed to retrieve OCSP for trustpoint: ASDM_TrustPoint0

On the ASA logs I can see:

3    Mar 28 2018    13:58:39    717032                    OCSP status check failed. Reason: OCSP Responder cert validation failed.

3    Mar 28 2018    13:58:39    717032                    OCSP status check failed. Reason: Failed to verify OCSP response.

Which would indicate the ASA is not trusting the OCSP responder cert from ISE - but the cert is installed on the ASA trusted certs pool, and is a trustpoint.

I don't understand why the ASA is rejecting the OCSP responder cert.

Does anyone have any ideas on this?

I have yet failed to find a single document that covers setting up OCSP when you are using ISE as the CA and OCSP responder, so I don't know if i'm missing a step somewhere.

thanks

[Octavian Szolga]

Hi,

Check if the OCSP responder (ISE) cert is self-signed. If not (I assume it's not), maybe this may help you (from the ASA config guide):

The ASA allows a five-second time skew for OCSP responses.
You can configure the ASA to make OCSP checks mandatory when authenticating a certificate by using the revocation-check ocsp command. You can also make the OCSP check optional by using the revocation-check ocsp none command, which allows the certificate authentication to succeed when the validation authority is unavailable to provide updated OCSP data.
OCSP provides three ways to define the OCSP server URL.

The ASA uses these servers in the following
order:
1 The OCSP URL defined in a match certificate override rule by using the match certificate command).
2 The OCSP URL configured by using the ocsp url command.
3 The AIA field of the client certificate.

To configure a trustpoint to validate a self-signed OCSP responder certificate, you import the self-signed responder certificate into its own trustpoint as a trusted CA certificate. Then you configure the match certificate command in the client certificate validating trustpoint to use the trustpoint that includes the self-signed OCSP responder certificate to validate the responder certificate. Use the same procedure for configuring validating responder certificates external to the validation path of the client certificate.

The OCSP server (responder) certificate usually signs the OCSP response. After receiving the response,
the ASA tries to verify the responder certificate. The CA normally sets the lifetime of the OCSP responder certificate to a relatively short period to minimize the chance of being compromised. The CA usually also includes an ocsp-no-check extension in the responder certificate, which indicates that this certificate does not need revocation status checking. However, if this extension is not present, the ASA tries to check revocation status using the same method specified in the trustpoint. If the responder certificate is not verifiable, revocation checks fail. To avoid this possibility, use the revocation-check none command to configure the responder certificate validating trustpoint, and use the revocation-check ocsp command to configure the client certificate.

Regards,

Octavian

[mamckenn · Accepted solution]

Hi Octavian, thanks for the response, you pointed me in the right direction.

All I changed was that I ensured that all the endpoint sub-CA trustpoints on the ASA had a cert map override configured that used the URL of my primary PSN1, and PSN1’s OCSP cert, and that got it working.

Regarding your comment:

>Check if the OCSP responder (ISE) cert is self-signed. If not (I assume it's not)

As the OCSP responder certificate has been created as part of ISE’s CA, I assume it is self-signed.

Although I got it working, it was a lot of trial and error.. and I’m not sure I really understand the flow of what exactly is going on during an OCSP conversation. Are you aware of an OCSP diagram that shows what exactly is happening? It seems that OCSP may not be that complex to configure, but as there is no decent documentation out there around how to do this it was a real headache!

One thing I haven’t been able to work out is how you configure a second cert map override for a second responder.. Is this even possible? If not I assume the only option for HA is to ensure that OCSP fails open by ticking ‘Consider cert valid if revocation info cannot be received’ in the CA endpoint trustpoint configuration?

thanks

[Octavian Szolga]

Hi,

I asked you if it's self-signed or not because my understanding was/is that OCSP functionality uses a separate certificate signed by ISE-CA, not ISE-CA cert itself which indeed is self-signed.

Regarding the flow, someone presents you a cert which you must check. Wikipedia quote:

1. Alice and Bob have public key certificates issued by Carol, the certificate authority (CA).
2. Alice wishes to perform a transaction with Bob and sends him her public key certificate.
3. Bob, concerned that Alice's private key may have been compromised, creates an 'OCSP request' that contains Alice's certificate serial number and sends it to Carol.
4. Carol's OCSP responder reads the certificate serial number from Bob's request. The OCSP responder uses the certificate serial number to look up the revocation status of Alice's certificate. The OCSP responder looks in a CA database that Carol maintains. In this scenario, Carol's CA database is the only trusted location where a compromise to Alice's certificate would be recorded.
5. Carol's OCSP responder confirms that Alice's certificate is still OK, and returns a signed, successful 'OCSP response' to Bob.
6. Bob cryptographically verifies Carol's signed response. Bob has stored Carol's public key sometime before this transaction. Bob uses Carol's public key to verify Carol's response.
7. Bob completes the transaction with Alice.

And another key point that I think was somehow the inital problem as a concept :)

The key that signs a response need not be the same key that signed the certificate. The certificate's issuer may delegate another authority to be the OCSP responder. In this case, the responder's certificate (the one that is used to sign the response) must be issued by the issuer of the certificate in question, and must include a certain extension that marks it as an OCSP signing authority (more precisely, an extended key usage extension with the OID {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) ocspSigning(9)})

Regarding your second question, I don't know if it's possible to configure a second cert map override. You can answer yourself to this question by simply configuring it and checking if it works :)

Thanks,

Octavian