Milestone: 100M Certificates Issued • Hacker News Board

Re: Milestone: 100M Certificates Issued

#131

Post by F_r_k » Thu, Jun 29, 2017, 3:56 PM UTC

twothamendment wrote: post #74

koolba wrote: post #43

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 generat…

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 emai…

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

Re: Milestone: 100M Certificates Issued

#132

Post by pfg » Thu, Jun 29, 2017, 4:04 PM UTC

eropple wrote: post #130

pfg wrote: post #129

Earlier quoted context omitted.

Again, you're assuming whatever automation you built is bug-free. Practice shows that sufficiently-complex software is never bug-free, no matter how many tests you wrote. Checking the expiration date on a certificate is easy, so why not have that safety net?

If I'm worried about that, Chef is performing those tests . I'm saying, you're putting it in the wrong place. It's not a monitoring problem, it's a configuration management problem--"I have defined a policy, am I in compliance with that policy?". And, from experience consulting with a pretty wide range of clients, putting it in the monitoring stack encourages manual work instead of automation. Instead of having activ…

If your CM is testing that the expiration date of the certificate that is actually used by a TLS server is correct, through whatever means, for example after each renewal operation, and if you also have some way to verify that the renewal operation runs regularly, then you're effectively monitoring your certificate expiration date. I'm not particularly concerned with where you do it from, whether it's part of your CM or a third-party service, etc., as long as it happens.

There are plenty of other things related to your TLS certificate you might want to monitor that don't quite fit into CM (OCSP revocation status and availability, unexpected key rotations, etc.), so you'll likely need separate monitoring either way.

Re: Milestone: 100M Certificates Issued

#133

Post by floatboth » Thu, Jun 29, 2017, 4:09 PM UTC

koolba wrote: post #43

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 generat…

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

Re: Milestone: 100M Certificates Issued

#134

Post by floatboth » Thu, Jun 29, 2017, 4:10 PM UTC

collinmanderson wrote: post #122

rmc wrote: post #117

Earlier quoted context omitted.

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.

Re: Milestone: 100M Certificates Issued

#135

Post by j_s » Thu, Jun 29, 2017, 4:11 PM UTC

theandrewbailey wrote: post #56

JshWright wrote: post #39

Earlier quoted context omitted.

They have a variety of "challenges" used to prove control of the domain. They basically boil down to: - LE makes a request to example.com, to a known URL that contains a key that LE told you to put there - LE does a DNS lookup for a specific TXT record (again, containing a key they told you to put there). The complete answer to your question can be found in the ACME spec (the protocol LE uses): https://ietf-wg-acme.g…

LE probably does that multiple times from a few places around the internet, to reduce the likelihood of something unexpected going on.

Ain't nobody got time for that!

They might have "a few places around the internet" to verify from, but I doubt it is very diverse location-wise. And there's no way they're going to bother with doing it multiple times, for free.

Re: Milestone: 100M Certificates Issued

#136

Post by cyphar » Thu, Jun 29, 2017, 4:14 PM UTC

philliphaydon wrote: post #120

cyphar wrote: post #111

Earlier quoted context omitted.

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…

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

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

Re: Milestone: 100M Certificates Issued

#137

Post by F_r_k » Thu, Jun 29, 2017, 4:15 PM UTC

eropple wrote: post #121

pas wrote: post #32

And most of that is because LE [still] doesn't issue wildcard certs, nor does it really plan to :(

And that is a without-exception good thing. Wildcard certificates are dangerous and encourage bad practices around SSL. You shouldn't use them. Instead, you should fix your workflow to know exactly what domains you have and have active and use automated tooling to provision them correctly.

I don't think so.

I have an industrial VPN with ~300 embedded devices behind them. For some reason the user wants to access to each one of it via https.

I thus set up an Apache proxy which proxies https://device_n.vpn.cust.tld to the VPN device (and some auth)

LE cant issue 300 certificates and it would be very ugly.

Re: Milestone: 100M Certificates Issued

#138

Post by j_s » Thu, Jun 29, 2017, 4:20 PM UTC

pfg wrote: post #76

j_s wrote: post #23

Earlier quoted context omitted.

LetsEncrypt could easily sell extended expirations out-of-band. I see it as nearly inevitable when they need (more) money.

It's unlikely. Google and Mozilla are pushing hard for short-lived certificates, and the CA/B Forum has already passed a ballot that limits certificate lifetimes to 27 months, starting with March 1, 2018. Google wants to see that brought down to 12 months and might enforce that in their own products if the CA/B Forum doesn't keep up.

Pay $10 to disable the cron job running yet another pile of 3rd-party code on a production server, even if it was (eventually) just for a year? I don't see it as a "never!".

The market is probably (a) people who want to support/donate to LetsEncrypt and (b) people who are ultra-paranoid / strongly prefer less moving parts in ops.

The one major downtime I'm aware of so far (a month ago) could also be a factor: Let's Encrypt is down | https://news.ycombinator.com/item?id=14374933

Re: Milestone: 100M Certificates Issued

#139

Post by eropple » Thu, Jun 29, 2017, 4:28 PM UTC

F_r_k wrote: post #137

eropple wrote: post #121

Earlier quoted context omitted.

And that is a without-exception good thing. Wildcard certificates are dangerous and encourage bad practices around SSL. You shouldn't use them. Instead, you should fix your workflow to know exactly what domains you have and have active and use automated tooling to provision them correctly.

I don't think so. I have an industrial VPN with ~300 embedded devices behind them. For some reason the user wants to access to each one of it via https. I thus set up an Apache proxy which proxies https://device_n.vpn.cust.tld to the VPN device (and some auth) LE cant issue 300 certificates and it would be very ugly.

I don't believe LE has an upper limit on its number of SANs.

For systems not explicitly public, whitelists are almost always better than blacklists.

Re: Milestone: 100M Certificates Issued

#140

Post by giobox » Thu, Jun 29, 2017, 4:31 PM UTC

cyphar wrote: post #111

Asdfbla wrote: post #108

Earlier quoted context omitted.

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…

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.