> 4. Key rotation: Again, I know of only one web server that does this by default and automatically (cough Caddy).
This misses the point, because whilst nginx/Apache don't handle this for you - the automated ACME clients like Certbot (and e.g. Lego) do and will ensure you get a fresh keypair used for renewals.
>5. Certificate transparency: As of now, there is not enough useful consumption of CT logs. We have TBs of data but no one to read them.
I don't disagree adoption is probably low but it seems more appropriate for a specialised service (as part of your existing monitoring infrastructure) to handle this.
> This misses the point, because whilst nginx/Apache don't handle this for you - the automated ACME clients like Certbot (and e.g. Lego) do and will ensure you get a fresh keypair used for renewals.
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.
>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.
This 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
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.
I 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
First 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.
This misses the point, because whilst nginx/Apache don't handle this for you - the automated ACME clients like Certbot (and e.g. Lego) do and will ensure you get a fresh keypair used for renewals.
>5. Certificate transparency: As of now, there is not enough useful consumption of CT logs. We have TBs of data but no one to read them.
Don't these sort of monitoring services already exist? https://sslmate.com/certspotter/ https://developers.facebook.com/tools/ct/
I don't disagree adoption is probably low but it seems more appropriate for a specialised service (as part of your existing monitoring infrastructure) to handle this.