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 15th, 2013. Windows Azure currently uses the GTE CyberTrust Global Root and beginning
on April 15th, 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 15th, 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
For more details, please refer to this official
Below is an extract from the referred official blog post. Highlighted statement in bold specified that both Baltimore CyberTrust Root , GTE CyberTrust Global Root needs to be in the trusted root list. So, you shouldkeep the GTE
CyberTrust Global Root.
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<sup>th</sup>, 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
Thanks for the information but I really don't know if this will affect my application. Can you provide more information about typical scenarios. Whilst the information might be clear to experts on certificates, those familiar with the global
root and the complete Azure stack, I have no idea if this will affect my application and I am concerened about a sudden loss of service.
Like many others, I use Azure to host an ASPX web application.
As far as I know I use a certificate for RDP and have one for my single role. These are just just existing Azure services I am using. Do I need to make any change and if so can you provide clear instructions how to make typical web role applications
"accept certificates chained to both the GTE CyberTrust Global Root and the Baltimore CyberTrust Root".
Is there any way we can test our application in this new environment before the switch over (so that we do not suddenly face loss of service)
I use Azure to run a web site as well as for running a Virtual Machine role. For my site and VM role I use only one cerificate I know of - the management certificate used by Windows Azure Tools to upload my code to azure via visual studio.
Is this certificate affected? Kindly spell it out for us. Apologies if this question seems trivial, I am a newcomer to the Azure family.
As a few others have mentioned, I think we need more information:
By customer, does this mean "us" as azure devOps/admin/users of the Azure Portal? or does this mean
"customers" using our applications written on top of Azure?
I realise you mention that "customers" will probably not notice any difference.. again, how can we test this? and again is this purely aimed at Azure dev/ops and not internet facing apps?
Will be good to get some clarification on this as what actual action we need to perform. For instance our end-user certificate is identified as QuoVadis Root CA 2.. so does this mean (as I cannot see the GTE CyberTrust Global Root there at all) we
are not affected?
Obviously going through to the Azure Portal, the certificate (root) IS the GTE CyberTrust Global.. so again it would be good to get clarification to the above points.
My customers use a browser to work with my application, so just to make sure, if their browsers have the
Baltimore CyberTrust registered as one of the Trusted Root Certification Authorities everything should be alright for us, right?
Thanks to everyone for the feedback and questions. We are working on a comprehensive post which will outline the major scenarios where Azure customers might be impacted. Please continue to post your questions here so we can ensure that we address
The certificate update is only being applied to Microsoft owned Azure URLs such as *.windowsazure.com, *.accesscontrol.windows.net, *.blob.core.windows.net. Your own HTTPs certificate for something like
https://www.myapp.com is not impacted, so if you are hosting a website in Azure and your customers are accessing your website using an https URL like this then you should see no issues.
The most common scenarios for impact will be the following applications which make HTTPs calls to Azure URLs such as the ones noted above:
Applications which implement a custom ServerCertificateValidationCallback callback.
A small number of older embedded or mobile devices.
A more detailed and comprehensive list will be coming soon.