Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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).

share|improve this question
    
Are you sure it wasn't there before you started? Many operating systems ship with pretty complete PKI hierarchies. – kce Jun 3 '14 at 16:39
    
@kce - it definitely wasn't there. That's why I built a brand new clean VM just to check my sanity. – Kev Jun 3 '14 at 16:44

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.

share|improve this answer
1  
Can you see the update to my question. You're correct about the .pfx file. However see the second part of my update. – Kev Jun 3 '14 at 18:25
    
I suspect that's an undocumented "feature" for expert users – HBruijn Jun 3 '14 at 20:40

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.

share|improve this answer
    
Thanks for the answer, the plot thickens :) – Kev Aug 21 '15 at 12:50

It all depends on the format of the certificate you received from your Certificate Authority, GlobalSign, Comodo, Symantec (formerly VeriSign). If you received the Certificate in the PKCS#7 format, it will include the root and intermediates. If you received the cert in the x.509, it does not normally include the root and intermediates, therefore you will need to grab those files from your Cert Authority Site. I've installed certs in Windows IIS 6,7, and 8 and from what I know, the recommended format is PKCS#7. I did not use openssl. The root and intermediate is automatically installed when you go through the wizard.

You can look in the cert file you received by changing it to a .txt file. You will normally see ===Begin Certificate=== and ====End Certificate===. If you see 3 or 4 of those, then the root and/or intermediates are bundled in that cert file. If you see only one, then you will need to get the root and intermediate from your Cert Authority's site.

share|improve this answer
    
Sorry, the recommended format is PKCS#7 for Windows IIS, but you were to install on something like Oracle, the x.509 would be use because you will need to install the root and intermediates separately and maybe installed in a certain order. – Hunny Aug 27 '15 at 18:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.