none
Problem with Revocation check of domain controller certificate with Win2k8 R2

    Pergunta

  • I seem to have come across an issue that there isn't alot of information on.  maybe you all can help me out.

    I work for the US Army.  They have a vast AD forest.  So AD controllers are not local.  I'm building windows 2008 R2 TS servers to host my Citrix XenApp6 farm, and when trying to RDP into the servers with a CAC card I get the following error:

    "The system could not log you on.  The revocation status of the domain controller certificate used for smart card authentication could not be determined."

    Only happens on my 2008 R2 servers.  I have installed all the normal DoD software that is used to help facilitate CAC login (ActivClient-middleware, Tumbleweed-CRL checking).  I have talked with both vendors.  No one has alot of experience with R2 and CAC login.  I removed tumbleweed, since it deals with revocation, and that did not help.

    I figure out the box the server should be able to take my CAC login.  So I built a fresh server with no GPO and just middleware and tumbleweed, and I get the same error.  I do not have this problem with any other OS.  I've tried different RDP clients (Win7, Vista) and they both display the error. 

    I have seen issues on this forum with RDP and CRL checking for SSL/TLS communication with Win7 and 2008 R2.  Nothing that seems to deal with smartcards, but its the same concept. 

    Anyone have any experience with R2 and TS/RDP with smartcard login or more specifically DoD CAC cards?

    terça-feira, 15 de junho de 2010 22:36

Respostas

  • Mr. Watkins,

    I think you would be doing yourself a big favor by deleting this post or have Microsoft do it for you.

    You have put far too much information about the Army's configuration and your personal data on a public forum.

    Then as the previous gentleman mentioned, your PKI office or DISA can help you with this.

    Im sure this will get turned in to security.


    • Editado Nunya777 segunda-feira, 18 de junho de 2012 03:10
    • Marcado como Resposta VASysAdmin quarta-feira, 11 de julho de 2012 13:37
    segunda-feira, 18 de junho de 2012 03:10

