AIA | PeteNetLive

KB ID 0000473

Problem

Event ID 6

Source: Microsoft-Windows-CertificateServicesClient-AutoEnrollment

Description:

Automatic certificate enrollment for local system failed (0x800706ba) The RPC server is unavailable.

Event ID 13

Source: Microsoft-Windows-CertificateServicesClient-CertEnroll

Description:

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]

Problem

I seem to have done a lot of PKI the last 18 months. This week I needed an OCSP server deploying for the CA server on my test bench so I took the time to document it for future use. One of the most overlooked parts of a PKI deployment, is how to cope with ‘revoking’ certificates.

Traditionally this has been done with a CRL, but there is a downside to CRL’s. Network devices tend to cache them, and they don’t get updated as often as they should. Which is why OCSP is a lot better, it runs as a service and answers revocation requests immediately.

Solution

This is a walk though on configuring OCSP, I’m assuming you already have your PKI and your CRL is already setup, if not take a look at the following article;

Windows Certificate Services – Setting up a CRL

1. Launch the certificate services management console > Certificate Templates > Manage.

2. Locate the OCSP Response Signing Certificate > Properties.

3. Security Tab > Add in the server that will be hosting the OCSP service, (I always use the same server that’s serving my CRL).

4. Grant the server read and enroll rights > Apply > OK.

5. Then issue the OCSP Responder Template.

6. Open the properties of the Certificate Services Server.

7. Extensions Tab > Change the drop-down to Authority Information Access (AIA) > Add >Enter the URL of the server that will serve OCSP, this will need to be resolvable internally and of the service is presented to the outside works the URL will need registering in public DNS > OK.

8. Select the URL you have just entered > Tick ‘Include in the online certificate status protocol (OCSP) extension’ > Apply > OK.

9. On the server that you want to install the OCSP service > Launch Server Manager > Manage > Add Roles and Services > Add in the Active Directory Certificate Services Role.