Oops: LinkedIn country subdomains SSL cert just expired LinkedIn's country subdomain SSL certificate has expired – apparently as of about noon GMT today. According to the sslscan certificate testing tool, us.linkedin.com and all its altnames were no longer valid at the time of publication. The certificate issuer is DigiCert SHA2 Secure Server CA. The certificate for the naked …
It is stupid that expired certificates are the same level of "NO DONT CARRY ON!!" as invalid certificates.
Recently expired certificates are 99% trustworthy and the "NO STOP! OMG!" just trains users to ignore this stuff.
Unless it's been revoked, browsers should show a small information message, not a shouty threatening "The end is nigh" warning..
Self signing makes certificate signing irrelevant and expiry dates add nothing to security. If someone has stolen your current cert they can probably steal your new one too. Its extra pointless security that should only be used in specific circumstances but because its used everywhere people become blase to it and mentally filter out any warnings.
Bollocks! Self-signed certs won't help on someone else's machine because the issuer (you) won't be in their trusted root certificate authorities list. Expiry dates add plenty to security for the simple reason that somehow-compromised certificates have a self-limiting window of usefulness to the bad guys. And "stealing" an SSL cert is useless without the private key. You've got the certificate for The Register on your machine already if you've viewed it in your browser, but only the public key and not the private one.
Other than that I agree with everything you've said. Ahem.
If it warns clearly (a click through warning not just a yellow padlock or something else 99% of people will never notice) then accepting for a week seems reasonable. That would give time for the domain owner to become aware and correct the issue. If they don't notice for six months they apparently never visit their own site, so that's on them.
The Linux open source operating system, or Linux OS, is a freely distributable, cross-platform operating system based on Unix that can be installed on PCs, laptops, netbooks, mobile and tablet devices, video game consoles, servers, supercomputers and more.
If you wanted to find out, you could use telnet to talk raw HTTP to the site and issue a HEAD request. If you're using Windows, this is painful to do (different types of painful depending on the version of Windows/telnet client) but on Linux or even MacOS it's a piece of piss. If you're a wimp you can always try netcraft.com/whats.
"If you're using Windows, this is painful to do"
Except that Windows, being the most widely used desktop OS in the world, has a huge variety of third party applications available including decent Telnet clients. Putty is a few clicks and seconds of download away from anyone with an Internet connection, and does a fine job as a Telnet client.
Don't turn a task like this into a Windows vs Linux/MacOS argument, just because they include a Telnet client in the OS by default. It's perfectly valid for Microsoft not to, given that only a small percentage of users would want one.
If you want to have that kind of argument, I'll simply say that Emacs and vi are both terrible, and nano is the only decent Linux text editor.
I'll simply say that Emacs and vi are both terrible, and nano is the only decent Linux text editor.
Burn the heretic! The holy Vi should *never* be mentioned in the same sentance as the never-to-be-sufficiently-damned Emacs[1]. Nano is all right though.
[1] It corrupts my soul to have even typed thaT evil name. I shall now repeat 500 :wq! commands until all is clean again.
Don't turn a task like this into a Windows vs Linux/MacOS argument, just because they include a Telnet client in the OS by default. It's perfectly valid for Microsoft not to, given that only a small percentage of users would want one.
I was talking of the Microsoft-supplied telnet client, not a third-party one. You're right. For just about anything you want to do on Windows, don't rely on the shit that Microsoft supply. Wise words, indeed.
There have been two versions of Microsoft telnet client I've encountered, one black text on white, the other white text on black. Both had two serious shortcomings when used to connect to web servers for a quick HEAD request. One shortcoming was common to both, the other shortcoming differed.
As I recall, both handled the delete key incorrectly and sent a backspace rather than deleting the character from the send buffer (or maybe the output was unbuffered). Either way, you couldn't afford to make a typo because you couldn't correct it. Fail. Maybe using ctrl-H would have worked, I kept meaning to try but always forgot to because after the first fail I'd switch to a Linux machine if there were one around or find some other way (and swear to never use Windows for anything ever again, no matter how simple).
One of them didn't local echo. Which made typos (that you can't correct) very likely. Supposedly you could enable it somehow but I never got it to work. I'm willing to put the blame on me for being unable to get it to work but firmly blame Microsoft for not defaulting to local echo when connecting to a non-telnet port in the first place, like every non-Microsoft telnet client I've ever used does.
The other timed out before you could type the entire request (minimum of "HEAD resource," "HOST domain" and an extra carriage-return. Of course, you could type really fast, but rarely fast enough and then you had typos you could see but not correct.
Both were a pile of steaming shit. Yeah, you can say not many people need telnet, and even fewer need telnet to do quick HEAD tests on web servers, but every other telnet client I've ever used got it right. It's not like Microsoft didn't have examples to emulate (and code to rip off).
BTW, one of them (can't remember which, think it was white-on-black-no-local-echo) was included with Win 7, it was just well-hidden and you needed admin privs to make it unhide itself (as I recall, "super-installing" something that is already installed). Which may well also be the case with Win 10.
Don't try to defend the indifensible.
certs are still as secure and valid as they were yesterday
Secure - yes (possibly - if an organisation isn't organised enough to have people or processes checking for certificate expiry, it makes you wonder what else they have failed to do..). Valid - no. Let me explain the concept of an expiry date again..
-and some random guy with sharp eyes snaps it up, tenderly holds it like an abandoned baby in his strong yet gentle arms, then turns it back over to the authorities. Here's the a link you were looking for (edit: wow, apparently they did this more than once?).
https://www.theregister.co.uk/2003/11/06/microsoft_forgets_to_renew_hotmail/
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
