Cert Renewal – RPC Server Unavailable

Question

If this is not the correct place to post this, a link to the correct place would be much appreciated.

Setup: We have our own PKI infastructure with a stand-alone Server 2019 CA and a domain joined Server 2019 Sub-CA joined to the domain as a member server. It’s not a DC or BDC. The problem is with the Sub-CA.

History: A few months back we had to reload the DC from scratch. To prep for this, I did a backup of the Sub-CA per the guidance at https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/move-certification-authority-to-another-server  Then I uninstalled the CA services and disjoined this server 2019 computer from the domain.

After wiping and reloading the DC from scratch using the same domain name and all that stuff, I joined the Sub-CA server 2019 member server to the new domain, installed CA services and restored from the backup. All works fine as I’ve had no issues requesting and issuing certs. However, the end of last month the machine certificate for the Serve 2019 Sub-CA computer expired and did not auto-renew.

In my troubleshooting I’ve made forward progress in solving/fixing this. But now I’m at a point where I’m lost and don’t know where to go next. Here’s what I’m doing on the CA member server.

-          Run certlm.msc

-          Right-Click on Personal, select All Tasks – Request New Certificate. The Certificate Enrollment wizard opens.

-          Click Next, and on the Select Certificate Enrollment Policy screen I’m presented with two options:

o   Configured by your administrator
Active Directory Enrollment Policy

o   Configured by You
<The CA computer name)

-          I select Active Directory Enrollment Policy, then click Next.

-          On the Request Certificates screen I’m presented 2 options

o   OCSP response signing

o   Computer

-          Both certificates are expired. So I select the checkbox for both, then click the Enroll botton.

-          At this point I get a messagebox popup that reads, “An error occurred while enrolling for a certificate. The certificate request could not be submitted to the certification authority. URL: <computername.domain>.local<friendlyname>
Error: The RPC Server is unavailable. 0x800706ba (WIN32: 1722 RCP_S_SERVER_UNAVAILABLE)

I don’t know where to go from here, and really could use some help.

 

Answer 1

Hi Carl Burch

it seems a network issue. Check if the RPC ports required for certificate enrollment are already opened. ( TCP 135 and dynamic s)port

Certificate Services (Port Requirements)

Please don't forget to mark helpful answer as accepted

Answer 2

Well, got the machine cert and the OSCP cert renewed. But now, when I re-enable revocation check, the certsvc service stops, and will not restart.

To originally disable revocation check I ran certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

To re-enable it I ran certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

Basically, just changed the plus sign to a minus sign. After executing the command, certsvc stops, and when I restart it, it won't stay running. If I disable revocation check again, then it stays running.

Answer 3

....aaaaaaand once again! I've managed to solve it, but not on my own. Another IT friend of mine suggested I check not just the expiration date of the CRL in question, but the effective date also. Doing so revealed what I should have seen and realized from the get-go. This particular CRL was good for a year, having expired just a few days ago. The only CRL with that long a period would have been issued by the offline Root CA. So............

Solution: When setting up my PKI environment, the CDP was manually published to the Subordinate CA for security reasons (the Root CA should be turned off most of the time). That being said, manually generating a new CRL from the Root CA, coping it over to the Subordinate CA's directory that is publishing the CRL, and restarting the Active Directory Certificate Services service did the trick for me.

To manually generate the CRL from the Root CA

1. Open up Active Directory Certificate Services (Start->Administrative Tools->Certification Authority)
2. 2. Under Certificate Authority, expand your CA, right click on Revoked Certificates, and select All Tasks -> Publish.
3. Click New CRL when the Publish CRL dialog box pops up and click OK
4. Navigate to the directory where the CDP gets published via Windows Explorer The default directory for this is usually at C:\Windows\System32\CertSrv\CertEnroll
5. Copy the YourCAName.crl file to an external hard drive to copy over to your subordinate ca.

Importing the CRL on the subordinate CA

1. On the machine hosting the on-line Subordidate CA server Open up IIS Manager (Start->Administrative Tools->Internet Information Services (IIS) Manager
2. Expand the server, Sites, Default Web Site, and right click on CDP, select Explore. In my particular case, I had to right click on CERTDATA and Explore since I already knew that's where CRL is located.
3. Copy the CRL we generated from the Root CA to the directory that just opened (if your certificate authority was working before, replace the old CRL with this one).
4. Click Start->Administrative Tools->Services
5. Right click on Active Directory Certificate Services and select Restart (or Start if the service blew up like mine)
6. To re-enable revocation checking, from an administrative command prompt enter: certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE
7. It may be necessary to restart the Active Directory Certificate Services again. (Steps 4 & 5 above) All is well now.

Answer 4

Hi @Carl Burch

Thank you for your feedback.

I will put your answer here to be able to close your thread:

.aaaaaaand once again! I've managed to solve it, but not on my own. Another IT friend of mine suggested I check not just the expiration date of the CRL in question, but the effective date also. Doing so revealed what I should have seen and realized from the get-go. This particular CRL was good for a year, having expired just a few days ago. The only CRL with that long a period would have been issued by the offline Root CA. So............

Solution: When setting up my PKI environment, the CDP was manually published to the Subordinate CA for security reasons (the Root CA should be turned off most of the time). That being said, manually generating a new CRL from the Root CA, coping it over to the Subordinate CA's directory that is publishing the CRL, and restarting the Active Directory Certificate Services service did the trick for me.

To manually generate the CRL from the Root CA

1. Open up Active Directory Certificate Services (Start->Administrative Tools->Certification Authority)
2. Under Certificate Authority, expand your CA, right click on Revoked Certificates, and select All Tasks -> Publish.
3. Click New CRL when the Publish CRL dialog box pops up and click OK
4. Navigate to the directory where the CDP gets published via Windows Explorer The default directory for this is usually at C:\Windows\System32\CertSrv\CertEnroll
5. Copy the YourCAName.crl file to an external hard drive to copy over to your subordinate ca.

Importing the CRL on the subordinate CA

1. On the machine hosting the on-line Subordidate CA server Open up IIS Manager (Start->Administrative Tools->Internet Information Services (IIS) Manager
2. Expand the server, Sites, Default Web Site, and right click on CDP, select Explore. In my particular case, I had to right click on CERTDATA and Explore since I already knew that's where CRL is located.
3. Copy the CRL we generated from the Root CA to the directory that just opened (if your certificate authority was working before, replace the old CRL with this one).
4. Click Start->Administrative Tools->Services
5. Right click on Active Directory Certificate Services and select Restart (or Start if the service blew up like mine)
6. To re-enable revocation checking, from an administrative command prompt enter: certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE
7. It may be necessary to restart the Active Directory Certificate Services again. (Steps 4 & 5 above) All is well now.