SoylentNews is people
SoylentNews
Late last night (~10 PM UTC), the security certificates for SoylentNews.org expired. (Out-of-date certs result in nasty warning messages being displayed by your browser.)
Please accept my apologies for any inconvenience the outage caused.
Unfortunately, that was after I (and others on staff who could do anything about it) had gone to bed.
I had personally updated the certs in the past, but the last time was years ago. (TheMightyBuzzard had previously — and subsequently — handled getting and applying updated certs.) It had been so long that I could not find my notes on the process. (Note to self: it helps to look in the correct directory tree!)
Thankfully, audioguy appeared and was able to get things updated.
Please join me in thanking him for getting things straightened out!
P.S. The current certs are due to expire December 14, 2021, Please feel free to remind us as that date approaches!
P.P.S. The technical staff is aware of various automated solutions to renewals but made a conscious decision to do them manually. Remember that people make mistakes but to really foul things up use a computer!
(Score: 2, Interesting) by vali.magni on Thursday September 16 2021, @07:14AM (1 child)
Good idea, and I've thought about this earlier. What can work here are X.509 v3 extensions that (a) include information such as escalation paths, degradation strategies upon certificate expiry, etc, and (b) ecosystems that will honour this information and do what needs to be done.
Today, standard X.509 v3 extensions can contain information about the certificate issuer, public key IDs, usage constraints, policies and policy mappings and more. In the real world, the implementer or ecosystem decides the extensions they will support.
For example, the Golang runtime generally demands the use of the SAN extension but other runtime environments will happily take the CN field and run with it with or without the SAN extension.
One might consider using the X.509 "Subject Information Access" private extension defined in RFC5280 but it's a non-critical field, and I am yet to come across software ecosystems that work consistently well with the SIA extension.
An alternate approach is to ignore these altogether and just go with custom extensions that the browser makers agree upon, but this is a hacky approach that is bound to cause problems in the long term. Others have recommended that browsers themselves check certificate expiry dates and warn users a few weeks before they expire, but this too is ad-hoc behaviour.
There appears to be no real solution today unless I'm mistaken.
(Score: 4, Interesting) by bzipitidoo on Thursday September 16 2021, @02:28PM
While it will help to use X.509 extensions to make degradation more graceful, by adding something analogous to a yellow traffic light (and good on them for providing means to extend the standard), I think the entire idea of date based expiration needs a rethink.
One rather bad bug in Firefox that was fixed a few years back was its assumption that the system time was reliable. A failure point aging PCs are notorious for is the CMOS battery finally drained of all power some 5 years after purchase, causing it to be unable to remember the current date, instead setting it to a default starting date which may be Jan 1, 1980, or, nowadays, Jan 1, 2005 or so. The OS and Firefox ran with that date, and next thing you had was Firefox throwing up inappropriately scary messages and refusing to load any https at all, because all the certs were too far in the future to be valid. Firefox now uses a build date as a baseline.
Date based expiration is just plain crude. Much better to base expiration on events. Perhaps the timed expiration idea comes from a notion I heard a long time ago about passwords. The thinking was that a password could be brute forced in perhaps a year's time, and by forcing a password change every 30 days, the brute force work would have to be started over. Today, there's no excuse for using keys weak enough to be brute forced so fast. Throw another 64 bits in, and you've made a weak key into such a strong key that brute force is utterly impractical. So that reason for date based expiry is moot.