161–167 of 167 posts
Earlier quoted context omitted.
You're drawing conclusions from unintended behaviour, which has now changed (and a release has been issued).
> 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 .
"High assurance datacenter" High assurance my ass. Those don't go down unless there's a DDOS or catastrophic failure (often several). Then, they're right back up. People need to stop misusing this label. Another is "high-assurance" certs from vendors that get compromised or subverted easily. Only one high-assurance CA that I know of. It's not around for business reasons, though. http://www.anthonyhall.org/c_by_c_secu…
The issue here doesn't seem that a data center went down, but that there was a bug which caused downtime.
I'm not seeing any of this in the reporting that made it here. Definitely not high-assurance. Likely compromised by high-end attackers either for specific targets or in some general way. It will help protect in its intended way against the rest, though. Enormously positive development. Just not high-assurance security at any level.
Was fun finding this out during a random server cycle. Turns out, Caddy doesn't appreciate the ACME server being down, and refuses to start :) https://github.com/mholt/caddy/issues/1680
Updating to v0.10.3 should fix this problem and allow Caddy to start, provided your cert isn't less than 7 days from expiring: https://github.com/mholt/caddy/commit/410ece831f26c61d392e0e...
This fix gets almost everybody where they should be, the next time the same thing happens (and it will) Caddy isn't a problem for three weeks, which is definitely enough time. Meanwhile we're going to see the same Apache crappiness for OCSP again each time until someone over there finally snaps out of it and asks someone who actually knows how OCSP stapling was supposed to work.
Earlier quoted context omitted.
You can run your own ACME provider, the code is open source. Nothing stops you from running a CA that offers 1 year certs over ACME. Or just providing one that also offers 90 day certs. If people will trust that CA is another question. The automation of LE is not the problem either. Properly automated systems would extend/renew the cert well before they are invalid, almost every LE guide I know mentions this on groun…
> Nothing stops you from running a CA that offers 1 year certs over ACME. Or just providing one that also offers 90 day certs. If people will trust that CA is another question. You know that's BS. All of your users would get certificate errors, that's what's preventing you from running your own CA.
"if people wo trust that CA is another question"
Of course you won't get trusted but that's not the issue.
So in case this helps anyone, I had people complaining about strange OCSP errors all over the morning coming from my server (using apache httpd). It turns out apache does practically everything to behave as dumb as possible in case of OCSP downtimes. If the OCSP sends an error it will send the error as a stapled OCSP reply (instead of using an old, still valid OCSP reply). You can't make it behave sane here, but you…
Earlier quoted context omitted.
Is it? I spent one day getting certbot up and running, and ever since then it's been pretty much a done deal.
That's 1 day that I didn't have to spend, even better when dealing with many instances.
1. The cost does not scale with the amount of instances since it is the one-time cost to create the configuration package.
2. If you decide to go for Caddy instead, you'll have to spend the same time, if not more, learning Caddy.