Hello, I'm trying to understand the return codes that I'm receiving when I analyze a certificate using certutil -url. Let me preface this by saying that Windows reports any of my non-revoked end-entity certificates as valid and the Enterprise PKI snap-in found no problems with any of the CDPs or AIAs in my two-level hierarchy. When I run certutil -url on an end entity certificate, all CDPs and AIAs return as "Verified". When I use the command on the subCA certificate, however, while the CDPs are verified, the AIAs return "No CRL". Simultaneously, the command window displays the same rather cryptic error code for each AIA: 319.1046.0: 0x80092012 (-2146885614) Is this actually indicative of a problem or just a nuance of the URL Retrieval Tool? Thanks, Mike

It indicates a problemThe -URL tool simply helps you determine if the AIA and CDP URLs can be retrieved (or a response from the OCSP server).If you want to check whether there are problems with the URLs, or whether a certificate is revoked , use certutil -verify -urlfetch <Certfile.cer>Brian

Hi,The CERT_TRUST_STATUS structure contains trust information about a certificate in a certificate chain, summary trust information about a simple chain of certificates, or summary information about an array of simple chains.More info can be found herehttp://msdn.microsoft.com/en-us/library/aa377590(VS.85).aspxBest regardsMartin Rublik

Thanks, Brian. The command definitely provide additional information, but it still does't elaborate any further on what the "No CRL" response means. There doesn't seem to be any other indications of a problem either. Here is the output I received (I changed some non-pertinant info in order to keep my organization's interal AD names private):H:\_PKI\_ICS>certutil -verify -urlfetch subca.cer402.203.0: 0x80070057 (WIN32: 87): ..CertCli VersionIssuer: CN=fabricam ICS Root CA DC=fabricam DC=NETSubject: CN=fabricam ICS Remote Access CA DC=fabricam DC=netCert Serial Number: 3dfc703107608d77000000000002 dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)HCCE_LOCAL_MACHINECERT_CHAIN_POLICY_BASE-------- CERT_CHAIN_CONTEXT --------ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)ChainContext.dwRevocationFreshnessTime: 12 Days, 20 Hours, 44 Minutes, 23 Seconds SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)SimpleChain.dwRevocationFreshnessTime: 12 Days, 20 Hours, 44 Minutes, 23 Seconds CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0 Issuer: CN=fabricam ICS Root CA, DC=fabricam, DC=NET Subject: CN=fabricam ICS Remote Access CA, DC=fabricam, DC=net Serial: 3dfc703107608d77000000000002 Template: SubCA 97 69 dd 96 82 0c 6a 00 11 7a 88 0f 3a 1e 5a 2f bd 9b b6 a0 Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ----------------319.1046.0: 0x80092012 (-2146885614)319.1046.0: 0x80092012 (-2146885614) No CRL "Certificate (0)" Time: 0 [0.0] ldap:///CN=fabricam%20ICS%20Root%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=fabricam,DC=NET?cACertificate?base?objectClass=certificationAuthority No CRL "Certificate (0)" Time: 4 [1.0] http://certs.fabricamvip.com/ICSROOTCA_fabricam%20ICS%20Root%20CA.crt ---------------- Certificate CDP ---------------- Verified "Base CRL (3)" Time: 0 [0.0] ldap:///CN=fabricam%20ICS%20Root%20CA,CN=ICSROOTCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=fabricam,DC=NET?certificateRevocationList?base?objectClass=cRLDistributionPoint Verified "Base CRL (3)" Time: 4 [1.0] http://certs.fabricamvip.com/fabricam%20ICS%20Root%20CA.crl ---------------- Base CRL CDP ---------------- No URLs "None" Time: 0 -------------------------------- CRL 3: Issuer: CN=fabricam ICS Root CA, DC=fabricam, DC=NET e1 07 66 5c ff 41 ff 68 e7 98 cc 55 41 37 2c 41 8d ef 97 68 CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=fabricam ICS Root CA, DC=fabricam, DC=NET Subject: CN=fabricam ICS Root CA, DC=fabricam, DC=NET Serial: 3d9539ae99a2878a49a6dc0c0d0713c0 41 47 69 ed 73 bb 1e 9d f3 3d 59 cb 17 20 18 32 d2 d7 08 d7 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 -------------------------------- Exclude leaf cert: 21 bd d5 ff 01 99 1d e4 3e 06 30 f4 3f 5e c4 b1 04 16 87 01Full chain: 7c df d7 da 4a ff ad 54 87 61 ed f6 5b 4d d0 0d ab ee 80 42------------------------------------Verified Issuance Policies: NoneVerified Application Policies: AllCert is a CA certificateLeaf certificate revocation check passedCertUtil: -verify command completed successfully.

Hi, 0x80092012 means "The revocation function was unable to check revocation for the certificate." Please check if your CRLs are expired. Can you access the CRLs manually? Thanks.This posting is provided "AS IS" with no warranties, and confers no rights.

Yes; the CRL is accessible and valid at both CDPs.Also, notice that both the CDPs are "Verified" in the output while its returning "No CRL" when it tries to retreive the cert from the AIA. (The certs are manually accessible from the AIAs).

Yes; the CRL is accessible and valid at both CDPs.Also, notice that both the CDPs are "Verified" in the output while its returning "No CRL" when it tries to retreive the cert from the AIA. (The certs are manually accessible from the AIAs). Mike, I am experiencing exactly the same behavior. However I am not sure if this is an issue at all. Doesn't "No CRL" simply mean that you did not provide CRL distribution points for your Root CA certificate? And providing no CRLs for the Root CA certificate in my opinion is quite usual, isn't it. It obviously finds the AIA certificates but cannot find a CRL for the certificate, because there is none:I tested the following:1. Valid Root CA certificate on all distribution points"certutil -verify -urlfetch subca.cer" returns "No CRL" for each distribution point2. Change the name of the Root CA certificate on the HTTP DP; so no valid certificate exists on the HTTP DP"certutil -verify -urlfetch subca.cer" returns "Failed AIA" for the HTTP DPCan someone please confirm that?

The actual report, in case we are paraphrasing in this thread for a root CA is the following: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--------------------------------Note that it is "No URLs", not No CRLIn addition, just above is the status that the certificate is Self Signed.Mike's issue is a little bit different based on his outputBrian

I think Frank may be right. I performed the same certutil command on an end-entity certificate. When it checked the issuer AIA urls, the result was "verified" and the result for the Root was still "No CRLs".It may be that certutil doesn't know that I explicitly trust the Root CA certificate. When we built the root of this PKI, I'm not sure whether or not we specified the path length in the CA Policy. It would be interesting to see if setting the path length has any affect on how this certutil command behaves.