I'm quite new to the cryptography field, and I'm trying to understand a few things:

I used binwalk on Linux to analyse Minecraft.msi, and I found multiple certificates in the .msi See below:

enter image description here

I'm wondering why there are there multiple (4 here) certificates in the .msi?

I thought that these days all software would be signed, and that we would use the root certificate store and intermediate certificate on our computer to verify that the software we install/run is signed by something we trust.

So in my understanding, only one certificate would be required in the Minecraft.msi and we verify it with our own certificate's store.

Am I wrong?

  • The Windows certificate store does not contain all intermediate CA certificates that exists for all trusted root CAs trusted by Windows. New intermediate CAs can rise every day and how should Windows get those certificates, especially if it is in an offline environment (still a valid use case)?
    – Robert
    Jul 31, 2021 at 20:50
  • You can transfer the file to a Windows computer, right-click on it, and select Properties to look at the details for the digital signature and its chain of trust back to the root certificate. Some of the certificates shown in that interface come from your computer's certificate store (especially the root), but most of them usually come form the signed file itself. Aug 1, 2021 at 17:58

1 Answer 1


What you are probably not understanding is how certificate chains work.

So generally you have the root certificate, then an intermediate CA certificate or more, and finally a leaf certificate of the entity that performs the signing. That last certificate contains the public key that actually performs verification of the signature.

Generally all the certificates, quite often including the root certificate are included in the set of certificates. The verifier then first needs to try and build a certificate chain towards a trusted certificate - usually a root certificate. The public key of the leaf certificate should only be used once the certs in the chain have been verified, validated and checked for revocation.

In principle the root certificate could be left out, but usually it is included. In principle you could pin the root certificate by e.g. storing a hash instead of the root certificate itself. The CA certificates do need to be included with the signed code, as the verification software may not perform caching, or may not have cached those yet (they are not automagically downloaded from some URL or anything like that).

Finally, it is also possible that the certificate tree uses cross signing, which means that multiple roots and CA certificates need to be included.

You must log in to answer this question.