Certificate issues Active Directory Certificate Services could not process request 3699 due to an error: The revocation function was unable to check revocation because the revocation server was offline. 0x80092013

Question

_{Monday, December 15, 2014 1:52 PM}

Hi,

We have some problems with our Root CA. I can se a lot of failed requests. with the event id 22: in the logs. The description is: Active Directory Certificate Services could not process request 3686 due to an error: The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).  The request was for CN=xxxxx.ourdomain.com.  Additional information: Error Verifying Request Signature or Signing Certificate

A couple of months ago we decomissioned one of our old 2003 DCs and it looks like this server might have had something to do with the CA structure but I am not sure whether this was in use or not since I could find the role but I wasn't able to see any existing configuration.

Let's say that this server was previously responsible for the certificates and was the server that should have revoked the old certs, what can I do know to try and correct the problem?

Thank you for your help

//Cris

All replies (4)

_{Thursday, December 18, 2014 7:58 AM ✅Answered}

hello,

let me recap first:

you see these errors on a ROOT CA. so it seems like the ROOT CA is also operating as an ISSUING CA. Some clients try to issue a new certificate from the ROOT CA and this fails with your error mentioned.

do you say that you had a PREVIOUS CA which you decomissioned, and you now have a brand NEW CA, that was built as a clean install? When you decommissioned the PREVIOUS CA, that was your design decision to don't bother with the current certificates that it issued and which are still valid, right?

The error says, that the REQUEST signature cannot be validated. REQUESTs are signed either by itself (self-signed) or if they are renewal requests, they would be signed with the previous certificate which the client tries to renew. The self-signed REQUESTs do not contain CRL paths at all.

So this implies to me as these requests that are failing are renewal requests. Renewal requests would contain CRL paths of the previous certificates that are nearing their expiration.

As there are many such REQUEST and failures, it probably means that the clients use AUTOENROLLMENT, which tries to renew their current, but shortly expiring, certificates during (by default) their last 6 weeks of lifetime.

As you decommissioned your PREVIOUS CA, it does not issue CRL anymore and the current certificates cannot be checked for validity.

Thus, if the renewal tries to renew them by using the NEW CA, your NEW CA cannot validate CRL of the PREVIOUS CA and will not issue new certificates.

But it would not issue new certificates anyway even if it was able to verify the PREVIOUS CA's CRL, as it seems your NEW CA is completely brand new, without being restored from the PREVIOUS CA's database. Right?

So simply don't bother :-) As long as it was your design to decommission the PREVIOUS CA without bothering with its already issued certificates.

The current certificates which autoenrollment tries to renew cannot be checked for validity. They will also slowly expire over the next 6 weeks or so. After that, autoenrollment will ask your NEW CA to issue a brand new certificate without trying to renew. Just a clean self-signed REQUEST.

That will succeed.

You can also verify this by trying to issue a certificate on an affected machine manually from Certificates MMC.

ondrej.

_{Monday, December 15, 2014 7:00 PM}

If the server that was removed was your Root CA then that would cause this problem. One thing you can do to determine what the problem is is log onto your CA that is causing this problem and go to the %windir%\system32\certsrv\certenroll folder in a command prompt. In there you will see a .CRT certificate (possibly some with paranthesis in the name). Find the newest one and run the following command against it (please share the output).

certutil -urlfetch -verify <yourcrtfilehere.crt>

In the output, it will list the CA names in the chain but will also list the CDP locations and by default the LDAP (Active Directory) locations use the machine name in the distinguished name, so we might be able to look at it that way.

Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years.

_{Friday, December 19, 2014 2:04 AM}

Hi Cris,

Have you tried Mark's suggestion?

Best Regards,

Amy

Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Friday, December 19, 2014 12:15 PM}

Hi Mark and Ondrej,

The old CA and the "new" have in fact been running together for a while(without my knowledge). I was not aware that the old Ca was a Root CA hence when this was removed we started seeing these errors. I have checked some servers and it seems like Ondrej's explanation is exactly how it has worked in my environment. The "new" CA has not been able to renew/revoke the old certs that were issued by the old CA but it has been able to issue new certs with the current Root CA so I guess this part actually works ok

Thank you both for your input :)

//Cris