Todas as Respostas

  • You need to look at the domain controller certificate of the DC authenticating your smart card logon.

    From the R2 server, run certutil -verify -urlfetch <domaincontroller.crt> and post the results.

    This will tell us exactly what is causing the DC certificate to fail

    Brian

    quarta-feira, 16 de junho de 2010 12:11

  • The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)
    ------------------------------------
    Revocation check skipped -- server offline

    ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)
    CertUtil: The revocation function was unable to check revocation because the revocation server was offline.

    CertUtil: -verify command completed successfully.



    • Editado VASysAdmin quarta-feira, 11 de julho de 2012 14:11
    quarta-feira, 16 de junho de 2010 21:14
  • I don't have an answer yet, but I can confirm I have the same or a very similar issue since introducing my first R2 DC(x64 Enterprise).  We use gemalto seg smartcards for privileged accounts and I get an error when trying to log in with these accounts to the DC(domain admin).  It still works when RDP to a non R2(2008x86) dc.

    I CAN browse the http:// path and download the CRL without issue so access does not seem to be an issue...I've found about 3 or 4 users who have done this recently with similar posts. It would be nice if MS could get to the root cause from the introduction of R2.

    1) 

    Running certutil -dcinfo verify

    shows the same errors as your post

      Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
      Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
        CRL 0c:
        Issuer: CN=*******, OU=*******, O=*************, C=US
        93 f5 db cf ff b6 d9 ad e2 27 48 fc 1c 55 e0 48 49 ad 24 2b

    CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
     Issuer: CN=*******, OU=*******, O=*************, C=US
      NotBefore: 4/17/2003 1:31 PM
      NotAfter: 4/17/2013 1:41 PM
      Subject: CN=******** 01, OU=*******, O=*******, C=US
      Serial: 4e478a75def5ef8d4d466c9b1e737950
      16 ef cd 07 d8 4f 25 ef fa 65 91 91 8a 8f 01 7b 3b 25 54 cd
      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      Issuance[0] = 1.3.6.1.4.1.4995.1000.2.1.1.1

    Exclude leaf cert:
      a8 8b ee ce 73 fb 7c fc 70 e0 47 98 ab 02 55 15 be 90 31 b9
    Full chain:
      63 08 1f 3a 93 49 fe 3f 7a 92 55 c0 8c c3 8c a5 e7 7e 47 b4
       Issuer: CN=*******, OU=*******, O=*************, C=US
      NotBefore: 6/3/2010 6:14 PM
      NotAfter: 6/3/2011 6:14 PM
      Subject:
      Serial: 18a03eb90007000001e2
      SubjectAltName: DNS Name=AD05.*****.*******.***
      Template: Domain Controller Authentication
      3e e2 ce af 98 68 57 24 87 00 2b e4 c8 c0 1a 4f 40 00 b1 7e
    The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)

    2)

    The R2 DC presents this "friendly message" to my account 

    ...you cannot use a smart card to log on because smart card login is not supported for your user account...

    This isn't true(because it does work on the non R2 DCs...)

    3)The CAPI2 log shows things like this  EventID 41 EventID 53

    EventID 41

    Log Name:      Microsoft-Windows-CAPI2/Operational
    Source:        Microsoft-Windows-CAPI2
    Date:          8/6/2010 4:20:26 PM
    Event ID:      41
    Task Category: Verify Revocation
    Level:         Error
    Keywords:      Revocation,Path Validation
    User:          SYSTEM
    Computer:      ad05.******.*****.***
    Description:
    For more details for this event, please refer to the "Details" section
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-CAPI2" Guid="{5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}" />
        <EventID>41</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>41</Task>
        <Opcode>2</Opcode>
        <Keywords>0x4000000000000005</Keywords>
        <TimeCreated SystemTime="2010-08-06T23:20:26.407078600Z" />
        <EventRecordID>8677</EventRecordID>
        <Correlation />
        <Execution ProcessID="480" ThreadID="968" />
        <Channel>Microsoft-Windows-CAPI2/Operational</Channel>
        <Computer>ad05.******.*****.***</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <UserData>
        <CertVerifyRevocation>
          <Certificate fileRef="AD99A70FC6AD4438FF57024E70B8B9912F034594.cer" subjectName="ad05.******.*****.***" />
          <IssuerCertificate fileRef="2B87F95CD57736BABAA18F7D3D296C826AE53AB4.cer" subjectName=" Issuing Certificate Authority 02" />
          <Flags value="8" CERT_VERIFY_REV_SERVER_OCSP_FLAG="true" />
          <AdditionalParameters timeToUse="2010-08-06T23:20:17.407Z" currentTime="2010-08-06T23:20:17.407Z" urlRetrievalTimeout="PT15S" />
          <RevocationStatus index="0" error="80092013" reason="0" />
          <EventAuxInfo ProcessName="lsass.exe" />
          <CorrelationAuxInfo TaskId="{E4D44C33-7559-4E8E-804F-0E333DAC664A}" SeqNumber="7" />
          <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>
        </CertVerifyRevocation>
      </UserData>
    </Event>

     

    EventID 53

    Log Name:      Microsoft-Windows-CAPI2/Operational
    Source:        Microsoft-Windows-CAPI2
    Date:          8/6/2010 4:20:26 PM
    Event ID:      53
    Task Category: Retrieve Object from Network
    Level:         Error
    Keywords:      Automatic Root Update,Retrieval,Revocation,Path Discovery
    User:          SYSTEM
    Computer:      ad05.****.mydomain.com
    Description:
    For more details for this event, please refer to the "Details" section
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-CAPI2" Guid="{5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}" />
        <EventID>53</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>53</Task>
        <Opcode>2</Opcode>
        <Keywords>0x4000000000000036</Keywords>
        <TimeCreated SystemTime="2010-08-06T23:20:26.407078600Z" />
        <EventRecordID>8675</EventRecordID>
        <Correlation />
        <Execution ProcessID="480" ThreadID="968" />
        <Channel>Microsoft-Windows-CAPI2/Operational</Channel>
        <Computer>ad05.****.mydomain.com</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <UserData>
        <CryptRetrieveObjectByUrlWire>
          <URL scheme="http">http://mydomainpki.mydomain.com/CertEnroll/ad-pe03/ad-pe03.mydomain.com_***%20Issuing%20Certificate%20Authority%2002(8).crt/MEswSTBHMEUwQzAJBgUrDgMCGgUABBTS3OzXzrfz8vStnB%2FcZcZEH0y5FgQUc3HYw7oBJZ7KJ6xt8mKQ6vhXnG0CChuPPR0ACAAhk3U%3D?Content-Type: application/ocsp-request</URL>
          <Object type="CONTEXT_OID_OCSP_RESP" constant="6" />
          <Timeout>PT15S</Timeout>
          <Flags value="302004" CRYPT_WIRE_ONLY_RETRIEVAL="true" CRYPT_LDAP_SCOPE_BASE_ONLY_RETRIEVAL="true" CRYPT_HTTP_POST_RETRIEVAL="true" CRYPT_PROXY_CACHE_RETRIEVAL="true" />
          <AuxInfo cacheFileNamePrefix="B845EBB61AA5FE901E4864D5742123FA_" httpStatusCode="404" />
          <AdditionalInfo>
            <NetworkConnectivityStatus value="1" _SENSAPI_NETWORK_ALIVE_LAN="true" />
            <Action name="Call_WinHttpGetProxyForUrl">
              <Error value="2F94">The Proxy Auto-configuration URL was not found.</Error>
            </Action>
            <Action name="NoProxy" />
            <Action name="Call_WinHttpGetProxyForUrl">
              <Error value="2F94">The Proxy Auto-configuration URL was not found.</Error>
            </Action>
            <Action name="NoProxy" />
            <HTTPRequestHeadersInfo>
              <Header>POST /CertEnroll/ad-pe03/ad-pe03.mydomain.com_***%20Issuing%20Certificate%20Authority%2002(8).crt HTTP/1.1</Header>
              <Header>Accept: */*</Header>
              <Header>Content-Type: application/ocsp-request</Header>
              <Header>User-Agent: Microsoft-CryptoAPI/6.1</Header>
              <Header>Cache-Control: no-cache</Header>
              <Header>Pragma: no-cache</Header>
              <Header>Connection: Keep-Alive</Header>
              <Header>Content-Length: 77</Header>
            </HTTPRequestHeadersInfo>
            <HTTPResponseHeadersInfo>
              <Header>HTTP/1.1 404 Not Found</Header>
              <Header>Date: Fri, 06 Aug 2010 23:20:26 GMT</Header>
              <Header>Content-Length: 1245</Header>
              <Header>Content-Type: text/html</Header>
              <Header>Server: Microsoft-IIS/7.5</Header>
            </HTTPResponseHeadersInfo>
            <Action name="HTTP_STATUS">
              <Error value="194" />
            </Action>
          </AdditionalInfo>
          <EventAuxInfo ProcessName="lsass.exe" />
          <CorrelationAuxInfo TaskId="{E4D44C33-7559-4E8E-804F-0E333DAC664A}" SeqNumber="5" />
          <Result value="80190194" />
        </CryptRetrieveObjectByUrlWire>
      </UserData>
    </Event>


    UC Berkeley
    sexta-feira, 6 de agosto de 2010 23:55
  • Hi,

    any news in this case? We retrieved exactly the same behaviour (while testing in a similar environment).

    terça-feira, 29 de março de 2011 09:59
  • Yes, Just received this error yesterday.. everything was working fine...
    quarta-feira, 20 de abril de 2011 13:23
  • We just figured out our issue. Although everything was configured correctly the originator of the problem was a DNS issue. The test environment did not have internet access (dedicated VLAN), but was configured with an existing domain name. The test client LAN-NIC was configured to access the test-VLAN, however, he even had WLAN access to another VLAN with internet access. For this, the client did not resolve the domain at the existing DNS server at his LAN NIC, he resolved the domain name from an external DNS server (via WLAN). This is why the revocation provider was recognized as "offline" although everything was ok.

     

    quinta-feira, 21 de abril de 2011 09:50
  • All,
    Was wondering if anyone came up with anything on this. I am getting this on a Windows 2008 Sp2 x64 non-r2 server. I have ActiveClient and Tumbleweed installed and both setup the same as our other smartcard clients. The certs for all of our DC's appear ok. The funny thing is if you try 3 or 4 times you will eventually get in using RDP/TS??

     

    segunda-feira, 9 de maio de 2011 20:49
  • Hi All,

     

    One of our LDAP server certificate is giving below details of the certificate.Its showing as Valid certificate. We are facing issue with LDAP connection over SSL(636) port. Is this due to revocation error mentioned below?

     


    C:\WINDOWS\system32>Certutil -VerifyStore MY
    ================ Certificate 0 ================
    Serial Number: 33809a33000000000060
    Issuer: CN=Issuing CA for dnsroot.biz, DC=dnsroot, DC=biz
    Subject: CN= FQDN of server
    Certificate Template Name: WebServer
    Non-root Certificate
    Template: WebServer, Web Server
    Cert Hash(sha1): 63 63 e3 9a a9 8c 79 f3 85 34 52 14 f4 df ec cb ef a7 53 93
      Key Container = cf342572e5a09152046bafea2b523453_9b4162fb-a43e-416b-bbe0-b6d6a
    fd50a7b
      Provider = Microsoft RSA SChannel Cryptographic Provider
    Private key is NOT exportable
    Encryption test passed
    -------- CERT_CHAIN_CONTEXT --------
    ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
    ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
    ChainContext.dwRevocationFreshnessTime: 695 Days, 20 Hours, 15 Minutes, 15 Secon
    ds

    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
    SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
    SimpleChain.dwRevocationFreshnessTime: 695 Days, 20 Hours, 15 Minutes, 15 Second
    s

    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040
      Issuer: CN=Issuing CA for dnsroot.biz, DC=dnsroot, DC=biz
      Subject: CN=tuwigmap23.thomsonuk.dnsroot.biz
      Serial: 33809a33000000000060
      Template: WebServer
      63 63 e3 9a a9 8c 79 f3 85 34 52 14 f4 df ec cb ef a7 53 93
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
      Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
        CRL 5:
        Issuer: CN=Issuing CA for dnsroot.biz, DC=dnsroot, DC=biz
        c3 e7 80 5c 25 6a f6 48 fa 3f f2 48 ab 17 4f 95 9c 6b 11 05
      Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication

    CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
      Issuer: CN=Domain Root CA, DC=dnsroot, DC=biz
      Subject: CN=Issuing CA for dnsroot.biz, DC=dnsroot, DC=biz
      Serial: 1e93244d000000000002
      Template: SubCA
      d9 5e 68 9a 73 43 22 a6 46 ba fc 35 ff 7d 0c 60 1e e5 75 dc
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
        CRL 12:
        Issuer: CN=Domain name Root CA, DC=dnsroot, DC=biz
        40 b2 18 1b 1f 7a bd 51 c4 ac 44 07 bb fc ca 39 e0 ea 6a a8

    CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=Domain name Root CA, DC=dnsroot, DC=biz
      Subject: CN=Domain name Root CA, DC=dnsroot, DC=biz
      Serial: 120f1ab2f7d0d7874838e637e141115b
      cb 74 3e 24 d1 a7 48 22 2c 77 72 e8 e1 d1 1a 03 3a dd 25 65
      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

    Exclude leaf cert:
      35 99 8f 6b ed 37 07 0c 45 52 c9 dc 2b 49 06 3d 2c 90 8f c5
    Full chain:
      63 e3 da 50 f0 87 19 db b6 3a a4 ec b8 e3 df ee 2f 91 dc 9a
      Issuer: CN=Issuing CA for dnsroot.biz, DC=dnsroot, DC=biz
      Subject: CN=tuwigmap23.thomsonuk.dnsroot.biz
      Serial: 33809a33000000000060
      Template: WebServer
      63 63 e3 9a a9 8c 79 f3 85 34 52 14 f4 df ec cb ef a7 53 93
    The revocation function was unable to check revocation because the revocation se
    rver was offline. 0x80092013 (-2146885613)
    ------------------------------------
    Revocation check skipped -- server offline
    Certificate is valid

     

    Please guide on this, is this certificate is ok for LDAP SSL certificate.

     

    -----

    v235

    sábado, 25 de junho de 2011 09:12
  • I seem to have come across an issue that there isn't alot of information on.  maybe you all can help me out.

    I work for the US Army.  They have a vast AD forest.  So AD controllers are not local.  I'm building windows 2008 R2 TS servers to host my Citrix XenApp6 farm, and when trying to RDP into the servers with a CAC card I get the following error:

    "The system could not log you on.  The revocation status of the domain controller certificate used for smart card authentication could not be determined."

    Only happens on my 2008 R2 servers.  I have installed all the normal DoD software that is used to help facilitate CAC login (ActivClient-middleware, Tumbleweed-CRL checking).  I have talked with both vendors.  No one has alot of experience with R2 and CAC login.  I removed tumbleweed, since it deals with revocation, and that did not help.

    I figure out the box the server should be able to take my CAC login.  So I built a fresh server with no GPO and just middleware and tumbleweed, and I get the same error.  I do not have this problem with any other OS.  I've tried different RDP clients (Win7, Vista) and they both display the error. 

    I have seen issues on this forum with RDP and CRL checking for SSL/TLS communication with Win7 and 2008 R2.  Nothing that seems to deal with smartcards, but its the same concept. 

    Anyone have any experience with R2 and TS/RDP with smartcard login or more specifically DoD CAC cards?

    This is not the appropriate place to be posting this information. It should be going through your local PKI office.
    sexta-feira, 12 de agosto de 2011 19:26
  • Mr. Watkins,

    I think you would be doing yourself a big favor by deleting this post or have Microsoft do it for you.

    You have put far too much information about the Army's configuration and your personal data on a public forum.

    Then as the previous gentleman mentioned, your PKI office or DISA can help you with this.

    Im sure this will get turned in to security.


    • Editado Nunya777 segunda-feira, 18 de junho de 2012 03:10
    • Marcado como Resposta VASysAdmin quarta-feira, 11 de julho de 2012 13:37
    segunda-feira, 18 de junho de 2012 03:10
  • Nunya777, Thanks, information has been removed.

    Sorry, for not posting a fix to this problem.  By now, most have probably stubbled on the fix.  If not, the issue was a few things.  Keep in mind, that my issue revolved around Citrix/RDP and smartcard auth. 

    Resolution - Put the 64 bit Tumbleweed client (version 4.10) on the Windows 2008 Citrix server and now I can successfully RDP with Smartcard to the Windows 2008 Citrix Server. I put the 64 bit Tumbleweed client (version 4.10) and the hotfix for 979530 on the Windows 2008 R2 Citrix server and now I can successfully RDP with Smartcard to the Windows 2008 Citrix Server. 979530 A Windows Server 2008 R2-based Remote Desktop server denies some connection requests randomly under heavy logon or logoff conditions You put the hotfix from kb 979530 http://support.microsoft.com/kb/979530.  Dont know why it had anything to do with my issue, but updating AC and TW did not resolve the issue itself.

    Those versions are now old for both ActivClient and Tumbleweed, as well as KB979530 is part of services packs for 2008 and R2.  So up to date software with those packages should fix the issue. 

    BTW, my PKI office was completely clueless on this issue when I brough it up years ago.  I worked with Microsoft, Tumbleweed, ActivClient and a third party Citrix Systems Integrator to resolve the issue.



    • Editado VASysAdmin quarta-feira, 11 de julho de 2012 14:25
    quarta-feira, 11 de julho de 2012 14:02
  • I disagree. My local PKI office simply know how to issue smartcards. They know nothing of certificate authentication. This was completely a technical issue,  that was resolved by software updates. Certificate information was removed, and was not pertinent anyways to the problem.  Information was reviewed by sys admins in my office as well as security personnel.

    quarta-feira, 11 de julho de 2012 14:22