Re:Let's Encrypt is down
by scrollaway on Friday May 19, 2017 @11:30AM
(#14376619)
You're drawing conclusions from unintended behaviour, which has now changed (and a release has been issued).
I still think that refusing to start if the cert expires in 7 days or less is still an issue if Let's Encrypt is down.
There should be at most a warning but it should start. Otherwise you end up with an external dependency that can cause your web server to not start through no fault of your own.
> unintended behaviour
Ahem. https://github.com/mholt/caddy/issues/1680#issuecomment-3026...
Emphasis mine:
> So, this is not a bug and all is working as intended.
Re:Let's Encrypt is down
by scrollaway on Friday May 19, 2017 @08:46PM
(#14380386)
Have you noticed that the bug has been fixed?
This wasn't caused by a bug. This was a deliberate decision to fail to start if the certificates on-disk were <= 30 days away from expiring and the CA can't be contacted.
> Drawing the conclusion you did from the variables at play is shortsighted
Using caddy is the web-server-stack equivalent of "putting all your eggs in one basket". If one thing about it isn't working the way you want, you have to either a) replace it completely or b) work out how to disable the bit that's not working how you want, and replace that part of it.
> Drawing the conclusion you did from the variables at play is shortsighted
- People use a piece of software that serves as both ACME TLS certificate client and web server
- Said software by design won't start if the CA can't be contacted 30-days out from expiry
The conclusion I drew is that such integration leave the operator with less control than if they followed a separation-of-concerns approach, and left web serving to a web server, and TLS certificate renewal to an ACME client. The former doesn't need to care about how old the certificates are, just use what it's given.