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

Let's Encrypt is down

letsencrypt.status.io

Post reply on HN
Print view View original

61–70 of 167 posts

Re: Let's Encrypt is down

#61

Post by jerf »

kogepathic wrote: post #57
jerf wrote: post #54

Earlier quoted context omitted.

Alternatively, maybe Let's Encrypt ought to Chaos Monkey this up and be down for 4 random hours every month or something on purpose. Or if you want to make very sure you don't turn people away, be down for 4 hours every month for any cert that has been in Let's Encrypt for more than a month or two, so you don't turn away new users. Because if you have a problem with a brief outage, the problem is in the user code, no…

> Alternatively, maybe Let's Encrypt ought to Chaos Monkey this up and be down for 4 random hours every month or something on purpose. And then gain a reputation for being unreliable? > Or if you want to make very sure you don't turn people away, be down for 4 hours every month for any cert that has been in Let's Encrypt for more than a month or two, so you don't turn away new users. Because if you have a problem wit…

"And then gain a reputation for being unreliable?"

If they tell people what they are doing and why, and only do it for established certificates, I'm not sure that would happen.

"Let's Encrypt should offer testing servers which are down for well defined periods throughout the day that people can use to test their platform against."

Who would use them? Anyone who cares enough to simulate LE failure is presumably already doing it.

Re: Let's Encrypt is down

#62

Post by ptman »

mholt wrote: post #50
discreditable wrote: post #13

Earlier quoted context omitted.

Wow @ that close comment: > So, this is not a bug and all is working as intended. Caddy folks had better never restart the caddy service (or server) while LE happens to be down, even if you already have a valid cert!

Caddy restarts gracefully with zero downtime. If you're killing the process and starting one anew, you're doing it wrong. Use signal USR1 to gracefully apply new configuration changes. Failed reloads fall back to the current working configuration without any changes or downtime. https://caddyserver.com/docs/cli#usr1

What if there's a reason to restart the server or spawn a new one?

Re: Let's Encrypt is down

#63

Post by hsivonen »

foepys wrote: post #45
nailer wrote: post #33

Earlier quoted context omitted.

OK done: we move to self signed certs. - Someone connects to wifi. - The wifi gives a DNS server. - The DNS server says some IP is foo.com. - foo.com isn't actually the foo.com you expect [1], but it's got a self signed DV cert so you connect to it, and give some bad person your data. That's why we don't more to self signed certs. [1] Of course, if you want to assert foo.com is actually the 'Foo, Inc' you were expect…

TLSA DNS records coupled with DNSSEC could eliminate the need for CAs but we still have a long way to go until we can rely on it.

DNSSEC has a 1024-bit RSA root after Web PKI ( at least Mozilla-flavored) no longer did.

Are the TLDs audited like CAs? Having to change the domain name to evade the TLDs bad security practices is more disruptive than switching CAs.

Re: Let's Encrypt is down

#65

Post by atonse »

mholt wrote: post #50
discreditable wrote: post #13

Earlier quoted context omitted.

Wow @ that close comment: > So, this is not a bug and all is working as intended. Caddy folks had better never restart the caddy service (or server) while LE happens to be down, even if you already have a valid cert!

Caddy restarts gracefully with zero downtime. If you're killing the process and starting one anew, you're doing it wrong. Use signal USR1 to gracefully apply new configuration changes. Failed reloads fall back to the current working configuration without any changes or downtime. https://caddyserver.com/docs/cli#usr1

This misses the overall point.

If I am hosting 5 sites on caddy, and add a 6th one, I restart the server. If the 6th site doesn't work (for example, if DNS didn't resolve for lets encrypt), the other 5 sites which were working before the restart, all fail to start as caddy completely crashes.

This is basic resiliency you'd expect from your web server. Why should the other 5 sites fail to start if their configs are completely valid?

Re: Let's Encrypt is down

#66

Post by fb03 »

scrollaway wrote: post #60
enimodas wrote: post #48

Earlier quoted context omitted.

Why did you switch away from nginx?

Not having to deal with certificate renewal is a big deal.

I am running nginx reverse-proxying to a python API right now. Dealing with certificate renewal is a matter of running a daily cronjob issuing 'certbot renew'. If it works it replaces the fullchain.pem certificate, and that's it, easy peasy.

Am I missing something?

Re: Let's Encrypt is down

#67

Post by merkaloid »

tyingq wrote: post #19
discreditable wrote: post #13

Earlier quoted context omitted.

Wow @ that close comment: > So, this is not a bug and all is working as intended. Caddy folks had better never restart the caddy service (or server) while LE happens to be down, even if you already have a valid cert!

That's going to be a limiter for adoption. Hopefully @mholt reconsiders. Update: Mholt pushed a change where caddy only refuses to start if the cert is expiring in 7 days or less. https://github.com/mholt/caddy/commit/410ece831f26c61d392e0e...

Or someone forks it

Re: Let's Encrypt is down

#68

Post by jpgvm »

jaas wrote: post #55

Josh from Let's Encrypt here. First, my apologies for the trouble this has caused. I want to offer people here an early root cause analysis. I say early because we have not entirely completed our investigation or a post-mortem. OCSP requests that use the GET method use standard base64 encoding, which can contain two slashes one after another. While debugging why a small number of OCSP requests consistently failed our…

Thanks for the insight.

Would love to read a full postmortem of both the OCSP and issuance issues.

Re: Let's Encrypt is down

#70

Post by TechTechTech »

jaas wrote: post #55

Josh from Let's Encrypt here. First, my apologies for the trouble this has caused. I want to offer people here an early root cause analysis. I say early because we have not entirely completed our investigation or a post-mortem. OCSP requests that use the GET method use standard base64 encoding, which can contain two slashes one after another. While debugging why a small number of OCSP requests consistently failed our…

Just a quick question. Does this mean that if your OCSP servers were to go down, a lot of SSL enabled websites and applications will stop working? Seems like a serious single point of failure for modern day internet. I was always under the assumption that clients do not have to contact the CA (every time?) before a TLS handshake takes place.

OCSP Stapling seems to be the way to mitigate this problem, but not all web servers implement it (for instance lighttpd does not). Any recommendation from Let's Encrypt on this issue?

Post reply on HN