I first saw this problem a few years ago trying to get some Windows clients to auto enrol with server 2008, then this week my colleagues could not get new 2019 Domain Controller to enrol for a Kerberos certificate, and the this was caused by the same problem.
Symtoms (RPC Error)
1. Test to make sure the client can see the CA, and is able to communicate with it, issue the following command;
[box]
certutil -pulse
[/box]
As you can see above, the first time I ran the command I got the following error;
I then ran the command window ‘as administrator’ and it completed, this was the first inkling I had, that permissions were probably not right.
2. Run mmc on an affected machine, and add in the certificates (local computer*) snap-in. right click the ‘personal container’ > attempt to get the certificate you have published manually.
Problem seen on a Domain Controller (Attempting to get a Kerberos Certificate).
An error occurred while enrolling for a certificate. The Certificate request could not be submitted to the certification authority
Url: {CA Server Path}
Error: the RPC server is unavailable. 0x80076ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)
Problem seen on Windows Client (attempting to enrol for a Computer Certificate).
*Or local user if you are auto enrolling user certificates.
At that point I on the Windows cliebntgot this error;
Active Directory Enrollment Policy
STATUS: Failed
The RPC server is unavailable.
Resolution (Windows Certificate RPC Error)
The most common cause for that error, is the membership of the ‘Certificate Service DCOM Access’ group is incorrect, check yours and make sure it matches the one below.
On the CA Server launch the Certification Authority management tool and look at the properties of the CA Server itself, on the security tab make sure yours looks like this, (Domain computer and domain controllers should have the ‘request certificates‘ rights).
Still on the CA Server, check the permissions on the C:Windows\System 32\certsrv directory, authenticated users should have Read & Execute rights.
This is the change that finally fixed mine: In active directory users and computers, locate the Builtin container, within it there is a group called ‘Users’. Make sure it contains Authenticated Users and INTERACTIVE.
Run a ‘gpupdate /force’ on your test client, and/or reboot it.
Related Articles, References, Credits, or External Links
I needed to change the certificate used by an ADFS server today. I’d used a temporary self signed wildcard cert to get me up and running now I needed to replace it with a new publicly signed one.
I found a number of ways of doing this INCORRECTLY, so hopefully I will save you making the same mistakes!
Solution
Firstly you need to import your certificate, here from a PFX file, (if you want a PFX file import by double clicking the certificate, then export the certificate, include the private key, and set a password on it). I’ve done this in lots of different articles just use the search bar above it you get stuck.
Make sure your certificate has a small key over the icon, or says ‘you have a private key that corresponds to this certificate‘. If yours does not, then import it on the server/PC you created the CSR (Certificate Signing Request) on, then export it to PFX, them import it using the command above on your ADFS server.
On your certificate > All Tasks > Manage Private Keys.
Add > Object Types > Select Service Accounts > Locate and select your ADFS service account. Grant full control.
Launch the AD FS management console > Service > Certificates > Set Service Communication Certificate.
Select the correct (new) certificate > OK.
On the properties of your new certificate locate the thumbprint (not the serial number!) Copy it to the clipboard, then execute the following command;
[box]
Set-AdfsSslCertificate -Thumbprint {Paste in the thumbprint - minus the spaces!}
[/box]
Note: BEWARE: If you press tab to complete the above command make sure you DON’T use Set-AdfsCertificate it’s Set-AdfsSslCertificate(it will accept the wrong command, without error, and then wont work at the end).
Changing ADFS Certificates: Things That Might Go Wrong
Error;
The ServiceCommunications primary certificate cannot be used because the KeySpec must have a value of AT_KEYEXCHANGE (1).
This value can be changed by reimporting the certificate from a pfx file. From an elevated command prompt, use the command “certutil -importpfx filename.pfx AT_KEYEXCHANGE”. For more information, see http://go.microsoft.com/fwlink/?LinkId=798501
You will also see an Event ID 550
Solution: Import the certificate using the ‘certutil -importpfx certificate-name.pfx AT_KEYEXCHANGE‘ syntax.
Error
Solution: Disable certificate rollover with ‘Set-ADFSProperties -AutoCertificateRollover $false‘ syntax. (Note: Dont forget to enable it again afterwards!)
Related Articles, References, Credits, or External Links
A colleague was having some certificate problems onsite the other week. Someone suggested just using Certificate Services to simplify matters. I said I’d spin it up and configure it for him, (I’ve done a lot of Microsoft CA work, search the site!)
My fist question was, “Do they already have certificate services?’, unsurprisingly the answer was “I don’t know”.
So if you’re on a domain, and you want to locate your CA server, or simply find out if you have one, what do you do?
Solution
The simplest option is look in Active Directory Users and Computers, then locate the ‘Cert Publishers’ group and look at its members.
Or you can run adsiedit.msc > CN=Certification Authorities, CN=Public Key Services, CN=Services, CN=Configuration, DC={domain-name},DC={domain-extension}
Easy Option: If you’re lazy, (like me!) Simply run the following command;
[box]
certutil –config – -ping
[/box]
If you don’t have any CA’s this is what you will see;
But if you do (below there is one, but there may be many);
Related Articles, References, Credits, or External Links
Sometimes the services on your CA server will stop and complain about not being able to see your CRL, and some times the service will just refuse to start with the following error;
The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE).
Solution
OK the way to fix this permanently is to fix your CRL and make sure it’s setup properly, a CRL has been published and is in date, and the CA server can see it.
That might take a while, in the mean time, the way to get the services up and issuing is to temporarily stop the CA server checking for CRL services. Open an administrative command window and issue the following command;
Source: AutoEnrollment Description: Automatic certificate enrollment for the local system failed to enroll for one Domain Controller certificate (0x80070005). Access is denied.
Solution
1. Go to your domain controller > Open Active Directory users and computers > Locate the CERTSVC_DCOM_ACCESS group.
2. Add in the “Domain Controllers” group.
3. On your Certification Authority Server > drop to command line and issue the following three commands.
[box]
certutil –setreg SetupStatus –SETUP_DCOM_SECURITY_UPDATED_FLAG
net stop certsvc
net start certsvc
[/box]
Related Articles, References, Credits, or External Links
Certificate enrollment for Local system failed to enroll for a DomainController certificate with request ID N/A from {hostname}{name of CA}(The RPC server is unavailable. 0x800706ba (WIN32: 1722)).
Solution
Note: The pertinent information in the Event ID 13 above is 0x800706ba there are Other causes of this Event ID make sure yours is the same.
In my case I had an Exchange server that was using a certificate that had been “self signed”. And the Root CA that signed the certificate had been ungracefully removed from the domain. Take a note of the Root CA name from the Event ID error shown arrowed).
1. Launch Active Directory Sites and Services” > Select the top level object > View > Show Services Node.
2. Expand Services > Public Key Services > AIA > Delete the “Problem CA”.
3. Then select “Enrollment Services” > Delete the “Problem CA”.
If you have a New CA (in this example you would have seen it in step 2), then DO NOT perform the next two steps!!!
4. Providing you DONT have a CA now, select “Certificate Templates” and delete them all.
5. Providing you DONT have a CA now, select “Public Key Services” and delete the NTAuthCertificates item.
6. To tidy up, (On the server logging the error) run the following command:
[box] certutil -dcinfo deleteBad [/box]
7. Finally on the server logging the error run the following command to update the policies:
[box] gpupdate /force [/box]
Related Articles, References, Credits, or External Links
I was trying to enroll some ASA firewalls to NDES to get some certificates. Each time the process failed with the following error.
[box]
% Error in receiving Certificate Authority certificate: status = FAIL, cert length = 0[/box]
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.
[box]
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#
[/box]
The switch failed with the same error as the firewall but at least now I had some debugging information.
[box]
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#
[/box]
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.
[box]
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 loggcrypto_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)#
[/box]
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;
[box]AlternateSignatureAlgorithm=1[/box]
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;
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.
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
