Comment by nly | Hacker News Reader

Comment by nly | Hacker News Reader

Parent Full thread

"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 are that significant, but given that LE takes just as much time and effort for initial set-up as a standard multi-year cert, if not more, I think the mantra "some risk of failure is more risk of failure than no risk of failure" is something worth baring in mind.

And I'm not convinced having 90 day certs is a huge security win. Not only can someone do a lot of damage in 90 days, but your private key (the important bit) can't be rolled every 90 days anyway without integrating your rollover scripts with your HPKP config. If you botch that then your visitors can't come back to your website until the pin expires. Scary. Site ending scary. And if you're not using HPKP then i'm not even going to debate the security pros and cons.

On remembering to renew certs... there are many many services out there to send you reminders. Pick 2 or 3 and use them all. Or use a CA that sends reminders.

I'm glad LetsEncrypt exists, but let's not treat it like the be-all-and-end-all.

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

I renew every month and have not hit their rate limits. That way, even if the cron job doesn’t fire and I don’t notice, there is another chance a month later.

  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.

> Use a self-signed cert and ask your visitors via a side channel to tick the box to add an exception.

Don't do this. If you have to ask your users to add an SSL exception you're doing it very wrong.

He was comparing the tls equivalent of how SSH works. First time you connect to an ssh server, you have to accept the host key, which most people do not (and in most situations, can not) verify.

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.

As the Caddy server linked in another comment shows, nothing in LE requires you to depend on a "pile of scripts" to do roll-over for you, it's just early days.

Yes, there will be products to make this simpler, but the point is, unless you are willing to grant LetsEncrypt a DV cert monopoly, to the exclusion of all others (or at least those not compatible with their API), then, in general, it can never be as easy as just turning it on.

DNSSEC puts the CA monopoly in the DNS. There is no API for a hypothetical web server using DANE, because there's no need for periodic domain validation. Of course, DNSSEC is a disaster, so it's a non-starter... but I'm still going to lament the fact that everything is terrible.

Since LetsEncrypt's API protocol is being standardized through the IETF (https://tools.ietf.org/html/draft-ietf-acme-acme), there's no reason any new competing free certificate providers can't be compatible with it. In the long term, if more show up (and I wouldn't be surprised if some existing CAs refocus their business on EV and start offering free DV certs through ACME), I see no problem with software giving the protocol a "monopoly", in the sense of building in auto-configuration support for it.

Let's Encrypt renews certificates after 60 days by default, giving you a 30-day grace period for outages, etc. Use a daily cronjob and monitor your certificates. Setup alerts if your certificates are closer than, say, 25 days to expiration. This should cover temporary outages, bugs, etc. - and the monitoring bit is no different from what you should already have even with manual renewal.

> 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 run my cron job[1] every hour. It checks for the expiry of my existing set of certificates and has a configurable parameter as to how soon before expiry to renew them.

[1] https://github.com/frutiger/concorde

Nagios will tell me when my certificate is a month within expiring. This is a standard nagios plugin. The cronjob runs nightly, checks if renewal is necessary (once a month, certificates valid for 3 months, so will renew when 2 months are still left) and then does its thing.

run it @weekly

it's what I do

Reply on news.ycombinator.com