I'm working on a project which requires certificate verification for executable files. I have created my own trusted root certificate store, and used openssl to perform verification.
However, when I decided to inspect how windows performs certificate verification, i noticed something and it didn't make sense to me. Here is the issue:
I have an executable file, lets call it test.exe. I also have the trusted certificate store that is provided with windows.
Here is the screenshot of the store, before i right click to the file and go to the properties/digital signatures tab to inspect if the certificate is valid or not. It contains 26 Trusted Root Certificates and 3 Intermediate Certificates.
Trusted Root Certificates
Now, when i go to the properties/digital signatures tab, and inspect the signature, it says the certificate is valid and trusted.
After we inspect this certificate, Trusted Root Certificates and Intermediate Certificates has one more certificate added to each. They contain 27 and 4 certificates, respectively. Here is the screenshot for the store:
Windows cert verifier tool downloaded 2 certificates (1 root 1 intermediate) by looking the original cerfificate's AIA (Authority Information Access) field, and added both of them to the trust store. What didn't make sense to me was, how did the cert verifier tool decide whether or not it can trust the root certificate (DigiCert Assured ID Root CA) that it just downloaded from AIA field? Because, it seems to me that the verifier trusted the new root certificate that the system doesn't have in it's trusted certificate store. How can this process be explained?
