Cisco ASA, OCSP

I have successfully operating OpenSSL OCSP responder with this hierarchy:
RootCA > OCSP responder (signed by RootCA).

I have deployed a trustpoint (named RootCA) into the ASA with RootCA public key. So I expect that ASA will be trust to OCSP, because it’s trusts to RootCA which signed OCSP sign key. But seems it is not. Due to VPN client connection I have

CRYPTO_PKI: Blocking chain callback called for OCSP response <…> status: 2

debug message, which indicating a problem with certificate signer, according to BRKSEC-3053
https://clnv.s3.amazonaws.com/2015/usa/pdf/BRKSEC-3053.pdf

So, I did import the OCSP key into separate trustpoint (named OCSP) and did create a certificate map with overriding OCSP rule. The revocation check hierarchy now looks like this:

VPN client > RootCA > certificate map > OCSP responder.

With that scheme, the OCSP responces are trusted and revocation check completed successfully.

My questions are:

  1. Do we really need a separate trustpoint for OCSP signing key ?
  2. Or this is expected behavior with OCSP responder implementation in OpenSSL ?
  3. Or maybe I have missed something important ?

Thank you!

Continue reading Cisco ASA, OCSP

Cisco ASA, OCSP

I have successfully operating OpenSSL OCSP responder with this hierarchy:
RootCA > OCSP responder (signed by RootCA).

I have deployed a trustpoint (named RootCA) into the ASA with RootCA public key. So I expect that ASA will be trust to OCSP, because it’s trusts to RootCA which signed OCSP sign key. But seems it is not. Due to VPN client connection I have

CRYPTO_PKI: Blocking chain callback called for OCSP response <…> status: 2

debug message, which indicating a problem with certificate signer, according to BRKSEC-3053
https://clnv.s3.amazonaws.com/2015/usa/pdf/BRKSEC-3053.pdf

So, I did import the OCSP key into separate trustpoint (named OCSP) and did create a certificate map with overriding OCSP rule. The revocation check hierarchy now looks like this:

VPN client > RootCA > certificate map > OCSP responder.

With that scheme, the OCSP responces are trusted and revocation check completed successfully.

My questions are:

  1. Do we really need a separate trustpoint for OCSP signing key ?
  2. Or this is expected behavior with OCSP responder implementation in OpenSSL ?
  3. Or maybe I have missed something important ?

Thank you!

Continue reading Cisco ASA, OCSP