Discussion:
CertVerifyCertificateChainPolicy - CRL offline error help
(too old to reply)
AL
2005-02-09 12:10:17 UTC
Permalink
Hello,
I have a problem with CRL checking - getting a
CRYPT_E_REVOCATION_OFFLINE even when I don't expect that, maybe I do
something wrong? Really need help.

My test:
I have a valid certificate; I perform a check by calling:

- CertCreateCertificateChainEngine passing a timeout value
(ChainConfig.dwUrlRetrievalTimeout) of 60 seconds

- then I find my cert with CertFindCertificateInStore

- and then call CertGetCertificateChain

I normally get pChainContext->TrustStatus.dwErrorStatus =
CERT_TRUST_NO_ERROR (ok); however, I wanted to test CRL fetching, so I
deleted the cached crl file from IE temporary internet files and
disconnected from the network.

Problem 1: validation was still successfull, but a new CRL was not
downloaded. There must be a caching of the CRL some place other than IE
temp.int.files, but where? Can I clear this cache?

Ok, I then changed my PC time - date brought forward by some days -, so
that it thinks revocation list is expired, and tries to get a new one.

Problem 2: After this, my app does fetch the crl (checked the CA IIS
log), but then gives me a CRYPT_E_REVOCATION_OFFLINE error! How is it
possible, is it a fault of mine?
In this case I get an unknown pChainContext->TrustStatus.dwErrorStatus
from the call to CertGetCertificateChain (16777280, what's that?), and
the subsequent call to CertVerifyCertificateChainPolicy gives me a
CERT_CHAIN_POLICY_STATUS dwerror of CRYPT_E_REVOCATION_OFFLINE.
Shouldn't I get some other error, e.g. not-time-nested?

Finally, I have a third problem in the production evironment.

Problem 3: even if I set a long timeout (60 seconds over the default of
20, following the article at
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx),
as timeout for CRL url fetching, and have a reachable CDP on a list of
two/three, revocation checking always gives a CRYPT_E_REVOCATION_OFFLINE
error.
Is it correct to delete some CDP (e.g. ftp and file, given I only need a
http endpoint) in order to let the check to perform more quickly?
If I change CDP at the CA I must revoke user certificates and assign new
ones, or is there a way to update them with the new list of CDPs?

And one last question: if two http CDP are listed, do cryptoapi verify
both of them, right? Say the former is an internal (intranet) url and
the latter a public one: I should be able to complete a crl check (from
outside the intranet) without getting the CRYPT_E_REVOCATION_OFFLINE
error (given the url is valid and there's no authentication needed),
right? I doubt all the timeout is spent of the first url, unreachable,
and that I get the error instead of trying the second. Is there a way to
trace this? Capimon does not seem to do this, does it?


Thank you for any help,
al.
David Cross [MS]
2005-02-09 13:30:44 UTC
Permalink
1. Yes, CRLs are cached and you cannot clear the cache.
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx

2. This may help you debug the scenario/application:

CAPIMON:
http://www.microsoft.com/downloads/details.aspx?FamilyId=0BFE87A8-4E79-4441-9D4C-0CAB35D49A01&displaylang=en.

3. CAPI will walk through the CDP URIs one at a time with a decreasing
timeout to attempt to retrieve. you may be getting a timeout by the time it
reaches a good CDP. see
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx
--
David B. Cross [MS]
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Top Whitepapers:

Auto-enrollment whitepaper:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoenro.mspx
Best Practices for implementing Windows Server 2003 PKI:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx
Troubleshooting Certificate Status and Revocation whitepaper:
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx
Windows Server 2003 web enrollment and troubleshooting guide:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.mspx
Windows Server 2003 web enrollment and troubleshooting guide:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.mspx
Post by AL
Hello,
I have a problem with CRL checking - getting a CRYPT_E_REVOCATION_OFFLINE
even when I don't expect that, maybe I do something wrong? Really need
help.
- CertCreateCertificateChainEngine passing a timeout value
(ChainConfig.dwUrlRetrievalTimeout) of 60 seconds
- then I find my cert with CertFindCertificateInStore
- and then call CertGetCertificateChain
I normally get pChainContext->TrustStatus.dwErrorStatus =
CERT_TRUST_NO_ERROR (ok); however, I wanted to test CRL fetching, so I
deleted the cached crl file from IE temporary internet files and
disconnected from the network.
Problem 1: validation was still successfull, but a new CRL was not
downloaded. There must be a caching of the CRL some place other than IE
temp.int.files, but where? Can I clear this cache?
Ok, I then changed my PC time - date brought forward by some days -, so
that it thinks revocation list is expired, and tries to get a new one.
Problem 2: After this, my app does fetch the crl (checked the CA IIS log),
but then gives me a CRYPT_E_REVOCATION_OFFLINE error! How is it possible,
is it a fault of mine?
In this case I get an unknown pChainContext->TrustStatus.dwErrorStatus
from the call to CertGetCertificateChain (16777280, what's that?), and the
subsequent call to CertVerifyCertificateChainPolicy gives me a
CERT_CHAIN_POLICY_STATUS dwerror of CRYPT_E_REVOCATION_OFFLINE.
Shouldn't I get some other error, e.g. not-time-nested?
Finally, I have a third problem in the production evironment.
Problem 3: even if I set a long timeout (60 seconds over the default of
20, following the article at
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx), as
timeout for CRL url fetching, and have a reachable CDP on a list of
two/three, revocation checking always gives a CRYPT_E_REVOCATION_OFFLINE
error.
Is it correct to delete some CDP (e.g. ftp and file, given I only need a
http endpoint) in order to let the check to perform more quickly?
If I change CDP at the CA I must revoke user certificates and assign new
ones, or is there a way to update them with the new list of CDPs?
And one last question: if two http CDP are listed, do cryptoapi verify
both of them, right? Say the former is an internal (intranet) url and the
latter a public one: I should be able to complete a crl check (from
outside the intranet) without getting the CRYPT_E_REVOCATION_OFFLINE error
(given the url is valid and there's no authentication needed), right? I
doubt all the timeout is spent of the first url, unreachable, and that I
get the error instead of trying the second. Is there a way to trace this?
Capimon does not seem to do this, does it?
Thank you for any help,
al.
AL
2005-02-09 16:35:02 UTC
Permalink
Post by David Cross [MS]
1. Yes, CRLs are cached and you cannot clear the cache.
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx
http://www.microsoft.com/downloads/details.aspx?FamilyId=0BFE87A8-4E79-4441-9D4C-0CAB35D49A01&displaylang=en.
3. CAPI will walk through the CDP URIs one at a time with a decreasing
timeout to attempt to retrieve. you may be getting a timeout by the time it
reaches a good CDP. see
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx
David,
would it be correct for me to review the list of distribution points,
removing unneeded ones and reordering them so that, ideally, I won't get
a timeout?

thanks,
al.
David Cross [MS]
2005-02-11 13:31:59 UTC
Permalink
Yes, that would be a good suggestion.
--
David B. Cross [MS]
--
This posting is provided "AS IS" with no warranties, and confers no rights.


Top Whitepapers:

Auto-enrollment whitepaper:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoenro.mspx

Best Practices for implementing Windows Server 2003 PKI:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx

Troubleshooting Certificate Status and Revocation whitepaper:
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx

Windows Server 2003 web enrollment and troubleshooting guide:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.mspx
Post by AL
Post by David Cross [MS]
1. Yes, CRLs are cached and you cannot clear the cache.
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx
http://www.microsoft.com/downloads/details.aspx?FamilyId=0BFE87A8-4E79-4441-9D4C-0CAB35D49A01&displaylang=en.
3. CAPI will walk through the CDP URIs one at a time with a decreasing
timeout to attempt to retrieve. you may be getting a timeout by the time
it reaches a good CDP. see
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx
David,
would it be correct for me to review the list of distribution points,
removing unneeded ones and reordering them so that, ideally, I won't get a
timeout?
thanks,
al.
AL
2005-02-14 15:12:29 UTC
Permalink
Post by David Cross [MS]
Yes, that would be a good suggestion.
David,
thanks again for helping. As with CLR verification I think I solved,
even if I'm not sure of the order by which the DP are evaluated for CLR
downloading.

I did some tests with a sniffer, and found that normally Distribution
Points are evaluated in the order they appear in the certificate DP
list. However, at least in one case (with a DP of type "file", eg
"file://someNetbiosURI") I saw the order was not respected: first a DP
of type "file", third in my list, was evaluated, then the others.

Is this normal? I mean, DP searching is done with a sort of
"round-robin" between all DP available, or their order should be
strictly observed?

Thanks,
AL.

AL
2005-02-09 17:35:06 UTC
Permalink
Post by David Cross [MS]
1. Yes, CRLs are cached and you cannot clear the cache.
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx
http://www.microsoft.com/downloads/details.aspx?FamilyId=0BFE87A8-4E79-4441-9D4C-0CAB35D49A01&displaylang=en.
3. CAPI will walk through the CDP URIs one at a time with a decreasing
timeout to attempt to retrieve. you may be getting a timeout by the time it
reaches a good CDP. see
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx
David,
I verified with a sniffer that my app does retrieve the revocation list
by trying the first CDP, failing on it and then successfully getting it
from a second CDP. No timeout involved in this test, working on a LAN.
If I do this test after changing my computer's date (moved forward by 1
month to force crl fetching), I get a CRYPT_E_REVOCATION_OFFLINE error.
Is this normal? I'd expect it to tell me my certificate is not time
nested or not valid... maybe this is a fault of my code (see my first
message)?

thank you,
al.
David Cross [MS]
2005-02-11 13:32:52 UTC
Permalink
revocation offline is probably occuring since the CRL it retrieved is no
longer current for the updated time...
--
David B. Cross [MS]
--
This posting is provided "AS IS" with no warranties, and confers no rights.


Top Whitepapers:

Auto-enrollment whitepaper:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoenro.mspx

Best Practices for implementing Windows Server 2003 PKI:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx

Troubleshooting Certificate Status and Revocation whitepaper:
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx

Windows Server 2003 web enrollment and troubleshooting guide:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.mspx
Post by AL
Post by David Cross [MS]
1. Yes, CRLs are cached and you cannot clear the cache.
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx
http://www.microsoft.com/downloads/details.aspx?FamilyId=0BFE87A8-4E79-4441-9D4C-0CAB35D49A01&displaylang=en.
3. CAPI will walk through the CDP URIs one at a time with a decreasing
timeout to attempt to retrieve. you may be getting a timeout by the time
it reaches a good CDP. see
http://www.microsoft.com/technet/security/topics/crypto/tshtcrl.mspx
David,
I verified with a sniffer that my app does retrieve the revocation list by
trying the first CDP, failing on it and then successfully getting it from
a second CDP. No timeout involved in this test, working on a LAN.
If I do this test after changing my computer's date (moved forward by 1
month to force crl fetching), I get a CRYPT_E_REVOCATION_OFFLINE error. Is
this normal? I'd expect it to tell me my certificate is not time nested or
not valid... maybe this is a fault of my code (see my first message)?
thank you,
al.
Loading...