1

According to this answer IIS can use Authority Information Access certificate extension to retrieve missing issuer certificate.

Here's the scenario. There's an IIS installation with an HTTPs endpoint which has an SSL certificate. Normally the IIS owner must also install all the intermediate certificates into the local "Intermediate Authorities" ("CA") store so that when a client connects the server can send all the chain except the root certificate. However IIS owner may forget to install the intermediate certificate. Then according to that answer IIS will use AIA and retrieve the intermediate certificate and continue serving it to all clients.

Looks like this is the default behavior and I cannot find how it can be changed.

Can I prohibit IIS from fetching intermediate certificates? Are there any settings for that?

Community
  • 1
sharptooth
  • 2,739
  • 4
  • 32
  • 40
  • why do you want this? Looking at your related questions, they doesn't make any sense for me. – Crypt32 Mar 04 '16 at 11:57
  • @CryptoGuy I want this to have reproducible behavior. The current guess is that it all worked for years even without the intermediate installed because IIS used AIA and retrieved it "for convenience". Then something happened and IIS no longer could get the intermediate and the clients started failing to validate the site certificate. So I want to disable this "AIA fetch" at least for testing purposes. – sharptooth Mar 04 '16 at 13:04
  • @CryptoGuy I found a way which is suitable for test purposes and added it as an answer. – sharptooth Mar 22 '16 at 10:14

1 Answers1

1

Looks like there's nothing like detailed documentation for this behavior but a little amount of blackbox testing shows that this behavior is on at all times and can only be suppressed by blocking the connection between the server and the CA infrastructure with a firewall rule. Here's how it can be done for Azure Web Roles with osFamily=3 (Windows Server 2012):

  1. In the .csdef don't list the intermediate certificate under <Certificates> element.
  2. Deduce on which IP addresses range the CA infrastructure responds. To do this inspect your certificate and find some AIA or OCSP URI in the certificate properties, then use ping to find the IP address.
  3. Create a network security group in Azure with a firewall rule allowing inbound connections from any addresses (so that you can access your service and validate SSL functioning) and disallowing outbound connections to the IP range of the CA (that's the key to the experiment).
  4. Create a virtual network in Azure and inside it create a subnet and bind the subnet to the network security group above.
  5. Change you .cscfg by adding a <NetworkConfiguration> instructing to deploy the service into the previously created virtual network and (the key point) to deploy your web role into the previously created subnet. Set instance count to 1 for easier testing.

Now you're ready. Deploy your service and observe third-party tools reporting that the intermediate certificate is not being served. Change the firewall rule to "allow" and reimage the role instance - once it restarts the third party tools report that the intermediate is now served. Change the rule to "deny" and reimage the instance - the intermediate is no longer served.

This blackbox test proves that certificate installation process can make use of CA online infrastructure. If CA online infrastructure is inaccessible then the intermediate certificates will not be fetched online. It's unclear if it's part of IIS or part of Windows but that perhaps doesn't matter.

This is why Azure cloud services should always have all the intermediate certificates listed in the .csdef to ensure that they are deployed onto the instance no matter if CA infrastructure is accessible or not at the moment of deployment.

sharptooth
  • 2,739
  • 4
  • 32
  • 40