I'm having a problem in a lab environment where Active Directory Certificate Services cannot issue certificates. First I'll describe the error, and then detail the environment configuration. The reported error: When attempting to sign a certificate request, the Certification Authority mmc snap-in logs it as a failed request, stating “The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).” The 'request disposition message' reports “Error Constructing or Publishing Certificate” - this information is mirrored in the event log as Event ID 53, which provides the same info as stated above. The environment: The environment consists of 2 Windows Server 2008 Standard servers: a domain controller (sc-domain) and the AD CS server (sc-certs), and an XP Pro client (sc-xp.) After promoting the AD server, the AD CS server took on the roles of IIS and an Enterprise Subordinate CA, and its certificate request was signed by an offline root CA (non-Microsoft.) This signed Subordinate CA certificate was imported on the sc-certs AD CS server and the service starts normally without error. A certificate for TLS Web Server Authentication was also generated by the offline root CA for the IIS site to handle secure web enrollment. The CRL distribution point of both the Subordinate CA and the IIS web server certificate (issued by the root CA) point to http://sc-certs.testdomain.local/CertEnroll/test-ca.crl – this CRL is uploaded manually from the offline root CA to the directory hosting this file on the IIS server. The IIS server does not require any type of authentication for access for the CertEnroll subdirectory or the CRLs contained within (demonstrated by access from a system not on the domain without any prompting for credentials.) The offline root CA certificate and the issued Subordinate CA certificate were published via GPO under the nodes Computer Configuration / Policies / Windows Settings / Security Settings / Public Key Policies / Trusted Root Certification Authorities and Intermediate Certificate Authorities, respectively. This GPO was then linked to the OUs holding the domain controller and domain members. Generating the certificate request: A user account was created as a member of Domain Admins and a certificate request for an Enrollment Agent is generated from the web portal at https://sc-certs.testdomain.local/CertSrv (a request was also manually created from the Certificates mmc without change in the original error.) Regardless of whether this certificate request is passed to AD CS via the web portal or manually via an X.509 certificate request (PKCS#10) and submitted manually via the Certification Authority mmc on the server, the error is the same as stated at the top of this problem description. What is known to be working in the environment: The trust chain is working correctly, including CRL verification. The IIS secure site at https://sc-certs.testdomain.local/CertSrv is correctly identified as a trusted, secure site, and examing the certificate presented reveals a verified trust chain up to the root CA. pkiview.msc on the AD CS server (sc-certs) also confirms the trust chain, including the CRL of both the root CA and the Subordinate CA (hosted at http://sc-certs.testdomain.local/CertEnroll/test-ca.crl .) All the certificates and CDP/CRL locations report OK, and the CRLs are viewable from the listed location. Additionally, the CRL for the Subordinate CA is available via LDAP at ldap:///CN=testdomain-SC-CERTS-CA,CN=sc-certs,CN=CDP,CN=Public%20%Key%20Services,CN=Services,CN=Configuration,DC=testdomain,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint (this and the delta CRL are published via both http and ldap as indicated above.) To clarify, ALL of these CDP locations verify correctly in the pkiview.msc mmc console, showing that both the trust chain and CRL verification are working properly. Additional troubleshooting steps performed: Pursuant to http://technet.microsoft.com/en-us/library/cc726352%28WS.10%29.aspx regarding Event ID 53 under Sever 2003, all relevant troubleshooting steps have been performed, and no failures result. Of particular relevance given the stated error checking the revocation status, the CRL signed by the root CA is verified and reports no problems when checking the certificate chain for both the Subordinate CA and the root CA. To clarify more fully based on the recommendations in the referenced article: the AD user has a DNS name for the domain in question; the certificate chain verifies (that is both the root CA and Subordinate CA verify without issue in both pkiview.msc and via certutil -urlfetch -verify <cert.crt>); both CRLs (that for the root CA and Subordinate CA) are properly published and visible from the listed http URLs; manually publishing to AD has no effect as the certificates and CRLs are already published; the Subordinate CA CRL is published to the LDAP path listed above and confirmed as availble via adsiedit, pkiview, and certutil; certutil -getreg ca\crlpublicationurls reports both the web and LDAP CRL Distribution Point locations without error; and the user requesting the certificate is a domain admin and permissions on the template in question have been verified as permissive to this request. Where to go from here? Given that none of the verification steps relating to trust chain and CRL verification fail, I am left with no idea why the AD CS service reports that the revocation server is offline. With pkiview actively verifying the http and ldap URLs and positive results when directly downloading the CRLs from these locations, I'm unable to find any additional information that may be relevant to this situation and error. Suggestions are more than welcome. Thanks.