Все сервисы 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 and iOS. Его признают IE, Safari, Chrome, Firefox, and 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 апреля.
Автор: Gonzalo
