none
certutil OCSP issues - Expired "OCSP" Time: 0 RRS feed

  • Question

  • Hello All,

    I have a strange behavior when performing a revocation check with certutil and OCSP. Certutil gives status "Expired "OCSP" Time: 0".

    However, the OCSP Responder is online and available - The user certificate can even be used for domain smartcard logon with revocation checking enabled (as you can see, i used a dummy CRL DP in order to force OCSP).

    I dont think that it is a time issue as the OCSP server uses NTP in order to apply the time from the AD (2012 R2) server (from where certutil is execued). Both are in the same timezone and has the exact same local time set (not even one second difference).

    Even wireshark confirms that the OCSP server responds a "success" - so why do certutil say "Expired "OCSP" Time: 0"? Any help would be highly appreciated.

    Certutil Log:

    Issuer:
        CN=Test Root CA
        O=company
      Name Hash(sha1): f5c2466f81aa265ec06d6f0309532b0d27ebb467
      Name Hash(md5): f03c18e44668c47f9fa06dd4d42bc6de
    Subject:
        CN=user3
        OU=users
        O=system
      Name Hash(sha1): 9404a3a101a6b93d9683b18f3e182b102cfea854
      Name Hash(md5): 60e135bef88c93219bb44a92f8dc5d84
    Cert Serial Number: a9fecd6cc4b36a93c7ac953a5c18c9e7
    
    dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
    HCCE_LOCAL_MACHINE
    CERT_CHAIN_POLICY_BASE
    -------- CERT_CHAIN_CONTEXT --------
    ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    ChainContext.dwRevocationFreshnessTime: 4 Minutes, 6 Seconds
    
    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    SimpleChain.dwRevocationFreshnessTime: 4 Minutes, 6 Seconds
    
    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
      Issuer: CN=Test Root CA, O=company
      NotBefore: 10/11/2016 12:18 PM
      NotAfter: 10/10/2021 12:18 PM
      Subject: CN=user3, OU=users, O=system
      Serial: a9fecd6cc4b36a93c7ac953a5c18c9e7
      SubjectAltName: Other Name:Principal Name=user3@testdomain.demo
      760f0d141c45d30eff5102d106c053087af2a1a2
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate CDP  ----------------
      Failed "CDP" Time: 0
        Error retrieving URL: The server name or address could not be resolved 0x800
    72ee7 (INet: 12007 ERROR_INTERNET_NAME_NOT_RESOLVED)
        http://dummyurl.de/crl.crl
    
      ----------------  Base CRL CDP  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate OCSP  ----------------
      Expired "OCSP" Time: 0
        [0.0] http://10.66.1.10:40001/ocsp
    
      --------------------------------
        CRL (null):
        Issuer: CN=ocspserviceuser, OU=CA, O=system
        ThisUpdate: 10/11/2016 10:29 PM
        NextUpdate: 10/12/2016 10:29 AM
        504759eeade841e2298f0623ce2b4581a45daa44
      Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
      Application[1] = 1.3.6.1.4.1.311.20.2.2 Smart Card Logon
    
    CertContext[0][1]: dwInfoStatus=10a dwErrorStatus=0
      Issuer: CN=Test Root CA, O=company
      NotBefore: 2/29/2016 4:23 PM
      NotAfter: 2/26/2026 4:23 PM
      Subject: CN=Test Root CA, O=company
      Serial: 72e54bc0be491df3e95827628c84db5c
      7a54b2001856ea55acbdbcbb14bd7386157168cb
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate CDP  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate OCSP  ----------------
      No URLs "None" Time: 0
      --------------------------------
    
    Exclude leaf cert:
      b53578a9f47b2ab5d653ad2575a5cd4c4a532ae8
    Full chain:
      6036f1b6e9251a68d45560bcf09b04acbfdca1b7
    ------------------------------------
    Verified Issuance Policies: None
    Verified Application Policies:
        1.3.6.1.5.5.7.3.2 Client Authentication
        1.3.6.1.4.1.311.20.2.2 Smart Card Logon
    Leaf certificate revocation check passed
    CertUtil: -verify command completed successfully.
    
    C:\Users\Administrator\Desktop>certutil -verify -urlfetch user3.cer
    Issuer:
        CN=Test Root CA
        O=company
      Name Hash(sha1): f5c2466f81aa265ec06d6f0309532b0d27ebb467
      Name Hash(md5): f03c18e44668c47f9fa06dd4d42bc6de
    Subject:
        CN=user3
        OU=users
        O=system
      Name Hash(sha1): 9404a3a101a6b93d9683b18f3e182b102cfea854
      Name Hash(md5): 60e135bef88c93219bb44a92f8dc5d84
    Cert Serial Number: a9fecd6cc4b36a93c7ac953a5c18c9e7
    
    dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
    HCCE_LOCAL_MACHINE
    CERT_CHAIN_POLICY_BASE
    -------- CERT_CHAIN_CONTEXT --------
    ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    ChainContext.dwRevocationFreshnessTime: 8 Minutes, 51 Seconds
    
    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    SimpleChain.dwRevocationFreshnessTime: 8 Minutes, 51 Seconds
    
    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
      Issuer: CN=Test Root CA, O=company
      NotBefore: 10/11/2016 12:18 PM
      NotAfter: 10/10/2021 12:18 PM
      Subject: CN=user3, OU=users, O=system
      Serial: a9fecd6cc4b36a93c7ac953a5c18c9e7
      SubjectAltName: Other Name:Principal Name=user3@testdomain.demo
      760f0d141c45d30eff5102d106c053087af2a1a2
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate CDP  ----------------
      Failed "CDP" Time: 0
        Error retrieving URL: The server name or address could not be resolved 0x800
    72ee7 (INet: 12007 ERROR_INTERNET_NAME_NOT_RESOLVED)
        http://dummyurl.de/crl.crl
    
      ----------------  Base CRL CDP  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate OCSP  ----------------
      Expired "OCSP" Time: 0
        [0.0] http://10.66.1.10:40001/ocsp
    
      --------------------------------
        CRL (null):
        Issuer: CN=ocspserviceuser, OU=CA, O=system
        ThisUpdate: 10/11/2016 10:29 PM
        NextUpdate: 10/12/2016 10:29 AM
        504759eeade841e2298f0623ce2b4581a45daa44
      Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
      Application[1] = 1.3.6.1.4.1.311.20.2.2 Smart Card Logon
    
    CertContext[0][1]: dwInfoStatus=10a dwErrorStatus=0
      Issuer: CN=Test Root CA, O=company
      NotBefore: 2/29/2016 4:23 PM
      NotAfter: 2/26/2026 4:23 PM
      Subject: CN=Test Root CA, O=company
      Serial: 72e54bc0be491df3e95827628c84db5c
      7a54b2001856ea55acbdbcbb14bd7386157168cb
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate CDP  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate OCSP  ----------------
      No URLs "None" Time: 0
      --------------------------------
    
    Exclude leaf cert:
      b53578a9f47b2ab5d653ad2575a5cd4c4a532ae8
    Full chain:
      6036f1b6e9251a68d45560bcf09b04acbfdca1b7
    ------------------------------------
    Verified Issuance Policies: None
    Verified Application Policies:
        1.3.6.1.5.5.7.3.2 Client Authentication
        1.3.6.1.4.1.311.20.2.2 Smart Card Logon
    Leaf certificate revocation check passed
    CertUtil: -verify command completed successfully.


    Tuesday, October 11, 2016 11:57 AM

