Hacker News Reader

Comment by koolba | Hacker News Reader

SSL certificate from a traditional provider valid for a year: $10.

SSL certificate from a traditional provider valid for two years: $20.

Automated SSL certificate generation and deployment via LetsEncrypt with zero human intervention and more importantly zero human intervention to renew it going forward - priceless.

---

That's the real value for me. At $10/cert, that's not even a rounding error. But manually generating a new CSR, uploading it via crappy web form, waiting a random amount of time, proving domain ownership by responding to an email (sent in plaintext), waiting a different random amount of time, downloading the new cert (again usually sent via plaintext email), and finally copying it over the old cert and reloading the SSL conf ... now that costs some serious time and time is money.

View on HN

It's even more painful when you're a web agency with lots of clients. Especially if they have hosting elsewhere and you don't have access to their emails. You have to contact your client and either get them to set up a specific email forwarder or inbox for you to access.

You then have to wait for them to respond back to you and you'll mostly get a reply with something like "I thought our emails were with you" or "We don't know who our provider is". Like, you're paying someone for some service, how can you not know who is providing you that service?

Then when they do finally set the email up, you have to go through the process which you just spoke about. It's such a pain, but with LE, it cuts all of this crap out and makes for happier businesses.

> Automated SSL certificate generation and deployment via LetsEncrypt with zero human intervention and more importantly zero human intervention to renew it going forward - priceless.

That also means one can make effectual suggestions to webmasters.

I told a webmaster who maintains a forum about LetsEncrypt a few months ago and that I'd help them set it up just so that users aren't practicing the bad habit of logging in over http. I just went back to check and the forum is now https by default using LetsEncrypt certificate.

I couldn't have achieved that a few years ago. The pain of setting up SSL would have inescapably digressed into a low-quality flamewar about how PKI is broken.

The LE protocol is fully open and even specified in RFCs - I wonder if any paid cert providers will ever move to that type of painless automated renewal (plus automated billing, of course). This would allow folks to potentially get their "advanced" certs (EV, wildcard, crossdomain, etc.) renewed without the rigmarole that you mention (although some cert categories come with their own non-automatable processes).

Right now, I have LE certs for my main website and for a test webserver hosted on my laptop, both renewed automatically and painlessly through cron jobs. The fire and forget nature of LE is very convenient.

EV certificates are not allowed to be renewed automatically AFAIK.

That's not a part of the ACME protocol (which is what Let's Encrypt implements), it's a policy decision of Let's Encrypt. Grandparent's comment is about other CAs offering EV certs over ACME.

???

EV guidelines have nothing to do with Let's Encrypt or ACME. They state that even for renewal all checks have to be done again, which cannot be automated.

Maybe not fully automated, but at least the provider could "start" the process, only requiring the company they are validating to answer some questions, reply to mail, reply to whatever kind of extra authentication/verification is needed, then the technical portion can happen automatically after that.

The situation is that facts about the Subject recorded in a certificate must be Validated.

For the Domain Name Validation (which is the main thing web browsers and several other kinds of software care about) this is done by one of the 10 Blessed Methods. ACME automates three of those ten methods. Some others can't be automated (e.g. get a bona fide lawyer to sign a physical paper document saying they've checked you really own the DNS name)

EV requires also validating the Subject entity's name and place of business. This cannot be entirely automated today. But some CA issuers specialising in EV get very close, like an hour turnaround in most cases for businesses in places where they operate.

The intent in ACME is that semi-automated processes would be handled to one side of ACME, you'd do them offline, and you'd gain "authz" which are how ACME tracks validation, for the things which had been validated offline.

Also, it's not necessary to re-validate everything for every new issuance. Suppose you prove you're really EXA Metal Pole Location Executives, business #123123123 of Some City, Texas. A CA would be entitled to rely on having validated that for some time, I think it's currently up to three years. In that time you could issue and re-issue hundreds, even thousands of certificates with no extra fuss.

