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

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    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

  • Question
    Sign in to vote
    0
    Sign in to vote
    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

  • Question
    Sign in to vote
    1
    Sign in to vote

    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
  • Question
    Sign in to vote
    0
    Sign in to vote

    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
  • Question
    Sign in to vote
    0
    Sign in to vote
    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
  • Question
    Sign in to vote
    0
    Sign in to vote
    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
  • Question
    Sign in to vote
    0
    Sign in to vote
    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