Изменения TLS-сертификатов Azure
Внимание
Эта статья была опубликована параллельно с изменением сертификата TLS, изменения в нее не вносятся. Актуальные сведения о центрах сертификации см. в разделе Сведения о центрах сертификации Azure.
Корпорация Майкрософт использует сертификаты TLS из набора корневых центров сертификации (ЦС), которые соответствуют базовым требованиям для центра сертификации и браузера. Все конечные точки TLS/SSL Azure содержат сертификаты, связанные с корневыми ЦС, которые указаны в этой статье. Реализация перехода для конечных точек Azure началась в августе 2020 г.; для некоторых служб обновление завершается в 2022 году. Все новые конечные точки TLS/SSL Azure содержат обновленные сертификаты, связанные с новыми корневыми ЦС.
Это изменение влияет на все службы Azure. Ниже приведены сведения о некоторых службах.
- Службы Microsoft Entra ID (Microsoft Entra ID) начали этот переход 7 июля 2020 года.
- Последние сведения об изменениях сертификата TLS для служб Интернета вещей Azure см. в этой записи блога Azure IoT.
- Центр Интернета вещей Azure начал этот переход в феврале 2023 года с ожидаемым завершением в октябре 2023 года.
- Azure IoT Central начнет этот переход в июле 2023 года.
- Центр Интернета вещей Azure служба подготовки устройств начнется в январе 2024 года.
- Для Azure Cosmos DB этот переход начался в июле 2022 года, и мы планируем завершить его в октябре 2022 года.
- Дополнительные сведения об изменениях сертификатов TLS службы хранилища Azure можно найти в этой записи блога службы хранилища Azure.
- Для Кэша Azure для Redis процесс отказа от сертификатов TLS, выпущенных корневым ЦС Baltimore CyberTrust, начался в мае 2022 года, как описано в этой статье.
- Для Службы метаданных экземпляров Azure завершение было запланировано на май 2022 года, как объясняется в этой записи в блоге о руководстве и управлении Azure.
Что изменилось?
До реализации соответствующих изменений большинство TLS-сертификатов, используемых службами Azure, были связаны со следующими корневыми ЦС:
Общее имя ЦС | Отпечаток (SHA1) |
---|---|
Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
После изменения TLS-сертификаты, используемые службами Azure, будут связаны с одним из следующих корневых ЦС:
Общее имя ЦС | Отпечаток (SHA1) |
---|---|
DigiCert Global Root G2 | df3c24f9bfd666761b268073fe06d1cc8d4f82a4 |
DigiCert Global Root CA | a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436 |
Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
D-TRUST Root Class 3 CA 2 2009 | 58e8abb0361533fb80f79b1b6d29d3ff8d5f00f0 |
Microsoft RSA Root Certificate Authority 2017 | 73a5e64a3bff8316ff0edccc618a906e4eae4d74 |
Microsoft ECC Root Certificate Authority 2017 | 999a64c37ff47d9fab95f14769891460eec4c3c5 |
Затронуто ли мое приложение?
Если в приложении явным образом указывается список допустимых ЦС, скорее всего, изменение его затронуло. Такой подход называется привязкой сертификатов. Дополнительные сведения о том, как оценить степень влияния на свои службы и определить дальнейшие действия, см. в статье сообщества Microsoft Tech Community об изменениях TLS для службы хранилища Azure.
Чтобы определить, повлияло ли изменение на ваше приложение, воспользуйтесь следующими методами:
Выполните в исходном коде поиск отпечатка, общего имени и других свойств сертификатов для всех центров сертификации Microsoft IT TLS CA, список которых можно найти в репозитории PKI Майкрософт. Наличие совпадений при поиске будет означать, что изменение затронет ваше приложение. Чтобы решить эту проблему, обновите исходный код, включив данные о новых ЦС. Рекомендуем обеспечить возможность быстрого добавления или изменения данных о ЦС. Отраслевые нормы требуют замены сертификатов ЦС в течение семи дней с момента изменения, поэтому клиентам, которые пользуются привязкой сертификатов, необходимо сделать это как можно скорее.
Если ваше приложение интегрируется с API-интерфейсами Azure или другими службами Azure и вы не уверены, использует ли оно привязку сертификатов, обратитесь к поставщику приложения.
Для разных операционных систем и сред выполнения на разных языках, которые обмениваются данными со службами Azure, может потребоваться выполнить дополнительные действия, чтобы правильно построить цепочку сертификатов с такими новыми корнями:
- Linux: многие дистрибутивы требуют добавления ЦС в /etc/ssl/certs. Дополнительные инструкции см. в документации по конкретному дистрибутиву.
- Java: убедитесь, что хранилище ключей Java содержит перечисленные выше ЦС.
- Windows, работающих в отключенных средах: системам, работающим в отключенных средах, потребуется добавить новые корни в хранилище доверенных корневых центров сертификации и промежуточные элементы, добавленные в хранилище промежуточных центров сертификации.
- Android: ознакомьтесь с документацией по устройству и версии Android.
- Другие аппаратные устройства, особенно IoT: обратитесь к производителю устройств.
Если у вас есть среда, в которой установлены правила брандмауэра, чтобы разрешить исходящие вызовы только для определенных списков отзыва сертификатов (CRL) и (или) расположений проверки состояния онлайн-сертификатов (OCSP), необходимо разрешить следующие URL-адреса CRL и OCSP. Полный список URL-адресов CRL и OCSP, используемых в Azure, см. в статье сведений о ЦС Azure.
- http://crl3.digicert.com
- http://crl4.digicert.com
- http://ocsp.digicert.com
- http://crl.microsoft.com
- http://oneocsp.microsoft.com
- http://ocsp.msocsp.com
Следующие шаги
Если у вас есть вопросы, свяжитесь с нашей службой поддержки.