Discussion:
CRL Lists always show offline
Jason Curl
11 years ago
Permalink
Hi,



Since the move to OCSP, I've never been able any more to confirm a
certificate from without Outlook. The problem occurs with Outlook 2010 as
well as Outlook 2013. Using Windows to verify the reason, it says that the
server is offline always. I wasn't able to find an answer on how to solve
this problem, and I have installed the latest certificates.



I can only guess that it thinks the root is not verifiable as it's still
looking at the original CRL which is no longer available. Any workarounds or
help?







D:\>certutil -verify -urlfetch jason.cer

Issuer:

CN=CAcert Class 3 Root

OU=http://www.CAcert.org

O=CAcert Inc.

Name Hash(sha1): f22a621693a6da5ad0b98d3a135e35d1eb183661

Name Hash(md5): 672766e51f92edc2096ab82dddf03351

Subject:

E=***@thecurls.onmicrosoft.com

CN=Jason Curl

Name Hash(sha1): e1345acbdba85068dc5f7d2a68965f94eacde4b2

Name Hash(md5): 8fc819915ebbb09593fbc8a3810ae8e1

Cert Serial Number: 011232



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.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)



SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)



CertContext[0][0]: dwInfoStatus=104 dwErrorStatus=0

Issuer: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.

NotBefore: 3/01/2013 14:17

NotAfter: 3/01/2015 14:17

Subject: E=***@thecurls.onmicrosoft.com, CN=Jason Curl

Serial: 011232

SubjectAltName: RFC822 Name=***@thecurls.onmicrosoft.com

1ed59356682c83239b7f2926840d279b39a23cf9

Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)

Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

---------------- Certificate AIA ----------------

No URLs "None" Time: 0

---------------- Certificate CDP ----------------

Verified "Base CRL" Time: 1

[0.0] http://crl.cacert.org/class3-revoke.crl



---------------- Base CRL CDP ----------------

No URLs "None" Time: 0

---------------- Certificate OCSP ----------------

Verified "OCSP" Time: 0

[0.0] http://ocsp.cacert.org



--------------------------------

CRL (null):

Issuer: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.

ThisUpdate: 26/08/2014 07:39

NextUpdate: 2/09/2014 07:39

ce1895dc206cd512c86ac1817cdfb7faf85d0ea8

Application[0] = 1.3.6.1.5.5.7.3.4 Secure Email

Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication

Application[2] = 1.3.6.1.4.1.311.10.3.4 Encrypting File System

Application[3] = 1.3.6.1.4.1.311.10.3.3

Application[4] = 2.16.840.1.113730.4.1



CertContext[0][1]: dwInfoStatus=101 dwErrorStatus=1000040

Issuer: E=***@cacert.org, CN=CA Cert Signing Authority,
OU=http://www.cace

rt.org, O=Root CA

NotBefore: 23/05/2011 19:48

NotAfter: 20/05/2021 19:48

Subject: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.

Serial: 0a418a

cefdad8afa6c7cf4e80be9f4fe3944fc643f7cad

Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)

Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)

Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

---------------- Certificate AIA ----------------

Verified "Certificate (0)" Time: 0

[0.0] http://www.CAcert.org/ca.crt



---------------- Certificate CDP ----------------

No URLs "None" Time: 0

---------------- Certificate OCSP ----------------

Verified "OCSP" Time: 0

[0.0] http://ocsp.CAcert.org/



--------------------------------

Issuance[0] = 1.3.6.1.4.1.18506



CertContext[0][2]: dwInfoStatus=109 dwErrorStatus=0

Issuer: E=***@cacert.org, CN=CA Cert Signing Authority,
OU=http://www.cacert.org, O=Root CA

NotBefore: 30/03/2003 14:29

NotAfter: 29/03/2033 14:29

Subject: E=***@cacert.org, CN=CA Cert Signing Authority,
OU=http://www.cacert.org, O=Root CA

Serial: 00

338fce76468880cd70b21a3be9b89cf436ec5c13

Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)

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 ----------------

Failed "CDP" Time: 0

Error retrieving URL: Moved permanently (301). 0x8019012d (-2145844947
HTTP_E_STATUS_MOVED)

https://www.cacert.org/revoke.crl



---------------- Certificate OCSP ----------------

No URLs "None" Time: 0

--------------------------------



Exclude leaf cert:

add445fbcd9c95ef02599f1b392b92307c256322

Full chain:

a348ff1df778b15e057c76c864cb4980769e582a

Issuer: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.

NotBefore: 3/01/2013 14:17

NotAfter: 3/01/2015 14:17

Subject: E=***@thecurls.onmicrosoft.com, CN=Jason Curl

Serial: 011232

SubjectAltName: RFC822 Name=***@thecurls.onmicrosoft.com

1ed59356682c83239b7f2926840d279b39a23cf9

The revocation function was unable to check revocation because the
revocation server was offline. 0x80092013 (-2146885613
CRYPT_E_REVOCATION_OFFLINE)

------------------------------------

Revocation check skipped -- server offline

Cert is an End Entity certificate

Leaf certificate revocation check passed

CertUtil: -verify command completed successfully.
Jason Curl
11 years ago
Permalink
Hello,

Does anyone know how to fix the problem that validity checks always fail in
Win7?

Failed "CDP" Time: 0
Error retrieving URL: Moved permanently (301). 0x8019012d (-2145844947
HTTP_E_STATUS_MOVED)
https://www.cacert.org/revoke.crl

NotBefore: 30/03/2003 14:29
NotAfter: 29/03/2033 14:29
Subject: E=***@cacert.org, CN=CA Cert Signing Authority,
OU=http://www.cacert.org, O=Root CA
Serial: 00

Thanks,
Jason.
_______________________________
From: cacert-support-***@lists.cacert.org
[mailto:cacert-support-***@lists.cacert.org] On Behalf Of Jason Curl
Sent: 31 August 2014 09:56
To: cacert-***@lists.cacert.org
Subject: CRL Lists always show offline

Hi,

Since the move to OCSP, I’ve never been able any more to confirm a
certificate from without Outlook. The problem occurs with Outlook 2010 as
well as Outlook 2013. Using Windows to verify the reason, it says that the
server is offline always. I wasn’t able to find an answer on how to solve
this problem, and I have installed the latest certificates.

I can only guess that it thinks the root is not verifiable as it’s still
looking at the original CRL which is no longer available. Any workarounds or
help?



D:\>certutil -verify -urlfetch jason.cer
Issuer:
    CN=CAcert Class 3 Root
    OU=http://www.CAcert.org
    O=CAcert Inc.
  Name Hash(sha1): f22a621693a6da5ad0b98d3a135e35d1eb183661
  Name Hash(md5): 672766e51f92edc2096ab82dddf03351
Subject:
    E=***@thecurls.onmicrosoft.com
    CN=Jason Curl
  Name Hash(sha1): e1345acbdba85068dc5f7d2a68965f94eacde4b2
 Name Hash(md5): 8fc819915ebbb09593fbc8a3810ae8e1
Cert Serial Number: 011232

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.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

CertContext[0][0]: dwInfoStatus=104 dwErrorStatus=0
  Issuer: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.
  NotBefore: 3/01/2013 14:17
  NotAfter: 3/01/2015 14:17
  Subject: E=***@thecurls.onmicrosoft.com, CN=Jason Curl
  Serial: 011232
  SubjectAltName: RFC822 Name=***@thecurls.onmicrosoft.com
  1ed59356682c83239b7f2926840d279b39a23cf9
  Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Certificate AIA  ----------------
  No URLs "None" Time: 0
  ----------------  Certificate CDP  ----------------
  Verified "Base CRL" Time: 1
    [0.0] http://crl.cacert.org/class3-revoke.crl

  ----------------  Base CRL CDP  ----------------
  No URLs "None" Time: 0
  ----------------  Certificate OCSP  ----------------
  Verified "OCSP" Time: 0
    [0.0] http://ocsp.cacert.org

  --------------------------------
    CRL (null):
    Issuer: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.
    ThisUpdate: 26/08/2014 07:39
    NextUpdate: 2/09/2014 07:39
    ce1895dc206cd512c86ac1817cdfb7faf85d0ea8
  Application[0] = 1.3.6.1.5.5.7.3.4 Secure Email
  Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication
  Application[2] = 1.3.6.1.4.1.311.10.3.4 Encrypting File System
  Application[3] = 1.3.6.1.4.1.311.10.3.3
  Application[4] = 2.16.840.1.113730.4.1

CertContext[0][1]: dwInfoStatus=101 dwErrorStatus=1000040
  Issuer: E=***@cacert.org, CN=CA Cert Signing Authority,
OU=http://www.cacert.org, O=Root CA
  NotBefore: 23/05/2011 19:48
  NotAfter: 20/05/2021 19:48
  Subject: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.
  Serial: 0a418a
  cefdad8afa6c7cf4e80be9f4fe3944fc643f7cad
  Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
  Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
  ----------------  Certificate AIA  ----------------
  Verified "Certificate (0)" Time: 0
    [0.0] http://www.CAcert.org/ca.crt

  ----------------  Certificate CDP  ----------------
  No URLs "None" Time: 0
  ----------------  Certificate OCSP  ----------------
  Verified "OCSP" Time: 0
    [0.0] http://ocsp.CAcert.org/

  --------------------------------
  Issuance[0] = 1.3.6.1.4.1.18506

