Office TLS 証明書の変更

[アーティクル]
08/11/2023

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

たとえば、これは、新しい証明書チェーンのいずれかを持つ有効な証明書です。

Teams TLS 証明書チェーン

この変更は私に影響しますか?

ルート 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 を信頼していることを確認します。デバイスの製造元に問い合わせる必要がある場合があります。
ファイアウォール規則で特定のエンドポイントへの送信呼び出しのみを許可する環境がある場合は、次の証明書失効リスト (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 つ目の方法では作成されません。