KB ID 0001021
Problem
I was trying to enroll some ASA firewalls to NDES to get some certificates. Each time the process failed with the following error.
% 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#
So we are getting the CA cert and the RA cert from the NDES server but we can’t read them.
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)#
Solution
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;
E_SIGNATURE_ALG_NOT_SUPPORTED
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.
From this point forward, all new certificates issued by this CA will use the older signature algorithm. So if you renew the CA Certificate the new one will be fine.
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.
Then delete the RA certificates used for NDES.
When NDES is reinstalled the new RA certs will use the correct signature algorithm.
What If You Have a Two or Three Tier PKI Deployment
If like me you have a multi tiered PKI deployment, you need to go all the way back to the Root CA > Fix that > Reissue all the Sub CA certs down the certificate path fixing each tier as you go.
Here’s the process I used, (Use at you own risk and I accept no responsibility if you trash your PKI environment).
Related Articles, References, Credits, or External Links
NA