CertContext[0][2]: dwInfoStatus=109 dwErrorStatus=0
  Issuer: E=***@cacert.org, CN=CA Cert Signing Authority,
OU=http://www.cacert.org, O=Root CA
  NotBefore: 30/03/2003 14:29
  NotAfter: 29/03/2033 14:29
  Subject: E=***@cacert.org, CN=CA Cert Signing Authority,
OU=http://www.cacert.org, O=Root CA
  Serial: 00
  338fce76468880cd70b21a3be9b89cf436ec5c13
  Element.dwInfoStatus = CERT_TRUST_HAS_EXACT_MATCH_ISSUER (0x1)
  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  ----------------
  Failed "CDP" Time: 0
    Error retrieving URL: Moved permanently (301). 0x8019012d (-2145844947
HTTP_E_STATUS_MOVED)
    https://www.cacert.org/revoke.crl

  ----------------  Certificate OCSP  ----------------
  No URLs "None" Time: 0
  --------------------------------

Exclude leaf cert:
  add445fbcd9c95ef02599f1b392b92307c256322
Full chain:
  a348ff1df778b15e057c76c864cb4980769e582a
  Issuer: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.
  NotBefore: 3/01/2013 14:17
  NotAfter: 3/01/2015 14:17
  Subject: E=***@thecurls.onmicrosoft.com, CN=Jason Curl
  Serial: 011232
  SubjectAltName: RFC822 Name=***@thecurls.onmicrosoft.com
  1ed59356682c83239b7f2926840d279b39a23cf9
The revocation function was unable to check revocation because the
revocation server was offline. 0x80092013 (-2146885613
CRYPT_E_REVOCATION_OFFLINE)
------------------------------------
Revocation check skipped -- server offline
Cert is an End Entity certificate
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.
Stefan Thode
11 years ago
Permalink
Hallo Jason,
to work on your Certificates you have to work with MMC.EXE.
After you started MMC, you have to include the Snap-In "Certificates" in
the File Menu.
The Snap-In "Certificates" has to be included 2 Times, first the
Computer Certificate-Store and second the User Certificate-Store.

In the Computer Certificate-Store you have to import the Root
Certificates "Root" and Class3". (With this you makes all Processes know
CAcert!)
In the User Certificate-Store you have to import your User Certificate.

You have to open every imported Certificate > Doubleclick it!
In the Folder Details click "Edit Details" and activate all Rights to
the Certificates.

That should fix your Problem. I had this Problem myself this Days and
fixed it this Way.

Regards
Stefan
...
Jason Curl
11 years ago
Permalink
Hi Stefan,

Thanks for the tip, but was unsuccessful. They were already in "Trusted Root
Certification Authorities" in both Certificates (Local Computer) and
Certificates (Current User). Writing my own code shows that trust works, but
revocation checks don't, resulting in a warning.

Note, the error I wrote is not related to an untrusted certificate, but to
the problem that the revocation list can't be determined. The command
"certutil -verify -urlfetch jason.cer" was something that I found from a MS
forum for debugging, and the result clearly shows that the CACert
certificate root with serial number 00 can't be verified online.

Because the CACert root has the CRL link, and as far as I'm aware there's no
possibility to create a new root certificate at this time, I'm guessing the
only solution is to reinstate the CRL server that serves only for the root
certificate with serial number "00".
Post by Jason Curl
---------------- Certificate CDP ----------------
Failed "CDP" Time: 0
Error retrieving URL: Moved permanently (301). 0x8019012d
(-2145844947
...
Regards,
Jason.

-----Original Message-----
From: cacert-support-***@lists.cacert.org
[mailto:cacert-support-***@lists.cacert.org] On Behalf Of Stefan Thode
Sent: Friday, September 05, 2014 8:56 PM
To: cacert-***@lists.cacert.org
Subject: Re: CRL Lists always show offline

Hallo Jason,
to work on your Certificates you have to work with MMC.EXE.
After you started MMC, you have to include the Snap-In "Certificates" in
the File Menu.
The Snap-In "Certificates" has to be included 2 Times, first the
Computer Certificate-Store and second the User Certificate-Store.

In the Computer Certificate-Store you have to import the Root
Certificates "Root" and Class3". (With this you makes all Processes know
CAcert!)
In the User Certificate-Store you have to import your User Certificate.

You have to open every imported Certificate > Doubleclick it!
In the Folder Details click "Edit Details" and activate all Rights to
the Certificates.

That should fix your Problem. I had this Problem myself this Days and
fixed it this Way.

