I have an offline rootCA and an issuing CA. I am getting EventID 96 on the Event Viewer on the Issuing CA."Certificate Services could not create an encryption certificate. Requested by XYZ\administrator. The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)." On the new laptop or server side, theEventID is 13 on the Event Viewer:"Automatic certificate enrollment forXYZ\administrator failed to enroll for one WirelessUserAccess certificate (0x80092013).The revocation function was unable to check revocation because the revocation server was offline"When I use PKIView on the Issuing server to check the CDP Container in Manage AD Containers, I see my issuing CA and Root CA have both expired.What do I have to do to get the CRL working again so my users can receive a certification on their machine? Thanks for all your help :)

OK, well the first thing you have to do is manage CRL publication better... much better in fact.1st of all, let's address the easy one, the issuing CA.The CRL is published based on the interval configured at the issuing CA. You must ensure that the updated CRL is copied to *all* locations configured for the CDP extension of the issuing CA. This may mean a scheduled task that copies the updated CRL (and delta CRL if implemented) to the Web server or LDAP server.Secondly, the offline root CA. This is definitely a manual publication (since the root CA is offline).You must publish the root CA's CRL again to every location referenced in the certificates issued by the root CA.LDAP: Typically, if the URL is not mangled, you would use certutil -dspublish CRLFILE.CRLHTTP: Manually copy the CRL to the location referenced in the HTTP URL.A well managed PKI would not be running into these issues.To get more details, check out each URL in the PKIView.msc console. (for each CA in the hierarchy)Brian

Hello, Yes, a Windows Server 2003 CA will always check revocation on all certificates in the PKI hierarchy (except the root CA certificate) before issuing an end-entity certificate. However in this situation, a valid Certificate Revocation List (CRL) for one or more of the intermediate certification authority (CA) certificates was not be found since the root CA was offline. This issue may occur if the CRL is not available to the certificate server, or if the CRL has expired. You may disabled the feature that checks revocation on all certificates in the PKI hierarchy with the following command on the CA: certutil setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE It returns as follows: ============== C:\>certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\SEASUB01\CRLFlags Old Value: CRLFlags REG_DWORD = 2 CRLF_DELETE_EXPIRED_CRLS -- 2 New Value: CRLFlags REG_DWORD = a (10) CRLF_DELETE_EXPIRED_CRLS -- 2 CRLF_REVCHECK_IGNORE_OFFLINE -- 8 CertUtil: -setreg command completed successfully. ============== Then restart the CA. For your reference: Custom CA Configuration--->Ignore Offline CRL Errors on the CA: http://technet2.microsoft.com/WindowsServer/en/library/f29fc69b-de1a-45ba-a0dd-a6b3d05137341033.mspx?mfr=true Online Enterprise Issuing CAs: http://technet2.microsoft.com/WindowsServer/en/library/4276821f-162f-4a8d-8441-65302da8d8b71033.mspx?mfr=true Hope it helps.

I have had this same issue between an offline root CA and an intermediate CA. I just want to know if temporarily disabling the CRL check is best practices. My root CA is offline. I manually export a request from my intermediate CA and import it into my root CA. I then export the certificate from my root CA (crt file) and import that into my intermediate CA and I get the "The revocation function was unable to check revocation because the revocation server was offline" error message when I try to start the certificate sercives. Is disabling the crl check ok to do in this instance? I searched for a .crl on the root CA and did not find one. I am guess the root CA has no crl. is this correct? Thank you very much for any responses.

No, that is absolutely the wrong thing to do, as you are not fixing the problem and will be unable to use any certificates issed by the intermediate CA.If your root CA has no CRLs (would be in C:\windows\system32\certsrv\certenroll), then you have a misconfigured root CA.1) What CDP extensions are defined at the root CA for issued certificates?2) What AIA extensions are defined at the root CA for issued certificates?3) Are there CDP extensions in the actual root CA certificate?4) Are there AIA extensions in the actual root CA certificate?5) Have you published/copied the root CA certificate and CRL to all referenced locations?You must know all of these and have them properly configured before you start issuing certificates.If your intermediate CA is also offline (not sure, you have not described your CA hierarchy), then you need to manually add the root CA certificate and CRL to the intermediate CA's cache.certutil -addstore root CAcert.crtcertutil -addstore root CAcrl.crlBrian

Wow that response was QUICK! Yes my root does have crls (I was looking in the wrong place) I installed this crl on my intermediate CA, manually copying it there from my root and then right clicking it and selecting install. After doing this I still could not start the service as I got the same error message. Do I need to reboot this server? My question is this though, if my root CA is ALWAYS going to be offline and completely removed from the network then how could my intermediate CA ever be able to reach it to verify the crl? The crl distribution point for root certificate are: http://caroot/CertEnroll/CAroot.crl file://\\caroot\certenroll\caroot.crl I must profess my ignorance here- I am not sure how to find the CDP and AIA extensions. --edit To add more info what I want to setup is an offline root ca, an online intermediate CA and an enterprise issuing ca.

