←back to thread

All extensions disabled due to expiration of intermediate signing cert

(bugzilla.mozilla.org)
1318 points xvector | 5 comments | 04 May 19 01:31 UTC | HN request time: 1.016s | source
Show context
needle0 ◴[04 May 19 01:56 UTC] No.19823806[source]▶
I’ll still keep using Firefox since I recognize the importance of browser diversity and the hazards of a Chrome monoculture (that and vertical tabs), but, yikes.

Still, this type of oversight seems all too common even in large companies. I remember several cases from Fortune 500 companies in the past few years alone. What would be a good way to automate checking for them? Has anyone developed a tool designed specifically to avoid certificate expiry disasters?

replies(18): >>19823825 #>>19823829 #>>19823831 #>>19823840 #>>19823848 #>>19823861 #>>19823913 #>>19823994 #>>19824009 #>>19824223 #>>19824243 #>>19824298 #>>19824668 #>>19824724 #>>19824795 #>>19824840 #>>19824927 #>>19825103 #
kam ◴[04 May 19 02:07 UTC] No.19823861[source]▶
ACME / Let's Encrypt go in the direction of making expiry happen so often that renewal gets automated, rather than a being a rare manual process that can be forgotten about.

Not sure that's viable for a signing certificate like this, but that's the way to solve it for the web PKI.

replies(3): >>19824049 #>>19824088 #>>19824159 #
SomeHacker44 ◴[04 May 19 02:48 UTC] No.19824049[source]▶
This is just abusive to the vast majority of users who do not care but still want to use SSL for their servers, frankly. I should be allowed to choose a near unlimited lifetime for my server's certificate if I don't care about the risks that may present.
replies(3): >>19824072 #>>19824221 #>>19824499 #
lugg ◴[04 May 19 03:23 UTC] No.19824221[source]▶
Security tends towards the lowest common denominator. I'd rather you just figured out how to run a cron job.

The problem comes if your keys ever get compromised or cracked all your historical traffic becomes vulnerable instead of just the most recent window.

replies(1): >>19824270 #
1. gboudrias ◴[04 May 19 03:34 UTC] No.19824270[source]▶
Yeah "just" a cron job except the implementation changes several times a year. Somehow this automated process was more time-consuming than the previous, manual one.
replies(1): >>19824317 #
2. lvh ◴[04 May 19 03:47 UTC] No.19824317[source]▶
Many cloud providers will make this process pretty much entirely automated. But let's say you don't want to do that: when is the last time the way you run caddy changed? Or the last time python-certbot-nginx changed?
replies(1): >>19824338 #
3. gboudrias ◴[04 May 19 03:54 UTC] No.19824338[source]▶
This was a few years ago, so things may have changed by now. But as they say, once bitten twice shy, and the wisdom of "just cron it" doesn't work with highly experimental tools like LE was for what I estimate to be the majority of its lifetime.
replies(2): >>19824359 #>>19825252 #
4. lvh ◴[04 May 19 04:00 UTC] No.19824359{3}[source]▶
I'm sure there's a way to make your LE experience consistently suck but the way to run caddy for a static website has been the same for about as long as caddy has had support for automatic HTTPS, and that's also true for python-nginx-certbot. But more importantly: we can argue about what it was 4 years ago, or we can just observe that it's really easy now.
5. lugg ◴[04 May 19 08:44 UTC] No.19825252{3}[source]▶
A tool not working well or being "experimental" does not dismiss the premise that frequently run automated tools are a better than infrequently run manual tasks when those manual tasks can take down your infrastructure if done improperly, missed or forgotten.

All it being new means is that depending on your risk ratio you need to decide whether updates to the software need testing or whether you need to invest in your own solution - or, how about just wait until it matures and keep the old process until then.

Waiting doesn't invalidate the premise either. It just means you lack the resources to implement it safely and that's ok.