KB ID 0001021 Dtd 09/01/15
% Error in receiving Certificate Authority certificate: status = FAIL, cert length = 0
That's a pretty generic error, and does not give me a lot to go on. So I thought I would try from another network device, (a Cisco Catalyst switch). It's a little easier to 'debug' the process in IOS rather than on the ASA, so that's what I did.
Enable NDES Debugging Petes-Router# debug crypto pki messages Crypto PKI Msg debugging is on Petes-Router# debug crypto pki transactions Crypto PKI Trans debugging is on Petes-Router#
The switch failed with the same error as the firewall but at least now I had some debugging information.
Petes-Router# show logg Jan 4 10:31:11.818: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/21, changed state to up Jan 4 10:32:40.648: CRYPTO_PKI: pki request queued properly Jan 4 10:32:40.648: CRYPTO_PKI: Sending CA Certificate Request: GET /CertSrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&message=PNL-Trustpoint HTTP/1.0 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI) Host: 192.168.1.100 Jan 4 10:32:40.648: CRYPTO_PKI: locked trustpoint PNL-Trustpoint, refcount is 1 Jan 4 10:32:40.656: CRYPTO_PKI: http connection opened Jan 4 10:32:40.656: CRYPTO_PKI: Sending HTTP message Jan 4 10:32:40.656: CRYPTO_PKI: Reply HTTP header: HTTP/1.0 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI) Host: 192.168.1.100 Jan 4 10:32:40.656: CRYPTO_PKI: unlocked trustpoint PNL-Trustpoint, refcount is 0 Jan 4 10:32:40.656: CRYPTO_PKI: locked trustpoint PNL-Trustpoint, refcount is 1 Jan 4 10:32:40.673: CRYPTO_PKI: unlocked trustpoint PNL-Trustpoint, refcount is 0 Jan 4 10:32:40.673: CRYPTO_PKI: Reply HTTP header: HTTP/1.1 200 OK Content-Length: 7946 Content-Type: application/x-x509-ca-ra-cert Server: Microsoft-IIS/8.5 Date: Wed, 07 Jan 2015 10:30:36 GMT Connection: close Content-Type indicates we have received CA and RA certificates. Jan 4 10:32:40.673: CRYPTO_PKI:crypto_process_ca_ra_cert(trustpoint=PNL-Trustpoint) Jan 4 10:32:40.673: CRYPTO_PKI: status = 0x722(E_SIGNATURE_ALG_NOT_SUPPORTED : signature algorithm not supported): crypto_certc_pkcs7_extract_certs_and_crls failed Jan 4 10:32:40.673: CRYPTO_PKI: status = 0x722(E_SIGNATURE_ALG_NOT_SUPPORTED : signature algorithm not supported): crypto_pkcs7_extract_ca_cert returned Jan 4 10:32:40.673: CRYPTO_PKI: Unable to read CA/RA certificates. Jan 4 10:32:40.673: %PKI-3-GETCARACERT: Failed to receive RA/CA certificates. Jan 4 10:32:40.673: CRYPTO_PKI: transaction GetCACert completed Petes-Router#
Here's the slightly less descriptive debug from the ASA firewall.
Petes-ASA(config)# debug crypto ca transactions Petes-ASA(config)# crypto ca authenticate PNL-Trustpoint ERROR: receiving Certificate Authority certificate: status = FAIL, cert length = 0 Petes-ASA(config)# show logg crypto_certc_pkcs7_extract_certs_and_crls failed (1826): crypto_certc_pkcs7_extract_certs_and_crls failed CRYPTO_PKI:crypto_pkcs7_extract_ca_cert returned 1826 Petes-ASA(config)#
I really struggled with this one, the bottom line is the Cisco device can't read the certificates, and the reason it can't is actually shown above;
What this is telling us is that the signature algorithm that Windows Certificate Services is using can not be understood by the Cisco network devices. At first I thought It might be because I was using Windows Server 2012 R2, and it might have some new security feature.
So I built a test Server in VMware Workstation, and presented an ASA and router to it from GNS3 and it worked first time, (annoyingly). When I looked at the certificates and compared them, and took into account the debug above, I spotted the difference.
If the signature algorithm is set to sha1RSA, it works if it's set to RSASSA-PSS it fails. To compound my problem even further I have a three tier PKI deployment with an offline root, intermediate (Sub CA), and an issuing CA (Sub CA). And the signature algorithm needs to be correct for EVERY CERTFICIATE IN THE CERTIFICATE PATH (CHAIN).
Why Has This Happened?
Basically when the offline root was created, I followed the instructions for deploying an offline CA as per the instructions on Technet. Before you even install the role, Microsoft recommend you create a CApolicy.inf file with the following line in it;
I says that this signature algorithm is more secure, but it's not compatible with Windows XP. What IT DOES NOT SAY, is it's incompatible with Cisco devices wanting to get certificates from NDES!
Note: Executing the following command also enables this;
Certutil -setreg CAcspAlternateSignatureAlgorithm 1
What this does is change a registry key, you can revert back by carrying out the following steps;
1. Open regedit and Navigate to;
2. Locate the AlternateSignatureAlgorithm value and change it to 0 (zero).
3. Open a command windows as administrator > Restart certificate services.
WARNING: When renewing the CA Cert MAKE SURE YOU DO NOT generate new keys (or previously issued certificates may stop working!)
If you only have one certificate server you can then simply remove NDES.
What If You Have a Two or Three Tier PKI Deployment
Related Articles, References, Credits, or External Links