Partager via

Windows Azure Root Certificate Migration – Impact Scenarios

  • Article

 

Overview

We recently published a blog post outlining the upcoming root certificate change from the GTE CyberTrust Global Root to the Baltimore CyberTrust Root which will take effect starting April 15, 2013.  This new blog post will attempt to outline the potential impact that this will have one users in various scenarios.  The first thing to point out is that this change will have zero impact on the vast majority of Windows Azure customers or end users who are consuming services hosted in Windows Azure. Standard applications running on modern OSes will automatically trust the new certificate.  The potential impact is limited to developers who have written very specific code to do custom cert validation, or niche scenarios such as specific embedded devices, ultra secure environments, or old development frameworks and OSes.

If you have additional questions not covered by the original blog post or this one, please feel free to post your question in the forum thread and we will attempt to address it.

 

What is Changing?

Microsoft is changing from the GTE CyberTrust Global Root to the Baltimore CyberTrust Root for all public facing HTTPs services.  This specific post will only target the Windows Azure Platform scenarios.  If you need assistance with other platforms such as Office 365 please engage with their support team.

This change only affects Microsoft owned domain names and does not have any impact on custom domain names you have specified for your hosted service.  For example, if you have a hosted service at myapp.cloudapp.net and a CNAME setup for www.myapp.com, then your HTTPs certificate for https://www.myapp.com is not affected by this change and your end users’ experience will not change.  The root cert change will only affect HTTPs calls to Microsoft owned URLs such as the following:

  • *.windowsazure.com
  • *.windows.net
  • *.azure.com
  • *.microsoftonline.com
  • *.msecn.net
  • *.azurewebsites.net

 

Impacted Scenarios

The following are the scenarios which might be impacted by this root cert change, roughly ordered by the probability of impact.  Because the scope of these scenarios is very limited, and the code or configuration required to be in one of these scenarios is very deliberate, if you aren’t sure if you are impacted by any of these scenarios then most like you are not.  Also note that in all of these scenarios you will only be impacted if your code is calling into one of the Azure domains noted above.  If your code is not calling an Azure domain then you will not be impacted by any of these scenarios.

  1. Sharepoint Server.  Sharepoint uses a custom certificate store rather than the standard Windows certificate store.  Sharepoint administrators must add certificates to the Sharepoint store via the admin console or the New-SPTrustedRootAuthority Powershell cmdlet.  If your Sharepoint Server uses Windows Azure Active Directory (Access Control Service) for user authentication, or if you have modules which make HTTPs calls to Azure services such as Storage Service, then you will need to add the new Baltimore CyberTrust Root certificate.
  2. .NET applications using ServerCertificateValidationCallback.  .NET exposes the System.Net.ServicePointManager.ServerCertificateValidationCallback and in .NET 4.5 the System.Net.HttpWebRequest.ServerCertificateValidationCallback callback functions which allow developers to use custom logic to determine certificate validity rather than relying on the standard Windows certificate store.  A developer can add logic which checks for a specific subject name or thumbprint, or use logic which only allows a specific root authority such as GTE CyberTrust Global Root.  If your application uses this callback function you should make sure that it accepts both the old and new certificates.
  3. Devices with custom certificate stores.  Embedded devices such as TV set top boxes and mobile devices often ship with a limited set of root authority certificates and have no easy way to update the certificate store.  If you write code for, or manage deployments of, custom embedded or mobile devices you will want to make sure the devices trust the new Baltimore CyberTrust Root certificate.  Most modern smartphone device already include the Baltimore CyberTrust Root certificate with the notable exception being that Google included the certificate with Android 2.3 Gingerbread which was released mid-2011 (source).
  4. Highly secured environments.  Clients running in environments which are highly secured may run into issues with not having the standard root certificates installed on the OS, having outbound network traffic restricted to specific addresses, or not allowing automatic certificate updates.  System administrators may remove all certificates that are not explicitly required, and may have removed the Baltimore CyberTrust Root from the trusted root store on the OS.  Network administrators may restrict outbound network traffic which may block the standard Certificate Revocation List checks performed by Windows during the process of validating certificates.  The “Microsoft Internet Authority” intermediate cert has changed as part of this update and the CRL distribution point has changed from https://www.public-trust.com/cgi-bin/CRL/2018/cdp.crl to https://cdp1.public-trust.com/CRL/Omniroot2025.crl.
  5. Runtime Environments.  Some runtime environments such as Java use custom certificate validation mechanisms instead of the standard Windows certificate validation.  We are currently unaware of any runtime environments which do not trust the Baltimore CyberTrust Root certificate, but if you are running on a niche or older runtime environment you should check with the vendor to determine if your application will be impacted.
  6. Native applications using WINHTTP_CALLBACK_STATUS_SENDING_REQUEST.  Similar to #2 above with the ServerCertificateValidationCallback, the WINHTTP_CALLBACK_STATUS_SENDING_REQUEST notification allows native applications to implement custom certificate validation algorithms.  Usage of this notification is very rare and requires a significant amount of custom code to implement.

 

