Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Encrypt has issued its first million certificates

eff.org

Post reply on HN
Print view View original

41–50 of 156 posts

Re: Let's Encrypt has issued its first million certificates

#41

Post by ascorbic »

jqueryin wrote: post #8
Ao7bei3s wrote: post #5

Earlier quoted context omitted.

You're supposed to automate renewal. Since v0.4.0 all it takes is a "letsencrypt renew && apachectl graceful" in a daily cronjob (or, preferably, systemd timer), it handles the rest. Tweak as you like.

Assuming you use Apache. For many, it's simply not a fast enough web server without reverse proxies in front of it. Still crossing fingers for full nginx support soon.

Use webroot auth and it's fine with nginx. I just ran my first set of renewals with half a dozen domains on nginx. All fine apart from one which hadn't used webroot when I first set it up. Edited the config and it then worked fine.

Re: Let's Encrypt has issued its first million certificates

#42

Post by feld »

throwaway7767 wrote: post #6
pingec wrote: post #4

Do their certificates still expire in only 90 days? That makes them very unappealing to me :/ Edit: I understand and agree on why they made it like this. But automating it is not an option in my use case, oh well... I agree it's for the better in the grand scheme of things :).

Yes. I think they do that on purpose to get people to automate the certificate renewal. Their default client of course messes with all sorts of configuration to make auto-renew work "out of the box". Many people (myself included) aren't fans of their client getting so much access, but there are other clients out there that don't need it. I use acme-tiny[0] in a small shell cronjob once a month. It lets acme-tiny requ…

Don't forget this[1] gem which is my favorite way to use letsencrypt. It will let me run it by cron (or periodic on FreeBSD) plus I can have my own post-run script that takes my certificates and keys and puts them in the format I need for Hitch (SSL termination for Varnish), push those changes, restart the service _inside_ a FreeBSD jail automatically.

It's advanced setups like this where LetsEncrypt fails out of the box, but it's nice we have tools like this at our disposal now.

[1] https://github.com/lukas2511/letsencrypt.sh

Re: Let's Encrypt has issued its first million certificates

#43

Post by svenfaw »

nly wrote: post #35
Sir_Cmpwn wrote: post #26

Given that LE does certificate transparency, would it be possible to find out what their millionth certificate was?

CT doesn't seem that transparent. crt.sh only shows the certificate for one of my domains, despite them all having certs issued by the same CA on the same day. Go figure.

Interesting. Are you comfortable with mentioning the domain name(s) here?

And for the record, here is the millionth LE cert in all its glory: https://crt.sh/?id=14392504

Re: Let's Encrypt has issued its first million certificates

#45

Post by michaelt »

nly wrote: post #37
tokenizerrr wrote: post #31

Earlier quoted context omitted.

What are you talking about? My nginx ssl config is static as well. It looks at a specific path for my certs, which just happens to be a symlink managed my by letsencrypt tooling. You're going to have to renew anyway. Previously you would have to remember to do that once a year, or maybe once every two years. Now let's ignore the security implications of having certificates that are valid for a year for a moment, and…

"Once" assuming nothing randomly breaks while you're not looking. What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date? What if one of the (Python?) dependencies has a bug or breaks? What if LEs servers are being DDoS'd? Can you enumerate and account for all the failure scenarios? I've already botched things with acme-tiny&LE in several different ways. I'm not claiming these risks…

  given that LE takes just as much time and effort for
  initial set-up as a standard multi-year cert
I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH - i.e. every server will configure itself right on first launch and keep itself that way.

It's just going to take a long time to get there :)

Re: Let's Encrypt has issued its first million certificates

#46

Post by r0muald »

IgorPartola wrote: post #39
tallanvor wrote: post #36

Earlier quoted context omitted.

I doubt it. CAs still have EV, wildcard, email, and code signing certificates that are often twice as expensive (or more) than their DV offerings. And some people will choose to pay for a DV cert just so they don't have to swap them out every 3 months anyway.