Answers

  • If you are using a third party OCSP, you'd have to look into its configuration and details. One thing that could be going, just as a speculation, is your OCSP Responder using NONCE for it's responses? If so, Windows clients do not suppose NONCE.

    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    Friday, October 21, 2016 4:13 PM

All replies

  • The problem with your test is that OCSP bases its decisions on CRLs, and you have blocked access to the CRLs. So now the OCSP responder is responding with a previously cached response, which is time invalid.

    Brian

    Tuesday, October 11, 2016 2:15 PM
  • The problem with your test is that OCSP bases its decisions on CRLs, and you have blocked access to the CRLs. So now the OCSP responder is responding with a previously cached response, which is time invalid.

    Brian

    Thanks for the reply Brian, but this makes no sense for me.

    The reason for using OCSP even is that it works completely independant from the CRL and always give a online-response of the current certificate status by querying the Responder via HTTP.

    And I also receive the "expired" status from OCSP when the CRL check is okay.

    Thursday, October 20, 2016 1:12 PM
  • I believe you might misunderstand how Microsoft OCSP (and OCSP in general) works. Microsoft OCSP Responder is a server service that reads a CA's CRL. It uses this information as the authoritative source of revocation details for the CA. When a client queries the server (which is called the responder) it provides an OCSP response to the client. If the OCSP Server/Responder can't access the CRL, it can't provide any revocation details to the client properly. So in your case, your responder only has old/expired CRL information available to it. You will need to make sure your OCSP Responder can access the CRL.

    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    Thursday, October 20, 2016 10:11 PM
  • I believe you might misunderstand how Microsoft OCSP (and OCSP in general) works. Microsoft OCSP Responder is a server service that reads a CA's CRL. It uses this information as the authoritative source of revocation details for the CA. When a client queries the server (which is called the responder) it provides an OCSP response to the client. If the OCSP Server/Responder can't access the CRL, it can't provide any revocation details to the client properly. So in your case, your responder only has old/expired CRL information available to it. You will need to make sure your OCSP Responder can access the CRL.

    Thank you for the clarification. However, the OCSP Server is not a Microsoft OCSP server => This one do not uses the CRL for revocation checking, but directly reads out the Certificate database in order to obtain the revocation status.

    This works fine when performing a Windows smartcard logon or when using OpenSSL for the OCSP test, even when the CRL is not accessible, but not with certutil. So if there is a dependeny between OCSP and the CRL, then only for some applications and use cases (I actually only identified this problems with certutil).

    But of course this would explain the bevavior of certutil. I will perform some additional tests after making the CRL available => If this resolves the issue, i am okay with this explanation.

    Friday, October 21, 2016 8:10 AM
  • If you are using a third party OCSP, you'd have to look into its configuration and details. One thing that could be going, just as a speculation, is your OCSP Responder using NONCE for it's responses? If so, Windows clients do not suppose NONCE.

    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    Friday, October 21, 2016 4:13 PM