1

As many of you know Addtrust certificate https://crt.sh/?id=1 expired 30 May 2020 as well as many other intermediate certs and now we have to update certs on many servers to either root cert https://crt.sh/?id=1199354 or using another chain with above mentioned root (same private key) as intermediate https://crt.sh/?id=1282303295 signed with another root https://crt.sh/?id=331986. This is all good according to RFC 4158. The same BTW about ECC keys.

But what I do not understand is how is this possible that expired root Addtrust key https://crt.sh/?id=1 has one still valid certificate https://crt.sh/?id=162879063 for code signing from Microsoft? You can click on "Subject Public Key Info:" to find all other keys with same private/public key pair. So, can we use it for web or it is only for binaries signing and Microsoft Code Verification Root SHA1 is not trusted for web https://crt.sh/?id=162461728 (actually if you will download it http://www.microsoft.com/pki/certs/MicrosoftCodeVerifRoot.crt Windows will say it is not trusted)? Should not it be revoked???

Валерий Заподовников
  • 51
  • 4
  • Yes #162879063 has EKU 'Code Signing' which means certs under it would not be trusted for SSL/TLS including web, even aside from the sha1 signature (which was acceptable in 2013 but not after 2015-7) and the fact #162461728 isn't trusted for validations done by programs like browsers (which you could change) -- but it still can be trusted for the code validation done by Windows itself. The dialog box message about 'not trusted' only means it isn't currently in the store used by programs, not that it is compromised, invalid, or otherwise revocable -- though it _could_ be. – dave_thompson_085 Mar 20 '22 at 07:13

2 Answers2

0

My understanding is that the Microsoft Code Verification Root (MCVR) is just used by the Windows kernel to decide whether a .sys driver file should be allowed to be loaded into the kernel. I wrote a lot about this. I don't think it is useful for websites, because the MCVR does not appear to be in the "Trusted Root Certification Authorities" list on my Windows 10 computer. You could check some other root certificate lists to get more verification of this.

David Grayson
  • 141
  • 4
  • Well, yes, I very much doubt you can use code signing cert (because of the special bits in ASN.1), but it is technically valid, and this is a problem IMHO. – Валерий Заподовников Jul 13 '20 at 19:53
  • Yes. https://crt.sh/?d=162461728 is not trusted as root. Okay... I edited my question. – Валерий Заподовников Jul 13 '20 at 20:09
  • I'm not sure what "technically valid" means to you. If there is a system checking cryptographic signatures somewhere and you don't like the conditions it is using, you can ask the people in charge to change the conditions (i.e. so it checks the validity dates of all certs in the chain of trust). Same for any standards documents descrbing how signatures should be checked. Maybe they are already doing the checks you want; I'm not sure. – David Grayson Jul 13 '20 at 20:58
0

I'm not sure if this is what you are after her, but: There are two models of how validity is inherited in a trust chain:

a) nested. An intermediate cert cannot be valid longer that its signing root cert, a final cert cannot be valid longer than its signing intermediate, etc. Consequently, all derived certs are valid at most as long as their root cert.

b) Not nested. A root cert valid now, can now sign an intermediate as being valid until next year, and that intermediate can (in about a year) sign a leaf cert that is valid from then until in two years. This way, the leaf cert validity depends a lot less on the root cert.

We are most used to model a) which is e.g. used with web security. In signing (e.g., code signing) we may use model b). This is not even new and corresponds to real-life signatures. You driving license does not expire prematurely because the issuing DMV worker gets retired. You don't loose your real estate because the notary public involved in the ales contract dies or the government granting them notary status gets reelected.

Hagen von Eitzen
  • 1,098
  • 8
  • 19
  • "An intermediate cert cannot be valid longer that [than] its signing root cert" That is absolutely wrong. See RFC 4158, if intermediate's public key (root expired or revoked) is also a trusted root certificate's public key than it is a valid chain. Also, and that also happened HERE, if both intermediate and root are expired or revoked we should try to built a trusted chain using keys in our key storage, both intermediate(s) and trusted root(s), if the chain is built up, all is good. – Валерий Заподовников Jul 13 '20 at 19:48