Double whammy for CACert.org users

If you are using OpenSSL (or ever did use it with any of your current keypairs in the last 3-4 years), you are probably in a rush to upgrade all your systems and replace all your private keys right now.

If your certificate authority is CACert.org then there is an extra surprise in store for you. CACert.org has changed their hash to SHA-512 recently and some client/server connections silently fail to authenticate with this hash. Any replacement certificates you obtain from CACert.org today are likely to be signed using the new hash. Amongst other things, if you use CACert.org as the CA for a distributed LDAP authentication system, you will find users unable to log in until you upgrade all SSL client code or change all clients to trust an alternative root.

Comments

Another way to think about this is that CACert are taking this opportunity to upgrade their community to the currently recommended versions of protocols. SHA-3 is a little bit early for now, but you'll also note that they recommend deprecating 1024 bit keys in favour of 2048 or even 4096 bit keys.

If CACert's policies mean that insecure clients can't access your services, then I would consider this a win.

Also, with the whole default CA list contraversy at the moment, groups using CACert already have a slightly higher administrative burden.

There is a big difference between deprecating 1024 bit RSA and forcing people onto the SHA-512 hash that current stable Linux releases are not supporting yet. They could have just gone with SHA-256 for now. Some people will simply walk away in frustration, moving to another CA or creating a local CA depending upon the use case. So while the CACert.org principles are good in theory, they may be shooting themselves in the foot in practice.

Hmm, that's odd.

I'm not running anything experimental in my deployments and sha512 certs have been accepted just fine. Since sha256 and sha512 are both part of the same standard and implementation release cycles, whenever one is supported so is the other. There's nothing special in sha512 that isn't in 256, perhaps a config file change but nothing fundamental.

Can you give an example?

I put a more verbose description of how to reproduce the problems with SHA-512 in the Debian bug tracker: http://bugs.debian.org/740160

CAcert was removed from Debian and MirBSD ca-certificates recently, too. It’s officially dead, even its former auditor (I was there when he left…) said that that’s the sensible thing to do despite the community-ness.