Regards
Stefan
Post by Jason Curl
Hello,
Does anyone know how to fix the problem that validity checks always fail in
Win7?
Failed "CDP" Time: 0
Error retrieving URL: Moved permanently (301). 0x8019012d
(-2145844947
...
(-2145844947
...
Jason Curl
11 years ago
Permalink
Hello,

I did some more debugging using some network packet sniffer analysis, but I
can't get to the root of the problem without help.

Everything is definitely OK, until the request to www.cacert.org:443 for
https://www.cacert.org/revoke.crl

Request to ocsp.cacert.org => 200 OK
GET
//MEQwQjBAMD4wPDAJBgUrDgMCGgUABBSLpMnLFykZRT67jnMJkbkl8oMiZQQUFrUyG9TH8%2BDm
jvO90rA67rI5GNECAwpBig%3D%3D, Version: HTTP/1.1
Request to ocsp.cacert.org => 200 OK
POST /
Request to crl.cacert.org => 200 OK
GET /class3-revoke.crl
Request to ocsp.cacert.org => 200 OK
POST /
Request to 213.154.225.245 => 200 OK
GET /ca.crt
Request to ocsp.cacert.org => 200 OK
POST /
Request to www.cacert.org HTTPS => ?? can't decode the content, and the
utility tool can detect a proxy replacing the certificate.

When running again on a different computer, I get the same error (but
without the error code)
---------------- Certificate CDP ----------------
Failed "CDP" Time: 0
Error retrieving URL: Error 0x8019012d (-2145844947)
https://www.cacert.org/revoke.crl

Help on resolving this would be much appreciated.

Regards
Jason.


-----Original Message-----
From: cacert-support-***@lists.cacert.org
[mailto:cacert-support-***@lists.cacert.org] On Behalf Of Stefan Thode
Sent: Friday, September 05, 2014 8:56 PM
To: cacert-***@lists.cacert.org
Subject: Re: CRL Lists always show offline

Hallo Jason,
to work on your Certificates you have to work with MMC.EXE.
After you started MMC, you have to include the Snap-In "Certificates" in
the File Menu.
The Snap-In "Certificates" has to be included 2 Times, first the
Computer Certificate-Store and second the User Certificate-Store.

In the Computer Certificate-Store you have to import the Root
Certificates "Root" and Class3". (With this you makes all Processes know
CAcert!)
In the User Certificate-Store you have to import your User Certificate.

You have to open every imported Certificate > Doubleclick it!
In the Folder Details click "Edit Details" and activate all Rights to
the Certificates.

That should fix your Problem. I had this Problem myself this Days and
fixed it this Way.

Regards
Stefan
Post by Jason Curl
Hello,
Does anyone know how to fix the problem that validity checks always fail in
Win7?
Failed "CDP" Time: 0
Error retrieving URL: Moved permanently (301). 0x8019012d
(-2145844947
...
(-2145844947
...
Benny Baumann
11 years ago
Permalink
Hi Jason,

do you have a trace available?

Also in order to read the HTTPS traffic you might try to create a
pre-master secret logfile (Firefox and Chrome can do this). If you
import this logfile into Wireshark you can transparently decrypt the SSL
connections for further analysis.

IDK if the Microsoft tool has a similar option, but might be worth a try.

@wytze: Could you give a try to transparently mirror the CRL-file
instead of redirection?

Regards,
BenBE.
...
Wytze van der Raay
11 years ago
Permalink
Post by Benny Baumann
Hi Jason,
do you have a trace available?
Also in order to read the HTTPS traffic you might try to create a
pre-master secret logfile (Firefox and Chrome can do this). If you
import this logfile into Wireshark you can transparently decrypt the SSL
connections for further analysis.
IDK if the Microsoft tool has a similar option, but might be worth a try.
@wytze: Could you give a try to transparently mirror the CRL-file
instead of redirection?
CRL requests directed to www.cacert.org are deliberately redirected to
crl.cacert.org since we don't want the (huge) CRL traffic on the main web
server.
The URL https://www.cacert.org/revoke.crl is *only* advertised in the CAcert
class1 root certificate, an unfortunate mistake made in 2003, from which we
are still suffering. All end-user certs are advertising the proper address
(http://crl.cacert.org/revoke.crl).
And of course we'd much prefer to see clients use OCSP instead of CRL,
as it is much more efficient.

But if it helps you debugging the problem (whatever it is), we can turn oo
the CRL redirection for a short period, say one hour, within which you can
perform the tests. Would that help?

But if you just want to see what happens on retrieving
https://www.cacert.org/revoke.crl, use wget:

$ wget https://www.cacert.org/revoke.crl
--2014-09-09 16:27:18-- https://www.cacert.org/revoke.crl
Resolving www.cacert.org (www.cacert.org)... 2001:7b8:3:9c::245, 213.154.225.245
Connecting to www.cacert.org (www.cacert.org)|2001:7b8:3:9c::245|:443...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://crl.cacert.org/revoke.crl [following]
--2014-09-09 16:27:19-- http://crl.cacert.org/revoke.crl
Resolving crl.cacert.org (crl.cacert.org)... 2001:7b8:616:163::104,
213.154.225.236
Connecting to crl.cacert.org (crl.cacert.org)|2001:7b8:616:163::104|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 6736576 (6.4M) [application/pkix-crl]
Saving to: ‘revoke.crl’

100%[====================================================>] 6,736,576
1.30MB/s in 5.0s

2014-09-09 16:27:24 (1.28 MB/s) - ‘revoke.crl’ saved [6736576/6736576]

Note that we are redirecting from https:// to http://, could that be
a problem??

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Hi Wytze,

The problem is when the chain of trust gets to the Class 3 signed against Class 1, so the validity of the Class 3 certificate cannot be checked. That's visible in my logs in the original mail and why the Class 3 shows the error. Note, the problem is not limited to only Outlook, but to all programs using the Windows Crypto API to check certificates (I'm writing a program that checks certificate chain of trust I get the same error from .NET).

I didn't think about the trick with WGET. That then shows that the MS certificate stack doesn't do the redirect.

I'm pretty convinced that fixing the redirect will work. Instead of a 301, can a URL rewrite work?

Do you have a Windows machine with a normal certificate used for s/mime? If so, instead of having to try to find a time where we're both available at the same time, just execute the command from the Windows command prompt:

certutil -verify -urlfetch <yourcert>.cer

I had the root and class3 (both current versions) in the user store and the machine store as originally suggested by Stefan Thode.

Regards,
Jason.

-----Original Message-----
From: Wytze van der Raay [mailto:***@cacert.org]
Sent: Tuesday, 9 September 2014 16:38
To: Benny Baumann; Jason Curl; Stefan Thode; cacert-***@lists.cacert.org
Cc: critical-***@cacert.org
Subject: Re: CRL Lists always show offline
Post by Benny Baumann
Hi Jason,
do you have a trace available?
Also in order to read the HTTPS traffic you might try to create a
pre-master secret logfile (Firefox and Chrome can do this). If you
import this logfile into Wireshark you can transparently decrypt the SSL
connections for further analysis.
IDK if the Microsoft tool has a similar option, but might be worth a try.
@wytze: Could you give a try to transparently mirror the CRL-file
instead of redirection?
CRL requests directed to www.cacert.org are deliberately redirected to
crl.cacert.org since we don't want the (huge) CRL traffic on the main web
server.
The URL https://www.cacert.org/revoke.crl is *only* advertised in the CAcert
class1 root certificate, an unfortunate mistake made in 2003, from which we
are still suffering. All end-user certs are advertising the proper address
(http://crl.cacert.org/revoke.crl).
And of course we'd much prefer to see clients use OCSP instead of CRL,
as it is much more efficient.

But if it helps you debugging the problem (whatever it is), we can turn oo
the CRL redirection for a short period, say one hour, within which you can
perform the tests. Would that help?

But if you just want to see what happens on retrieving
https://www.cacert.org/revoke.crl, use wget:

$ wget https://www.cacert.org/revoke.crl
--2014-09-09 16:27:18-- https://www.cacert.org/revoke.crl
Resolving www.cacert.org (www.cacert.org)... 2001:7b8:3:9c::245, 213.154.225.245
Connecting to www.cacert.org (www.cacert.org)|2001:7b8:3:9c::245|:443...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://crl.cacert.org/revoke.crl [following]
--2014-09-09 16:27:19-- http://crl.cacert.org/revoke.crl
Resolving crl.cacert.org (crl.cacert.org)... 2001:7b8:616:163::104,
213.154.225.236
Connecting to crl.cacert.org (crl.cacert.org)|2001:7b8:616:163::104|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 6736576 (6.4M) [application/pkix-crl]
Saving to: ‘revoke.crl’

100%[====================================================>] 6,736,576
1.30MB/s in 5.0s

2014-09-09 16:27:24 (1.28 MB/s) - ‘revoke.crl’ saved [6736576/6736576]

Note that we are redirecting from https:// to http://, could that be
a problem??

Regards,
-- wytze
Wytze van der Raay
11 years ago
Permalink
Hi Jason,
Post by Jason Curl
The problem is when the chain of trust gets to the Class 3 signed
against Class 1, so the validity of the Class 3 certificate cannot be
checked. That's visible in my logs in the original mail and why the
Class 3 shows the error. Note, the problem is not limited to only
Outlook, but to all programs using the Windows Crypto API to check
certificates (I'm writing a program that checks certificate chain of
trust I get the same error from .NET).
I do not fully understand the traces that you've sent, probably due to
my lack of familiarity with the Windows platform. It would be nice to
know exactly which step the validation software takes and what kind of
reply (or non-reply) is causing the failure.
Post by Jason Curl
I didn't think about the trick with WGET. That then shows that the MS
certificate stack doesn't do the redirect.
Right. It would be interesting to see what the relevant RFCs say about
this behaviour. At first sight, it would seem that the use of HTTP(S)
for CRL fetching implies that redirects should be handled as they occur.
Post by Jason Curl
I'm pretty convinced that fixing the redirect will work. Instead of a
301, can a URL rewrite work?
Since the replacement URL is on a different host (crl.cacert.org !=
www.cacert.org), it doesn't really matter whether we use a plain
redirect or a URL rewrite in the Apache2 config for this webserver.
A rewrite to another host also causes a redirect to be issued.
I've tested with a temp redirect (302) instead of a permanent one
(301), but the behaviour of the Windows software remains the same
for that.
Post by Jason Curl
Do you have a Windows machine with a normal certificate used for
s/mime? If so, instead of having to try to find a time where we're
both available at the same time, just execute the command from the
certutil -verify -urlfetch <yourcert>.cer
With some scrambling I have managed to do this. Like I wrote above:
no difference when using rewrite (302) rather than redirect permanent
(301). But turning off redirection entirely changes something indeed,
although not everything. I'll attach (Dutch!) traces of both versions,
but will inline the diff here:

--- LOG-redirect 2014-09-11 17:39:19.000000000 +0200
+++ LOG-noredirect 2014-09-11 17:38:27.000000000 +0200
@@ -88,9 +88,8 @@
---------------- Certificaat AIA ----------------
Geen URL's "Geen" Tijd: 0
---------------- Certificaat CDP ----------------
- Mislukt "CRL-distributiepunt (CDP)" Tijd: 0
- Fout tijdens het ophalen van de URL: Fout 0x8019012d (-2145844947)
- https://www.cacert.org/revoke.crl
+ Gecontroleerd "Basislijst met ingetrokken certificaten" Tijd: 5
+ [0.0] https://www.cacert.org/revoke.crl

---------------- Certificaat-OCSP ----------------

Looks nice, BUT: the conclusion at the very end does *not* change:

The revocation function was unable to check revocation because the
revocation server was offline. 0x80092013 (-2146885613
CRYPT_E_REVOCATION_OFFLINE)
------------------------------------
Revocation check skipped -- server offline

This message makes no sense to me ... does it make sense to you?

Anyway, in order to support your testing, I have left the redirection
for CRL fetches from www.cacert.org *disabled* for the time being.
Please perform your tests as soon as possible, and let us know when
you are done, so we can revert to the original setting -- or perhaps
to a new setting which is satisfactory for everyone!

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Hello Wytze

Sorry for the top posting, OL2010 makes it difficult to inline post.

I've seen the same difference as you, and I've been at it for the last 2
hours.

CertContext[0][0]: dwInfoStatus=104 dwErrorStatus=0
Subject: E=***@thecurls.onmicrosoft.com, CN=Jason Curl
Serial: 011232
CertContext[0][1]: dwInfoStatus=101 dwErrorStatus=1000040
Subject: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.
Serial: 0a418a

Problem still here (dwErrorStatus=1000040, should be 0).

CertContext[0][2]: dwInfoStatus=109 dwErrorStatus=0
Subject: E=***@cacert.org, CN=CA Cert Signing Authority,
OU=http://www.cacert.org, O=Root CA
Serial: 00

I confirmed that revoke.crl doesn't contain 0a418a.

I tried swapping out with the old MD5 Class 3 with serial number 01, I get the
same error.


Now, when I run "certutil -url root.cer", it comes up with a GUI (root.cer is
the class 1 with serial number 00).

Interestingly, when I click "CRL's (from CDP)", it waits and then indicates
"Failed".
Error retrieving URL: This operation returned because the timeout period
expired. 0x800705b4 (WIN32: 1460)

If I increase the timeout to 30s, it is then "verified" (but not always).

I have to figure out how to change the timeout with the command
"certutil -verify -urlfetch" to check if the problem is solved. That might be
on the weekend? I couldn't get any further tonight.

Summary: I think we have two problems:
1) The URL redirect causes problems. But it might not be the root cause
2) The CRL file from https://www.cacert.org/revoke.crl is too big and takes
more than 15s to download on my machine. I'll need to investigate this
further.

Regards,
Jason.

-----Original Message-----
From: Wytze van der Raay [mailto:***@cacert.org]
Sent: Thursday, September 11, 2014 7:47 PM
To: Jason Curl; Benny Baumann; Stefan Thode; cacert-***@lists.cacert.org
Cc: critical-***@cacert.org
Subject: Re: CRL Lists always show offline

Hi Jason,
Post by Jason Curl
The problem is when the chain of trust gets to the Class 3 signed
against Class 1, so the validity of the Class 3 certificate cannot be
checked. That's visible in my logs in the original mail and why the
Class 3 shows the error. Note, the problem is not limited to only
Outlook, but to all programs using the Windows Crypto API to check
certificates (I'm writing a program that checks certificate chain of
trust I get the same error from .NET).
I do not fully understand the traces that you've sent, probably due to
my lack of familiarity with the Windows platform. It would be nice to
know exactly which step the validation software takes and what kind of
reply (or non-reply) is causing the failure.
Post by Jason Curl
I didn't think about the trick with WGET. That then shows that the MS
certificate stack doesn't do the redirect.
Right. It would be interesting to see what the relevant RFCs say about
this behaviour. At first sight, it would seem that the use of HTTP(S)
for CRL fetching implies that redirects should be handled as they occur.
Post by Jason Curl
I'm pretty convinced that fixing the redirect will work. Instead of a
301, can a URL rewrite work?
Since the replacement URL is on a different host (crl.cacert.org !=
www.cacert.org), it doesn't really matter whether we use a plain
redirect or a URL rewrite in the Apache2 config for this webserver.
A rewrite to another host also causes a redirect to be issued.
I've tested with a temp redirect (302) instead of a permanent one
(301), but the behaviour of the Windows software remains the same
for that.
Post by Jason Curl
Do you have a Windows machine with a normal certificate used for
s/mime? If so, instead of having to try to find a time where we're
both available at the same time, just execute the command from the
certutil -verify -urlfetch <yourcert>.cer
With some scrambling I have managed to do this. Like I wrote above:
no difference when using rewrite (302) rather than redirect permanent
(301). But turning off redirection entirely changes something indeed,
although not everything. I'll attach (Dutch!) traces of both versions,
but will inline the diff here:

--- LOG-redirect 2014-09-11 17:39:19.000000000 +0200
+++ LOG-noredirect 2014-09-11 17:38:27.000000000 +0200
@@ -88,9 +88,8 @@
---------------- Certificaat AIA ----------------
Geen URL's "Geen" Tijd: 0
---------------- Certificaat CDP ----------------
- Mislukt "CRL-distributiepunt (CDP)" Tijd: 0
- Fout tijdens het ophalen van de URL: Fout 0x8019012d (-2145844947)
- https://www.cacert.org/revoke.crl
+ Gecontroleerd "Basislijst met ingetrokken certificaten" Tijd: 5
+ [0.0] https://www.cacert.org/revoke.crl

---------------- Certificaat-OCSP ----------------

Looks nice, BUT: the conclusion at the very end does *not* change:

The revocation function was unable to check revocation because the
revocation server was offline. 0x80092013 (-2146885613
CRYPT_E_REVOCATION_OFFLINE)
------------------------------------
Revocation check skipped -- server offline

This message makes no sense to me ... does it make sense to you?

Anyway, in order to support your testing, I have left the redirection
for CRL fetches from www.cacert.org *disabled* for the time being.
Please perform your tests as soon as possible, and let us know when
you are done, so we can revert to the original setting -- or perhaps
to a new setting which is satisfactory for everyone!

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Follow up: using the "-t 30" option in certutil doesn't change anything.

Using "certutil -f -verify -urlfetch <mycert>" shows pass, but in the
diagnostics it shows a failure which I don't understand.

I've posted my question on TechNet. Let's see if I get an answer there.
http://social.technet.microsoft.com/Forums/windowsserver/en-US/7e69d0d1-1df2-4830-8d22-f887b6261062/cacert-revocation-server-offline?forum=w7itprosecurity

Regards,
Jason.

-----Original Message-----
From: cacert-support-***@lists.cacert.org
[mailto:cacert-support-***@lists.cacert.org] On Behalf Of Jason Curl
Sent: 11 September 2014 22:22
To: Wytze van der Raay; Benny Baumann; Stefan Thode;
cacert-***@lists.cacert.org
Cc: critical-***@cacert.org
Subject: RE: CRL Lists always show offline

Hello Wytze

Sorry for the top posting, OL2010 makes it difficult to inline post.

I've seen the same difference as you, and I've been at it for the last 2
hours.

CertContext[0][0]: dwInfoStatus=104 dwErrorStatus=0
Subject: E=***@thecurls.onmicrosoft.com, CN=Jason Curl
Serial: 011232
CertContext[0][1]: dwInfoStatus=101 dwErrorStatus=1000040
Subject: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.
Serial: 0a418a

Problem still here (dwErrorStatus=1000040, should be 0).

CertContext[0][2]: dwInfoStatus=109 dwErrorStatus=0
Subject: E=***@cacert.org, CN=CA Cert Signing Authority,
OU=http://www.cacert.org, O=Root CA
Serial: 00

I confirmed that revoke.crl doesn't contain 0a418a.

I tried swapping out with the old MD5 Class 3 with serial number 01, I get the
same error.


Now, when I run "certutil -url root.cer", it comes up with a GUI (root.cer is
the class 1 with serial number 00).

Interestingly, when I click "CRL's (from CDP)", it waits and then indicates
"Failed".
Error retrieving URL: This operation returned because the timeout period
expired. 0x800705b4 (WIN32: 1460)

If I increase the timeout to 30s, it is then "verified" (but not always).

I have to figure out how to change the timeout with the command
"certutil -verify -urlfetch" to check if the problem is solved. That might be
on the weekend? I couldn't get any further tonight.

Summary: I think we have two problems:
1) The URL redirect causes problems. But it might not be the root cause
2) The CRL file from https://www.cacert.org/revoke.crl is too big and takes
more than 15s to download on my machine. I'll need to investigate this
further.

