Windows Azure: Microsoft is changing the root certification certificate

All Windows Azure services available over SSL today use certificate chains based on the same root certificate: GTE CyberTrust Global Root . Microsoft decided to change it to a more reliable Baltimore CyberTrust Root (sha1 instead of md5 and 2048 bits of the public key instead of 1024). The migration will start on April 15, 2013 and last for several months. All Azure service SSL / TSL certificates will be replaced.

Most users of the platform and applications hosted in it will not notice any changes: the “new” Baltimore CyberTrust Root is far from new and is present in the lists of root certificates of many OS including Windows, Windows Phone, Android and iOS. It is recognized by IE, Safari, Chrome, Firefox and Opera. The minority is recommended to have time to take action before April 15.

What is a root certificate?

The Windows Azure API and the management portal are accessible via SSL and TSL secure certificates. If you log in to the portal and get to the certificate information, you can see the following:


')
This means that the connection is protected by the Microsoft Secure Server Authority , which is signed by the Microsoft Internet Authority certificate, the validity of which, in turn, is confirmed by the GTE CyberTrust Global Root .

GTE CyberTrust Global Root - root and self-signed . There is no one to vouch for him, but the system trusts him, since he has been added to the list of root certificates. The browser trusts manage.windowsazure.com only because the whole chain is signed by one of the few root certificates known to it.

What happens if this chain changes its root on April 15?

At best, you will not notice anything - the new root certificate will be as well known to your system as the old one (that is, it is already on the trusted list), and everything will continue to work as before.

At worst - if your security policy prohibits SSL connections with invalid certificates and the Baltimore CyberTrust Root is not registered as root - your browser will not allow you to the portal (and all other sites signed by them).

In the same way, certificates will change for all Azure services located on * .windowsazure.com, * .accesscontrol.windows.net, * .core.windows.net, etc. This means that if you have an application that directly works with one of them (for example, uses blob storage or service bus), then on April 15 it will begin to encounter new SSL certificates and, in some cases, may not be ready for such turn of events.

Who will it touch?

1. The web application is hosted in Azure and is available to end users via SSL at an address like https: //*.azurewebsites.net or https: //*.cloudapp.net. - From April 15, users without a new root certificate may start receiving frightening messages from the browser about security threats.
2. The application / service / agent is installed on a virtual machine (Azure VM Role), uses azure storage or another Azure service, and Baltimore CyberTrust Root is not in the list of root certificates of this virtual machine. - C April 15, the service may lose performance.
3. SharePoint Server that uses Azure services (for example, ACS (* .accesscontrol.windows.net)) and does not have a “Trust Relationship” for Baltimore CyberTrust Root . - From April 15, SharePoint will cease to connect to them and will start to fall asleep to your EventLog with error messages

   "The following is the case of the following certificate has been:

4. Your application uses a non-standard certificate verification system (for example, for .net: the application implements its own ServerCertificateValidationCallback). - Depending on the validation logic, it may stop working.

What to do in this case?

1. If this is a regular web site, then it can be assumed that the number of users who do not have Baltimore CyberTrust Root is vanishingly small. But maybe they should be warned and give a link to a new certificate: cacert.omniroot.com/bc2025.crt .
2. Ensure that Baltimore CyberTrust Root is installed on all virtual machine instances.
3. Create a “Trust Relationship” with the Baltimore CyberTrust Root .
4. Check the logic.

Who will it not touch?

1. Web applications that are hosted in Azure and are available to end users at www.myapp.com addresses (this means that the application uses your own certificate, which will not change at all).
2. Applications that are hosted in Azure as the Cloud Service are written in .net and use the standard .net library to access resources (the platform will take care of everything).
3. Applications not using SSL.

Well, of course, the control, user, and all other certificate types loaded into Azure will not automatically change until April 15.