Certificate Enrollment on ASA

Unanswered Question

I'm having trouble loading a digital certificate on an ASA 5520 running 8.0(4). The CA is a Fedora Dogtag Certificate System with a very simple PKI scheme running (O=CM TEST). All of this is running on an isolated test network in a lab setting.

I'm able to enroll two ISRs (2800 and 3800) without issue to the CA using SCEP, but the ASA fails to parse the certificate response generating a "crypto_certc_pkcs7_extract_certs_and_crls failed (1795)" error message.

I've attached the relevant ASA config and debug output below. Manual enrollment (through both the ASDM and CLI) fails as well.

Any help is appreciated.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)

Have you authenticated the trustpoint yet? I have only done this process manually, but if I were configuring a new device I would perform the following steps:

crypto ca trustpoint tp_MyCA

crl optional

enrollment terminal

subject-name CN=vpn.mydomain.com,OU=IT,O=CompanyName,C=US,St=State,L=City

crl configure

crypto ca authenticate tp_MyCA

then paste the root certificate in

type quit, then accept the certificate.

crypto ca enroll tp_MyCA% Start certificate enrollment ..

% The fully-qualified domain name in the certificate will be: vpn.yourdomain.com

% Include the device serial number in the subject name? [yes/no]: no

Display Certificate Request to terminal? [yes/no]: yes

Certificate Request follows:

Copy your CSR and deliver it to the CSA. Get your certificate back and:

crypto ca import tp_MyCA certificate

paste in your certificate

then "quit", then associate the certificate with an interface:

ssl trust-point tp_MyCA OUTSIDE

That would be how you would do it manually.

if I had to guess based on the limited amount of config data, I would say you need to authenticate the trustpoint and you will be fine.

The CA authenticates without a problem, both via SCEP and cut-and-paste to the terminal. Whats failing is extracting the identity cert and/or crl from the pkcs7 message received from the CA to complete enrollment. As far as the CA is concerned, the process completes successfully and the ASA is enrolled.

At first, I thought a number of things could be the issue:

1) The DN in the certificate request is

"CN=VPNSvr1.cm.net,OU=ROUTERS,O=CM TEST", however the DN in the enrolled cert from the CA is "UNSTRUCTUREDNAME=VPNSvr1.cm.net, CN=VPNSvr1.cm.net, OU=ROUTERS, O=CM TEST". I thought that perhaps the ASA was failing because the DN was different, but I was able to correct this with the "fqdn none" statement for the trustpoint.

2) The ASA isn't finding a crl in the pkcs7 message (there isn't one), and is perhaps failing for this reason. I also noticed that the "revocation-check none" command wasn't showing up in the trustpoint configuration even though I had entered the command multiple times from the command-line and the ASDM. This was happening while running 8.0(3), but after an upgrade to 8.0(4) the "revocation-check none" command began to stick.

3) The enrolled certificate received from the CA contains two Key Usage extensions ( The first is non-critical for Digital Signature and Key Encipherment. The second is Critical and is for Digital Signature, Key Encipherment, Non Repudiation, and Data Encipherment. The original certificate request from the ASA specifies a Key Usage extension matching the first, and the Router Certificate Profile on the CA specifies the second Key Usage extensions.

I'm not trying to do anything fancy at this point, and the configuration should be straightforward. Obviously there is some configuration mismatch between what the ASA is expecting and what my CA is delivering. I know this isn't a SCEP issue, because I get the same result via a cut & paste to the terminal as well. Plus the two ISRs that I also have running in the lab enrolled without any issue whatsoever.

If additional debug or config info would be helpful, just let me know what it is.

Ok, I hadn't seen that. Thanks. But I'm pretty sure the DogTag system is recently open-sourced version of Netscape's CMS?

Anyway, I did some poking around and was able to get the cert loaded on the ASA. I had to modify the caRouterCert profile on the CA to remove the Key Usage extension that is populated by default. So it seems that its not that the DogTag system isn't supported, only that the default certificate profile used for SCEP enrollment isn't compatible with the ASA.

Is there a specification for a valid certificate profile for the ASA somewhere?


This Discussion