You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason will be displayed to describe this comment to others. Learn more.
The list of CA certificates from https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFTCSV is incomplete, it doesn't contain the intermediate certificates included in the Windows truststore (for example "Sectigo Public Code Signing CA R36", sha256 fingerprint 7FB0F58D71130ABE724969F1CDC9B6A8D3274DA18D059229B009A5B9B5557445).
The reason will be displayed to describe this comment to others. Learn more.
Isn't code_signing_ca.pem used for verifying signatures? If so including the intermediate certificates will ensure the verification result is consistent with the verification performed by Windows.
The reason will be displayed to describe this comment to others. Learn more.
Not really. The verifier only needs the trusted root CA; the valid signature should include all other necessary certificates. This approach underpins both PKCS#7 and Authenticode. The primary advantage of using X.509 is that the verifier needs to maintain only trusted roots, not an extensive list of all intermediate certificates.
The reason will be displayed to describe this comment to others. Learn more.
Hum I thought Windows had a list a intermediate CA certificates but I was wrong. The Windows certificate store adds the intermediate certificates automatically as it discovers them. Windows manages to validate signatures with missing intermediate certificates by fetching the parent certificates using the URL from the authorityInfoAccess field (1.3.6.1.5.5.7.1.1) of the certificate. So you're right, only the root CA are really required, the intermediate ones can be discovered dynamically if needed.
e4d471bThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The list of CA certificates from https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFTCSV is incomplete, it doesn't contain the intermediate certificates included in the Windows truststore (for example "Sectigo Public Code Signing CA R36", sha256 fingerprint 7FB0F58D71130ABE724969F1CDC9B6A8D3274DA18D059229B009A5B9B5557445).
The full list of root and intermediate CA can be retrieved by decade:
https://ccadb.my.salesforce-sites.com/ccadb/AllCertificatePEMsCSVFormat?NotBeforeDecade=2020
https://ccadb.my.salesforce-sites.com/ccadb/AllCertificatePEMsCSVFormat?NotBeforeDecade=2010
https://ccadb.my.salesforce-sites.com/ccadb/AllCertificatePEMsCSVFormat?NotBeforeDecade=2000
The list is huge, it has to be filtered to keep only the valid code signing certificates.
e4d471bThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why should it?
e4d471bThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't code_signing_ca.pem used for verifying signatures? If so including the intermediate certificates will ensure the verification result is consistent with the verification performed by Windows.
e4d471bThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. The verifier only needs the trusted root CA; the valid signature should include all other necessary certificates. This approach underpins both PKCS#7 and Authenticode. The primary advantage of using X.509 is that the verifier needs to maintain only trusted roots, not an extensive list of all intermediate certificates.
e4d471bThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum I thought Windows had a list a intermediate CA certificates but I was wrong. The Windows certificate store adds the intermediate certificates automatically as it discovers them. Windows manages to validate signatures with missing intermediate certificates by fetching the parent certificates using the URL from the authorityInfoAccess field (1.3.6.1.5.5.7.1.1) of the certificate. So you're right, only the root CA are really required, the intermediate ones can be discovered dynamically if needed.