Все сервисы Windows Azure, доступные по SSL сегодня, используют цепи сертификатов, основанные на одном корневом сертификате: GTE CyberTrust Global Root. Майкрософт решила поменять его на более надежный Baltimore CyberTrust Root (sha1 вместо md5 и 2048 бит открытого ключа взамен 1024). Миграция начнется 15 апреля 2013 и продлится несколько месяцев. Будут заменены все сервисные SSL/TSL сертификаты Azure.
Большинство пользователей платформы и хостящихся в ней приложений не заметят никаких изменений: «новый» Baltimore CyberTrust Root уже далеко не новый и присутствует в списках корневых сертификатов многих OS включая Windows, Windows Phone, Android и iOS. Его признают IE, Safari, Chrome, Firefox и Opera. Меньшинству же рекомендуется успеть принять меры до 15 апреля.
Windows Azure API и управляющий портал доступны по защищенным сертификатами протоколам SSL и TSL. Если залогиниться на портал и добраться до информации о сертификате, то можно увидеть следующее:
Это означает, что соединение защищено Microsoft Secure Server Authority, который подписан сертификатом Microsoft Internet Authority, достоверность которого в свою очередь подтверждена GTE CyberTrust Global Root.
GTE CyberTrust Global Root – корневой и самоподписанный. За него некому поручиться, но система доверяет ему, так как он добавлен в список корневых сертификатов. Браузер доверяет manage.windowsazure.com только потому, что вся цепь подписана одним из немногих известных ей корневых сертификатов.
В лучшем случае вы ничего не заметите — новый корневой сертификат будет так же хорошо известен вашей системе, как и старый (т.е. он уже есть в списке доверенных), и всё будет продолжать работать по-прежнему.
В худшем – если ваша политика безопасности запрещает SSL соединения с недостоверными сертификатами и Baltimore CyberTrust Root не зарегистрирован как корневой – ваш браузер не пустит вас на портал (и на все остальные сайты подписанные им).
Таким же образом сертификаты изменятся у всех сервисов Azure, расположенных на *.windowsazure.com, *.accesscontrol.windows.net, *.core.windows.net и т.п. Это значит, что если у вас есть приложение, которое напрямую работает с одним из них (например, использует blob storage или service bus), то 15 апреля оно начнет сталкиваться с новыми SSL сертификатами и, в некоторых случаях, может оказаться не готово к такому повороту событий.
Ну и конечно автоматически не будут меняться управляющие, пользовательские и все остальные типы сертификатов, загруженные в Azure до 15 апреля.
Большинство пользователей платформы и хостящихся в ней приложений не заметят никаких изменений: «новый» Baltimore CyberTrust Root уже далеко не новый и присутствует в списках корневых сертификатов многих OS включая Windows, Windows Phone, Android и iOS. Его признают IE, Safari, Chrome, Firefox и Opera. Меньшинству же рекомендуется успеть принять меры до 15 апреля.
Что такое корневой сертификат?
Windows Azure API и управляющий портал доступны по защищенным сертификатами протоколам SSL и TSL. Если залогиниться на портал и добраться до информации о сертификате, то можно увидеть следующее:
Это означает, что соединение защищено Microsoft Secure Server Authority, который подписан сертификатом Microsoft Internet Authority, достоверность которого в свою очередь подтверждена GTE CyberTrust Global Root.
GTE CyberTrust Global Root – корневой и самоподписанный. За него некому поручиться, но система доверяет ему, так как он добавлен в список корневых сертификатов. Браузер доверяет manage.windowsazure.com только потому, что вся цепь подписана одним из немногих известных ей корневых сертификатов.
Что произойдет, если 15 апреля у этой цепи поменяется корень?
В лучшем случае вы ничего не заметите — новый корневой сертификат будет так же хорошо известен вашей системе, как и старый (т.е. он уже есть в списке доверенных), и всё будет продолжать работать по-прежнему.
В худшем – если ваша политика безопасности запрещает SSL соединения с недостоверными сертификатами и Baltimore CyberTrust Root не зарегистрирован как корневой – ваш браузер не пустит вас на портал (и на все остальные сайты подписанные им).
Таким же образом сертификаты изменятся у всех сервисов Azure, расположенных на *.windowsazure.com, *.accesscontrol.windows.net, *.core.windows.net и т.п. Это значит, что если у вас есть приложение, которое напрямую работает с одним из них (например, использует blob storage или service bus), то 15 апреля оно начнет сталкиваться с новыми SSL сертификатами и, в некоторых случаях, может оказаться не готово к такому повороту событий.
Кого это коснётся?
- Веб приложение хостится в Azure и доступно конечным пользователям по SSL по адресу типа https://*.azurewebsites.net или https://*.cloudapp.net. – с 15 апреля пользователи без нового корневого сертификата могут начать получать пугающие сообщения браузера об угрозах безопасности.
- Приложение/сервис/агент установлен на виртуальной машине (Azure VM Role), пользуется azure storage или другим Azure сервисом, а в списке корневых сертификатов этой виртуалки отсутствует Baltimore CyberTrust Root. – C 15 апреля сервис может потерять работоспособность.
- SharePoint Server потребляющий Azure сервисы (например, ACS (*.accesscontrol.windows.net)) и не имеющий «Trust Relationship» для Baltimore CyberTrust Root. – С 15 апреля SharePoint перестанет коннектиться к ним и начнет засыпать ваш EventLog сообщениями об ошибке вида
«An operation failed because the following certificate has validation errors:… The root of the certificate chain is not a trusted root authority»
- Ваше приложение пользуется нестандартной системой проверки сертификатов (например, для .net: приложение реализует свой собственный ServerCertificateValidationCallback). – В зависимости от логики проверки, оно может перестать работать.
Что делать в таком случае?
- Если это обычный веб сайт, то можно предположить, что количество пользователей, у которых нет Baltimore CyberTrust Root, исчезающе мало. Но возможно их стоит предупредить и дать ссылку на новый сертификат: cacert.omniroot.com/bc2025.crt.
- Убедиться, что Baltimore CyberTrust Root установлен на все экземпляры виртуальной машины.
- Создать «Trust Relationship» с Baltimore CyberTrust Root.
- Проверить логику.
Кого это не коснется?
- Веб приложения, которые хостятся в Azure и доступны конечным пользователям по адресам типа www.myapp.com (это значит, что приложение использует ваш собственный сертификат, который никак не изменится).
- Приложения, которые хостятся в Azure как Cloud Service, написаны на .net и пользуются стандартной .net библиотекой для доступа к ресурсам (платформа сама обо всём позаботится).
- Приложения не использующие SSL.
Ну и конечно автоматически не будут меняться управляющие, пользовательские и все остальные типы сертификатов, загруженные в Azure до 15 апреля.