Microsoft hits snooze again on security certificate renewal Microsoft has expiration issues with its TLS certificates, resulting in unwanted security warnings. An eagle-eyed Register reader from Australia brought the plight of cdn.uci.officeapps.live.com to our attention, which is listed at one of Microsoft's worldwide endpoints for Microsoft 365 and Office Online. According to …
They did.
However, (the) Outlook decided it was too early to warn them. More pain ensued when (the) Outlook subsequently refused to connect to the domain because of an expired certificate without warning the users of the failed connectivity.
I couldn't log in with my TOTP authenticator this morning, it rejected all attempts saying the verification number was unexpected. Oddly enough having my account's 2FA reset, downloading the MS authenticator, and adding that to my account worked. Funny that.
You do now... The encryption wallahs worked out that they could get mullah for automatic renewals, so these days if you want it free, you've got to wait until the old cert dies every 3 months and then manually renew it. You can't do it before because the send button is disabled.
So much for FOSS
I have no idea what you are talking about... There is no "clicking" anything. You tell your server what hostname to listen on then your server software talks to let's encrypt* using an API that involves no human interaction. (Well, in theory you are meant to configure your email address for expiry notifications, but that is optional)
The handful of services I maintain which don't support automatic free certificate issuance and renewal get stuck behind a proxy that does.
* Other providers are available, however those normally need an account and an API key hence let's encrypt being the default in most software.
I'm not sure whether anyone else exfiltrating your LetsEncrypt certificate key(s) from LetsEncrypt would actually matter much?
Certificates are requested, when needed, at your end, by an ACME client running on your host - I'm not sure (I haven't checked) if your key actually even leaves your host at all as part of that process? It might even be the case that your system generates a new key whenever it requests a new cert (again, I haven't checked). In any case, no LEncr cert is valid for longer than 90 days anyway, and are usually auto-renewed after 60 days, to provide a suitable margin of safety overlap, limiting the time that any malicious cert could potentially be in use.
Also, your key is only part of the process of identifying the cert requester. The cert issuing process will only work if your request comes from a suitable host within your domain, with your webserver sending suitable responses during the process (so that you can't request a cert for a host that you don't manage, as the handshaking will try to call back to contact that host, not yours, and the request will fail). It is also possible to do the ownership authentication by creating appropriate DNS records.
LEncr also practices "certificate transparency" where every cert created is publicly logged, and there are various systems and numerous security researchers which monitor these logs and should be able to detect anything that has somehow made it through and looks amiss.
Sure, if LEncr's own keys or root certs were to get compromised, that would be much more serious, but that's a potential risk with any CA…
That reader has no idea what he is talking about. Certificate management is a key pillar to IT. You need a certificate vault to store them and it tells you when certificates are about to expire. NO ONE should be using a spreadsheet to manage their certificates. That's just lazy. Do better Register. Get a real IT journalist.
They just don't know how to implement it.
So... they forget stuff like their certs. They do remember other stuff. I got this:
begin quote
__________
Update your sign-in technology before September 16th, 2024 to maintain email access.
The safety and security of your information is top priority for Microsoft. To help keep your account secure, Microsoft will no longer support the use of third-party email and calendar apps which ask you to sign in with only your Microsoft Account username and password. To keep you safe you will need to use a mail or calendar app which supports Microsoft’s modern authentication methods. If you do not act, your third-party email apps will no longer be able to access your Outlook.com, Hotmail or Live.com email address on September 16th.
What do you need to do?
If you are receiving this email, you are currently using an email or calendar app that uses a less secure authentication method to connect to your Outlook.com email account. You will need to upgrade your third-party mail and calendar app to a version which supports modern authentication methods.
Microsoft provides free versions of Outlook for your PC, Mac, iOS, and Android devices which can be easily downloaded and connect to your email account. Using an updated version of an Outlook application will ensure you are connecting in the most secure way.
How can you set up your Gmail, Apple Mail, or other third-party mail application?
Various non-Microsoft applications will have their own steps for connecting to your Outlook.com email account using modern authentication methods. See our help article - Modern Authentication Methods now needed to continue syncing Outlook Email in non-Microsoft email apps. However, you may need to contact the creators of those applications to provide you with instructions. In many cases, simply removing and re-adding your account with the latest version of that application will configure it to use modern authentication methods.
_________
end quote
Yeah, they are deliberately breaking massively insecure (yeah, right) 3rd-party apps from Apple and Google but not, somehow, Outhouse. Gee. Hmm. Outhouse 'forgets' how to contact some email systems (Zoho...) and does so on multiple platforms, including Win10, macOS, iPadOS, iOS. Apple Mail, that so-inferior app, connects to all services I've tried on all Apple platforms (doesn't work really well on Windows, of course) and security updates for Mail may require a restart of the app but not usually a reboot of the device. I literally just had to reboot this laptop to get Outhouse to behave.
I see lots of problems coming for those who dare to use non-MS email services, and it will be all your fault, never theirs.
Please, someone, set up a good, or even just usable, cross-platform email client so that I can delete Outhouse from everything.
I said 'usable'. Thunderbird used to be usable. It's been almost as bad as Outhouse for years now. And there's no T-bird for iOS/iPadOS. Outhouse works, such as it is, on iOS/iPadOS. T-bird doesn't support devices that Outhouse does, kinda, support.
Proton Mail seems to support everything, but it looks as though they will be wanting money after the trial period.
This so-called "modern authentication", as Microsith claims to call it, is just OAuth2 (an open internet standard): rather than allowing a program to access the mailbox using only the username and password, you authorise an 'access token' for the program, so that the program cannot access your mailbox without this token, and you can revoke the token for each program or webmail system, etc, should it be necessary. Various email systems also use this (sometimes as an opt-in setting), not just Microsith.
Yes, communications about this from Microsith sleazily bend the truth somewhat and are clearly deliberately worded to pretend that this is some whizzbang feature unique or proprietary (blech) to them (it isn't) and that non-Microsith email programs are so much less secure than theirs (definitely not), and, yes, it is a little bit of a faff to set up (depending on your email program), but it is supported by most currently maintained email programs, including Thunderbird, Evolution, Apple Mail, even Alpine, and various webmail systems.
The same failing was a fairly common occurrence where I was employed. The various sites with which I had any association were hosted centrally as was the certificate management. In the end I wrote a short script that read a list of hosts (FQDN) and servername (SNI) and port from a file and invoked openssl to extract the site's certificate expiry date from the server.
The script ran every 24 hours and if the expiry was within two weeks it generated a warning for the particular site.
After a few days central IT would get a tap on the shoulder.
I actually checked the certificate's start date was also valid.
Staff attrition and turnover were the root causes of these problems (like letting their domains expire - twice) which I suspect is the same self inflicted wound that Microsoft and many (most?) enterprises are suffering.
A whiteboard or spreadsheet or registrary isn't much use if there isn't anyone left.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