Regards,
Jason.

-----Original Message-----
From: Wytze van der Raay [mailto:***@cacert.org]
Sent: Thursday, September 11, 2014 7:47 PM
To: Jason Curl; Benny Baumann; Stefan Thode; cacert-***@lists.cacert.org
Cc: critical-***@cacert.org
Subject: Re: CRL Lists always show offline

Hi Jason,
Post by Jason Curl
The problem is when the chain of trust gets to the Class 3 signed
against Class 1, so the validity of the Class 3 certificate cannot be
checked. That's visible in my logs in the original mail and why the
Class 3 shows the error. Note, the problem is not limited to only
Outlook, but to all programs using the Windows Crypto API to check
certificates (I'm writing a program that checks certificate chain of
trust I get the same error from .NET).
I do not fully understand the traces that you've sent, probably due to
my lack of familiarity with the Windows platform. It would be nice to
know exactly which step the validation software takes and what kind of
reply (or non-reply) is causing the failure.
Post by Jason Curl
I didn't think about the trick with WGET. That then shows that the MS
certificate stack doesn't do the redirect.
Right. It would be interesting to see what the relevant RFCs say about
this behaviour. At first sight, it would seem that the use of HTTP(S)
for CRL fetching implies that redirects should be handled as they occur.
Post by Jason Curl
I'm pretty convinced that fixing the redirect will work. Instead of a
301, can a URL rewrite work?
Since the replacement URL is on a different host (crl.cacert.org !=
www.cacert.org), it doesn't really matter whether we use a plain
redirect or a URL rewrite in the Apache2 config for this webserver.
A rewrite to another host also causes a redirect to be issued.
I've tested with a temp redirect (302) instead of a permanent one
(301), but the behaviour of the Windows software remains the same
for that.
Post by Jason Curl
Do you have a Windows machine with a normal certificate used for
s/mime? If so, instead of having to try to find a time where we're
both available at the same time, just execute the command from the
certutil -verify -urlfetch <yourcert>.cer
With some scrambling I have managed to do this. Like I wrote above:
no difference when using rewrite (302) rather than redirect permanent
(301). But turning off redirection entirely changes something indeed,
although not everything. I'll attach (Dutch!) traces of both versions,
but will inline the diff here:

--- LOG-redirect 2014-09-11 17:39:19.000000000 +0200
+++ LOG-noredirect 2014-09-11 17:38:27.000000000 +0200
@@ -88,9 +88,8 @@
---------------- Certificaat AIA ----------------
Geen URL's "Geen" Tijd: 0
---------------- Certificaat CDP ----------------
- Mislukt "CRL-distributiepunt (CDP)" Tijd: 0
- Fout tijdens het ophalen van de URL: Fout 0x8019012d (-2145844947)
- https://www.cacert.org/revoke.crl
+ Gecontroleerd "Basislijst met ingetrokken certificaten" Tijd: 5
+ [0.0] https://www.cacert.org/revoke.crl

---------------- Certificaat-OCSP ----------------

Looks nice, BUT: the conclusion at the very end does *not* change:

The revocation function was unable to check revocation because the
revocation server was offline. 0x80092013 (-2146885613
CRYPT_E_REVOCATION_OFFLINE)
------------------------------------
Revocation check skipped -- server offline

