• 5 min read

Windows Azure Root Certificate Migration

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…

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 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 15th, 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 15th, 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 15th, 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:

X509 Certificate:
Version: 3
Serial Number: 020000b9
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
    Algorithm Parameters:
    05 00
Issuer:
    CN=Baltimore CyberTrust Root
    OU=CyberTrust
    O=Baltimore
    C=IE
  Name Hash(sha1): c12f4576ed1559ecb05dba89bf9d8078e523d413
  Name Hash(md5): 918ad43a9475f78bb5243de886d8103c
 
NotBefore: 5/12/2000 10:46 AM
NotAfter: 5/12/2025 3:59 PM
 
Subject:
    CN=Baltimore CyberTrust Root
    OU=CyberTrust
    O=Baltimore
    C=IE
  Name Hash(sha1): c12f4576ed1559ecb05dba89bf9d8078e523d413
  Name Hash(md5): 918ad43a9475f78bb5243de886d8103c
 
Public Key Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA
    Algorithm Parameters:
    05 00
Public Key Length: 2048 bits
Public Key: UnusedBits = 0
    0000  30 82 01 0a 02 82 01 01  00 a3 04 bb 22 ab 98 3d
    0010  57 e8 26 72 9a b5 79 d4  29 e2 e1 e8 95 80 b1 b0
    0020  e3 5b 8e 2b 29 9a 64 df  a1 5d ed b0 09 05 6d db
    0030  28 2e ce 62 a2 62 fe b4  88 da 12 eb 38 eb 21 9d
    0040  c0 41 2b 01 52 7b 88 77  d3 1c 8f c7 ba b9 88 b5
    0050  6a 09 e7 73 e8 11 40 a7  d1 cc ca 62 8d 2d e5 8f
    0060  0b a6 50 d2 a8 50 c3 28  ea f5 ab 25 87 8a 9a 96
    0070  1c a9 67 b8 3f 0c d5 f7  f9 52 13 2f c2 1b d5 70
    0080  70 f0 8f c0 12 ca 06 cb  9a e1 d9 ca 33 7a 77 d6
    0090  f8 ec b9 f1 68 44 42 48  13 d2 c0 c2 a4 ae 5e 60
    00a0  fe b6 a6 05 fc b4 dd 07  59 02 d4 59 18 98 63 f5
    00b0  a5 63 e0 90 0c 7d 5d b2  06 7a f3 85 ea eb d4 03
    00c0  ae 5e 84 3e 5f ff 15 ed  69 bc f9 39 36 72 75 cf
    00d0  77 52 4d f3 c9 90 2c b9  3d e5 c9 23 53 3f 1f 24
    00e0  98 21 5c 07 99 29 bd c6  3a ec e7 6e 86 3a 6b 97
    00f0  74 63 33 bd 68 18 31 f0  78 8d 76 bf fc 9e 8e 5d
    0100  2a 86 a7 4d 90 dc 27 1a  39 02 03 01 00 01
Certificate Extensions: 3
    2.5.29.14: Flags = 0, Length = 16
    Subject Key Identifier
        e5 9d 59 30 82 47 58 cc ac fa 08 54 36 86 7b 3a b5 04 4d f0
 
    2.5.29.19: Flags = 1(Critical), Length = 8
    Basic Constraints
        Subject Type=CA
        Path Length Constraint=3
 
    2.5.29.15: Flags = 1(Critical), Length = 4
    Key Usage
        Certificate Signing, Off-line CRL Signing, CRL Signing (06)
 
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
    Algorithm Parameters:
    05 00
Signature: UnusedBits=0
    0000  a9 39 63 ea 42 24 c3 19  1d 81 e7 fc d5 3c ee b5
    0010  1e 6a 32 dc 81 fe d0 2e  38 d2 47 d2 32 b5 1d bb
    0020  5d 01 2c 44 47 cf 62 9e  8e fc f5 0f 65 a7 3d 33
    0030  d0 7a 94 30 3e af 90 ab  35 7e ee 11 10 e9 dd 18
    0040  8e ab 02 32 9a 8d 16 e3  e2 c2 92 73 88 50 f2 b7
    0050  1b bb 2e 9f f2 f0 ce b7  1f e6 64 bd 63 1a 6b 6d
    0060  70 fd 6d 4b 14 08 4e 9e  a4 c8 2e 7c 9e c8 b5 9e
    0070  9d f5 5e 3c e3 82 45 a3  f7 99 12 f4 2a a0 bf 18
    0080  7a 31 a9 d5 04 39 37 52  f8 b4 02 c0 0f a3 11 65
    0090  be 7f fd 05 b8 85 79 c0  84 5c 16 ff 70 7f 1a 48
    00a0  07 5e 75 be ee 74 01 b3  d2 4c 8e 31 68 dd ed 4f
    00b0  11 37 c6 38 7e a3 cc ec  4f 40 86 8d 25 0c e9 d6
    00c0  7c 30 bc c5 bd 0a d5 17  8a 12 6a 61 04 bd 70 61
    00d0  d4 a4 58 f9 0a 10 b8 23  13 19 f6 76 3f 79 b6 29
    00e0  29 da eb 17 10 a4 e3 30  d7 2d fd 64 f7 bd 03 84
    00f0  25 27 4f bb dd a0 05 42  68 51 6f e4 8e 5d 0c 85
Signature matches Public Key
Root Certificate: Subject matches Issuer
Key Id Hash(rfc-sha1): e5 9d 59 30 82 47 58 cc ac fa 08 54
                       36 86 7b 3a b5 04 4d f0
Key Id Hash(sha1):     30 a4 e6 4f de 76 8a fc ed 5a 90 84
                       28 30 46 79 2c 29 15 70
Key Id Hash(md5):      68 cb 42 b0 35 ea 77 3e 52 ef 50 ec
                       f5 0e c5 29
Key Id Hash(sha256):   a6 7f e2 a9 af 96 7c b5 bf fd c9 eb
                       da 8f 1a b5 ea bc a2 54 f1 03 96 52
                       77 fd 4b a3 3e 27 a1 87
Cert Hash(md5):        ac b6 94 a5 9c 17 e0 d7 91 52 9b b1
                       97 06 a6 e4
Cert Hash(sha1):       d4 de 20 d0 5e 66 fc 53 fe 1a 50 88
                       2c 78 db 28 52 ca e4 74
Cert Hash(sha256):     16 af 57 a9 f6 76 b0 ab 12 60 95 aa
                       5e ba de f2 2a b3 11 19 d6 44 ac 95
                       cd 4b 93 db f3 f2 6a eb
Signature Hash:        ce 0e 65 8a a3 e8 47 e4 67 a1 47 b3
                       04 91 91 09 3d 05 5e 6f