3 ms·
>So you're agreeing with him: nginx and Apache don't do it by default and automatically, they need an external tool. Which is yet another step to add and monito
by lol768 8y ago
>So you're agreeing with him: nginx and Apache don't do it by default and automatically, they need an external tool. Which is yet another step to add and monitor as an admin, which means fewer people will go through the hassle of doing it.
The vast majority of people using Let's Encrypt are going to be using an external tool such as Certbot to automatically generate and renew their certificates for them. It's the officially endorsed method for getting certificates [1]. It's more hassle to do it without such tools.
Proclaiming that existing solutions don't do key rotations is therefore misleading. The _web server_ in isolation might not be directly responsible for it, but then Apache and Nginx aren't responsible for injecting sponsor advertisements into your HTTP response headers either so there's perhaps some precedent for Caddy doing more than it should.
[1] https://letsencrypt.org/getting-started/ https://letsencrypt.org/getting-started/
- rakoo 8y agoThis is the officially endorsed solution because the Let's Encrypt project assumes none of the web servers have this functionality out of the box. Caddy does, and that's what the whole discussion is about. > more than it should. We're entering subjectivity here, but I think you can agree that doing proper https with rotating certificates is probably a should for easy-to-use servers in 2018
- jiveturkey 8y agothe unix way is small tools for small jobs. if you have to debug the OCSP renewal, would you rather debug an entire web server (and update it), or just the behind the scenes renewal tool, which doesn't require an interruption to ... web serving.
- rakoo 8y agoI know and agree with the philosophy, however there is a limit to how much you can decouple things and keep the whole system maintainable. Just look at the woes of our peers embarking on the microservices journey. This is especially relevant for caddy, which focuses strongly on the ease of use. Now of course it's not the perfect answer for everyone; different solutions for different people I guess
- jiveturkey 8y agoFirst I have to admit I know nothing of Caddy. This is the first I've heard of it. However, I don't think this is a case of different strokes. Even at a hobby level (1 webserver instance, not load balanced, per site or group of sites), in today's infra we can expect use of Let's Encrypt and therefore certbot, can we not? I mean, if we're talking about stapling at all, we're talking about enough infra that we do the type of automation that will include certbot. Once you're at that point, I cannot agree that it's easier, and more manageable, to include the functionality within the web server. Perhaps if Caddy integrated acquiring and renewing the cert itself, not just stapling, then I'd have a different opinion. Now at the point where you are load balancing, with or without an https proxy, in my experience debugging and maintaining smaller components is easier. Yes, interactions can create hard to debug problems, but large complex "monoliths" are worse. And we are talking about a sufficiently discrete component here. That said, I'm not an SRE. Back before SRE was a thing, I was a "LISA" sysadmin though.
- mholt 8y agoYeah you should take 2 minutes to check out Caddy: https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https > Perhaps if Caddy integrated acquiring and renewing the cert itself, not just stapling, then I'd have a different opinion. It does, so.... does that change your opinion? (That's, like, the point of Caddy.)