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

71–80 of 167 posts

Re: Let's Encrypt is down

#71

Post by majewsky »

atonse wrote: post #65
mholt wrote: post #50

Earlier quoted context omitted.

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

> If I am hosting 5 sites on caddy, and add a 6th one, I restart the server.

No, you don't. You reload the server, not restart it. Restarting a web server should only be required if you get an upgrade for it (or for OpenSSL etc.)

Re: Let's Encrypt is down

#72

Post by [deleted] »

TechTechTech wrote: post #70
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…

[deleted]

Re: Let's Encrypt is down

#73

Post by mastax »

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.

Then you just move all the WoT issues of the CA system into DNS, no?

Re: Let's Encrypt is down

#74

Post by scrollaway »

fb03 wrote: post #66
scrollaway wrote: post #60

Earlier quoted context omitted.

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?

And by running Caddy instead, I have one less piece to monitor and worry about.

The way Let's Encrypt works, it makes a lot of sense to have the functionality be part of the web server.

Re: Let's Encrypt is down

#75

Post by JshWright »

scrollaway wrote: post #74
fb03 wrote: post #66

Earlier quoted context omitted.

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?

And by running Caddy instead, I have one less piece to monitor and worry about. The way Let's Encrypt works, it makes a lot of sense to have the functionality be part of the web server.

> The way Let's Encrypt works, it makes a lot of sense to have the functionality be part of the web server.

That's an odd thing to say in this particular conversation thread...

Why would you want to tightly couple your webserver to the availability of another service provider?

Re: Let's Encrypt is down

#76

Post by e_d_e_v »

majewsky wrote: post #71
atonse wrote: post #65

Earlier quoted context omitted.

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

> If I am hosting 5 sites on caddy, and add a 6th one, I restart the server. No, you don't. You reload the server, not restart it. Restarting a web server should only be required if you get an upgrade for it (or for OpenSSL etc.)

This goes wholly against most cattle-not-pets devops philosophy though, right?

Re: Let's Encrypt is down

#77

Post by e_d_e_v »

GiorgioG wrote: post #51
scrollaway wrote: post #32

Earlier quoted context omitted.

Hm, yeah I hope so too :/ Been using Caddy in prod for a year now, this issue, rare as it may be, could single-handedly get me back on nginx. Having the server be unable to start through circumstances outside of the system's control is just such a huge no.

I'm done with Caddy - this is security theater at its finest. Back to nginx we go. Why did I pick Caddy, because it was simple/easy/fast-to-setup.

I moved from Caddy to Traefik (https://traefik.io/) several months ago. Granted, nginx has years (decades?) on some of these newer webserver/reverse-proxies, but I have been happy with all the built in niceties of traefik so far (single binary, etc), and haven't really experienced any negatives.

Re: Let's Encrypt is down

#78

Post by r1ch »

TechTechTech wrote: post #70
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…

I'm pretty sure revocation checks like CRL and OCSP all fail-open (they still allow the connection if contacting the revocation server fails).

Re: Let's Encrypt is down

#79

Post by tyingq »

fb03 wrote: post #66
scrollaway wrote: post #60

Earlier quoted context omitted.

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?

The simple config syntax and sane defaults is nice in Caddy. For example, 3 lines of config nets a https server with http/2 support and an A rating with Qualsys for ssl setup.
Post reply on HN