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

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

Answer 1

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.