Azure TLS 証明書の変更
重要
この記事は TLS 証明書の変更と同時に公開されたものであり、更新されていません。 CA に関する最新情報については、「Azure 証明機関の詳細」を参照してください。
Microsoft では、CA/ブラウザー フォーラムベースライン要件に準拠するルート証明機関 (CA) のセットの TLS 証明書を使用しています。 すべての Azure TLS/SSL エンドポイントには、この記事に記載されているルート CA にチェーンする証明書が含まれています。 Azure エンドポイントへの変更は 2020 年 8 月に移行が開始され、一部のサービスの更新は 2022 年に完了します。 新しく作成されるすべての Azure TLS/SSL エンドポイントには、新しいルート CA にチェーンする更新された証明書が含まれています。
すべての Azure サービスがこの変更の影響を受けます。 一部のサービスの詳細を次に示します。
- Microsoft Entra ID (Microsoft Entra ID) サービスは、2020 年 7 月 7 日にこの移行を開始しました。
- Azure IoT サービスの TLS 証明書の変更に関する最新情報については、こちらの Azure IoT ブログ投稿を参照してください。
- Azure IoT Hub では、この移行は 2023 年 2 月に開始され、2023 年 10 月に完了する予定です。
- Azure IoT Central では、この移行は 2023 年 7 月に開始されます。
- Azure IoT Hub Device Provisioning Service では、この移行は 2024 年 1 月に開始されます。
- Azure Cosmos DB では、この移行は 2022 年 7 月に開始され、2022 年 10 月に完了する予定です。
- Azure Storage の TLS 証明書での変更に関する詳細は、こちらの Azure Storage ブログ記事を参照してください。
- Azure Cache for Redis は、Azure Cache for Redis の記事に記載されているように、2022 年 5 月以降に、Baltimore CyberTrust ルートによって発行された TLS 証明書から移行します。
- Azure Instance Metadata Service では、こちらの Azure ガバナンスと管理に関するブログ記事に記載されているように、2022 年 5 月に完了する予定です。
変更箇所
変更前、Azure サービスで使用されている TLS 証明書のほとんどは、次のルート CA にチェーンされています。
| CA の共通名 | サムプリント (SHA1) |
|---|---|
| Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
変更後、Azure サービスによって使用される TLS 証明書は、次のいずれかのルート CA にチェーンされるようになります。
| CA の共通名 | サムプリント (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 |
アプリケーションへの影響
アプリケーションで、受け入れ可能な CA の一覧が明示的に指定されている場合は、アプリケーションに影響があった可能性があります。 この方法は、証明書のピン留めと呼ばれます。 サービスが影響を受けたかどうかを判断する方法に関する詳細と次の手順については、Azure Storage の TLS の変更に関する Microsoft Tech Community の記事を参照してください。
アプリケーションが影響を受けたかどうかを検出するいくつかの方法を次に示します。
ソース コードで、Microsoft PKI リポジトリ内の任意の Microsoft IT TLS CA のサムプリント、共通名、および他の証明書プロパティを検索します。 一致するものがある場合、アプリケーションは影響を受けます。 この問題を解決するには、新しい CA を含むようにソース コードを更新します。 ベスト プラクティスとして、短期間で CA を追加または編集できるようにすることをお勧めします。 業界の規制では、変更から 7 日以内に CA 証明書を交換する必要があるため、ピン留めを利用しているお客様は迅速に対応する必要があります。
Azure API または他の Azure サービスと統合されているアプリケーションがあり、証明書のピン留めが使用されているかどうかが不明な場合は、アプリケーション ベンダーに確認してください。
Azure サービスと通信するさまざまなオペレーティング システムと言語ランタイムでは、新しいルートを使用して証明書チェーンを正しく構築するために追加の手順が必要になる場合があります。
- Linux:多くのディストリビューションでは、CA を /etc/ssl/certs に追加する必要があります。 具体的な手順については、ディストリビューションのドキュメントを参照してください。
- Java: Java キース トアに上記の CA が含まれていることを確認します。
- 切断された環境で実行されている Windows: 切断された環境で実行されているシステムでは、新しいルートを信頼されたルート証明機関ストアに追加し、中間を中間証明機関ストアに追加する必要があります。
- Android: デバイスのドキュメントと Android のバージョンを確認してください。
- その他のハードウェア デバイス、特に IoT: デバイスの製造元に問い合わせてください。
特定の証明書失効リスト (CRL) のダウンロードやオンライン証明書状態プロトコル (OCSP) の検証場所のみに対する発信呼び出しが許可されるようにファイアウォール規則が設定されている環境の場合、次の CRL と OCSP の URL を許可する必要があります。 Azure で使用される CRL と OCSP の URL の完全なリストについては、Azure CA の詳細に関する記事を参照してください。
- http://crl3.digicert.com
- http://crl4.digicert.com
- http://ocsp.digicert.com
- http://crl.microsoft.com
- http://oneocsp.microsoft.com
- http://ocsp.msocsp.com
次の手順
その他の質問がある場合は、サポートを通じてご連絡ください。