Windows 2012R2 seems to automatically download and install intermediate root certificates

Whilst preparing a new Windows 2012R2 server for production I needed to install a (GlobalSign Domain) SSL certificate for the website powering our application. I did this by generating a certificate request, submitting to GlobalSign, then completing the request using the PEM formatted issued certificate.

Normally I would also have to go and grab the relevant GlobalSign DomainSSL intermediate certificate and install that as well. However the relevant intermediate certificate seemed to get automatically installed as soon I configured my IIS site bindings.

I know for a fact that the intermediate certificate wasn't present in the local computer certificate store under:

Intermediate Certification Authorities -> Certificates

...in the Certificates MMC snap-in.

I checked first and then when it magically appeared I ran through my SSL certificate .pfx import and IIS binding config on a virgin 2012R2 server and confirmed that the intermediate certificate had indeed automatically been installed.

I don't remember this happening with Windows 2008/R2. Is this a new feature, or something that is turned on by default that wasn't previously?

Update:

HBruijn's answer explains away the appearance of the intermediate certificate on my second "virgin" server mentioned above. I did indeed export the certificate as a .pfx file and imported it on the other server. Checking with the openssl tool reveals the presence of the root and intermediate certs.

However... on the original server I completed a pending certificate request and only loaded the "PEM" formatted certificate. This does not include the root/intermediate certificates (I checked with openssl).

A ".pfx" file is a PKCS#12 archive: an archive file format for storing many cryptography objects as a single file. It is commonly used to [snip] bundle a X.509 certificate and all the members of a chain of trust.

You imported the intermediate certificate together with SSL certificate.

I've seen this happen in the past as well, and we ran into some trouble causing me to look at this. My Windows 7 (SP1, Enterprise) system does the same. And digging around with Wireshark and Sysinternals's Process Monitor reveals the following.

One of my certificate stores has a COMODO-signed certificate for which a cert up the chain (b9b4c7a...) is unavailable in any of my certificate stores. But the certificate has an 'Authority Information Access' property, which contains the URL http://crt.comodoca.com/COMODOHigh-AssuranceSecureServerCA.crt.

Opening this certificate (through mmc.exe's Certificates snap-in) to show the standard Windows 'Certificate' dialog, triggers a download of the above URL, and the resulting b9b4c7a... certificate is put in the Intermediate Certification Authorities store for the current user.

And it is also cached in the c:\users\<currentUser>\C:\Users\mklooste\AppData\LocalLow\Microsoft\CryptnetUrlCache, with an entry in both the Metadata and the Content folder.

If I now repeat the same action (after deleting the certificate from the current users' Intermediate Certification Authorities store) then it gets restored again, but this time it is not downloaded from COMODO but copied from the CryptnewUrlCache.

I could not find any documentation on this feature from Microsoft. However, they seem to follow RFC 5280, section 4.2.2.1, "Authority Information Access", which says:

The referenced CA issuers description is intended to aid certificate users in the selection of a certification path that terminates at a point trusted by the certificate user.