This message makes no sense to me ... does it make sense to you?

Anyway, in order to support your testing, I have left the redirection
for CRL fetches from www.cacert.org *disabled* for the time being.
Please perform your tests as soon as possible, and let us know when
you are done, so we can revert to the original setting -- or perhaps
to a new setting which is satisfactory for everyone!

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Hello,
Post by Jason Curl
I've posted my question on TechNet. Let's see if I get an answer there.
http://social.technet.microsoft.com/Forums/windowsserver/en-US/7e69d0d1-1df2-4830-8d22-f887b6261062/cacert-revocation-server-offline?forum=w7itprosecurity
The last post talks about the Root self-signed certificate not following
recommendations:

I tried to test with my cacert certificate now but the redirect is again
in place. Without the redirect, HTTPS is used in the CDP which - as per
RFC 5280 <http://tools.ietf.org/html/rfc5280> - CAs /SHOULD NOT /do due
to potential issues with circular references. Relying parties "/MUST be
prepared for the possibility that this will result in unbounded
recursion/" - so it would be undertstandable if certutil would not
follow all the recursions.

The poster seems to suggest that the checks are failing due to potential
circular regressions. Is this worthwhile to submit a bug and to plan
with the new CAcert root?

Regards,
Jason.
Wytze van der Raay
11 years ago
Permalink
Hi Jason,
...
Posting another bug may not help that much, but I have added the information
above to https://bugs.cacert.org/view.php?id=1305, since that is already
discussing improvements to the CAcert root certificate.

By the way, if you think it is useful to do more testing with the redirect
disabled, let us know, and we can schedule another couple of days with the
CRL redirect disabled on the www.cacert.org server.

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Hi Wytze,
...
For now, I'm not convinced that I have an answer that makes it
worthwhile to do this test again. I think far better would be to
organise a test environment similar to the production site, but where we
can:
* Remove https://www.cacert.org/revoke.crl to
http://crl.cacert.org/revoke.crl
* Create two CRLs for testing - one that's huge (e.g. 10 MB, so it takes
about 60s to download); one that' nearly empty.

And of course step by step, so we know exactly why Windows behaves as it
does.

Then the feedback from this testing should be documented somewhere in
the NRE project (of which I've found none).

So if a bug report doesn't help, what does?

Regards,
Jason.
Benny Baumann
11 years ago
Permalink
Hi Jason,
...
At test.cacert.org we have a testserver environment which is also
available as a virtual maschine download. If you like you can play
around with that a bit. Just put it somewhere local, redirect the
subdomains for it accordingly so windows can find them and go ahead with
testing.
Post by Jason Curl
Then the feedback from this testing should be documented somewhere in
the NRE project (of which I've found none).
So if a bug report doesn't help, what does?
A bug helps, but to quote Terry Pratchett: If you want something done,
give it to someone busy ;-) Maybe you can get into with the NRE people
Post by Jason Curl
Regards,
Jason.
Regards,
BenBE.

Wytze van der Raay
11 years ago
Permalink
Hi Jason,
Post by Jason Curl
Sorry for the top posting, OL2010 makes it difficult to inline post.
No problem for me :-)
Post by Jason Curl
I've seen the same difference as you, and I've been at it for the last 2
hours.
CertContext[0][0]: dwInfoStatus=104 dwErrorStatus=0
Serial: 011232
CertContext[0][1]: dwInfoStatus=101 dwErrorStatus=1000040
Subject: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.
Serial: 0a418a
Problem still here (dwErrorStatus=1000040, should be 0).
I have been wondering what this message really means. Looking at the various
progress messages displayed by the certutil verification, I am guessing that
it attempts to check each certificate in two different ways:

(a) through the listed CDP (CRL Distribution Point), typically a URL for
downloading a CRL;
(b) through the listed AIA (Authority Information Access), typically a URL
for a OCSP server.

All normal certificates issued by CAcert contain both a CDP and an AIA.
Howver, the Class3 root certificate only contains an AIA, no CDP.
The Class1 root certificate only contains a CDP -- but this certificate
needs to be trusted anyway, as it is the real root; it cannot be
invalidated by OCSP or CRL.

Is it possible that the certutil verification process is complaining
about the lack of a CDP in the Class3 root certificate, by means of this
obscure "revocation offline" status??
...
It is a problem which we have temporarily swept under the carpet now.
The real solution will be to re-issue the root certificate with the
proper CDP, i.e. http://crl.cacert.org/revoke.crl, so redirects are
no longer needed.
Post by Jason Curl
2) The CRL file from https://www.cacert.org/revoke.crl is too big and takes
more than 15s to download on my machine. I'll need to investigate this
further.
Yes, it is too big (over 6 MB now), and that's one of the reasons for
promoting OCSP for certificate verification rather than CRL downloads.
But there is no stated limit in the X.509 protocols for CRL size, so
the software should be able to deal with it I think. The time needed
for download depends quite a bit on your network speed, so be generous
with your timeouts.

A third problem could be the issue with the non-present CDP in the Class3
root -- iff this is causing the dwErrorStatus=1000040 problem, which we
don't know.

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Hi Wytze,

I remember speaking with Marcus about the large CRL size. There's two other
options that I see:
1) Don't include expired certificates in the CRL. This appears to be done by
some CA's and is the default for the MS Certificate Server for enterprises.
2) Prevent new certificates being signed against the Class 1, set the validity
time to a higher value and after 2 years set the CRL to an even higher value
again (it should be empty).

As I mentioned in my other mail, I don't think it's related to the timeout
anymore, I set it to 30 seconds and it still failed.

No bites yet on the Technet site.

Regards,
Jason.

-----Original Message-----
From: Wytze van der Raay [mailto:***@cacert.org]
Sent: Friday, 12 September 2014 17:55
To: Jason Curl; Benny Baumann; Stefan Thode; cacert-***@lists.cacert.org
Cc: critical-***@cacert.org
Subject: Re: CRL Lists always show offline

Hi Jason,
Post by Jason Curl
Sorry for the top posting, OL2010 makes it difficult to inline post.
No problem for me :-)
Post by Jason Curl
I've seen the same difference as you, and I've been at it for the last 2
hours.
CertContext[0][0]: dwInfoStatus=104 dwErrorStatus=0
Serial: 011232
CertContext[0][1]: dwInfoStatus=101 dwErrorStatus=1000040
Subject: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.
Serial: 0a418a
Problem still here (dwErrorStatus=1000040, should be 0).
I have been wondering what this message really means. Looking at the various
progress messages displayed by the certutil verification, I am guessing that
it attempts to check each certificate in two different ways:

(a) through the listed CDP (CRL Distribution Point), typically a URL for
downloading a CRL;
(b) through the listed AIA (Authority Information Access), typically a URL
for a OCSP server.

All normal certificates issued by CAcert contain both a CDP and an AIA.
Howver, the Class3 root certificate only contains an AIA, no CDP.
The Class1 root certificate only contains a CDP -- but this certificate
needs to be trusted anyway, as it is the real root; it cannot be
invalidated by OCSP or CRL.

Is it possible that the certutil verification process is complaining
about the lack of a CDP in the Class3 root certificate, by means of this
obscure "revocation offline" status??
...
It is a problem which we have temporarily swept under the carpet now.
The real solution will be to re-issue the root certificate with the
proper CDP, i.e. http://crl.cacert.org/revoke.crl, so redirects are
no longer needed.
Post by Jason Curl
2) The CRL file from https://www.cacert.org/revoke.crl is too big and takes
more than 15s to download on my machine. I'll need to investigate this
further.
Yes, it is too big (over 6 MB now), and that's one of the reasons for
promoting OCSP for certificate verification rather than CRL downloads.
But there is no stated limit in the X.509 protocols for CRL size, so
the software should be able to deal with it I think. The time needed
for download depends quite a bit on your network speed, so be generous
with your timeouts.

A third problem could be the issue with the non-present CDP in the Class3
root -- iff this is causing the dwErrorStatus=1000040 problem, which we
don't know.

Regards,
-- wytze
Wytze van der Raay
11 years ago
Permalink
Hi Jason,
Post by Jason Curl
I remember speaking with Marcus about the large CRL size. There's two other
1) Don't include expired certificates in the CRL. This appears to be done by
some CA's and is the default for the MS Certificate Server for enterprises.
Yes, I have also advocated this for the past five years or so ... without
success until now. Some people want to be able to check even for expired
certs whether they were ever revoked during their lifetime. A compromise
would be possible by maintaining *two* separate CRLs: a small one with the
non-expired revoked certs only, and a large one containing all revoked certs
(ie the current one). But the software changes to deal with two rather than
one CRL per root cert have been postponed as far as I know.
Post by Jason Curl
2) Prevent new certificates being signed against the Class 1, set the validity
time to a higher value and after 2 years set the CRL to an even higher value
again (it should be empty).
Interesting idea ... what you are saying then is that we should use a new
class1 root cert (which could be subordinate to the current real root cert),
just like we already do for class3, and thus start a new and fresh CRL.
But that kind of major change is in the hands of the NRE (New Roots & Escrow)
team at CAcert, see also http://wiki.cacert.org/Roots/EscrowAndRecovery/NRE
Post by Jason Curl
As I mentioned in my other mail, I don't think it's related to the timeout
anymore, I set it to 30 seconds and it still failed.
Which also implies that the size of the CRL is not a real issue.
Post by Jason Curl
No bites yet on the Technet site.
Question too hard? :-)

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Hi Jason,
[JC] Hi Wytze
Post by Jason Curl
I remember speaking with Marcus about the large CRL size. There's two other
1) Don't include expired certificates in the CRL. This appears to be done by
some CA's and is the default for the MS Certificate Server for enterprises.
Yes, I have also advocated this for the past five years or so ... without
success until now. Some people want to be able to check even for expired
certs whether they were ever revoked during their lifetime. A compromise
would be possible by maintaining *two* separate CRLs: a small one with the
non-expired revoked certs only, and a large one containing all revoked certs
(ie the current one). But the software changes to deal with two rather than
one CRL per root cert have been postponed as far as I know.

