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):
- In the .csdef don't list the intermediate certificate under
- 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.
- 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).
- Create a virtual network in Azure and inside it create a subnet and bind the subnet to the network security group above.
- 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.