- MC1224565 の内容とは？
- DigiCert Global Root G2 証明書局（CA）とは？
- 何をすればいいのか？
- Windows でDigiCert ルート証明書が信頼されているかどうかを確認するには？
- 信頼されていない場合はどのようなエラーが返されるか？
- メール送受信の TLS 証明書認証の流れ
MC1224565 の内容とは？
利用しているメールクライアントやメールサーバーなどにて、DigiCert Global Root G2 証明書局(CA) およびその下位 CA を信頼していないとメールの送受信に影響があるという内容です。
DigiCert Global Root G2のルート証明書をインストールせずに、システムが古いルート証明書に依存して検証している場合、2026年 3 月 15 日以降にメールの送受信が失敗、または遅延する可能性があります。
メールの送受信の際に Exchange Online とクライアントやサーバー側にて TLS の暗号化通信を行いますが、その際に提示された Exchange Online の証明書を信頼していないため接続ができずにメールの疎通ができない状況となります。
DigiCert Global Root G2 証明書局（CA）とは？
DigiCert (デジサート) は、世界最大級・最上位クラスのデジタル証明書認証局を運営する企業です。
証明書局（CA：Certificate Authority）は、「このサイトやサーバーは本物ですよ」
と第三者として保証する機関です。
ざっくり言うと、DigiCert Global Root G2 は「世界中の HTTPS 通信を土台で支えている信頼の親玉」です。
何をすればいいのか？
Exchange Online や Microsoft 365 側で何か設定などの対処をおこなうものではなく、利用しているクライアントやサーバー側でDigiCert Global Root G2 証明書局(CA) およびその下位 CA の証明書の信頼状況を確認する必要があります。
具体的には、ExchangeOnline と直前に接続するクライアントやサーバーで証明書の信頼状況を確認する必要があります。
例として、セキュリティサーバーやメールゲートウェイなど中継サーバーを経由する構成である場合は、中継サーバー側で DigiCert Global Root G2 証明書局(CA) およびその下位 CA を信頼されているか確認する必要があります。
受信の場合
送信元クライアント > SMTPサーバー > 中継サーバー > Exchange Online
上記の構成の場合は、中継サーバー側で確認する必要があります。
送信の場合
送信元クライアント > Exchange Online > 中継サーバー > 外部の受信者サーバー
上記の構成の場合は、中継サーバー側で確認する必要があります。
また、中継サーバーがなく、自身のオンプレミスサーバーで受信する場合は、オンプレミスサーバー側で確認する必要があります。
送信元クライアント > Exchange Online > オンプレミスサーバー
Windows でDigiCert ルート証明書が信頼されているかどうかを確認するには？
DigiCert ルート証明書が信頼されているかどうかを確認するには、次の PowerShell コマンドで確認ができます。
<実行例>
Get-ChildItem -Path Cert:\LocalMachine\Root\ | Where-Object { $_.Thumbprint -eq "DF3C24F9BFD666761B268073FE06D1CC8D4F82A4" }
このコマンドで以下のように証明書を返した場合は問題ありません。
必要な証明書がローカル Windows マシン上で既に信頼されていることを示す結果
信頼されていない場合はどのようなエラーが返されるか？
Exchange Onlineからオンプレミスサーバーにメールを送信し、失敗した場合、Exchange 管理センターで [メッセージ追跡] を実行すると以下のエラーが確認できます。
エラー内容
LED=450 4.4.317 Cannot establish session with remote server [Message=451 5.7.3 STARTTLS is required to send mail]
オンプレミスサーバーから Exchange Online にメールを送信した場合に、失敗した場合は、オンプレミスサーバーのプロトコルログのエラーは以下のようなものです。
エラー内容
451 5.7.3 STARTTLS is required, 5.7.0 Must issue a STARTTLS command first
メール送受信の TLS 証明書認証の流れ
共通鍵を使った「その後の暗号化通信」が行われます。
- SMTP で接続
- STARTTLS で暗号化へ移行
- TLS ハンドシェイク開始
- サーバー証明書の提示
- クライアントが証明書を検証（これが“TLSの認証”）
- 共通鍵の生成
- 暗号化された SMTP 通信開始
STEP 1：プレーンな SMTP 接続の開始
送信サーバー（MTA）が受信サーバーに接続し、まずは平文の SMTP セッションを開始します。相手から返されるのが 220 応答です。
STEP 2：STARTTLS の利用宣言
送信側（クライアント MTA）は
EHLO <hostname>
を送り、受信サーバーが STARTTLS 機能をサポートしているか確認します。
受信側がサポートしている場合は、"250-STARTTLS" が返り、クライアントは次に "STARTTLS" を送信します。
ここで TLS への切替えが開始されます。
STEP 3：TLS ハンドシェイクの開始
STARTTLS が成功すると、SMTP の上で TLS ハンドシェイクが開始されます。
TLS のハンドシェイクでは
- どの暗号方式を使うか
- 証明書をどちらが提示するか
- セッション鍵（共通鍵）をどう作るか
が交渉されます。
STEP 4：受信サーバーが証明書を提示
受信側 SMTP サーバーは以下をクライアントに送ります。
- サーバー証明書
- 中間証明書（チェーン）
- 公開鍵
どの証明書を提示するかを Receive Connector の設定に基づいて選択すると文書化されています。
STEP 5：クライアント側の“証明書検証処理”
クライアント（送信側 MTA）は、受信側が提示した証明書を検証します。
これが「TLS の証明書認証」です。
① 証明書チェーンの検証
- ルート CA（例：DigiCert Global Root G2）まで正しくつながるか
- 中間証明書の署名が正しいか
- ルート CA が OS の 信頼ストアに存在するか
（Microsoft 365 で G2 を信頼しないとメール障害が起きるのはこの部分）
② サーバー証明書の“名前一致（SAN/ CN）”
提示された証明書の CN または SAN が接続先ホスト名（例： mx.example.com）と一致する必要があります。
一致しない場合は、
tls_process_server_certificate:certificate verify failed
のようなエラーになります。
③ 有効期限の検証
期限切れ → TLS 接続失敗
④ 鍵用途（Key Usage / EKU）の検証
SMTP over TLS に必要な Server Authentication 用途が含まれる必要があります。
⑤ 失効チェック（CRL / OCSP）
証明書が失効していないことを確認します。
※オフライン環境では失効チェックが行えず TLS 失敗の原因になります。
STEP 6：共通鍵を生成（鍵交換）
証明書検証に成功すると、クライアントとサーバーは安全に共通鍵を生成します。
- TLS 1.2：RSA or ECDHE
- TLS 1.3：ほぼ ECDHE（前方秘匿性強化）
この共通鍵で メールデータは暗号化されて送受信されます。
STEP 7：暗号化された SMTP 通信開始
ここから先の SMTP コマンドはすべて暗号化されます：
- MAIL FROM
- RCPT TO
- DATA
- メール本文
途中で盗聴されても内容はわかりません。
まとめ（図式）
[SMTP 接続]
↓
EHLO → STARTTLS
↓
[TLS ハンドシェイク開始]
↓
受信側が証明書を提示
↓
クライアントが証明書を検証
- 署名チェーン
- CA の信頼
- CN/SAN の一致
- 有効期限 / 失効チェック
↓
共通鍵（セッションキー）生成
↓
[TLS 暗号化された SMTP]
↓
メール送受信
![[MC1191578] EWS によるメールボックスへのアクセスがブロックされる？](https://cdn-ak.f.st-hatena.com/images/fotolife/i/it-bibouroku/20260131/20260131113952.png)