Ok I have decided to do the following, though I am still wondering if this is good procedure: My hierarchy looks like this: ROOT CA (OFFLINE) INTERMEDIATE CA (could be OFFLINE or ONLINE haven't decided yet) ENTERPRISE SUBORDINATE ISSUING CA (ONLINE of course) What I am going to do is disable CRL checking on the intermediate and enterprise subordinate CA just to get everything up and going after which I will change the CDP and AIA extensions on all three server to point to the ENTERPRISE SUBORDINATE CA. If I do this will I have to bring the ROOT CA and INTERMEDIATE CA online from time to time in order to keep their CRLs up to date? Any responses are much appriciated.

> I installed this crl on my intermediate CA, manually copying it there from my root and then right clicking it and selecting instalin that case CRL is installed in your CurrentUser store, but it MUST be installed in LocalMachine store. As Brian is sayed, you must use:certutil -addstore root path\file.crlor open MMC -> Certificates, point snapin to Computer account context and manueally add this CRL.> My question is this though, if my root CA is ALWAYS going to be offline and completely removed from the network then how could my intermediate CA ever be able to reach it to verify the crl?you will need to start your Offline CA to publish new CRLs (before previous will expire) and move (for example using flash drives) to CDP location point (in your case to web server that hosts HTTP url in CDP/AIA extensions). You MUST NOT use HTTP URLs that points to the same CA server, because most time this server will offline and files will become unavailable. HTTP URLs MUST be pointed to any web server that is always online.> What I am going to do is disable CRL checking on the intermediate and enterprise subordinate CAthis is impossible, because clients will unable to check each certificate in prospective certification path for revocation status (you cannot disable this check for them).What you should to do? If current Root/Inermediate CAs CDP and AIA URLs points to themselves, you will need to reconfigure CDP and AIA extensionsand reissue all wrong certificats.http://www.sysadmins.lv

Hi, I made the mistake of running the command "certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE". While it solved my problem initially, I resolved the real problem with the CRL and now I need to undo this command. Can you please provide the syntax to to do this? Thanks!

On Thu, 20 May 2010 23:17:11 +0000, AshHoliday wrote: > Hi, I made the mistake of running the command "certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE". While it > solved my problem initially, I resolved the real problem with the CRL and now I need to undo this command. Can you please provide > the syntax to to do this? Thanks! certutil -setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE -- Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca Paul Adare CTO IdentIT Inc. ILM MVP

I was just brought into a project where there is no CRL distrobution listed in the offline root. It is a 3 tier setup and certificates have already been issued by the issuing CA. Can I use certutil -dspublish to rectify this retoactively? can I edit the cert and try and push it out? or do I have to create a new one because of obvious and unforseen issues? Thank you Jesse

On Fri, 21 Oct 2011 23:29:07 +0000, jbagel206 wrote: I was just brought into a project where there is no CRL distrobution listed in the?offline root. It is a 3 tier setup and?certificates have already been issued by the issuing CA. Can I use certutil -dspublish to rectify this retoactively? can I edit the cert and try and push it out? or do I have to create a new one because of obvious and unforseen issues? The root certificate should not have a CDP listed in it as there's no point in checking to see if a root CA certificate has been revoked. According to the RFC an application should stop revocation checking one level below the top of the trust chain. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca Base 8 is just like base 10, if you are missing two fingers. -- Tom Lehrer

No, that is absolutely the wrong thing to do, as you are not fixing the problem and will be unable to use any certificates issed by the intermediate CA. If your root CA has no CRLs (would be in C:\windows\system32\certsrv\certenroll), then you have a misconfigured root CA. 1) What CDP extensions are defined at the root CA for issued certificates? 2) What AIA extensions are defined at the root CA for issued certificates? 3) Are there CDP extensions in the actual root CA certificate? 4) Are there AIA extensions in the actual root CA certificate? 5) Have you published/copied the root CA certificate and CRL to all referenced locations? You must know all of these and have them properly configured before you start issuing certificates. If your intermediate CA is also offline (not sure, you have not described your CA hierarchy), then you need to manually add the root CA certificate and CRL to the intermediate CA's cache. certutil -addstore root CAcert.crt certutil -addstore root CAcrl.crl Brian Brian, Thanks for this! I wish that it weren't possible for anyone but the original poster to mark their own posts as "the answer". In my case, I had an offline standalone root ca that was installed on a domain-joined server. So everyone already knew about the CA Cert... I just needed to run certutil -addstore root CAcrl.crl and then I restarted my subordinate enterprise ca. Everything works now, thanks! I assume that this happened because the root CA's CRL expired and then was offline and unable to provide a new one? If so, how can I configure the root CA to generate a CRL that is valid for a very long time? Thanks!

Trust me, a long time is still a time that you are going to forget about <G> You should look at publishing an updated CRL every 6 months or every year. You can log in at the root CA, Run the Certification Authority console, right-click Revoked Certificates, and define the validity period for the base CRL. Be sure to disable the delta CRL (0 days). You then need to restart ADCS. Once it restarts, right-click and publish an updated CRL. You then need to distribute it everywhere (manually to offline CAs and then to the CRL publication points included in the certificates issued by the root CA. HTH, BRian

That's exactly what i did and it solved my issue. additional information: check the place where your IssuingCA gets the CRT and CRL from and put both files from the RootCA to the IssuingCA's folder and try to restart the ADCS Service Generating the CRT/CRL-File can also done mannualy on the RootCA in the Certification Manger AddIn and Publish the Revocation-Folder.