Hi, There is an enterprise PKI setup on W28KR2 with a Root->Policy->Issuing hieararchy established. The Root's certificate is signed by an external TTP. The Issuing CA's certificate has a CRLDP with two distribution points: an HTTP URL pointing to the CRL file on the internet, and an LDAP URL pointing to the AD location (accessible only on the intranet). AIA extension has the appropriate CA certificates visible on the internet. When sending a digitally signed e-mail in Outlook, the reciver can correctly validate the signature and the chain when on the intranet. The same e-mail, when viewed disconnected from the intranet - but on the public internet - cannot validate the signature. Yet, the CRL and certificate chain is correctly available when viewed through IE. When doing a "certutil -verify -urlfetch" on the intranet, the command returns the following two errorss in the output: ---------------- Certificate CDP ---------------- Bad CA Cert Subject "Base CRL (04)" Time: 0 [0.0] http://www.******.com/pki/rootca.crl Bad CA Cert Subject "Base CRL (04)" Time: 0 [1.0] ldap:///CN=******%20Root%20CA,CN=RootCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=******,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint ---------------- ---------------- At the bottom is the following message: 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. Any suggestions on what's going on here? One observation: the Delta CRL is NOT identified in the CA leaf-certificate - just the Base CRL. Obviously, Microsoft tools can find this Delta CRL on the intranet in AD (because of inside knowledge not depicted in the certificate); but this is not available on the internet. Could this be causing the problem? There is no OCSP reponder or URL in the AIA extension. Thanks, in advance, for any suggestions.

On Wed, 19 Jan 2011 23:32:23 +0000, Arshad Noor wrote: One observation: the Delta CRL is NOT identified in the CA leaf-certificate - just the Base CRL.? Obviously, Microsoft tools can find this Delta CRL on the intranet in AD (because of inside knowledge not depicted in the certificate); but this is not available on the internet.? Could this be causing the problem?? There is no OCSP reponder or URL in the AIA extension. Thanks, in advance, for any suggestions. If delta CRLs are being used at all then they need to accessible whether the relying party is internal or external. Failure to retrieve either the base or the delta CRL will cause the verification to fail. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca To be, or not to be, those are the parameters.

If delta CRLs are being used at all then they need to accessible whether the relying party is internal or external. Failure to retrieve either the base or the delta CRL will cause the verification to fail. Would this be true even if the detla CRL is never referenced in the CRLDP, Paul? Seems counter-intuitive to me. If a CRLDP in a certificate only specifies a Base CRL, and if the CRL is valid at the time it is retrieved, why should the RP care whether there is a delta CRL or not? The software may not even have the knowledge that a delta CRL exists. Thanks.

What you are missing is that delta CRL URLs are never included in certificates, they are included in the base CRL. You need to check your URLs in the base CRLs. There is an extension named Freshest CRL (which is the URL to the delta CRL). As Paul stated, if the client cannot download both the base and delta CRL, the revocation function will report the error that you see. just an educated guess, but I bet that you have one of the two scenarios: 1) Only have the delta CRL published to LDAP 2) The delta CRL is published to an internal only location Brian

Apparently true. Delta CRLs are checked by CAPI's revocation-checking engine as long as delta CRLs are configured on the CA - it doesn't matter that the CRLDP refers only to a Base CRL. The delta is referred through the "FreshestCRL" extension (OID 2.5.29.46) that is added to the CRL itself, thus causing CAPI to look for the delta CRL. http://technet.microsoft.com/en-us/library/cc700843.aspx

I know it's true. I wrote the whitepaper on the revocation checking engine. You need to fix your CA configuration Brian