[JC] I think the last argument makes no sense. Once a certificate has expired,
it must be assumed that it's compromised, that's implicit in the expiry date.
No one will ever revoke a compromised certificate. Mail clients will complain
anyway, even if the certificate isn't revoked but expired if you get back to
reading your email after a couple of years.
Post by Jason Curl
2) Prevent new certificates being signed against the Class 1, set the validity
time to a higher value and after 2 years set the CRL to an even higher value
again (it should be empty).
Interesting idea ... what you are saying then is that we should use a new
class1 root cert (which could be subordinate to the current real root cert),
just like we already do for class3, and thus start a new and fresh CRL.
But that kind of major change is in the hands of the NRE (New Roots & Escrow)
team at CAcert, see also http://wiki.cacert.org/Roots/EscrowAndRecovery/NRE

[JC] Why do we even need to allow user certificates against the Class 1?
CACert assurers have already said at ATE's signing against the Class 3 is more
secure. Make it policy. And don't bother with the a new Class1 signed against
the root (it's no better than the existing Class 3). The class 1 should be the
most secure certificate CACert can make, and use Class 3 only for general use.
Then if the server is even compromised, Class1 is still safe as the private
key is never needed to be online anywhere, and only used to generate the class
3 if it is ever compromised.
Wytze van der Raay
11 years ago
Permalink
Hi Jason,
...
I am not the person that you need to convince here :-)
Other people have other views though.
...
You are describing here partly the new setup advocated by the NRE (New Roots &
Escrow) project, see also: http://wiki.cacert.org/Roots/EscrowAndRecovery/NRE
Until that is in place (and I have no idea when that will be), we cannot
simply stop issuing class1 certs from the current root -- these certificates
are highly popular with people who need certs quickly and cheaply but do not
want to go through the full CAcert assurance process to gain enough points
for getting access to CAcert's Class3 certificates. But if you think CAcert
should stop doing so, you should discuss it in the CAcert Policy mailing list:
https://lists.cacert.org/wws/info/cacert-policy

Regards,
-- wytze
Benny Baumann
11 years ago
Permalink
...
I'm all with you both here. Splitting up things would be a great deal
easier and there will be a change in the new software that will do
something like this, if it gets approved. Unfortunately this has to be
done through a change in the CPS/CP.
...
Just as a frame of reference: http://www.cacert.org/stats.php

Doing so will get about 80-90% of our users to loose access to
certificates. Thus: Yes, stopping to issue below the root directly
should be done, but a replacement Class1 subroot should be created in
this case.

@NRE: I heard some birds tweeting outside about a date not that far away
heavily influenced by a recent move by Mozilla. I guess the birds will
sing louder once they need you to listen to them.
Post by Benny Baumann
Regards,
-- wytze
Regards,
BenBE.
Wytze van der Raay
11 years ago
Permalink
Hi Jason,
Post by Jason Curl
Sorry for the top posting, OL2010 makes it difficult to inline post.
No problem for me :-)
Post by Jason Curl
I've seen the same difference as you, and I've been at it for the last 2
hours.
CertContext[0][0]: dwInfoStatus=104 dwErrorStatus=0
Serial: 011232
CertContext[0][1]: dwInfoStatus=101 dwErrorStatus=1000040
Subject: CN=CAcert Class 3 Root, OU=http://www.CAcert.org, O=CAcert Inc.
Serial: 0a418a
Problem still here (dwErrorStatus=1000040, should be 0).
I have been wondering what this message really means. Looking at the various
progress messages displayed by the certutil verification, I am guessing that
it attempts to check each certificate in two different ways:

(a) through the listed CDP (CRL Distribution Point), typically a URL for
downloading a CRL;
(b) through the listed AIA (Authority Information Access), typically a URL
for a OCSP server.

All normal certificates issued by CAcert contain both a CDP and an AIA.
Howver, the Class3 root certificate only contains an AIA, no CDP.
The Class1 root certificate only contains a CDP -- but this certificate
needs to be trusted anyway, as it is the real root; it cannot be
invalidated by OCSP or CRL.

Is it possible that the certutil verification process is complaining
about the lack of a CDP in the Class3 root certificate, by means of this
obscure "revocation offline" status??
...
It is a problem which we have temporarily swept under the carpet now.
The real solution will be to re-issue the root certificate with the
proper CDP, i.e. http://crl.cacert.org/revoke.crl, so redirects are
no longer needed.
Post by Jason Curl
2) The CRL file from https://www.cacert.org/revoke.crl is too big and takes
more than 15s to download on my machine. I'll need to investigate this
further.
Yes, it is too big (over 6 MB now), and that's one of the reasons for
promoting OCSP for certificate verification rather than CRL downloads.
But there is no stated limit in the X.509 protocols for CRL size, so
the software should be able to deal with it I think. The time needed
for download depends quite a bit on your network speed, so be generous
with your timeouts.

A third problem could be the issue with the non-present CDP in the Class3
root -- iff this is causing the dwErrorStatus=1000040 problem, which we
don't know.

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Hello Benny,

I don't have HTTPS traces (yet). I might have time this weekend to
investigate after I do some research. When I used Microsoft Network Monitor
to log HTTPS, it sets up an intermediate certificate and the "certutil" sees
that there is a "man-in-the-middle" and stops, not allowing traces.

Regards,
Jason.

-----Original Message-----
From: Benny Baumann [mailto:***@cacert.org]
Sent: Tuesday, 9 September 2014 11:35
To: Jason Curl; Stefan Thode; cacert-***@lists.cacert.org;
critical-***@cacert.org
Subject: Re: CRL Lists always show offline

Hi Jason,

do you have a trace available?

Also in order to read the HTTPS traffic you might try to create a
pre-master secret logfile (Firefox and Chrome can do this). If you
import this logfile into Wireshark you can transparently decrypt the SSL
connections for further analysis.

IDK if the Microsoft tool has a similar option, but might be worth a try.

@wytze: Could you give a try to transparently mirror the CRL-file
instead of redirection?

Regards,
BenBE.
Post by Jason Curl
Hello,
I did some more debugging using some network packet sniffer analysis, but I
can't get to the root of the problem without help.
Everything is definitely OK, until the request to www.cacert.org:443 for
https://www.cacert.org/revoke.crl
Request to ocsp.cacert.org => 200 OK
GET
//MEQwQjBAMD4wPDAJBgUrDgMCGgUABBSLpMnLFykZRT67jnMJkbkl8oMiZQQUFrUyG9TH8%2BDm
...
Jason Curl
11 years ago
Permalink
Hi,

I've found something that amounts to evidence that the CRL takes too long to download, that's why it isn’t verified.

On the site:
http://technet.microsoft.com/en-us/library/ee619754%28v=ws.10%29.aspx
"If a time-valid object is not found in the disk cache, the network retrieval
process starts. For each URL that is available for retrieval, CryptoAPI starts
a background thread to perform the network retrieval of that designated
object. By default, the calling thread will wait up to 15 seconds for the
retrieval to complete (as defined in Group Policy).
If the object takes longer than 15 seconds to download, then CryptoAPI will
report the server as offline, even as the retrieval continues in the
background. If the CRL distribution point specifies multiple working URLs,
then CryptoAPI will start the download of the second URL 15 seconds after the
URL retrieval began."

I can put the CRL manually in the cache with the command, and setting a large enough timeout.
certutil -url https://www.cacert.org/revoke.crl

Start Outlook and verification *PASSES*.

Erase the cache with the command:
certutil -urlcache * delete
and verification FAILS again.

The group policy object on Windows can be controlled with the link
http://technet.microsoft.com/en-us/library/cc771429.aspx

While it fails the first time, the docs from MS are true to their word, it's downloaded in the background and then second time I start Outlook it works. I'm not entirely sure how this timeout parameter is used (because I expected it to work immediately), but now it partially works (and there is other docs that an app can provide the timeout itself, which may very well be what Outlook is doing).

NEXT TEST: Temporarily (say for one week), reduce the CRL size to only a few hundred kilobytes (e.g. 15s * 50kB/s = 750kB) and retest. Or tell me how to get a test certificate for a test server that has a large CRL with a Class 1 and Class 3, and I test on that.

I don't have any other plausible explanation right now.

Regards,
Jason.

