This story has been widely under-reported and the impact is potentially huge. My beef with MS is this: the keys were leaked in 2021 and were still signing authentication tokens in 2023, but there's not a single Azure service that allows me to enter credentials with a 2 years duration. It's a classic case of "do as I say, not as I do".
Imagine what the CA/Browser Forum would do if they discovered that a PKIX CA had lost control of its signing keys, didn't revoke them and in fact carried on using them for 2 years without telling anyone...
$ dpkg -l ca-certificates
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===============-============-============-=================================
ii ca-certificates 20230311 all Common CA certificates
$ trust list | grep Microsoft
label: Microsoft ECC Root Certificate Authority 2017
label: Microsoft RSA Root Certificate Authority 2017
On RHEL 9:
$ rpm -q ca-certificates
ca-certificates-2023.2.60_v7.0.306-90.1.el9_2.noarch
$ trust list | grep Microsoft
label: Microsoft ECC Product Root Certificate Authority 2018
label: Microsoft ECC Root Certificate Authority 2017
label: Microsoft ECC TS Root Certificate Authority 2018
label: Microsoft Identity Verification Root Certificate Authority 2020
label: Microsoft RSA Root Certificate Authority 2017
label: Microsoft Root Authority
label: Microsoft Root Certificate Authority
label: Microsoft Root Certificate Authority 2010
label: Microsoft Root Certificate Authority 2011
label: Symantec Enterprise Mobile Root for Microsoft
Interesting that RHEL has many more certificates, when both packages take whatever's bundled into NSS.
According to 'rpm -q --changelog ca-certificates' RHEL take their certs from "CKBI 2.60_v7.0.306 from NSS 3.91" and according to /usr/share/doc/ca-certificates/changelog.Debian.gz, Debian take theirs from "Mozilla certificate authority bundle" 2.60.
> Imagine what the CA/Browser Forum would do if they discovered that a PKIX CA had lost control of its signing keys, didn't revoke them and in fact carried on using them for 2 years without telling anyone...
Are these certificates affected? Or perhaps the CA/Browser Forum aren't aware of the scope.
I sure hope not. But I suppose only Microsoft are able to confirm whether their PKIX CA private keys are or are not affected by their various security incidents, including the Azure token leak mentioned by ggeorgovassilis.
Are you aware of what applications and services are verified by these keys? I am thinking it might be worth removing these specific root certificates if they are used only for a select number of purposes, considering that the vast majority of 'normal' websites use other CAs like DigiCert or Let's Encrypt.
No one has any business trusting Microsoft, apparently?
I’m under no delusions that an intelligence agency with ‘home team advantage’ wouldn’t already have the keys to the kingdom. If they are in the apparent habit of leaving the keys sitting around in random Cafes, the odds that other non-home team intelligence agencies have a copy increases dramatically too. Or even random miscreants.
The worst part of the story to me is —- those were not even the right keys, those were something issued to a client and scoped, but scoping check was broken. It’s unbelievably bad all around
You can still create "app registration secrets" that last for up to two years. Until recently, you could create essentially unlimited-duration secrets.
