As part of our ongoing commitment to security we are making a change to our SSL certificate chain that will require a small number of customers to take action before April 15^th, 2013. Windows Azure currently uses the GTE CyberTrust Global Root and beginning on April 15^th, 2013 will migrate to the Baltimore CyberTrust Root. The new root certificate uses a stronger key length and hashing algorithm which ensures we remain consistent with industry-wide security best practices.  If your application does not accept certificates chained to both the GTE CyberTrust Global Root and the Baltimore CyberTrust Root, please take action prior to April 15^th, 2013 to avoid certificate validation errors. While we seek to minimize the need for customers to take specific action based on changes we make to the Windows Azure platform, we believe this is an important security improvement. The Baltimore CyberTrust Root can be downloaded from https://cacert.omniroot.com/bc2025.crt.

To learn more about our commitment to security in Windows Azure please visit our Trust Center. For more information on the April 15^th, 2013 root certificate migration please see the details below.

Background

The Windows Azure platform APIs and management portal are exposed to customers over the SSL and TLS protocols, which are secured by certificates. For example, when you visit the Windows Azure Management Portal (https://manage.windowsazure.com), the “lock” icon in your browser lets you know that you are visiting the legitimate website – not the website of an impostor. The same mechanism protects all of our SSL-based services such as Windows Azure Storage and Service Bus.

Applications that call these services implement their own certificate validation checks – the equivalent of the test that your browser uses to verify the certificate before showing the “lock” icon.  The details of these checks vary per application.  These checks often include validation of the root certificate in the certificate chain against a trusted root list.  Currently, Windows Azure uses SSL/TLS certificates that chain to the GTE CyberTrust Global Root. For example, at the time of this writing, the following certificate chain secures the Windows Azure Management Portal:                  

What is Changing?

All of the SSL/TLS certificates exposed by the Windows Azure platform are being migrated to new chains rooted by the Baltimore CyberTrust Root. We are making this change to stay up to date with industry-wide security best practices for trusted root certificates. The new root certificate uses a stronger key length and hashing algorithm. The migration process will begin on April 15^th, 2013 and take several months for all services to complete the migration. We expect to continue to use the Baltimore CyberTrust Root for the foreseeable future, however, as part of our commitment to security we will continue to make changes as industry security standards and threat mitigations evolve.

 Customer Impact

The Baltimore CyberTrust Root is widely trusted by a number of operating systems including Windows, Windows Phone, Android and iOS, and by browsers such as Internet Explorer, Safari, Chrome, Firefox, and Opera. We expect that the vast majority of customers will not experience any issues due to this change. However, some customers may experience certificate validation failures if their custom applications do not include the Baltimore CyberTrust Root in their trusted root lists. Customers with such applications must modify these applications to accept both the Baltimore CyberTrust Root and the GTE CyberTrust Global Root. We advise our customers to make this change no later than April 15^th, 2013, as the majority of Windows Azure platform services will begin the migration process on that date. Customers who do not have the Baltimore CyberTrust root in their trusted root lists and do not take the prescribed action will receive certificate validation errors, which may impact the availability of their services.

As a best practice, we recommend that our customers do not hard-code trusted root lists for certificate validation. Instead, we recommend using policy-based root certificate validation that can be updated as industry standards or certificate authorities change. For many customers, the default trusted root list provided as part of your operating system or browser distribution is a reasonable mechanism. In other cases, more restrictive organization-wide policies may be implemented to meet regulatory or compliance requirements.

Additional Information

Additional information can be found in Kevin Williamson's blog post here.  If you still have questions about this change, please post a comment on this forum and we’ll respond as quickly as possible. 

-Mike

For reference, the following is a full dump of the Baltimore CyberTrust Root certificate, generated using certutil.exe -dump: