Windows Azure Root Certificate Migration
Posted on
5 min read
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 |