What's the justification of traditional providers to charge for the certificates? Do they offer services or extended certificates that "Let's encrypt" doesn't or is it just a matter of "no one tried to offer it for free before"?
Given that traditional CA models don't actually have much more security than LE (in fact from personal experience they're far less secure), I wonder whether they should be in the business of providing wildcard certificates at all.
The "grey padlock" for an otherwise perfectly valid certificate seems to confuse a very small subset of users, especially when there's a ton of badly written articles out there advising users only to trust "green padlocks", given the behavior in almost all other browsers. Thankfully showing google.com not using an EV certificate is usually easiest way to shut these conversations down.
It's not so much about browser-specific behavior, it's about using the padlock to ensure that the company or other entity you're interacting with is the one you wanted, as opposed to only ensuring that the server you're talking to is the one indicated in the address bar.
A gray padlock is better than none, but telling less technically-inclined, clicks-all-the-links, fat-fingered users to trust them outright may not be the best idea now that you can go get bankofomerica.com, dress it up to look like BoA's site, and put a gray padlock on it for free.
I think Chrome/Firefox got this one right by using a green padlock for both valid EV _and_ DV certificates like Letsencrypt, displaying the extra EV information clearly inline in the URL bar if it is present. The changing color in Safari/Edge can give the impression that the the non-EV certificate is somehow less secure, which in technical terms is not the case. Questions of identity verification and security of data transmission are two separate issues which the Safari/Edge approach arguably conflates - both EV and DV can provide equal security of transmission, even if only EV provides some degree of identity confirmation.
As a user, it's simply not possible to make the distinction too - if I visit your fake Bank Of America site with a grey padlock, how can I even be sure the 'real' site had an EV certificate and a green one, when there's so many companies that don't? As a user you are effectively forced to treat the grey and green padlocks the same, so why not make them the same color and display extra EV info if it is there, like the other browsers?
There are vanishingly few reasons to ever share private keys across multiple automated systems. This is not one of them. (Are your systems not automated? Fix that.)
Obviously this is highly dependent on the usage of the certs to begin with.
However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists.
It's not about if I'm using SANs anyway. It's that LE is fine with that, but not with wildcard certs.
> However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists.
Can you elaborate what you mean here?
> Can you elaborate what you mean here?
Me saying "this cert is valid for example.com, foo.example.com, and bar.example.com" is an incrementally better security posture than saying "this cert is valid for *.example.com". It constrains an attacker from running a phishing attack from, say, "private.example.com" or "secure.example.com". You're whitelisting what you're covering by explicitly declaring all of them.
It is incremental, but it's a thing.
When it comes to security, including phishing, it behooves all of us to not assume that permissiveness is a de facto positive.
If you work through all of the ways ACME verification works (/.well-known/, DNS, and so on) you can come up with several plausible setups that become insecure if you allow wildcard certificates.
Here's a stack exchange question about it: https://security.stackexchange.com/questions/157972/why-cant....
> The authentication test can't merely back down one level to mysub.example.com because that isn't covered by the cert requested, and may not be under the control of the requesting agent either.
This just seems wrong. Performing the check like that seems to be a sane way to do it. If people can't control the base domain they have no business requesting a wildcard cert.
Alternatively they could just do a DNS check. If you can configure DNS for a.com, you control *.a.com.
"heavily implies" is too low of a bar to make it safe for a CA to provide wildcard certificates through an entirely automated process. While they could do it, they care enough about security to make the decision not to.
> If you can configure DNS for a.com, you control *.a.com.
This assumes that if you can create a TXT record for a.com that you must also have access to the ability to create other records for a.com.
While it is a stretch, I would say that the only bar sufficiently high would be fulfilled is forcing an administrator to prove that they can change the NS records for a domain. Which I don't believe would be a practical thing to test, and might run into problems with things like cloudflare.
Yup! And LE is totally fine with this! Have you read the ACME DNS verification spec?
BUT, being _able_ to make certificates is very expensive. ISRG (the charity behind Let's Encrypt) spends _millions of dollars per year_ on this.
Purely mechanically Let's Encrypt needs a data centre with a bunch of high availability servers and pretty good Internet access, employees to look after all that stuff, a deal with CDNs to serve up their OCSP responses around the world (which ensure certificates stay working after they're issued) and so on, none of which is cheap and all of which needed to be in place before issuing even one certificate.
In practice to be any use the certificates need to be trusted, which meant meeting the standards of the big Trust Stores (definitely Apple, Microsoft, Mozilla, probably Google, Oracle, and ideally dozens more besides). Those standards require physical site security, regular third party audits, and so on, which cost even _more_.
Now, for Let's Encrypt the solution is this is a charity, you can pitch in $10 and if a hundreds of thousands of people like you do that then it all gets paid for, or if a few bigger organisations pitch in $1000 each that helps too.
But for a commercial outfit, well, why not charge $10 to cover costs? And if $10, why not $50? Why not $1000?
They could, so they did.
"Why pay for something that’s free, you ask? When a user visits a website that is secured with a self-signed, or free SSL certificate, most web browsers will post an error message. While some people will click “I understand the risks” and proceed to your site, it’s likely that many people will click the “Get me out of here!” button and never return.
The real problem lies in the fact that self-signed certificates are virtually unregulated. If your site is compromised, it may still appear secure; however, certificates issued by a trusted certificate authority can be revoked and therefore alert users of any potential threats."
Source: http://searchengineland.com/comprehensive-guide-ssl-certific...
That article makes the mistake of assuming that if a certificate is free then it _must_ be self-signed, which is obviously false.