SSLMate Blog

> Root cause: Symantec was willfully disregarding industry regulations by issuing trusted certificates without proper authorization.

Source: https://sslmate.com/certspotter/failures

“Willfully” is the key word here. The business side of running a CA is fundamentally at odds with the security side. A few short-sighted decisions by business-minded managers with their eyes set on profits can completely eviscerate the security side of a company, and it’s possible that nobody remains at Symantec who has the combination of security knowledge + internal political power + will.

There’s also the Trustico fiasco. Trustico revoked 50,000 Symantec-issued certificates in a shockingly bad way. Because policies allowed for certificates with compromised public keys to be revoked, Trustico intentionally compromised the private keys in order to achieve the desired revocation.

https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wxX4Yv0E3Mk

> As one of Symantec's former largest partners - my personal opinion and personal experience is that Symantec is a company that thrives on recklessness and one that I wouldn't trust nor deal with.

You can see more bad behavior here—Symantec is seen as a reckless company, and Trustico (recklessly) cuts ties with Symantec for its business needs. Both actors are bad enough that their relationship reflects poorly on both of them.

I’m sure there are some people who could fix this problem in six months, but I bet they don’t work for Symantec…

I would approach the issue rom the opposite direction.

What is the minimum failure of any CA required for me to get popped? If some malicious actor goes through the effort to get me, how many other clients/servers on the internet can get from the same CA breach / malicious cert?

How would you know to un-trust a CA you already trust until after the incident (a malicious certificate issued) had already happened? Even if the incident happened, someone still needs to alert you to un-trust the CA involved. That takes time.

History of mistakes / bad decisions by cert authorities: https://sslmate.com/resources/certificate_authority_failures

> who is issuing certificates some lunatic wrote nonsense into, but which you trust

Do you know every CA your OS and each browser trusts out of the box? Have you done an audit of each one of them? Does an audit 100% prevent a breach from happening in the future?

What are the odds that their policies are perfectly followed every time and that no employee in the right place can be bribed/blackmailed?

Remember Cert Authorities are watering holes. Almost all of the internet trusts a few of them. By breaching one (which may be very significant, either technically or reputationally), the payoff can be massive.

Check out my startup, SSLMate: https://sslmate.com. What sets SSLMate apart is that we're working on making SSL certificate management extremely easy on Linux servers. You buy certs from the command line in a single step that takes a minute or less and automates important details like bundling the chain certificate. You can set up a cron job for automatic renewals. Even well-run sites have been known to forget or botch cert renewals, and we want to put an end to that by automating everything. Many features are in the pipeline and will be announced in the coming weeks.

Regarding EV certs, they're not worth the extra money and inconvenience. They provide no additional security, and the assurance they provide visitors is highly questionable (e.g. see shiftpgdn's comment about how switching to a non-EV cert resulted in absolutely no change in order metrics: https://news.ycombinator.com/item?id=8344666).

Awesome! I love CT logs and use a service called Cert Spotter [0] to notify me every time a new cert is generated for one of my domains. This knocks out their Q1 goal [1], I'm very excited about their Q2 goal of Multi-Perspective Validation [2]. It will make getting a cert issued to a malicious actor via BGP hijacking much more difficult. I'm also excited about them getting a ECDSA root certificate and was bummed out when it de-prioritized from being a 2018 feature, but Multi-Perspective Validation is certainly a better priority. All this provided for free, lets encrypt is certainly one of my favorite non-profits [3].

[0] https://sslmate.com/certspotter/

[1] https://letsencrypt.org/upcoming-features/

[2] https://letsencrypt.org/2018/12/31/looking-forward-to-2019.html

[3] https://letsencrypt.org/donate/

> 4. Key rotation: Again, I know of only one web server that does this by default and automatically (cough Caddy).

This misses the point, because whilst nginx/Apache don't handle this for you - the automated ACME clients like Certbot (and e.g. Lego) do and will ensure you get a fresh keypair used for renewals.

>5. Certificate transparency: As of now, there is not enough useful consumption of CT logs. We have TBs of data but no one to read them.

Don't these sort of monitoring services already exist? https://sslmate.com/certspotter/ https://developers.facebook.com/tools/ct/

I don't disagree adoption is probably low but it seems more appropriate for a specialised service (as part of your existing monitoring infrastructure) to handle this.

I've had a lot of good experiences lately using SSLMate (https://sslmate.com/) to automatically buy, download, generate chains, and renew certificates.

Then, I use Mozilla's SSL configuration generator (https://mozilla.github.io/server-side-tls/ssl-config-generator/) to set up the cypher suite.

Those two together will have get you running very quickly. It's certainly a good idea to know what you're dealing with, but there are smart people behind both of these services that really simplify things.