Live data from Hacker News

Microsoft failed to rotate certificates for winget CDN on time

cdn.winget.microsoft.com

51–60 of 69 posts

Re: Microsoft failed to rotate certificates for winget CDN on time

#51
Why would anyone standardize on winget when there's chocolatey and it works everywhere you can run Windows software?

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, someday-maybe.

Re: Microsoft failed to rotate certificates for winget CDN on time

#52
post #4

I think the default certificate expiration time (2 years) is a terrible idea. Its long enough that there's a good chance whoever registered the cert last time has left the team or the company. Its long enough that I've forgotten how to generate a certificate with openssl on the command line. And its long enough that each time, I (and everyone else) can justify not bothering to automate the process. But 2 years is sti…

Ballmer's Law: Engineers will design a system's maintenance schedule to be just beyond their promotion cycle

Re: Microsoft failed to rotate certificates for winget CDN on time

#53

Earlier quoted context omitted.

When a certificate expires, it can be removed from the CRL. If certificates never expire then the CRL grows without bound. 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 accurat…

You are forgetting something. 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…

Code signing certificates are NOT TLS certificates. Old code signing certs are an entirely different issue from old TLS server certs.

Re: Microsoft failed to rotate certificates for winget CDN on time

#54
post #19

Earlier quoted context omitted.

In your case, "something breaks in your automation" might mean that, by the time the cert is (about to be) in need of renewal, the notifications you set up are now going to an email account that doesn't exist any more, because you left the department got re-orged and...

If "monitoring" is set up as "send email to specific personal mailbox" then things are gonna suck a lot.

I was more imagining that it was going to an email account called e.g. "devops@"; and then when you left (possibly very quickly, e.g. via termination), the need for the continuity of that account was forgotten, because it had never become institutional knowledge; and then during a reorg, a new group (= email distribution list) was created to match the new department name; with nobody remembering to forward devops@ to the new address, because it wasn't receiving emails anybody needed to see on any sort of consistent basis, only these once-in-a-blue-moon emails.

Re: Microsoft failed to rotate certificates for winget CDN on time

#55

Earlier quoted context omitted.

Advantage of certbot: a systemd timer that runs every other week is very easy to write, because "certbot renew" doesn't need any user interactions. So it's literally < 10 lines of systemd unit file to automate it.

Or one line of cron.

[deleted]

Re: Microsoft failed to rotate certificates for winget CDN on time

#56
post #19

Earlier quoted context omitted.

In your case, "something breaks in your automation" might mean that, by the time the cert is (about to be) in need of renewal, the notifications you set up are now going to an email account that doesn't exist any more, because you left the department got re-orged and...

If "monitoring" is set up as "send email to specific personal mailbox" then things are gonna suck a lot.

The same can happen if you assign it to the team's mailbox, reorganizations happen at all levels.

Re: Microsoft failed to rotate certificates for winget CDN on time

#57
post #20
post #5

Earlier quoted context omitted.

The maximum expiration time is now down to 13 months, for certs that need to be valid in a browser. And if you want to cycle yours more frequently, you can. But there's enough places that can't set up automated processes that trying to make it 90 days for everyone would be a lot of pain and a lot of broken sites.

> But there's enough places that can't set up automated processes 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.

Several of the appliances we manage have certificates that are installed using a Web gui and require a reboot with a 15 minute outage for the change to take effect. We've looked at automating some things but there's only so far I want to go down the rabbit hole of headless chrome vs manually installing a cert yearly.

Re: Microsoft failed to rotate certificates for winget CDN on time

#58
post #20

Earlier quoted context omitted.

> But there's enough places that can't set up automated processes 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.

Several of the appliances we manage have certificates that are installed using a Web gui and require a reboot with a 15 minute outage for the change to take effect. We've looked at automating some things but there's only so far I want to go down the rabbit hole of headless chrome vs manually installing a cert yearly.

It seems like enforcing faster rotation would do a lot to encourage people and companies to move away from such obtuse platforms, no?

Re: Microsoft failed to rotate certificates for winget CDN on time

#59

Earlier quoted context omitted.

If "monitoring" is set up as "send email to specific personal mailbox" then things are gonna suck a lot.

The same can happen if you assign it to the team's mailbox, reorganizations happen at all levels.

Of course it "can happen". Anything "can happen". It's about mitigating risk by picking a strategy. In this case, from worst to better: personal mailbox -> team mailbox -> an actual monitoring solution and not friggin emails.

Re: Microsoft failed to rotate certificates for winget CDN on time

#60
post #54

Earlier quoted context omitted.

If "monitoring" is set up as "send email to specific personal mailbox" then things are gonna suck a lot.

I was more imagining that it was going to an email account called e.g. "devops@"; and then when you left (possibly very quickly, e.g. via termination), the need for the continuity of that account was forgotten, because it had never become institutional knowledge; and then during a reorg, a new group (= email distribution list) was created to match the new department name; with nobody remembering to forward devops@ to…

That's one reason why nobody who knows what they're doing relies (solely) on email for monitoring. You use a monitoring solution, and if that whole system gets "forgotten" then there are bigger problems anyway.
Post reply on HN