CAcert Root Certificate, SHA-2 hashed
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
Apple iOS, Oct 13, 2011, About the security content of iOS 5 Software Update
CVE-ID: CVE-2011-3427
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.
Microsoft, Aug 13, 2013, Update for deprecation of MD5 hashing algorithm for Microsoft root certificate program
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.
Microsoft, Nov 4 2015, SHA-1 Deprecation Update
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.
Google, Dec 31 2015, SHA-1 Deprecation: No Browser Left Behind
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, Sep 20 2016, MacOS & Safari SHA-1 deprecation policy
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.
CAcert SHA-256 re-sign project
Altough CAcert guys think that there is no security flaw in MD5-signed certificates, they chose to do something about this. They managed to get the existing root certificate re-signed with SHA-2 on number of occasions. The most recent one is: root certificate re-signed. This was executed successfully on 2016-03-12
The result is kinda published, it's not publicly available, but if you're willing to go the SHA-256 project's SVN repository at http://svn.cacert.org/CAcert/SystemAdministration/signer/re-sign-2016/outputs/, the result is available.
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.
macOS
For this to work, you'll need
- root access to your Mac
- old MD5 signed root cert
- new SHA-2 signed root cert
First disable trust to the old cert:
security remove-trusted-cert -d CAcert-root.crt
Remove the old cert by it's signature:
security delete-certificate \
-Z 135CEC36F49CB8E93B1AB270CD80884676CE8F33 \
/Library/Keychains/System.keychain
Add and trust the new cert:
security add-trusted-cert -d -r trustRoot \
-k /Library/Keychains/System.keychain \
root_256.crt
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.
iOS
... This one I'll get back in a later post.
Chris Charabaruk on :
Jari Turkia on :
Anyway, I've been using CAcert for over a decade, but I'm losing my faith. Since the org is a non-profit, they do not seem to have enough volunteers to make the thing work at all. However, I don't know what would be a viable alternative. StartSSL hands out free certs, but their operation is very untrustworthy. Let's Encrypt is a piece of shit python crap. I totally hate their faulty code and general approach of attempting to alter my configurations. They seem to have the CA-side handled better, so all I would need is a proper approach to get my cert.
Any other sources for no-cost certs?
James on :
how can one be sure that the proverbial "coffee-shop hacker" isn't replacing the file with his own "internal" CA's cert, which will then be used to authenticate his funneling through of ALL the fake websites, with a green padlock?
If we can't verify the fingerprint, and we're not leaning into an existing PKI (X.509 trust chains terminating in vendor-trusted CAs) to verify the data, how the heck are we going to verify the data?
Jari Turkia on :
If you'd care to visit http://www.cacert.org/index.php?id=3 the SHA-256 signed CA root certificate is there to download. It has been there since February 2019. Also on that page, there are certificate fingerprints.
What you can do to defeat your coffee shop hacker is download the file, run:
$ openssl x509 -noout -fingerprint -sha256 -in root_X0F.crt
and compare the given fingerprint to published by CAcert.org.
In my Linux the output of SHA256 Fingerprint=07:ED:BD:82:4A:49:88:CF:EF:42:15:DA:20:D4:8C:2B:41:D7:15:29:D7:C9:00:F5:70:92:6F:27:7C:C2:30:C5 does match what's expected.
James on :
But, didn't you get that fingerprint in the first place off the same insecure link?
If I ever get the opportunity to visit them in real-life, I'll certainly ask them for a printed copy of their fingerprint, "just in case".
Jari Turkia on :
The signature information in the cert is something you can verify. That's kinda the idea of certificate _chain_. In this case, a root certificate, is always self-signed, but still: the point remains, you can take the certificate bytes and verify the signature is by the same entity who issued the cert. Which hash is used in the signature doesn't matter, you can always do the verification by yourself. A hash is embedded in the cert, MD-5 or SHA-256, that can be completely ignored and can be considered to be there to save time.
At the time I didn't, but now I took the certificates I had from year 2016 and did the due diligence. Hashes match. Both MD-5 signed and SHA-2 256 signed root certificates produce identical SHA-2 256 hash, which again matches the information given in the cert. No forgery, real deal.
I'll be happy to elaborate, if you're really into X.509 as much as I am.
James on :
I'm definitely on a bit of an "X.509 obsession" this year: I'm currently trying to code up some better constraints on Certificate authorities.
The browser vendors made HSTS, HPKP, OCSP, Must-Staple, CT, Embedded SCTs...all these attempts at trying to tie up "nice and securely" this tenuous system, but none of them really "worked" yet and made everything cleanly secure.
If you've got any reading materials you'd recommend on the topic, please point me to them! I'd love to know as much as possible about the field before sinking my teeth into this project all the way.
Jari Turkia on :
Mathematics is an universal language and having different ISP or different computer isn't a factor. You simply cannot fake the results 1+1=2 on a computer. Also, the SHA-2 256-bit hash of a given certificate will be same regardless how it is signed.
About reading materials: When I'm learning new stuff, I typically won't start by reading a book about it. Doing stuff is much more fun. When there is enough failure and/or understanding about the subject, then I'll do a deep dive by reading a book about it. As an example, how I learned about how X.509 signature works is by writing a tool to do that. Source code is at https://github.com/HQJaTu/cert-check.
Oliver G on :
Julian on :
unless that's teh add-trusted_cert line..
Jari Turkia on :
If you ever laid eyes on CAcert.org's Root Certificate page and saw the MD5-signed files on that, you might have a clue.
Also I understand, that the SVN repo has 17 files in it, but guess what! Only two of them are actual certificates. One is the CAcert's root certificate and another is the intermediate CA's certificate. Hint: To distinguish different types of files from each other, you may want to examine the file extensions.
Patrik Arven on :
Me and some others has been using CAcert for a shared mail server, but just some weeks ago one of the clients iPhones stopped getting emails after an update, saying something like "the servers identity is not trusted" or similar. I spent 2h trying to help her installing the CAcert root certificate on the device (which usually helps) but listen to this: Apple has now, in their wisdom, removed the "trust" button in the upper right corner, that you have to press after installation of a new cert.
The root cert is also supposed to be listed on a settings page so that you can later disable/enable them, but CAcert's root cert does not show up there. It's just installed as a "profile".
My guess is that this might be because of the MD5 thing. Could this be true?
If so, I feel I have no option but to move to LE, but I'm a bit scared of letting their scripts loose on the mail server.
Could installing the SHA2 Cacert root cert from your link, on her iPhone, help her (temporary I guess until I've investigated the LE scripts better)?
Jari Turkia on :
Given, that I'm using number of Apple-devices on daily basis, the issue affects me and you both. I just never found the time/motivation to polish the iOS-process into a blog post, but since you gave me the extra motivation boost, here it is:
https://blog.hqcodeshop.fi/archives/402-iPhone-Mobile-Profile-for-a-new-CA-root-certificate-Case-CAcert.org.html
Go do what it instructs, or if you're really brave, you can also do the fast but stupid thing.
Patrik Arven on :
As I am horribly lazy (and because I have no Mac myself) I at once jumped to the bottom link and downloaded the .mobileconfig file. There is however some binary goo at the top and bottom of the file that scared me off, as I expected a somewhat readable (apart from the encoded payload maybe) xml file.
When I was sitting fumbling with the client's iPhone we always tried to install the one here: https://www.cacert.org/certs/root.crt.
I was kind of hoping you'd tell me to just browse to your SVN link for root_256.crt from the device. I actually never tried that. But that wouldn't work either, right?
(Just want to make sure before running off to the Mac store...)
Jari Turkia on :
Importing the X.509 cert via Safari won't work anymore. They yanked that out around iOS 10, probably at 10.3.
I'm assuming, that you already did your due diligence on the topic and found out lot of people asking how to do this. Just beware obsoleted information. On many pages, the information is regarding iOSes older than 10.3 or alternatively, the people just assumes, that it still works with Safari, like it used to.