4 ms·

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 usi

by yrro 3y ago

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...

inetknght 3y ago
Have you checked if you have a Microsoft CA installed to your system?
- yrro 3y ago
  I simply assume Microsoft have already compromised my systems already. :)
- yrro 3y ago
  More seriously, on my Debian stable system: $ 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.
  - inetknght 3y ago
    And so, to back to your question: > 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.
    - yrro 3y ago
      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.
  - seabass-labrax 3y ago
    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.
    - yrro 3y ago
      Among other things, Azure services use certificates issued by those issuers.

by yrro 3y ago

inetknght 3y ago

Have you checked if you have a Microsoft CA installed to your system?

yrro 3y ago
I simply assume Microsoft have already compromised my systems already. :)
yrro 3y ago
More seriously, on my Debian stable system: $ 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.
- inetknght 3y ago
  And so, to back to your question: > 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.
  - yrro 3y ago
    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.
- seabass-labrax 3y ago
  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.
  - yrro 3y ago
    Among other things, Azure services use certificates issued by those issuers.