none
Revocation server - offline

    Question

  • I have an offline root CA 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, the EventID is 13 on the Event Viewer:

    "Automatic certificate enrollment for XYZ\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 :)

    Tuesday, June 17, 2008 8:47 PM

Answers

  •  

    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.

    Thursday, June 19, 2008 10:22 AM
    Moderator

All replies

  • 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.CRL
    HTTP: 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
    Wednesday, June 18, 2008 5:09 AM
  •  

    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.

    Thursday, June 19, 2008 10:22 AM
    Moderator
  • 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.
    Wednesday, December 16, 2009 3:48 PM
  • 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
    Wednesday, December 16, 2009 3:58 PM
  • 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.
    Wednesday, December 16, 2009 4:14 PM
  • 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.
    Wednesday, December 16, 2009 5:27 PM
  • > I installed this crl on my intermediate CA, manually copying it there from my root and then right clicking it and selecting instal

    in 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.crl
    or 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 CA

    this 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 extensions and reissue all wrong certificats.
    http://www.sysadmins.lv
    Wednesday, December 16, 2009 5:51 PM
  • 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!
    Thursday, May 20, 2010 11:17 PM
  • 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
    Thursday, May 20, 2010 11:46 PM
  • 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

    • Proposed as answer by Onlinejul Friday, April 28, 2017 11:42 AM
    Friday, October 21, 2011 11:29 PM
  • 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

    Saturday, October 22, 2011 5:41 AM
  • 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!

    Tuesday, January 17, 2012 8:41 PM
  • 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

    Tuesday, January 17, 2012 11:06 PM
  • 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.
    • Proposed as answer by uerueluem Thursday, July 12, 2012 9:49 AM
    Thursday, July 12, 2012 9:49 AM
  • I opend a new topic... http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/8d850695-8fec-49a9-9d78-9ec942120658

    • Edited by M K Unify Friday, November 9, 2012 10:28 AM
    Thursday, November 8, 2012 12:31 PM
  • Brian is right, setting the ignoring the CRLF_REVCHECK_IGNORE_OFFLINE flag in a production environment is a terrible idea.

    In my case the problem was just that the CRL for the Root CA had expired, which it does naturally every 6 month by default.  The fix was pretty easy, although somewhat manual: regenerate the .crl file and put it at the URL clients are trying to find it at.

    http://www.concurrency.com/blog/the-revocation-server-was-offline/

    Running "certutil -crl" on the root ca and then copying a file is just as quick, perhaps even easier to do, and is the right way.


    MrShannon | Concurrency Blogs | UAG SP1 DirectAccess Guide | RDS in Server 2012 Guides

    Tuesday, March 25, 2014 4:02 AM
  • We had same issue, but first we renewed the CRL for root CA and copied file to CRL server and just restarted the Sub CA certificate Authority Service.  Once you do that you can renew other server certificate online.

    Just reference I have refer the site

    http://www.coretekservices.com/2014/jun/26/certificate-services-did-not-start-sub-ca

    Thanks

    Vijay Dalimkar

    Pune


    Vijay Dalimkar VCP,MSTS,MCITP,SCSA

    Wednesday, January 7, 2015 2:43 AM
  • I have the same issue and attempted to copy a newly generated CRL from my offline root CA to my domain-joined issuing CA and still service won't start on my issuing CA.

    I followed MrShannon's http://www.concurrency.com/blog/the-revocation-server-was-offline/ solution but didn't work for me. 

    Also, looked at Vijay Dalimkar's:http://www.coretekservices.com/2014/jun/26/certificate-services-did-not-start-sub-ca and looked promising. But, looking at the Details on the CRL Distribution Points on the issuing CA certificate corresponds to CRL Distribution Point on the root CA certificate under Extensions. So, at this point....I'm at a loss.

    Any other suggestions???

    Monday, January 26, 2015 6:17 PM
  • Opened a case with Microsoft and this issue. Our company doesn't have a support contract so luckily, the resolution was minor that the case wasn't charged.

    Turns out, after generating a new CRL from the root CA and copying it to the subordinate CA (%systemroot%\system32\certsrv\certenroll), also need to publish new CRL to Active Directory:

                                             certutil -v -f -dsPublish “FileName.crl”

    After that, AD certificate services started back up again. 

    • Proposed as answer by Rock07 Wednesday, January 28, 2015 4:53 PM
    Wednesday, January 28, 2015 4:53 PM