-----Original Message-----
From: Wytze van der Raay [mailto:***@cacert.org]
Sent: Saturday, September 13, 2014 4:00 PM
To: Jason Curl; Benny Baumann; Stefan Thode; cacert-***@lists.cacert.org
Cc: critical-***@cacert.org
Subject: Re: CRL Lists always show offline

Hi Jason,
Post by Jason Curl
I remember speaking with Marcus about the large CRL size. There's two other
1) Don't include expired certificates in the CRL. This appears to be done by
some CA's and is the default for the MS Certificate Server for enterprises.
Yes, I have also advocated this for the past five years or so ... without
success until now. Some people want to be able to check even for expired
certs whether they were ever revoked during their lifetime. A compromise
would be possible by maintaining *two* separate CRLs: a small one with the
non-expired revoked certs only, and a large one containing all revoked certs
(ie the current one). But the software changes to deal with two rather than
one CRL per root cert have been postponed as far as I know.
Post by Jason Curl
2) Prevent new certificates being signed against the Class 1, set the
validity
time to a higher value and after 2 years set the CRL to an even higher value
again (it should be empty).
Interesting idea ... what you are saying then is that we should use a new
class1 root cert (which could be subordinate to the current real root cert),
just like we already do for class3, and thus start a new and fresh CRL.
But that kind of major change is in the hands of the NRE (New Roots & Escrow)
team at CAcert, see also http://wiki.cacert.org/Roots/EscrowAndRecovery/NRE
Post by Jason Curl
As I mentioned in my other mail, I don't think it's related to the timeout
anymore, I set it to 30 seconds and it still failed.
Which also implies that the size of the CRL is not a real issue.
Post by Jason Curl
No bites yet on the Technet site.
Question too hard? :-)

Regards,
-- wytze
Wytze van der Raay
11 years ago
Permalink
Hi Jason,
...
This looks like pretty convincing evidence to me for your theory.
So it is indeed the size of CRL and the time needed to download it
(on your apparently somewhat slow network connection) which is confusing
the CryptoAPI.
Post by Jason Curl
The group policy object on Windows can be controlled with the link
http://technet.microsoft.com/en-us/library/cc771429.aspx
So you will need to tune the timer there to the speed of your network link
and the size of the CRL ... ugh :-(
...
Sorry, that is not possible. We cannot just haphazardly manipulate the CRL.
But I have created bug entry https://bugs.cacert.org/view.php?id=1306 for
the size issue, in the hope that documenting it will get some movement on
this front finally.
Post by Jason Curl
Or tell me
how to get a test certificate for a test server that has a large CRL with a
Class 1 and Class 3, and I test on that.
You can use test.cacert.org (aka cacert1.it-sls.de), it has its own root
certificate, but runs mostly identical software to the production server.
Its current CRL is 330 kilobyte. You can grow it by requesting an revoking
lots of certificates (although that would be rather time consuming probably).
Post by Jason Curl
I don't have any other plausible explanation right now.
Your current explanation looks good enough I think.

I am going to wrap up this CRL testing issue, and have submitted two entries
in the bug tracker to deal with it:

https://bugs.cacert.org/view.php?id=1305 "CAcert Class1 root certificate
needs to be reissued with an updated CDP and a SHA-based signature"

https://bugs.cacert.org/view.php?id=1306 "expired certificates should not be
listed in the CAcert CRLs"

I will now revert the situation on the production server back to "normal",
i.e. reinstate the redirection of the CRL URLs to crl.cacert.org. Note
that during the past days, with redirection disabled, the outgoing traffic
of this server increased from an average 1 - 2 GB per day to 7 - 9 GB per
day. Pretty dramatic, although insiginficant to the amount of traffic
handled by our CRL server (typically 130+ GB per day).

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Hello Wytze,

I appreciate your effort and supportiveness in going through until the end and helping me test what's going on here.

Probably the last things to say on this topic:
1) Moving back to the CRL server definitely broke everything that I got working until now. So to solve this problem it's a must have to implement the new root; or reduce the CRL and get rid of the redirect.

The NRE project *should* be, according to the project plan page, finished in 2 months. I'm wondering how credible this really is seeing that there appears to be no feedback on that page, and given you're not sure, it doesn't sound very well communicated.

2) I think the limiting factor for downloads is the server. Downloading the CRL is definitely not using up my bandwidth, with somewhere between 100kb/s and 500kb/s (I can download 700kb/s). And the download rate just got worse after moving back to the CRL server:
=> 2014-09-15 21:48:44 (66.1 KB/s) - `revoke.crl' saved [6748038/6748038]
traceroute to crl.cacert.org (213.154.225.236), 30 hops max, 60 byte packets
1 router.home.lan (192.168.1.1) 0.621 ms 0.842 ms 0.979 ms
2 dslb-094-218-240-001.094.218.pools.vodafone-ip.de (94.218.240.1) 19.141 ms 20.426 ms 21.890 ms
3 88.79.10.181 (88.79.10.181) 24.144 ms 25.289 ms 26.710 ms
4 92.79.212.237 (92.79.212.237) 30.884 ms 31.073 ms 34.971 ms
5 92.79.213.138 (92.79.213.138) 53.421 ms 53.618 ms 53.812 ms
6 amsix-501.xe-0-0-0.jun1.bit-2a.network.bit.nl (195.69.144.35) 53.887 ms 54.840 ms 56.037 ms
7 crl.cacert.org (213.154.225.236) 57.220 ms 30.570 ms 30.612 ms

So unfortunately, given that it took years just to update the certificate EKU and KU (hey, now I can sign my PDF's at least), I would be very surprised for any kind of resolution soon, which is a pity, as until then anyone using Outlook and Windows has no real way to verify the trust of any certificate issued.

I've only read a few posts of the policy list from the archives, but it looks considerably more bureaucratic than this somewhat user friendly forum. Not sure how much luck I would have...

Regards,
Jason.

-----Original Message-----
From: Wytze van der Raay [mailto:***@cacert.org]
Sent: 15 September 2014 16:52
To: Jason Curl; Benny Baumann; Stefan Thode; cacert-***@lists.cacert.org
Cc: critical-***@cacert.org
Subject: Re: CRL Lists always show offline

Hi Jason,
...
This looks like pretty convincing evidence to me for your theory.
So it is indeed the size of CRL and the time needed to download it
(on your apparently somewhat slow network connection) which is confusing
the CryptoAPI.
Post by Jason Curl
The group policy object on Windows can be controlled with the link
http://technet.microsoft.com/en-us/library/cc771429.aspx
So you will need to tune the timer there to the speed of your network link
and the size of the CRL ... ugh :-(
...
Sorry, that is not possible. We cannot just haphazardly manipulate the CRL.
But I have created bug entry https://bugs.cacert.org/view.php?id=1306 for
the size issue, in the hope that documenting it will get some movement on
this front finally.
Post by Jason Curl
Or tell me
how to get a test certificate for a test server that has a large CRL with a
Class 1 and Class 3, and I test on that.
You can use test.cacert.org (aka cacert1.it-sls.de), it has its own root
certificate, but runs mostly identical software to the production server.
Its current CRL is 330 kilobyte. You can grow it by requesting an revoking
lots of certificates (although that would be rather time consuming probably).
Post by Jason Curl
I don't have any other plausible explanation right now.
Your current explanation looks good enough I think.

I am going to wrap up this CRL testing issue, and have submitted two entries
in the bug tracker to deal with it:

https://bugs.cacert.org/view.php?id=1305 "CAcert Class1 root certificate
needs to be reissued with an updated CDP and a SHA-based signature"

https://bugs.cacert.org/view.php?id=1306 "expired certificates should not be
listed in the CAcert CRLs"

I will now revert the situation on the production server back to "normal",
i.e. reinstate the redirection of the CRL URLs to crl.cacert.org. Note
that during the past days, with redirection disabled, the outgoing traffic
of this server increased from an average 1 - 2 GB per day to 7 - 9 GB per
day. Pretty dramatic, although insiginficant to the amount of traffic
handled by our CRL server (typically 130+ GB per day).

Regards,
-- wytze
Wytze van der Raay
11 years ago
Permalink
Hi Jason,
Post by Jason Curl
I appreciate your effort and supportiveness in going through until
the end and helping me test what's going on here.
1) Moving back to the CRL server definitely broke everything that
I got working until now. So to solve this problem it's a must have
to implement the new root; or reduce the CRL and get rid of the
redirect.
Yes, that's quite clear indeed.
Post by Jason Curl
The NRE project *should* be, according to the project plan page,
finished in 2 months. I'm wondering how credible this really is
seeing that there appears to be no feedback on that page, and
given you're not sure, it doesn't sound very well communicated.
As far as I know, the planning goals have not been met, so indeed:
finished in two months sounds not so credible.
Post by Jason Curl
2) I think the limiting factor for downloads is the server.
Downloading the CRL is definitely not using up my bandwidth,
with somewhere between 100kb/s and 500kb/s (I can download 700kb/s).
=> 2014-09-15 21:48:44 (66.1 KB/s) - `revoke.crl' saved [6748038/6748038]
Hmmm, I didn't notice this myself, seeing typically speeds of 1 MB/s or
better. It turns out though that this is due to my usage of IPv6, and
the fact (bug) that the rate limiting on the CRL server does apparently
not extend to IPv6 traffic. Hey, secret tip hiding here :-)

