RSS feeds of this Blog

Blog Administration

Powered by

Sunday, January 8. 2017

CAcert is my favorite source of certificates. It has been that for years. The buggy Let's Encrypt I loathe, their poorly tinkered Python-scripts won't work and after couple hours of unnecessary fixing of their bugs, the scripts decide to write to my configurations. So, those guys really don't have a clue what they're doing.

However, CAcert isn't doing much better. Their root certificate is still MD5-signed. Argh!

CAcert's claim is, that "Severe weaknesses have been found in MD5, but at present they do not open vulnerabilities for X.509 certificates". But nobody else is buying that. It's just that this international non-profit organization is light on resources and they want to get his one done right. They just don't seem to be able to squeeze a re-signed root certificate out.

Update 20th Apr 2018: There is a follow-up post about installing this into iOS-device.

Briefly on certificate hashes

A X.509 certificate needs to be signed to make sure it originated from the Certification Authority announced in the certificate. Since the root certificates are typically self-signed, they are at the end of the certification chain, there is no other authority to validate them. That's why the hash of the signature is published at the CA's website. In case the hash doesn't match, it is possible to notice that somebody modified the signature.

What others are doing: Expiring MD5 and SHA-1 hash algorithms

Description:
Certificates signed using the MD5 hash algorithm were accepted by iOS. This algorithm has known cryptographic weaknesses. Further research or a misconfigured certificate authority could have allowed the creation of X.509 certificates with attacker controlled values that would have been trusted by the system. This would have exposed X.509 based protocols to spoofing, man in the middle attacks, and information disclosure. This update disables support for an X.509 certificate with an MD5 hash for any use other than as a trusted root certificate.

On affected releases of Microsoft Windows, security update 2862973 requires that certificates no longer use the MD5 hashing algorithm. Microsoft products or third-party products that call into the CertGetCertificateChain function will no longer trust certificates that have MD5 hashes.

We announced that Windows will block SHA-1 signed TLS certificates starting on January 1, 2017. In light of recent advances in attacks on the SHA-1 algorithm, we are now considering an accelerated timeline to deprecate SHA-1 signed TLS certificates as early as June 2016.

After December 31, 2015, SSL certificates that use the SHA-1 hash algorithm for their signature will be declared technology non grata on the modern Internet. .. over the course of 2016, will begin issuing warnings and eventually completely distrust connections to sites using SHA-1 signed certs.

Apple hasn't made any specific announcements here. The nearest we've come is a general warning in WWDC 2016 Session 706 What’s New in Security:

SSLv3 cryptographic protocol and the RC4 symmetric cipher suite are no longer supported, starting at the end of 2016. It's recommended that you stop using the SHA-1 and 3DES cryptographic algorithms as soon as possible.

Go there! Get it! Use it!

Installation instructions

Should I install the intermediate certificate too?

No.

The idea with web server certificates is, that you establish trust to root certificate. All certificates are issued from intermediate-CA, which certificate can be revoked at any given time. That's why the intermediate certificate needs to be deployed with the server certificate. This is something many system admins keep misunderstanding.

Which keychain / store the CAcert root certificate should be installed?

My preference is always to install new root certs into system-wide keychain / store. That way any human users (me and possibly others) or system/daemon users get the new cert at once.

Add and trust the new cert:

The important point in macOS is to remember, that adding a root certificate to keychain doesn't make it trusted. You'll need to implicitly tell an added certificate, that you trust it too. That's kinda weird, but ... some smart guy at Apple designed that so.

Windows

For this to work, you'll need

administrator access to your Windows

new SHA-2 signed root cert

Remove MD5-signed:

certutil -delstore Root 135CEC36F49CB8E93B1AB270CD80884676CE8F33

Add and trust the new cert:

certutil -addstore Root root_256.crt

Linux

Ah, there are too many distros out there.

Any typical approach would be to place the file into /etc/pki/tls/certs/ and symlink the certificate's OpenSSL hash 99d0fa06.0 into it.