Share via


CertGetCertificateChain() method fails revocation check

Question

Monday, April 22, 2013 11:39 AM

Hi, 

We have implemented OCSP on our gateway using CertGetCertificateChain API. However, though certutil -url verifies the certificate on the gateway correctly, the API returns the following value in its trust status: 

TrustStatus 

  - ErrorStatus 

   [ value]  1000040 
   [ CERT_TRUST_REVOCATION_STATUS_UNKNOWN]  true 
   [ CERT_TRUST_IS_OFFLINE_REVOCATION]  true 
 

Can anyone help me debug this? 

All replies (6)

Monday, April 22, 2013 12:08 PM | 1 vote

You need to provide the results of certutil -verify -urlfetch certfile.crt

****This will provide you with the details. Remember that the entire chain is evaluated to produce this result you see in your first post

Brian


Wednesday, April 24, 2013 6:22 AM

Hi Brian,

Thanks a lot for the prompt response! I have dumped the output of "certutil -verify -urlfetch " and provided it below. As you can see, the command verifies the certificate and does not raise the error flag in the trust status. 

It is only when I use the same certificate for authentication with the CertGetCertificateChain API, that the above mentioned error occurs. I am not able to figure out why, when certutil validates the certificate successfully, CertGetCertificateChain() fails the revocation check. 

 -- Draghav

C:\ certutil -verify -urlfetch certnew_21.cer
Issuer:
    CN=I-RootCA
    DC=Aug2012win7
    DC=com
Subject:
    CN=node-21.Aug2012win7.com
Cert Serial Number: 15ba6574000000000047

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: 23 Hours, 13 Minutes, 48 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 23 Hours, 13 Minutes, 48 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=I-RootCA, DC=Aug2012win7, DC=com
  NotBefore: 4/18/2013 12:16 PM
  NotAfter: 4/18/2015 12:16 PM
  Subject: CN=node-21.Aug2012win7.com
  Serial: 15ba6574000000000047
  Template: WebServer
  0a 03 16 2c b4 e0 3a a5 3c d7 f4 cb e3 50 ad 12 7c 54 48 f6
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
   Certificate AIA  
  Verified "Certificate (0)" Time: 0
    [0.0] http://ca44.Aug2012win7.com/CertEnroll/ca44.Aug2012win7.com_I-RootCA.crt

   Certificate CDP  
  Failed "CDP" Time: 0
    Error retrieving URL: The specified network resource or device is no longer
available. 0x80070037 (WIN32: 55)
    ldap:///CN=I-RootCA,CN=ca44,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Aug2012win7,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

  Verified "Base CRL (b9)" Time: 0
    [1.0] http://ca44.Aug2012win7.com/CertEnroll/I-RootCA.cr
l

  Failed "CDP" Time: 0
    Error retrieving URL: The specified network resource or device is no longer available. 0x80070037 (WIN32: 55)
    [1.0.0] ldap:///CN=I-RootCA,CN=ca44,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Aug2012win7,DC=com?deltaRevocationList?base?objectClass=cRLDistributionPoint

  Verified "Delta CRL (b9)" Time: 0
    [1.0.1] http://ca44.Aug2012win7.com/CertEnroll/I-RootCA+.crl

   Base CRL CDP  
  No URLs "None" Time: 0
   Certificate OCSP  
  Verified "OCSP" Time: 0
    [0.0] http://ca44.Aug2012win7.com/ocsp

 
    CRL (null):
    Issuer: CN=ca44.Aug2012win7.com
    41 68 27 72 88 d9 71 1b 1e d2 f4 de 24 38 47 69 ec 09 0a 0c
  Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication

CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
  Issuer: CN=I-RootCA, DC=Aug2012win7, DC=com
  NotBefore: 8/6/2012 3:03 PM
  NotAfter: 8/6/2017 3:13 PM
  Subject: CN=I-RootCA, DC=Aug2012win7, DC=com
  Serial: 50b5990bac9b66914ae2357b0c10604e
  23 ad 34 1b a8 fc 60 55 be 81 25 3c 94 80 9c 32 d5 11 14 c2
  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)
   Certificate AIA  
  No URLs "None" Time: 0
   Certificate CDP  
  No URLs "None" Time: 0
   Certificate OCSP  
  No URLs "None" Time: 0
 

Exclude leaf cert:
  d4 f6 97 5b 10 f9 e3 81 6c b4 0f 7a 33 d5 df dc bd 28 f9 8c
Full chain:
  88 df 80 8e 13 cb e9 c0 5d 0a 8c 78 2c 6c 13 ed 59 66 b3 31

Verified Issuance Policies: None
Verified Application Policies:
    1.3.6.1.5.5.7.3.1 Server Authentication
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.


Friday, April 26, 2013 6:35 AM

I have been debugging the issue further using CAPI2 debugging in event logs. 

I keep seeing the following event 42 being logged: 

 - CertRejectedRevocationInfo

 Action 
   [ name]  CheckFreshnessTime 

I'm unable to figure out why this error keeps occurring. Any ideas? 


Friday, April 26, 2013 7:09 AM | 1 vote

is the root CA placed in the computer's root CA list or just in the user's? Make sure the computer trusts the CA.

ondrej.


Friday, April 26, 2013 8:56 AM

Hi Ondrej,

Yes, the rootCA's certificate is placed in the trusted root list. The computer does trust the CA. 

Since certutil run on the node verifies the certificate, I guess this validates that it can't be a trust issue? 


Tuesday, May 14, 2013 11:49 AM

Hi,

I think I finally figured out what is causing the error. 

The thisUpdate value in the OCSP response sent by the CA keeps getting set to a back-dated value i.e 24-hours behind. 

If the client machine's time gets set to the time specified in thisUpdate, then the CertGetCertificateChain API validates the OCSP response successfully. 

However, the CA should not be sending this incorrect thisUpdate time.

I found a hotfix for this : http://support.microsoft.com/kb/2635621/en-us?wa=wsignin1.0

But this is only applicable for Windows Server 2008. My CA is running on Windows Server 2008 R2. 

Does anyone have any idea whether there is a similar fix for 2008 R2?

-- Draghav