Microsoft failed to rotate certificates for winget CDN on time(cdn.winget.microsoft.com) |
Microsoft failed to rotate certificates for winget CDN on time(cdn.winget.microsoft.com) |
But 2 years is still short enough that if you have a couple domains, remembering to renew them is an ongoing hassle!
Letsencrypt certificates last 90 days, and they recommend renewing them every 60 days. This is a much better duration, because it encourages the entire ecosystem - developers and admins - to set up processes which automate renewal. And if the automated renewal process fails, letsencrypt starts emailing you about it to let you know your certificate is about to expire. (And you have enough time to fix it).
Why can't they be automated?
And anyway, this is the exact problem that short expiration times avoid! Systems that aren't set up for automation, and rely on someone once a year remembering some creaky, error prone process to get a new cert. Much better to force short expiration times so manual cert renewal is a thing of the past.
And even worse, if you do automate it there is a pretty good chance something changes and breaks your automation by the time it is needed. And that is assuming you actually tested the automation before your new cert is close to expiring.
The expiration warning is configured so that it starts to yell at me if it passes that timeframe.
That gives me plenty of time to fix it IF it goes wrong.
that is all fine and good for things that have the ability to automate that process, plenty of hardware and device do not. Some are not even legacy are still actively being sold and developed
It is also not good for internal networks where you can not valid out to something like lets encrypt to automate that validation process, sure you could do your own internal PKI and run your own CA for that but......
In my current org 60 days would be a NIGHTMARE to manage.
Or you can set up certbot or similar on a public facing server (or something that can add DNS records to for your domain), and use a secure channel to send the private keys to the things that need it.
I would like to see more of a push to make setting up an internal CA a lot easier though. Because that is probably most correct way to handle that.
Why not? Just use DNS validation.
So it's literally < 10 lines of systemd unit file to automate it.
Rotating the certificates constantly works for personal websites but it is not ideal in places where one can't easily update things - like behind corporate firewalls or where corporate processes permit updating/replacing things only in fixed cycles, which are often much longer than 90 days.
Don't remember the Let's Encrypt root certificate expiring fiasco from year ago? Granted, that wasn't really Let's Encrypt's fault but it shows well that these things can be a tad more complicated than just running a script every 90 days.
Especially with short-lived letsencrypt certificates. Despite all the evangelists assurances, certbot is not always easy to set up. After letsencrypt gained popularity, the percentage of small websites with expired certificates significantly increased IMO.
Also, checking CRL is implemented in different ways. Some checks may be "soft", where a connection failure to the CRL is ignored. You probably want this anyway, if the CRL goes offline you don't want the internet to break. An expiry check, on the other hand, works as long as your clock is accurate.
oh, looks like it was either hotmail.co.uk or passport.com
https://slashdot.org/story/99/12/25/114201/microsoft-hotmail...
from
https://whoapi.com/blog/5-all-time-domain-expirations-in-int...
Recently I decided to install Windows Server on one of my PC instead of Windows 10/11. I thought, why not attempt to use winget and/or the Windows App Store to install basic software to see how far that takes me.
Immediate dead end. Apparently there's no access from the App Store on Windows Server. You have to have your IT set it up. And all the documentation refer to using winget from the App Store. :/ Microsoft, I can't even with you right now.
With Windows Server 2022, apparently you can get winget to work, but you have to install something else or other that's in preview.
For real, guys. Please get with the program.
Possible workarounds: Anything that's a workaround is already a non-starter for me because I'm not trying to experiment to see what I can get to work. I'm trying to move to using a new norm so I don't get left behind. If Microsoft was pushing winget as the new norm for global silent command-line installations of all things Windows, as an alternative to Chocolately, great! I would have given it a try. Other than that, imma just wait until y'all get your act together, <i>someday-maybe</i>.
(Azure Front Door)
And hilariously thinking Microsoft would spin up a critical incident team for a free open-source product. I'm rolling on the floor laughing.
We updated the certificate about an hour before this post. It takes 6 - 8 hours for the certificate to fully propagate.
For each distro, with each having their own format and own crond implementation, at each different file paths.
If you want to reinstall some old software, lets say MS Small Business Server 2000 or Small Business Server 2003 today, the certificates in the installation files prevent the installation of said software. So you wouldnt even get as far as being able to remove any certs.
Your only recourse is change the system date and time back to before the certificates in installation files would have expired.
Besides being a stealth way to prevent old software from being reinstalled, it narrows down the window of opportunity for hackers.
I used to automatically issue certs for my own servers which lasted 24hr's because if a hacker had got in to my system without me knowing which is a real possibility, at least an expired cert being used by someone else would highlight this problem.
As it happened, despite locking everything down to packet level and controlling the packets, my devices were just prevented from getting online. My ISP at the time TalkTalk had a very responsive system, issuing new IP address every 2 seconds in a bid to prevent me from hosting a website, with a domain name using dynamic ip address domain name service.
There is way more surveillance than most people realise at least here in the UK.
I think at least in some cases it'll still work. What matters is that the signature was created while the cert was still valid, not that the installation happens when the cert is valid. How do we prevent backdating attacks? By using a separate timestamp signature.[1]
TLS is different. It requires the cert-holder (aka webserver) to be online at all times. You don't need to be able to validate a signature created in the past. So TLS doesn't have this problem and thus doesn't need its solution (timestamp signatures).
E.g. because of regulatory requirements, chain of responsibility, a paper has to be signed with a pen, etc.
Shorter expiration times just mean they send me an email with the new .pfx every 4 months instead of every 12.
But if I wanted to, I can do so even now without being forced - request new certificate during it's validity period, and revoke the former one.
The only upside of EV certificates is that the PKI companies can seek a higher rent.
The problem is - in modern internet it is very hard to find out who is behind a particular domain: NS/A often point to a CDN or a cloud, info in whois is hidden and all you can see is 'Private'. OV/EV cert is often the only way to know that a domain like acmecorp-invoices.com is used by the same company as acmecorp.com and not phishing (registering a domain similar to the main company's domain is a bad but not uncommon practice).
One of a reasons to get OV/EV cert is to avoid you domain being listed as phishing - if would give a security expect no hints that your suspiciously looking domain is a legit one and not impersonation there is a risk that it would be blocked.
Phisher practically never use OV/EV certs on other hand (probably because they know there are little to no changes they'll get a cert with the target company's name in organizationName).