none
AD CS (Certificate Services) revocation errors. How to configure CS with a offline root?

    Question

  •  I'm trying to properly configure a Windows Server 2008 AD CS offline root with an Enterprise subordinate and need some assistance as I'm getting revocation errors.

    Setup:
    Stand-Alone Root CA - Windows Server 2008 Standard - in Workgroup (normally would be offline)
    Enterprise Subordinate CA - Windows Server 2008 Enterprise - In Domain (member server)

    I exported the root ca cert and imported as a trusted root cert on my sub ca.  I copied the request from the sub ca to the root ca, issues a cert, exported and copied back to the sub ca, then installed it.  I published my root crl to it's local drive and then copied it to my sub ca in the same relative path.  The sub ca starts up ok, however it can not issue certificates due to a revocation error.

    I did try this a few times with some minor changes so now I have a few certs for my sub ca from my root ca.

    Event Log Warning:
    Log Name:      Application
    Source:        Microsoft-Windows-CertificationAuthority
    Date:          9/26/2008 1:35:48 PM
    Event ID:      53
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          SYSTEM
    Computer:      Server_C.Company_B.com
    Description:
    Active Directory Certificate Services denied request 60 because The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614).  The request was for CN=User_A, CN=Users, DC=Company_B, DC=com.  Additional information: Error Constructing or Publishing Certificate
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-CertificationAuthority" Guid="{6A71D062-9AFE-4F35-AD08-52134F85DFB9}" EventSourceName="CertSvc" />
        <EventID Qualifiers="33370">53</EventID>
        <Version>0</Version>
        <Level>3</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2008-09-26T17:35:48.000Z" />
        <EventRecordID>6235</EventRecordID>
        <Correlation />
        <Execution ProcessID="0" ThreadID="0" />
        <Channel>Application</Channel>
        <Computer>Server_C.Company_B.com</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData Name="MSG_DN_CERT_DENIED_WITH_INFO">
        <Data Name="RequestId">60</Data>
        <Data Name="Reason">The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614)</Data>
        <Data Name="SubjectName">CN=User_A, CN=Users, DC=Company_B, DC=com</Data>
        <Data Name="AdditionalInformation">Error Constructing or Publishing Certificate</Data>
      </EventData>
    </Event>

    Is this due to an error between the root ca and the sub ca or the sub ca and the client?

    I found some step by step guides for setting up an Enterprise Root CA but not  anything dealing with a stand alone root ca and a sub ca, which seems to be the recomended model.

    I seem to be having trouble with the details of properly setting up the CA's.  Can someone please provide the proper steps on how to setup both?

    Thanks,
    Craig
    Monday, September 29, 2008 12:21 PM

Answers

  •  

    Hi,

     

    This issue can occur if CDP and AIA extensions are not properly created. Here is a best practice guide for implementing PKI,  the “Example Scenario for Contoso” section described how to configure offline root CA in detail.

     

    http://technet.microsoft.com/en-us/library/cc772670.aspx

     

    Hope the information is helpful.

    Wednesday, October 1, 2008 9:52 AM
    Moderator
  • Hi Craig,

    I would also recommend the Best Practives White Paper mentioned by Joson.

    In summary, I believe that the Issuing CA cannot access the CRL published by the Root CA because either

    1) The CDP (CRL Distribution Point) URL in the Issuing CA cert. points to a URL hosted on the Root CA machine, such as http://<RootCAMachine>/<RootCAName>.crl - which is the default

    2) or you have configured a CDP URL at the Root CA, so the Issuing CA cert. contains a reasonable URL. But the CRL file had not been copied yet from the Root CA to this publication server.

    So in a nutshell the processes are:

    # Setup the Root CA
    # Configure CDP (and AIA URL) in the properties of the Root CA, so that they point to an accessible server, URLs must not contain the name of the Root CA machine (which is offline)
    # Publish Root CA certificate and CRL (thus .crt and .crl files) to the configured locations manually
    # Setup the Issuing CA
    # Transfer the request to the Root CA and issue the Issuing CA cert
    # Transfer the Issuing CA cert. back to the Issuing CA
    # Validate the Issuing CA cert. running certutil -verify -urlfetch <IssuingCACert>.crt. This will help you detect any URL problems.
    # If the validation was OK, install the CA certificate.
    # Configure CDP and AIA URLs at the Issuing CA
    # Publish CRLs and the CA certificate (this should later be done by a copy or FTP job)
    # Issue a test certificate
    # Validate the full path including the test certificate running running certutil -verify -urlfetch against it.

    Best regards,
    Elke

     

    • Marked as answer by Craig.B Monday, October 6, 2008 12:46 PM
    Wednesday, October 1, 2008 1:43 PM

All replies

  •  

    Hi,

     

    This issue can occur if CDP and AIA extensions are not properly created. Here is a best practice guide for implementing PKI,  the “Example Scenario for Contoso” section described how to configure offline root CA in detail.

     

    http://technet.microsoft.com/en-us/library/cc772670.aspx

     

    Hope the information is helpful.

    Wednesday, October 1, 2008 9:52 AM
    Moderator
  • Hi Craig,

    I would also recommend the Best Practives White Paper mentioned by Joson.

    In summary, I believe that the Issuing CA cannot access the CRL published by the Root CA because either

    1) The CDP (CRL Distribution Point) URL in the Issuing CA cert. points to a URL hosted on the Root CA machine, such as http://<RootCAMachine>/<RootCAName>.crl - which is the default

    2) or you have configured a CDP URL at the Root CA, so the Issuing CA cert. contains a reasonable URL. But the CRL file had not been copied yet from the Root CA to this publication server.

    So in a nutshell the processes are:

    # Setup the Root CA
    # Configure CDP (and AIA URL) in the properties of the Root CA, so that they point to an accessible server, URLs must not contain the name of the Root CA machine (which is offline)
    # Publish Root CA certificate and CRL (thus .crt and .crl files) to the configured locations manually
    # Setup the Issuing CA
    # Transfer the request to the Root CA and issue the Issuing CA cert
    # Transfer the Issuing CA cert. back to the Issuing CA
    # Validate the Issuing CA cert. running certutil -verify -urlfetch <IssuingCACert>.crt. This will help you detect any URL problems.
    # If the validation was OK, install the CA certificate.
    # Configure CDP and AIA URLs at the Issuing CA
    # Publish CRLs and the CA certificate (this should later be done by a copy or FTP job)
    # Issue a test certificate
    # Validate the full path including the test certificate running running certutil -verify -urlfetch against it.

    Best regards,
    Elke

     

    • Marked as answer by Craig.B Monday, October 6, 2008 12:46 PM
    Wednesday, October 1, 2008 1:43 PM
  • Hi,

    I wanted to thank both of you for posting some answers to point me in the right direction.  I'm still working through everything.  I ran into some other issues with hardware on the server that needed to be resolved. 

    Update:  The problem is resolved and certificates are flowing.

    Thanks,
    Craig
    • Edited by Craig.B Monday, October 6, 2008 12:46 PM
    Friday, October 3, 2008 12:17 PM