The low speed you are experiencing over IPv4 is in fact quite typical
unfortunately, and due to the large number of simultaneous clients for
the CRLs, coupled with the need to rate limit (throttle) the aggregate
download speed to ~12 Mbps in order to avoid hefty charges from our ISP.
So we are effectively sharing 1200 kb/s over often 20 - 80 simultaneous
clients, resulting in an average speed per client of 15 - 60 kb/s.
When you downloaded the CRL from www.cacert.org, you got better speeds
since you had much less "competion", even with a rate limit of 5 Mbps
for that server.

It seems that many clients are downloading the CRLs much more often
than sensible. For those who really need to have a very up-to-date
version, we are offering access through rsync (see for that:
https://blog.cacert.org/2013/10/efficient-method-for-frequent-retrieval-of-crls/
). But it's rarely used by our clients :-(
Gzip compression can also be negotiated with our server, resulting in a
cut-down of the CRL size with about 66%, so downloading will take only
1/3 of the normal time. This is successfully used by some clients, but
not nearly by all.
Post by Jason Curl
So unfortunately, given that it took years just to update the certificate
EKU and KU (hey, now I can sign my PDF's at least), I would be very
surprised for any kind of resolution soon, which is a pity, as until then
anyone using Outlook and Windows has no real way to verify the trust of
any certificate issued.
Hmm, but let's take a big step back here: why can't you use OCSP for
verifying your certificates? OCSP is by far the preferred method for
that these days. And if OCSP is not working for you, can we find out
why that is, and maybe fix it??
Post by Jason Curl
I've only read a few posts of the policy list from the archives, but it
looks considerably more bureaucratic than this somewhat user friendly forum.
Not sure how much luck I would have...
Yeah, it's a different type of discussion that is conducted there :-)

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Hello Wytze,

Checking of my client certificate based on the class 3 is done via OCSP and it even works. But for Windows to completely verify trust it also needs to verify the class 3 intermediate against the CRL given in the CACert root, which is the actual problem.

My testing until now showed that when the CRL from class 1 is available, the class 3 can be verified as not revoked resulting in a complete chain of trust.

I assumed that the CRL field of the class 1 is self signed as part of the class 1 hence it is not possible to override. Further until now I've not found any documentation that describes how to download the CRL separately as some background process and tell Windows to use that.

I did get a bite from TechNet since it was moved, let's see if any thing constructive comes out of it.

Sent from my Windows Phone
________________________________
From: Wytze van der Raay<mailto:***@cacert.org>
Sent: ‎16/‎09/‎2014 17:51
To: Jason Curl<mailto:***@thecurls.onmicrosoft.com>; cacert-***@lists.cacert.org<mailto:cacert-***@lists.cacert.org>
Cc: critical-***@cacert.org<mailto:critical-***@cacert.org>
Subject: Re: CRL Lists always show offline

Hi Jason,
Post by Jason Curl
I appreciate your effort and supportiveness in going through until
the end and helping me test what's going on here.
1) Moving back to the CRL server definitely broke everything that
I got working until now. So to solve this problem it's a must have
to implement the new root; or reduce the CRL and get rid of the
redirect.
Yes, that's quite clear indeed.
Post by Jason Curl
The NRE project *should* be, according to the project plan page,
finished in 2 months. I'm wondering how credible this really is
seeing that there appears to be no feedback on that page, and
given you're not sure, it doesn't sound very well communicated.
As far as I know, the planning goals have not been met, so indeed:
finished in two months sounds not so credible.
Post by Jason Curl
2) I think the limiting factor for downloads is the server.
Downloading the CRL is definitely not using up my bandwidth,
with somewhere between 100kb/s and 500kb/s (I can download 700kb/s).
=> 2014-09-15 21:48:44 (66.1 KB/s) - `revoke.crl' saved [6748038/6748038]
Hmmm, I didn't notice this myself, seeing typically speeds of 1 MB/s or
better. It turns out though that this is due to my usage of IPv6, and
the fact (bug) that the rate limiting on the CRL server does apparently
not extend to IPv6 traffic. Hey, secret tip hiding here :-)

The low speed you are experiencing over IPv4 is in fact quite typical
unfortunately, and due to the large number of simultaneous clients for
the CRLs, coupled with the need to rate limit (throttle) the aggregate
download speed to ~12 Mbps in order to avoid hefty charges from our ISP.
So we are effectively sharing 1200 kb/s over often 20 - 80 simultaneous
clients, resulting in an average speed per client of 15 - 60 kb/s.
When you downloaded the CRL from www.cacert.org, you got better speeds
since you had much less "competion", even with a rate limit of 5 Mbps
for that server.

It seems that many clients are downloading the CRLs much more often
than sensible. For those who really need to have a very up-to-date
version, we are offering access through rsync (see for that:
https://blog.cacert.org/2013/10/efficient-method-for-frequent-retrieval-of-crls/
). But it's rarely used by our clients :-(
Gzip compression can also be negotiated with our server, resulting in a
cut-down of the CRL size with about 66%, so downloading will take only
1/3 of the normal time. This is successfully used by some clients, but
not nearly by all.
Post by Jason Curl
So unfortunately, given that it took years just to update the certificate
EKU and KU (hey, now I can sign my PDF's at least), I would be very
surprised for any kind of resolution soon, which is a pity, as until then
anyone using Outlook and Windows has no real way to verify the trust of
any certificate issued.
Hmm, but let's take a big step back here: why can't you use OCSP for
verifying your certificates? OCSP is by far the preferred method for
that these days. And if OCSP is not working for you, can we find out
why that is, and maybe fix it??
Post by Jason Curl
I've only read a few posts of the policy list from the archives, but it
looks considerably more bureaucratic than this somewhat user friendly forum.
Not sure how much luck I would have...
Yeah, it's a different type of discussion that is conducted there :-)

Regards,
-- wytze
Wytze van der Raay
11 years ago
Permalink
Hi Jason,
Post by Jason Curl
Checking of my client certificate based on the class 3 is done via OCSP and it
even works. But for Windows to completely verify trust it also needs to verify
the class 3 intermediate against the CRL given in the CACert root, which is
the actual problem.
Well, it needs to verify whether the class3 intermediate has not been revoked.
That check can simply be made against the OCSP server for the root, ie
ocsp.cacert.org.
Post by Jason Curl
My testing until now showed that when the CRL from class 1 is available, the
class 3 can be verified as not revoked resulting in a complete chain of trust.
Using the CRL is the second choice of course -- but once you have that
donwloaded, can it not be kept cached by the Microsoft CrytoAPI tools?
Post by Jason Curl
I assumed that the CRL field of the class 1 is self signed as part of the
class 1 hence it is not possible to override. Further until now I've not found
any documentation that describes how to download the CRL separately as some
background process and tell Windows to use that.
Right, that would be a nice work-around indeed.
Post by Jason Curl
I did get a bite from TechNet since it was moved, let's see if any thing
constructive comes out of it.
OK, let me know when something comes up.

Regards,
-- wytze
Jason Curl
11 years ago
Permalink
Hi Wytze, see in line with [JC]

-----Original Message-----
From: Wytze van der Raay [mailto:***@cacert.org]
Sent: 19 September 2014 17:05
To: Jason Curl
Cc: cacert-***@lists.cacert.org; critical-***@cacert.org
Subject: Re: CRL Lists always show offline

Hi Jason,
Post by Jason Curl
Checking of my client certificate based on the class 3 is done via OCSP and it
even works. But for Windows to completely verify trust it also needs to verify
the class 3 intermediate against the CRL given in the CACert root, which is
the actual problem.
Well, it needs to verify whether the class3 intermediate has not been revoked.
That check can simply be made against the OCSP server for the root, ie
ocsp.cacert.org.

[JC] Except that it uses what's in the Class 1 Root, and the Class 1 root
doesn't mention the OCSP. If it did, I guess we wouldn't have a problem.
Post by Jason Curl
My testing until now showed that when the CRL from class 1 is available, the
class 3 can be verified as not revoked resulting in a complete chain of trust.
Using the CRL is the second choice of course -- but once you have that
donwloaded, can it not be kept cached by the Microsoft CrytoAPI tools?

[JC] I can manually install it in the Intermediate Certification Authorities,
Certificate Revocation List, answering partially my own question below. How to
distribute this on my network is still an open question. Downloading via my
Linux server with WGET isn't the issue, it's putting it automatically in the
CRL store.
Post by Jason Curl
I assumed that the CRL field of the class 1 is self signed as part of the
class 1 hence it is not possible to override. Further until now I've not found
any documentation that describes how to download the CRL separately as some
background process and tell Windows to use that.
Right, that would be a nice work-around indeed.
Post by Jason Curl
I did get a bite from TechNet since it was moved, let's see if any thing
constructive comes out of it.
OK, let me know when something comes up.

[JC] Not yet. Just a couple of questions, but nothing concrete. If I do get
something, I'll let you know.

Regards,
-- wytze
Continue reading on narkive:
Search results for 'CRL Lists always show offline' (Questions and Answers)
6
replies
who win the match for jonh and randy ortan?
started 18 years ago
rugby league
Loading...