Details and Testing

To get details about the old and new certificates you can browse to the following two URLs.  The way you check the certificate will depend on your OS, but in Windows using IE you can browse to that URL and then click the lock icon near the address bar.  This will bring up the certificate where you can inspect the details and certificate chain.  You should also try connecting to these two URLs from your environment to ensure that you will not run into any issues.

Old GTE CyberTrust Global Root certificate - https://jag-db.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml

New Baltimore CyberTrust Root certificate - https://jag-sn.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml

New Baltimore CyberTrust Root certificate - https://ewew3t8qjn.database.windows.net/

 

Error Messages

If you are impacted by this certificate update then the error messages you receive will be dependent on the type of environment you are running in and which scenario you are impacted by.  You should check Windows Application event logs, CAPI2 event logs, and custom application logs.  Here is an example of an error message you may receive in the Application event logs:

An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=accesscontrol.windows.net\nIssuer Name: CN=MSIT Machine Auth CA 2, DC=redmond, DC=corp, DC=microsoft, DC=com\nThumbprint: 3562E9B2583B8E4AA74E4E6C07A0A419B11DEBAD\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority.

 

Q & A

Q: I have an HTTPs certificate for my website hosted in Azure. Will this affect me?

A:   No.  If you are using a standard HTTPs certificate which you obtained from a domain registrar to secure traffic to your custom domain name (ie. https://www.myapp.com) then this change does not affect you.  Your HTTPs certificate is chained to whatever root certificate authority your registrar is using and has nothing to do with the change that Microsoft is making for Azure specific domain names.  The only caveat to this is that if your website is utilizing Azure services such as Table or Blob storage then you might fall into the Scenario #2 if you have custom code in your application to implement the ServerCertificateValidationCallback.

 

Q: But the HTTPs certificate for my website has GTE CyberTrust Global Root as its root certificate. Does this mean I need to change my certificate?

A:   No.  Your service’s certificate is completely unrelated to the certificates for Microsoft owned domain names as listed earlier.  Your service will continue to be chained to whatever root certificate was provided to you and the end users who access your website will continue to trust the GTE CyberTrust Global Root certificate, which means they will continue to trust your certificate.

 

Q: Does this affect my service management or RDP certificates which I got from Microsoft to manage my Azure services?

A:   No.  The service management certificate (used by things like Visual Studio, Powershell, and the REST APIs) and RDP certificates are self-signed certificates which are not chained to a root authority.

 

Q: I am still not sure if I will be impacted by this change, what can I do?

A:   As mentioned in the scenarios section above, it takes a very deliberate effort to modify the default certificate validation processes which means that typically the only people who would be impacted by a change like this are the people who already have processes in place to track and mitigate these types of issues.  This means that if you aren’t sure if you are impacted by this event, then you are almost certainly not going to be impacted.  If you have questions that are not addressed here, please post them in the forum thread.

 

Q: I see the Baltimore CyberTrust Root and the GTE CyberTrust Global Root in my Trusted Root Authority certificate store. Should I remove the GTE one?

A:   No.  The GTE root certificate is still a valid root certificate and many other websites around the world will continue to use it as the root for their certificate chains.

 

Q: Do my Azure VMs already have the Baltimore CyberTrust Root in the certificate store or do I need to deploy this certificate with my service?

A:   All Azure VMs are built with the Baltimore CyberTrust Root (among many other known trusted root authority certificates).  You do not need to make any modifications to your hosted service package to include a new certificate.

 

 I would like to say thanks to Hui Zhu and Jaganathan Thangavelu for their expertise in putting together this post.

Comments

  • Anonymous
    March 20, 2013
    Thanks for the clear post on this.  I have been answering with most of these same replies to my partners.  But it is nice to have a blog post to point them too instead.

  • Anonymous
    April 01, 2013
    The URL jag-sn.accesscontrol.windows.net/.../FederationMetadata.xml still has the OLD GTE certificate. Can you please point us to a testing URL with the new certificate.

  • Anonymous
    April 01, 2013
    Thanks for the note Nik.  It looks like the jag-sn endpoint has been reverted back to the GTE certificate.  I am looking for a new URL with the Baltimore certificate and I will update this post once I have one.

  • Anonymous
    April 01, 2013
    I have updated the URL for testing the new Baltimore CyberTrust root to ewew3t8qjn.database.windows.net.

  • Anonymous
    April 02, 2013
    @Kevin, Thanks for the speedy response. We were able to validate the new Baltimore CyberTrust certificate.