Yes, several CAs have indicated that they are at the least watching the ACME development, and it was intended from the outset that ACME would have other users beyond Let's Encrypt.

Also keep in mind that if you're a big customer the big CAs already had products where things are streamlined for you, so the annoying experience you get as a small operator is not necessarily happening at scale for a large corporation like, say, Disney.

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"?

Currently their only upside is that they provide wildcard (and EV) certificates. EV certs can't be automated for obvious reasons, but LE doesn't support wildcard certs because they don't believe there's a secure way of providing an automated way of getting them.

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.

Why is providing wildcard certs not secure???? Amazon seems to do it?

Because once your wildcard certificate is compromised--and you must design systems with the assumption that your certificates will be compromised--it becomes a very achievable exercise to use that wildcard certificate to compromise users going to any of your subdomains. With each domain governed under its own TLS certificate, you install firebreaks between systems to contain the damage an attacker can do.

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.)

Meanwhile SAN is fine? The alternative to wildcards is that you get a single cert with tons of subdomains as alternative name. Exact same risks, yet much more hassle to add subdomains. I don't see it.

That's a fine point, if you're using SANs. With Let's Encrypt, you don't need to use a SAN so long as each of your endpoints is distinct. (If they're not, I'm uneasy with your architecture in the first place, y'know?)

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.

SNI is not yet always an option if you have to support older clients.

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?

If you have to support older clients--definitely, SAN is your only option if you have to run on the same host. (And I sympathize, because that sucks.) At that point, though, my inclination becomes to attach a bunch more public IPs and wire up my DNS correctly to match.

> 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.

IPv4 addresses are relatively expensive. I encounter it quite often where a wildcard gets pointed to a single server (with single IP) which hosts multiple services. There are no security issues compared to a large SAN that I can see in such a situation.

I would submit, respectfully, that you're not being creative enough.

When it comes to security, including phishing, it behooves all of us to not assume that permissiveness is a de facto positive.

Very helpful. Thanks.

So the Low risk of compromise for most people is more important than the ability to easily maintain a system? If a certificate is going to be compromised it's most likely going to be the most important cert to the system anyway. A hacker isn't going to go after the meaningless ones. But by your logic I should increase the maintainability of the system for no benefit.

Obviously this is highly dependent on the usage of the certs to begin with.

Yes, many services "seem to do it". The problem is how do you safely verify that a wildcard certificate is actually being given to the owner of that domain space? It's "trivial" to provide a certificate for a particular domain is owned by someone, but the same techniques don't work for wildcard certificates because now you're verifying only a single domain and providing certificates for an entire class of domains.

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....

That SO post makes no sense to me. It claims:

> 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.

But *.a.com doesn't cover a.com, so it's not very clear that the inverse ownership relationship should hold. Yes, it's true on a DNS level but that's one argument I would imagine against doing it that way.

No, but ownership of a.com heavily implies ownership of (wildcard).a.com (HN is being weird with the asterisk)

Alternatively they could just do a DNS check. If you can configure DNS for a.com, you control *.a.com.

> heavily implies ownership

"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.

> 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.

Yup! And LE is totally fine with this! Have you read the ACME DNS verification spec?

I regularly have subdomain zones delegated to AWS for Route 53 use without having direct control over the root domain. The idea that I must have direct control to assert control over a subdomain is pretty questionable.

If you don't have access, fine. You can't make use of this functionality. Stick with what is available today. Nothing lost. If you do have access, like 99% of the domains out there, you now get access to more functionality. Win-win.

One annoying thing I've seen less technical stakeholders ask about with letsencrypt is "why the padlock isn't green" in Safari/Edge. Unlike Chrome and I think Firefox, those browsers only display a green padlock for SSL certs with EV, which of course letsencrypt doesn't (and arguably can't really) do.

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.

What types of users have asked you about that? I'm lucky if I can get regular users not to click their way through cert errors.

Like you I've never seen a "customer" user notice, which is why I was careful to use the word "stakeholder". For me it's almost always been product management/sales types in the company.

>> only to trust "green padlocks"

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.

Given how piecemeal the use of EV certs is by big companies, I'm not sure EV as implemented today delivers any 'real' benefits. It absolutely is about browser specific behaviors. How can you tell users only to interact with companies if they have an EV certificate, when huge internet properties like Amazon, Google and Facebook don't use them? In reality you can't, which means Safari/Edge's behavior arguably doesn't really help anyone. I'm not saying Safari/Edge shouldn't tell the user an EV certificate is present, they absolutely should, but that the approaches used by rival browsers arguably make more sense.

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?

I agree with you. My point - which I admittedly didn't state very well - is that the best-practice messaging to non-technical users needs an update. In the earlier days of the web, it was as simple as "look for the padlock," because the state of SSL was such that generally only legit sites had it. With the presence of LE and the overall failure of the "web of trust", this is no longer good advice - they need to carefully double-check the address bar as well.

> What's the justification of traditional providers to charge for the certificates

They could, so they did.

No-one did free which works in all browsers before.

StartSSL worked with any Windows XP SP2+ computer. Though you couldn't automate it and their website was kinda slow.

And they demanded personal data. Even checked that your personal address is not a business address! "Domain validation" my ass.

Is this total BS then?:

"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...

Sort of, that's conflating all free SSL certs with self signed certs. The whole point of an SSL cert is to provide authentication that the server you're talking to is really the server you were trying to reach at www.example.com . They are talking about self signed certificates which is basically the remote server saying "I'm www.example.com, you can trust me because I said so". Let's Encrypt is the same as other CAs out there in terms of authentication. In fact, if you see a certificate that's signed by Symantec, it's more likely to be mississued than a certificate signed by Let's Encrypt.

The certificates Let's Encrypt issues are _not_ self-signed. They are signed by a trusted certificate authority which Let's Encrypt manages, and are no different from domain validated certs signed by any other CA.

That article makes the mistake of assuming that if a certificate is free then it _must_ be self-signed, which is obviously false.

Among other things they provide certs which are valid up to three years. Let's Encrypt certs are short term. There idea is to auto renew, but sometimes that is difficult to implement.

Just making a certificate costs almost nothing. So in a sense $0 seems like the right price.

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?

The price is nice, but what makes it a must have for me is the ability to generate a cert with 100 domains on it and have it validated by hitting the server.

The "old" way required all customers/domain owners to either give us control of their domain or to answer an email every time we needed to get a new cert. Now we've automated moving around domains between certs and generate new ones as needed. Validation by email to 100 different people is like herding cats. Validation that happens in an automated way - priceless.

With SNI, what's the advantage of having a cert with 100 domains on it ?

With our setup, certificates are handled by Amazon elastic load balancers. A single ELB with a cert for 100 domains using SAN is easier to manage than 100 certs on a few servers using SNI.

I'm not saying you should design this way from the start, but this is what we grew into and SAN works for us. I only wish the limit of 100 per cert was higher.

Older clients. Windows XP, android 2, older java versions

Also, HTTP/2 can reuse the same TCP connection for multiple domains with SAN

> At $10/cert, that's not even a rounding error

For businesses, sure, but the fact that you had to pay money at all was very discouraging for personal websites!

Totally agree. Actually wished there was a paid acme service, basically the same as letsencrypt but without such low rate limits.

And this has been the same problem with pgp and crypt ion in general. Too costly in man time. To much to manage, regenerate, etc. unless it becomes transparent or setup once and forget it encryption will never get easier to deploy or manage or be more widely adopted.

> Automated SSL certificate generation and deployment via LetsEncrypt with zero human intervention

Unless you are on a shared hosting, which is still one of the most popular options.

Reply on news.ycombinator.com