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.
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
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.
Should I install the intermediate certificate too?
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.
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.
How are we supposed to trust that SVN link when it's served over plain old HTTP? And with the fingerprint unverifiable by a third party?
Your point about lack of fingerprint is valid. The transfer over plain HTTP is not. In a X.509 certificate there is nothing that needs to be hidden or kept secret. It contains only public information, which is available ... correction, which needs to be publicly available for the certificate chain verification to function at all. Thus, no need to encrypt the transfer.
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.