EV can die a fiery death. It is bullshit. I don't see a reason why LE can't issue wildcards in the future, though with their current setup they are even less important. Email certificates can be issued by LE as well. Code signing is the only one I see as problematic. In either case, I suspect that LE will take a huge bite out of CA's bottom lines, since there are a lot more DV certs out there than EV ones.

Yeah, wildcards are a necessity when every certificate is difficult to obtain, but LE really means we hit post-scarcity and certificates can be issued on the fly for new domains and subdomains.

Re: Let's Encrypt has issued its first million certificates

#47

Post by _yy »

nly wrote: post #37
tokenizerrr wrote: post #31

Earlier quoted context omitted.

What are you talking about? My nginx ssl config is static as well. It looks at a specific path for my certs, which just happens to be a symlink managed my by letsencrypt tooling. You're going to have to renew anyway. Previously you would have to remember to do that once a year, or maybe once every two years. Now let's ignore the security implications of having certificates that are valid for a year for a moment, and…

"Once" assuming nothing randomly breaks while you're not looking. What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date? What if one of the (Python?) dependencies has a bug or breaks? What if LEs servers are being DDoS'd? Can you enumerate and account for all the failure scenarios? I've already botched things with acme-tiny&LE in several different ways. I'm not claiming these risks…

> What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date?

That's why I renew them a week in advance. I set up Nagios checks which alert me when a certificate is not renewed. Those were already in place before LetEncrypt since human error is just as likely as a script breaking.

Re: Let's Encrypt has issued its first million certificates

#48

Post by nly »

michaelt wrote: post #45
nly wrote: post #37

Earlier quoted context omitted.

"Once" assuming nothing randomly breaks while you're not looking. What if your cronjob doesn't fire? What if LEs script has a bug and you're not up to date? What if one of the (Python?) dependencies has a bug or breaks? What if LEs servers are being DDoS'd? Can you enumerate and account for all the failure scenarios? I've already botched things with acme-tiny&LE in several different ways. I'm not claiming these risks…

given that LE takes just as much time and effort for initial set-up as a standard multi-year cert I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH - i.e. every server will configure itself right on first launch and keep itself that way. It's just going to take a long time to get there :)

> I think the LE endgame is that setting up HTTPS will be as easy as setting up SSH

It already is. Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception. That's the security model of SSH, and has the same assurances. It's just a terrible comparison. We can do better.

A better comparison would be with DNSSEC...

The way to simplify TLS deployment, while getting a better level security as DV CAs, would have been DANE. DNSSEC has an unfortunate reputation as being hard to setup ("pdnssec secure-zone mydomain" is not hard), but it also has exactly the same X day rollover key problem to solve as LE. Solving it once instead of twice would have made a lot of sense.

The symmetries between DNSSEC and LetsEncrypt are striking. Your account key is your KSK. Your cert is your ZSK... but instead of your webserver (in DNSSEC, your DNS server) doing rollover for you, you're depending on a pile of scripts, leaning on an already insecure DNS, and setting it up is still, comparatively, a pita.

Re: Let's Encrypt has issued its first million certificates

#49

Post by vmuhonen »

XorNot wrote: post #27

The default LE client was kind of a pain to work with. The docker container was better but where it really helped was the Lego golang implementation. That one 'just works' and was super easy to setup behind nginx to run automatically. It also writes a nicer config dir.

I found the default client to work as expected. It doesn't automatically modify nginx config, but I really don't want it to. It's simple to point the config to a correct location and then just use the webroot plugin. (Granted that needed the change to allow access to hidden directory via HTTP, but that wasn't rocket science either)

Re: Let's Encrypt has issued its first million certificates

#50

Post by ubergesundheit »

pingec wrote: post #4

Do their certificates still expire in only 90 days? That makes them very unappealing to me :/ Edit: I understand and agree on why they made it like this. But automating it is not an option in my use case, oh well... I agree it's for the better in the grand scheme of things :).

May I point you to the awesome Caddy server of Matt Holt [0]. It automatically obtains and !renews! lets-encrypt certificates.

[0] https://github.com/mholt/caddy

Post reply on HN