NDES – Fails to Issue Certificates (Signature Algorithm)

KB ID 0001021 Dtd 09/01/15

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.

Signature Algorithm

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).

CA Certificate Path

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;

AlternateSignatureAlgorithm=1

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;

HKEY_LOCAL_MACHINE >SYSTEM > CurrentControlSet > Services > CertSvc > Configuration > {SERVER-NAME} > CSP

2. Locate the AlternateSignatureAlgorithm value and change it to 0 (zero).

Alternate Signature Algorithm

3. Open a command windows as administrator > Restart certificate services.

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!)

Use Same Keypair

If you only have one certificate server you can then simply remove NDES.

Remove NDES

Then delete the RA certificates used for NDES.

Remove NDES Certificates

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

Author: Migrated

Share This Post On