Every computer connected to the internet today has a series of "certificate stores" contained within it. These stores are crucial to encrypted communication everywhere, but their state often drifts between providers and can many times extend trust further than users expect.
The underlying Certificate Authority technology doesn't offer solutions for fine grained management, active countermeasures and misuse prevention for end-user machines. Any system you buy will come loaded with trust of countless CA's, which means that your encrypted connections are at risk of eavesdropping or misrepresentation if any CA creates privacy-destructive or nefarious certificates. Read up on the background if you're interested.
Trust with another party needs to be earned, not defaulted. cert-manage is a tool to give users easier control of their trusted x509 Certificate stores on their systems and applications.
cert-manage offers a few features currently: List, Whitelisting and Backup/Restore. These are explained as follows:
- Add
- Add certificates to a store
- Connect
- Establish a TLS connection with a remote host using a provided certificate store
- List
- Show the certificates installed and trusted by a given certificate store. This is useful for an initial trust audit
- Whitelist
- Remove (or distrust) installed certificates. This will prevent good acting programs (and platforms) from making connections signed by organizations you don't trust.
- Backup and Restore
- Capture and revert the status of CA trust in a platform or application.
- Whitelist Generation
- Generate whitelists from browser history or flat files.
Download the latest release or build from source with go get github.com/adamdecaf/cert-manage
# List certificates trusted on your system (or app)
$ cert-manage list
$ cert-manage list -app java
Certificate
SHA256 Fingerprint - 3a43e220fe7f3ea9653d1e21742eac2b75c20fd8980305bc502caf8c2d9b41a1
SerialNumber: 246153180488710619953605749449532672687
Subject: VeriSign, Inc., Class 2 Public Primary Certification Authority - G2
Issuer: VeriSign, Inc., Class 2 Public Primary Certification Authority - G2
NotBefore - 1998-05-18 00:00:00 +0000 UTC, NotAfter - 2028-08-01 23:59:59 +0000 UTC
IsCA - false
...
$ cert-manage list -file example.crt
$ cert-manage list -url https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt
# Trim down what CA's are trusted on your system
$ cert-manage whitelist -file urls.yaml # or json
$ cert-manage whitelist -app chrome -file urls.yaml
# Backup and Restore the current trust
$ cert-manage backup
$ cert-manage restore [-file <path>]
cert-manage abstracts over the differences in Certificate stores for the following platforms:
| Level | Platforms(s) |
|---|---|
| Full Support | Linux (Alpine, Debian, Ubuntu) |
| Partial Support | Darwin/OSX, Windows |
Also, cert-manage abstracts over the following application's certificate stores across the supported platforms.
| Level | Application(s) |
|---|---|
| Full Support | Java |
| Partial Support | Chrome, Firefox, OpenSSL |
- Analysis of the HTTPS Certificate Ecosystem (2013)
- "We investigate the trust relationships among root authorities, intermediate authorities, and the leaf certificates used by web servers, ultimately identifying and classifying more than 1,800 entities that are able to issue certificates vouching for the identity of any website."
- "Disturbingly, we find that the compromise of the private key used by one particular intermediate certificate would require 26% of HTTPS websites to immediately obtain new certificates."
- CAge - Taming Certificate Authorities by Inferring Restricted Scopes
- "We find that simple inference rules can reduce the attack surface by nearly a factor of ten without hindering 99% of CA activity over a 6 month period."
- You Won't Be Needing These Any More: On Removing Unused Certicates From Trust Stores
- "We found that of the 426 trusted root certificates, only 66 % were used to sign HTTPS certificates."
There have been numerous recent exploits in the wild surrounding CA's (Certificate Authorities) that don't understand the power they have on every system which trusts communications signed with their keys. Additionally distributors of certificate stores have started to become aware and demand stricter working requirements from CA's, but the power is not readily available in the users hands for them to make these decisions themselves.
Below is a short list of incidents over the past couple of years (2015-2017) from CA's either acting carelessly or maliciously.
- Blizzard / EA Origin
- Local CA (clienttolocalhostonly.com and localblizzard.net) Blizzard and EA were running an HTTPS webserver on 127.0.0.1 (where the domains resolve) with a valid certificate. This implies that there's a private key bundled with the software which is considered a "key compromise" and requires revocation of the certificate. This issue is not itself bad, but allows an attacker to mitm the dns for either domain and be presented with a valid connection to end users.
- Comodo
- Invalid domains
Comodo issued certs for invalid domains. In specific,
www.sbwhich should not have been generated. It has since been revoked. - OCR to validate documents OCR is a process in which algorithms try to find and understand human/computer writing in digital documents. This process is far from perfect and should only be used as a means of creating faster processes prior to human validation steps. It was found that OCR algorithms could lead to bogus (and fraudulent) certificates being generated.
- Invalid domains
Comodo issued certs for invalid domains. In specific,
- CNNIC
- DigiCert
- DigiNotar
- DYMO
- GlobalSign
- GoDaddy
- Government Root Certification Authority
- Guang Dong Certificate Authority
- IdenTrust
- Let's Encrypt
- PROCERT
- Savitech USB audio drivers
- StartCom
- Symantec
- Trustico CEO emailing DigiCert 23k Private Keys
- TunRootCA2
- WoSign and WoTrus
- Visa
I'm always looking for new contributors and anything from help with docs, bugfixes or new certificate store additions is gladly appreciated. If you're interested in contributing then pull down the source code and submit some PR's or join ##cert-manage on the freenode irc network.
You can build the sources with make build. Run tests with make test. Currently we required Go 1.10.
Note: Many tests will run if docker is enabled/setup. To disable this run commands with MOCKED=true (e.g. MOCKED=true make test)
This project follows the Google Code of Conduct.