View Revisions: Issue #1305

Summary 0001305: CAcert Class1 root certificate needs to be reissued with an updated CDP and a SHA-based signature
Revision 2014-10-03 07:44 by wytze
Description The CAcert Class1 root certificate (THE CAcert root) is suffering from two operational problems:

1. The CDP (CRL Distribition Point) listed in the root cert is
        https://www.cacert.org/revoke.crl
But since we do not want to distribute the (huge) CRL through our main web server but rather through a specialized CRL server, the main web server is redirecting all requests for the above URL to http://crl.cacert.org. It turns out that some validation software, for example Microsoft's CryptoAPI, is unable to deal with such HTTP redirects, and reports a verification failure.

Also, the use of HTTPS in the CDP is *not* recommended, see RFC5280 http://tools.ietf.org/html/rfc5280, in the section Security Considerations:
   When certificates include a cRLDistributionPoints extension with an
   https URI or similar scheme, circular dependencies can be introduced.
   The relying party is forced to perform an additional path validation
   in order to obtain the CRL required to complete the initial path
   validation! Circular conditions can also be created with an https
   URI (or similar scheme) in the authorityInfoAccess or
   subjectInfoAccess extensions. At worst, this situation can create
   unresolvable dependencies.

So the CDP should be http://crl.cacert.org/revoke.crl.

2. The current root cert is signed with a MD5 hash. While from a security point of view, the quality of the hash algorithm used for such a trusted cert does not matter, from time to time rumours and sometimes even software appear which choke about this. A SHA-256 based signature would kill all such issues right away.

Revision 2014-10-03 07:43 by wytze
Description The CAcert Class1 root certificate (THE CAcert root) is suffering from two operational problems:

1. The CDP (CRL Distribition Point) listed in the root cert is
        https://www.cacert.org/revoke.crl
But since we do not want to distribute the (huge) CRL through our main web server but rather through a specialized CRL server, the main web server is redirecting all requests for the above URL to http://crl.cacert.org. It turns out that some validation software, for example Microsoft's CryptoAPI, is unable to deal with such HTTP redirects, and reports a verification failure.

Also, the use of HTTPS in the CDP is *not* recommended, see RFC5280 <http://tools.ietf.org/html/rfc5280>, in the section Security Considerations:
   When certificates include a cRLDistributionPoints extension with an
   https URI or similar scheme, circular dependencies can be introduced.
   The relying party is forced to perform an additional path validation
   in order to obtain the CRL required to complete the initial path
   validation! Circular conditions can also be created with an https
   URI (or similar scheme) in the authorityInfoAccess or
   subjectInfoAccess extensions. At worst, this situation can create
   unresolvable dependencies.

So the CDP should be http://crl.cacert.org/revoke.crl.

2. The current root cert is signed with a MD5 hash. While from a security point of view, the quality of the hash algorithm used for such a trusted cert does not matter, from time to time rumours and sometimes even software appear which choke about this. A SHA-256 based signature would kill all such issues right away.

Revision 2014-09-15 14:07 by wytze
Description The CAcert Class1 root certificate (THE CAcert root) is suffering from two operational problems:

1. The CDP (CRL Distribition Point) listed in the root cert is
        https://www.cacert.org/revoke.crl
But since we do not want to distribute the (huge) CRL through our main web server but rather through a specialized CRL server, the main web server is redirecting all requests for the above URL to http://crl.cacert.org. It turns out that some validation software, for example Microsoft's CryptoAPI, is unable to deal with such HTTP redirects, and reports a verification failure.
2. The current root cert is signed with a MD5 hash. While from a security point of view, the quality of the hash algorithm used for such a trusted cert does not matter, from time to time rumours and sometimes even software appear which choke about this. A SHA-256 based signature would kill all such issues right away.