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.
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 (188.8.131.52). 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?
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...