Office TLS 証明書の変更
Microsoft 365 では、別のルート証明機関 (CA) の TLS 証明書を使用するように、メッセージング、会議、テレフォニー、音声、ビデオに電力を供給するサービスを更新しています。 この変更は、現在のルート CA が 2025 年 5 月に期限切れになるためです。
影響を受ける製品は次のとおりです。
- Microsoft Teams
- Skype
- Skype for Business Online
- Microsoft Dynamics 365
- GroupMe
- Kaizala
- Azure Communication Services
影響を受けるエンドポイントには、次のものがあります (ただし、これらに限定されません)。
- *.teams.microsoft.com
- *.skype.com
- *.skypeforbusiness.com
- *.groupme.com
- *.communication.azure.com
- *.operatorconnect.microsoft.com
さらに、Microsoft 365 の米国政府機関向けナショナル クラウド インスタンスの Teams および Skype for Business Online エンドポイントも同じ変更を行い、次のようなエンドポイントに影響を与えます。
- *.gcc.teams.microsoft.com
- *.dod.teams.microsoft.us
- *.gov.teams.microsoft.us
- *.online.dod.skypeforbusiness.us
- *.online.gov.skypeforbusiness.us
- *.um-dod.office365.us
- *.um.office365.us
この変更は、Microsoft 365 の中国またはドイツ国内クラウド インスタンスで使用される証明書、ドメイン、またはサービスには影響しません。
この記事のすべての証明書情報は、2020 年 10 月以降に Microsoft 365 暗号化チェーン で以前に提供されていました。
ヒント
E5 のお客様でない場合は、90 日間の Microsoft Purview ソリューション試用版を使用して、Purview の追加機能が組織のデータ セキュリティとコンプライアンスのニーズの管理にどのように役立つかを確認してください。 Microsoft Purview コンプライアンス ポータルのトライアル ハブで今すぐ開始してください。 サインアップと試用期間の詳細については、こちらをご覧ください。
この変更はいつ発生しますか?
サービスは 2022 年 1 月に新しいルート CA への移行を開始し、2022 年 10 月まで継続されます。
何が変わるのですか?
現在、Microsoft 365 サービスで使用される TLS 証明書のほとんどは、次のルート CA までチェーンされています。
CA の共通名 | 拇印 (SHA1) |
---|---|
Baltimore CyberTrust Root | d4de20d05e66fc53fe1a50882c78db2852cae474 |
次のいずれかの中間 CA を使用します。
CA の共通名 | 拇印 (SHA1) |
---|---|
Microsoft RSA TLS CA 01 | 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a |
Microsoft RSA TLS CA 02 | b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75 |
Microsoft 365 サービスで使用される新しい TLS 証明書が、次のいずれかのルート CA にチェーンされるようになりました。
CA の共通名 | 拇印 (SHA1) |
---|---|
DigiCert Global Root G2 | df3c24f9bfd666761b268073fe06d1cc8d4f82a4 |
Microsoft RSA ルート証明機関 2017 | 73a5e64a3bff8316ff0edccc618a906e4eae4d74 |
Microsoft ECC ルート証明機関 2017 | 999a64c37ff47d9fab95f14769891460eec4c3c5 |
次のいずれかの中間 CA を使用します。
CA の共通名 | 拇印 (SHA1) |
---|---|
Microsoft Azure TLS Issuing CA 01 | 2f2877c5d778c31e0f29c7e371df5471bd673173 |
Microsoft Azure TLS Issuing CA 02 | e7eea674ca718e3befd90858e09f8372ad0ae2aa |
Microsoft Azure TLS Issuing CA 05 | 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5 |
Microsoft Azure TLS Issuing CA 06 | 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0 |
たとえば、これは、新しい証明書チェーンのいずれかを持つ有効な証明書です。
この変更は私に影響しますか?
ルート CA "DigiCert Global Root G2" は、Windows、macOS、Android、iOS などのオペレーティング システムや、Microsoft Edge、Chrome、Safari、Firefox などのブラウザーによって広く信頼されています。 Microsoft 365 のお客様のほとんどは影響を受けないことを期待しています。
ただし、 受け入れ可能な CA の一覧を明示的に指定すると、アプリケーションが影響を受ける可能性があります。 この方法は"証明書のピン留め" と呼ばれます。 受け入れ可能な CA の一覧に新しいルート CA がないお客様は、証明書の検証エラーを受け取ります。これは、アプリケーションの可用性や機能に影響を与える可能性があります。
アプリケーションが影響を受ける可能性があるかどうかを検出する方法を次に示します。
ソース コードで、ここで見つかったいずれかの中間 CA の拇印、共通名、またはその他のプロパティを検索 します。 一致するものがある場合、アプリケーションに影響が及びます。 この問題を解決するには、ソース コードを更新して、新しい CA のプロパティを追加します。 ベスト プラクティスとして、簡単な通知で CA を追加または編集できることを確認します。 業界の規制では、状況によっては CA 証明書を 7 日以内に置き換える必要があるため、証明書のピン留めを実装するアプリケーションは、これらの変更に迅速に対応する必要があります。
.NET では、 と コールバック関数が
System.Net.HttpWebRequest.ServerCertificateValidationCallback
公開System.Net.ServicePointManager.ServerCertificateValidationCallback
されています。これにより、開発者はカスタム ロジックを使用して、標準の Windows 証明書ストアに依存するのではなく、証明書が有効かどうかを判断できます。 開発者は、特定の共通名または拇印をチェックするロジックを追加したり、"Baltimore CyberTrust Root" などの特定のルート CA のみを許可したりできます。 アプリケーションでこれらのコールバック関数を使用する場合は、古い CA と新しいルート CA と中間 CA の両方が受け入れられることを確認する必要があります。ネイティブ アプリケーションでは、 を使用
WINHTTP_CALLBACK_STATUS_SENDING_REQUEST
している可能性があります。これにより、ネイティブ アプリケーションはカスタム証明書検証ロジックを実装できます。 この通知の使用はまれであり、実装するには大量のカスタム コードが必要です。 上記と同様に、アプリケーションが古い CA と新しいルート CA と中間 CA の両方を受け入れるようにします。Microsoft Teams、Skype、Skype for Business Online、または Microsoft Dynamics API と統合されているアプリケーションを使用していて、証明書のピン留めを使用しているかどうかが不明な場合は、アプリケーション ベンダーとチェックします。
Azure サービスと通信するさまざまなオペレーティング システムと言語ランタイムでは、新しい証明書チェーンを正しく構築して検証するための他の手順が必要になる場合があります。
- Linux: 多くのディストリビューションでは、 に CA を追加する
/etc/ssl/certs
必要があります。 具体的な手順については、ディストリビューションのドキュメントを参照してください。 - Java: Java キー ストアに上記の CA が含まれていることを確認します。
- 切断された環境で実行されている Windows: 切断された環境で実行されているシステムでは、新しいルート CA をストアに
Trusted Root Certification Authorities
追加し、新しい中間 CA をストアに追加するIntermediate Certification Authorities
必要があります。 - Android: デバイスと Android のバージョンのドキュメントを確認します。
- IoT または埋め込みデバイス: テレビ セット トップ ボックスなどの埋め込みデバイスには、多くの場合、ルート証明機関証明書のセットが限られており、証明書ストアを簡単に更新する方法はありません。 カスタム埋め込みデバイスまたは IoT デバイスのデプロイのコードを記述または管理する場合は、デバイスが新しいルート CA を信頼していることを確認します。 デバイスの製造元に問い合わせる必要がある場合があります。
- Linux: 多くのディストリビューションでは、 に CA を追加する
ファイアウォール規則で特定のエンドポイントへの送信呼び出しのみを許可する環境がある場合は、次の証明書失効リスト (CRL) またはオンライン証明書状態プロトコル (OCSP) URL を許可します。
http://crl3.digicert.com
http://crl4.digicert.com
http://ocsp.digicert.com
http://crl.microsoft.com
http://oneocsp.microsoft.com
http://ocsp.msocsp.com
http://www.microsoft.com/pkiops
この変更の影響を受けた場合は、実行中の環境の種類と影響を受けたシナリオに応じてエラー メッセージが表示されることがあります。 Windows アプリケーション イベント ログ、CAPI2 イベント ログ、およびカスタム アプリケーション ログで、次のようなメッセージを確認します。
An operation failed because the following certificate has validation errors: Subject Name: CN=teams.microsoft.com Issuer Name: CN=Microsoft Azure TLS Issuing CA 01, O=Microsoft Corporation, C=US Errors: The root of the certificate chain is not a trusted root authority.
セッション ボーダー コントローラーを使用する場合、Microsoft は、SBC アプライアンスが新しいルート CA から発行された証明書を信頼していることを確認するために使用できるテスト エンドポイントを準備しました。 このエンドポイントは、SIP OPTIONS ping メッセージにのみ使用し、音声トラフィックには使用しないでください。
Global FQDN: sip.mspki.pstnhub.microsoft.com Port: 5061
正常に動作しない場合は、デバイスの製造元に問い合わせて、新しいルート CA をサポートするための更新プログラムがあるかどうかを確認してください。
古い CA 情報はいつ廃止できますか?
現在のルート CA、中間 CA、リーフ証明書は失効しません。 既存の CA 共通名や拇印は、既存の証明書の有効期間に基づいて、少なくとも 2023 年 10 月まで必要になります。
既知の問題
非常にまれな状況では、エンタープライズ ユーザーは、ルート CA "DigiCert Global Root G2" が失効として表示される証明書検証エラーを表示することがあります。 これは、次の両方の条件で Windows の既知のバグが原因です。
- ルート CA は CurrentUser\Root 証明書ストアにあり、 プロパティと
NotBeforeEKU
プロパティがありませんNotBeforeFileTime
- ルート CA は LocalMachine\AuthRoot 証明書ストアにありますが、 と
NotBeforeEKU
プロパティの両方をNotBeforeFileTime
持っています - ルート CA が LocalMachine\Root 証明書ストアにありません
の後 NotBeforeFileTime
にこのルート CA から発行されたすべてのリーフ証明書が失効したと表示されます。
管理者は、CAPI2 ログでこのエラーを調べることで、問題を特定してトラブルシューティングできます。
Log Name: Microsoft-Windows-CAPI2/Operational
Source: Microsoft-Windows-CAPI2
Date: 6/23/2022 8:36:39 AM
Event ID: 11
Task Category: Build Chain
Level: Error
[...]
<ChainElement>
<Certificate fileRef="DF3C24F9BFD666761B268073FE06D1CC8D4F82A4.cer" subjectName="DigiCert Global Root G2" />
[...]
<TrustStatus>
<ErrorStatus value="4000024" CERT_TRUST_IS_REVOKED="true" CERT_TRUST_IS_UNTRUSTED_ROOT="true" CERT_TRUST_IS_EXPLICIT_DISTRUST="true" />
<InfoStatus value="10C" CERT_TRUST_HAS_NAME_MATCH_ISSUER="true" CERT_TRUST_IS_SELF_SIGNED="true" CERT_TRUST_HAS_PREFERRED_ISSUER="true" />
</TrustStatus>
[...]
<RevocationInfo freshnessTime="PT0S">
<RevocationResult value="80092010">The certificate is revoked.</RevocationResult>
</RevocationInfo>
</ChainElement>
</CertificateChain>
<EventAuxInfo ProcessName="Teams.exe" />
<Result value="80092010">The certificate is revoked.</Result>
要素の存在に CERT_TRUST_IS_EXPLICIT_DISTRUST="true"
注意してください。
次certutil
のコマンドを実行し、出力を比較することで、異なるNotBeforeFileTime
プロパティを持つルート CA の 2 つのコピーが存在することを確認できます。
certutil -store -v authroot DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
certutil -user -store -v root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
ユーザーは、次の手順を実行して、証明書ストア内のルート CA のコピーを削除することで、この問題を CurrentUser\Root
解決できます。
certutil -user -delstore root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
または
reg delete HKCU\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates\DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 /f
1 つ目の方法では、ユーザーがクリックする必要がある Windows ダイアログが作成されますが、2 つ目の方法では作成されません。
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示