Slashdot Mirror
Google Joins Mozilla and Apple In Distrusting WoSign and StartCom Certificates (csoonline.com)
itwbennett quotes a report from CSO Online: Following similar decisions by Mozilla and Apple, Google plans to reject new digital certificates issued by certificate authorities WoSign and StartCom because they violated industry rules and best practices. The ban will go into effect in Chrome version 56, which is currently in the dev release channel, and will apply to all certificates issued by the two authorities after October 21. Browsers rely on digital certificates to verify the identity of websites and to establish encrypted connections with them. Certificates issued before October 21 will continue to be trusted as long as they're published to the public Certificate Transparency logs or have been issued to a limited set of domains owned by known WoSign and StartCom customers. "Due to a number of technical limitations and concerns, Google Chrome is unable to trust all pre-existing certificates while ensuring our users are sufficiently protected from further misissuance," said Chrome security team member Andrew Whalley in a blog post Monday. "As a result of these changes, customers of WoSign and StartCom may find their certificates no longer work in Chrome 56. Sites that find themselves on the whitelist will be able to request early removal once they've transitioned to new certificates," Whalley said. "Any attempt by WoSign or StartCom to circumvent these controls will result in immediate and complete removal of trust."
It's complicated. They're basically whitelisting all StartCom certificates before a certain issue date. However, WoSign silently took over StartCom and started sharing infrastructure and keys for about a year. When Mozilla investigated them for backdating weak certificates, they split up the operations again trying to 'fix' the situation and fired WoSign's CEO.
Since they were sharing infrastructure for about a year and it's not sure how many certificates were backdated a browser can't be sure when WoSign's key(s) and StartCom's key(s) were used to sign the certificate and whether or not it was backdated.
So they can't "trust all pre-existing certificates" but they can trust certain ones (the ones they are sure were definitely issued and signed by StartCom before they were taken over).
Custom electronics and digital signage for your business: www.evcircuits.com
Let's Encrypt, motherfucker.
ACME CAs such as Let's Encrypt have practical problems in the following situations:
A. The website is hosted on shared hosting, and the shared host offers no way to automatically run Certbot or another ACME client to request and install a certificate. There exist ACME clients that run without superuser privilege, but a provider may offer no way for subscribers to automate uploading a certificate obtained through an ACME client. Until very recently, for example, WebFaction required to manually file a support ticket every time. And for Let's Encrypt, this would be less than two months.
B. The owner of a domain allows users to sign up for subdomains. Let's Encrypt does not offer wildcard certificates and severely limits how many certificates can be issued under a particular domain in one week (source). This has already caused problems, for example, for operators of dynamic DNS services who want to make certificates available to their subscribers.
Stop babbling about client certs.
Why?
What's the point of a free SSL cert if it can't be trusted? The whole point of having it is to establish trust that you are who you say you are.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
You don't have to run their software (that is, the reference implementation) on your servers. There's plenty of other ACME clients, including short Bash scripts that don't require root and are relatively easy to audit. You could write your own, if you want.
The short expiration times for Let's Encrypt certs exist for two reasons:
1. Revoking certs is a pain. Yes, OCSP is a thing, but malicious actors that can control the network can block OCSP and force users to keep trusting revoked certificates up to their expiration time. Most browsers treat OCSP failures as a soft-fail. This is partially alleviated with OCSP stapling, but not many servers support it. By having short certificate lifetimes, the window of validity for a compromised certificate is smaller.
2. It encourages automation. Rather than certificate issuance (and renewal) being an unusual thing that one needs to do every 1-3 years, during which time one likely has forgotten the procedure and has to go through many manual steps, issuing and renewing certs becomes routine and something easily scriptable and handled by automation. This makes it easier for more sites to deploy HTTPS, and for hosts to enable it with easy, automated tools.
Of course, there's plenty of other CAs out there offering relatively inexpensive certificates with longer lifetimes if you wish. As you say, that's something you prefer. That's fine too: I use LE certs for most of my sites, but some long-lived ones from other CAs for others. It's nice having options.