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: 5, Interesting) by bzipitidoo on Wednesday September 15 2021, @03:02PM (21 children)
This illustrates a complaint I've made before about certs: at the magic expiration moment, they go from working perfectly, to not working at all. They're like Cinderella's carriage, instantly turning back into a pumpkin at the stroke of midnight. Or like the first traffic lights, which had only a red and a green, no yellow light. And why? The system ought to include a warning period.
(Score: 1, Touché) by Anonymous Coward on Wednesday September 15 2021, @03:15PM
Sounds like you are asking for a script that runs periodically that checks the site cert expiration date and creates a report/alarm if it will expire soon.
(Score: 3, Insightful) by DannyB on Wednesday September 15 2021, @04:21PM (9 children)
It sounds like you're asking for a feature in the certificate that specifies an expiration warning number of days (or an absolute date). Any browser that recognizes and honors this feature would warn that the certificate is due to expire soon.
Maybe better would be if the certificate also included an expiration notification URL. Any browser recognizing and honoring this feature would poke that URL to alert the site owners that their certificate is about to expire. Sites with soon to expire certificates would experience . . . uh, um . . . the "green site" effect.
Next up, someone could get themselves a lot of shiny new certificates that have the expiration warning feature, but will poke a URL of some DDOS target site when the certificate is due to expire. Those pin pricks would come from all different sorts of browsers from many locations.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 1, Insightful) by Anonymous Coward on Wednesday September 15 2021, @04:51PM (5 children)
No need to add a feature to the cert. Just have the browser check current date against expiration and warm 30 days out.
(Score: 0) by Anonymous Coward on Wednesday September 15 2021, @05:01PM (3 children)
That warns the visitor, not the administrator.
(Score: 2) by DannyB on Wednesday September 15 2021, @05:25PM (1 child)
But the visitors can make fun of the administrator.
Sort of like when the microsoft.com DNS name expired. Some kind soul on the green site renewed it. Microsoft paid him some token amount in the foam of a check, which he had framed.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Wednesday September 15 2021, @11:01PM
Just think, with modern banking apps, he could send a picture to his bank to cash it and still frame the check!
Hmm, any pictures of his framed check on the net?
(Score: 1, Insightful) by Anonymous Coward on Wednesday September 15 2021, @05:36PM
Imagine your average computer illiterate visitor visiting Bank of America and receiving a popup that says the cert is about to expire in 30 days. What the heck is the visitor supposed to care?
(Score: 5, Touché) by DannyB on Wednesday September 15 2021, @05:25PM
That is a needlessly simple solution to a problem which can have a much more complex solution.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Wednesday September 15 2021, @07:31PM (2 children)
This site uses Let's Encrypt. They send at least 2 e-mails to the contact prior to expiration giving plenty of time to renew manually, if required.
(Score: 4, Touché) by c0lo on Thursday September 16 2021, @12:57AM (1 child)
The eds need to write an email-to-IRC forwarder. In a deprecated PERL version.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Thursday September 16 2021, @02:09AM
There are a couple of those and I’m pretty sure at least one is in Perl.
(Score: 1, Insightful) by Anonymous Coward on Wednesday September 15 2021, @04:51PM (3 children)
Warning the users that the certificate is about to expire is much less helpful than emailing the site administrator who can actually fix the problem.
(Score: 0) by Anonymous Coward on Wednesday September 15 2021, @07:46PM (2 children)
Well, when the site administrator who was taking care of the certificates is driven away from the site, sending an email to said admin just might not result in it getting done.
(Score: 2) by MostCynical on Thursday September 16 2021, @08:26AM (1 child)
this is a problem with domain registration and app stores as well - one person (named individual) is the registration contact.
They may be a minor grade employee at a large company or government department.
The contact is their email, their phone number, and their name
They leave (quit/get fired/die).. the effort required to get the name changed is enormous- if it can be done at all.
There is almost never a 'second contact'.. one person is solely responsible for the 'ownership' of the whole company's or government department's entire web presence..
"I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
(Score: 0) by Anonymous Coward on Friday September 17 2021, @03:57AM
The tradition of using "admin [at] domain [dot] com" came about for a reason, but it became a spam magnet so we can't have nice things. :(
(Score: 5, Interesting) by digitalaudiorock on Wednesday September 15 2021, @05:21PM (1 child)
Combine that with the fact that the "industry" has decided that we can't buy certs with anything longer than a one year lifetime...because this bullshit apparently wasn't quite annoying enough.
(Score: 1, Interesting) by Anonymous Coward on Friday September 17 2021, @03:53AM
Limiting certs to a year was because too many old certs were compromised and their contact information was long out of date. Too much set-and-forget-and-retire. A shorter term doesn't eliminate it completely but it limits the impact. Making it yearly also means that the admins can mark a date on their calendar to help them remember.
(Score: 0) by Anonymous Coward on Wednesday September 15 2021, @05:58PM
> The system ought to include a warning period.
As long as we can list your cell phone number for my mother to call when her computer issues a warning. You can explain the expiring cert issue to her and that it's OK now, but check in a few days (she will call you).
(Score: 1) by fustakrakich on Wednesday September 15 2021, @06:44PM
Exactly, and all browsers should have the the option to bypass them, and we can leave it at that. I guess Chrome is good for something...
HTTPS is the devil's work. All certs can be rendered "expired" by the CA, and then how will you get in?
La politica e i criminali sono la stessa cosa..
(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.