Exchange Serverでのデジタル証明書と暗号化

暗号化とデジタル証明書は、すべての組織において重要な考慮事項です。 既定では、Exchange Serverはトランスポート層セキュリティ (TLS) を使用して、内部 Exchange サーバー間とローカル サーバー上の Exchange サービス間の通信を暗号化するように構成されています。 ただし、Exchange 管理者は、内部と外部のクライアント (コンピューターとモバイル デバイス)、外部のメッセージング サーバーとの通信に関する暗号化要件を考慮する必要があります。

注:

Exchange Server 2019 には、クライアントとサーバーの接続のセキュリティを向上させるための重要な変更が含まれています。 暗号化の既定の構成では、TLS 1.2 のみが有効になり、以前のアルゴリズム (具体的には、DES、3DES、RC2、RC4、MD5) のサポートは無効になります。 また、それにより非楕円曲線アルゴリズムに優先して、楕円曲線鍵交換アルゴリズムが構成されます。 Exchange Server 2016 以降では、すべての暗号化の設定がオペレーティング システムで指定されている構成から継承されます。 詳細については、「EXCHANGE SERVER TLS 構成のベスト プラクティス」を参照してください。

このトピックでは、使用可能なさまざまな種類の証明書、Exchange の証明書の既定の構成、Exchange で使用する必要がある追加の証明書に関する推奨事項を説明します。

Exchange Serverの証明書に必要な手順については、「Exchange Serverの証明書の手順」を参照してください。

デジタル証明書の概要

デジタル証明書は、オンライン パスワードのように動作し、ユーザーまたはコンピューターの ID を確認する電子ファイルです。 これらは、クライアント通信に使用される暗号化されたチャネルを作成するために使用されます。 証明書は、証明機関 (CA) によって発行されたデジタルステートメントであり、証明書所有者の ID を保証し、暗号化を使用して関係者が安全な方法で通信できるようにします。

デジタル証明書は、次のサービスを提供します。

• 暗号化: 盗難や改ざんから交換されたデータを保護するのに役立ちます。

• 認証: 所有者 (ユーザー、Web サイト、さらにはルーターなどのネットワーク デバイス) が本当に誰であるか、何であると主張しているかが確認されます。 通常、認証は一方向であり、ソースがターゲットの身元を確認しますが、相互 TLS 認証も可能です。

証明書はさまざまな目的で使用するために発行できます。 これには、Web ユーザー認証、Web サーバー認証、Secure/Multipurpose Internet Mail Extensions (S/MIME)、インターネット プロトコル セキュリティ (IPsec)、コード署名などがあります。

証明書には公開キーが含まれ、その公開キーを対応する秘密キーを保持するユーザー、コンピューター、サービスの ID に結び付けます。 公開キーと秘密キーは、データを送信する前に暗号化するために、クライアントとサーバーで使用されます。 Windows のユーザー、コンピューター、サービスでは、信頼されたルート証明書ストアにルート証明書が定義されていて、証明書に有効な証明のパスが含まれている場合に、CA に対する信頼が確立されます。 証明書は、取り消されていない (CA の証明書失効リストまたは CRL に含まれていない) 場合、または有効期限が切れていない場合に有効と見なされます。

次の表で、デジタル証明書の主な 3 つの種類について説明します。

型	説明	メリット	デメリット
自己署名証明書	証明書は、証明書を作成したアプリケーションによって署名されます。	コスト (無料)。	証明書は、クライアント コンピューターとモバイル デバイスで自動的に信頼されません。 証明書は、すべてのクライアント コンピューターとデバイス上の信頼されたルート証明書ストアに手動で追加する必要がありますが、一部のモバイル デバイスでは信頼されたルート証明書ストアを変更できません。 一部のサービスは、自己署名証明書に対応していません。 証明書ライフサイクル管理のインフラストラクチャの確立が困難です。 たとえば、自己署名証明書を取り消すことはできません。
内部 CA によって発行された証明書	証明書は、組織の公開キー基盤 (PKI) によって発行されます。 例として、Active Directory 証明書サービス (AD CS) などがあります。 詳細については、「Active Directory 証明書サービスの概要」を参照してください。	組織が独自の証明書を発行できます。 商用 CA からの証明書よりも安価です。	PKI の展開と保守がより複雑です。 証明書は、クライアント コンピューターとモバイル デバイスで自動的に信頼されません。 証明書は、すべてのクライアント コンピューターとデバイス上の信頼されたルート証明書ストアに手動で追加する必要がありますが、一部のモバイル デバイスでは信頼されたルート証明書ストアを変更できません。
商用 CA によって発行された証明書	信頼された商用 CA から証明書を購入します。	すべてのクライアント、デバイス、サーバーが自動的に証明書を信頼するため、証明書の展開が簡略化されています。	コスト。 必要な証明書の数を最小限にするために事前に計画する必要があります。

証明書の所有者の身元が正しいことを証明するには、証明書は他のクライアント、デバイス、サーバーに対する証明書の所有者を正確に識別する必要があります。 これを行うための 3 つの基本的な方法を、次の表で説明します。

メソッド	説明	メリット	デメリット
証明書のサブジェクト一致	証明書の Subject フィールドには、ホストの共通名 (CN) が含まれています。 たとえば、 www.contoso.com に発行された証明書は、Web サイトの https://www.contoso.comに使用できます。	すべてのクライアント、デバイス、サービスと互換性があります。 区画化。 ホストの証明書を取り消しても、他のホストには影響しません。	必要な証明書の数。 証明書は、指定したホストに対してのみ使用できます。 たとえば、 サービスが同 じサーバーにインストールされている場合でも、ftp.contoso.com に www.contoso.com 証明書を使用することはできません。 複雑さ。 Web サーバーでは、各証明書に独自の IP アドレスのバインドが必要です。
証明書のサブジェクトの別名 (SAN) 一致	Subject フィールドに加えて、証明書の Subject Alternative Name フィールドに複数のホスト名が一覧表示されます。 次に例を示します。 www.contoso.com ftp.contoso.com ftp.eu.fabirkam.net	利便性。 複数の個別のドメイン内にある複数のホストに対して同じ証明書を使用できます。 クライアント、デバイス、サービスのほとんどは、SAN 証明書をサポートしています。 監査とセキュリティ。 SAN 証明書を使用できるホストを正確に把握できます。	綿密な計画が必要です。 証明書の作成時に、ホストの一覧を提供する必要があります。 区画化はありません。 証明書内のすべてのホストに影響を与えずに、一部の指定されたホストの証明書を選択的に取り消すことはできません。
ワイルドカード証明書一致	証明書の Subject フィールドには、ワイルドカード文字 (*) の後に単一のドメインまたはサブドメインが続く共通名が含まれています。 たとえば、*.contoso.com や *.eu.contoso.com のようにします。 *.contoso.com のワイルドカード証明書は、次に対して使用できます。 www.contoso.com ftp.contoso.com mail.contoso.com	柔軟性。 証明書を要求するときにホストの一覧を指定する必要はありません。また、今後必要になる可能性のある任意の数のホストで証明書を使用できます。	他のトップレベル ドメイン (TLD) でワイルドカード証明書を使用することはできません。 たとえば、* .contoso.com ホストに対して * .contoso.com のワイルドカード証明書は使用できません。 ワイルドカード証明書は、ワイルドカードのレベルのホスト名に対してのみ使用できます。 たとえば、www.eu.contoso.com に *.contoso.com 証明書を使用することはできません。 または、www.uk.eu.contoso.com に *.eu.contoso.com 証明書を使用することはできません。 前のクライアント、デバイス、アプリケーション、サービスは、ワイルドカード証明書をサポートしていない場合があります。 ワイルドカードは、EV (Extended Validation) 証明書では使用できません。 監査と制御は慎重に行う必要があります。 ワイルドカード証明書が侵害されると、指定したドメイン内のすべてのホストに影響します。

Exchange の証明書

Exchange 2016 または Exchange 2019 をサーバーにインストールすると、2 つの自己署名証明書が作成され、Exchange によってインストールされます。 3 つ目の自己署名証明書は、インターネット インフォメーション サービス (IIS) の Web 管理サービス用に Microsoft Windows によって作成され、インストールされます。 これら 3 つの証明書は、Exchange 管理センター (EAC) と Exchange 管理シェル に表示され、次の表に詳細が説明されています。

名前	注釈
Microsoft Exchange	この Exchange 自己署名証明書には次の機能があります。 証明書は、組織内にある他のすべての Exchange サーバーによって自動的に信頼されます。 これには、Exchange organizationにサブスクライブされているエッジ トランスポート サーバーが含まれます。 証明書は、ユニファイド メッセージング以外のすべての Exchange サービスで自動的に有効になり、Exchange サーバー、同じコンピューター上の Exchange サービス、メールボックス サーバー上のクライアント アクセス サーバーからバックエンド サービスにプロキシ処理されているクライアント接続間の内部通信を暗号化するために使用されます。 (注: UM は Exchange 2019 では使用できません)。 証明書は、外部 SMTP メッセージング サーバーからの受信接続、および外部 SMTP メッセージング サーバーへの送信接続で自動的に有効になります。 この既定の構成により、Exchange は、すべての受信および送信 SMTP 接続に 対して日和見 TLS を提供できます。 Exchange は、外部のメッセージング サーバーを使用して SMTP セッションを暗号化しようとしますが、外部サーバーが TLS 暗号化をサポートしていない場合、セッションは暗号化されません。 証明書は、内部クライアントまたは外部クライアントとの暗号化された通信を提供しません。 クライアントとサーバーは、証明書が信頼されたルート証明書ストアに定義されていないため、Exchange 自己署名証明書を信頼しません。
Microsoft Exchange Server Auth Certificate	この Exchange 自己署名証明書は、OAuth を使用したサーバー間の認証と統合に使用されます。 詳細については、「SharePoint とSkype for BusinessとのExchange Server統合を計画する」を参照してください。
WMSVC	この Windows 自己署名証明書は、IIS の Web 管理サービスで使用され、Web サーバーとそれに関連する Web サイトやアプリケーションのリモート管理を有効にします。 この証明書を削除すると、有効な証明書が選択されていない場合、Web 管理サービスを開始できません。 この状態でサービスを使用すると、Exchange の更新プログラムをインストールしたり、サーバーから Exchange をアンインストールしたりできなくなる可能性があります。 この問題を修正する方法については、「イベント ID 1007 - IIS Web Management Service Authentication」を参照してください。

これらの自己署名証明書のプロパティについては、「既定の自己署名証明書のプロパティ」セクションで説明されています。

これらは、Exchange の証明書について考慮する必要がある重要な問題です。

• 組織内の Exchange サーバーとサービス間のネットワーク トラフィックを暗号化するために、Microsoft Exchange 自己署名証明書を置き換える必要はありません。

• 内部クライアントと外部クライアントで Exchange サーバーへの接続を暗号化するには、追加の証明書が必要です。

• Exchange サーバーと外部メッセージング サーバー間で SMTP 接続を強制的に暗号化するには、追加の証明書が必要です。

Exchange Serverの計画と展開の次の要素は、証明書要件の重要なドライバーです。

• 負荷分散: ロード バランサーまたはリバース プロキシ サーバーで暗号化されたチャネルを終了し、レイヤー 4 またはレイヤー 7 ロード バランサーを使用し、セッション アフィニティを使用するか、セッション アフィニティを使用しないか。 詳細については、「 Exchange 2016 での負荷分散」を参照してください。

• 名前空間の計画: Exchange のバージョンは何ですか、バインドされた名前空間モデルまたはバインドされていない名前空間モデルを使用していますか。また、 スプリット ブレイン DNS (内部アクセスと外部アクセスに基づいて同じホストに異なる IP アドレスを構成する) を使用していますか? 詳細については、「Exchange 2016 での名前空間の計画」を参照してください。

• クライアント接続: クライアントが使用するサービス (Web ベースのサービス、POP、IMAP など) と、どのバージョンの Exchange が関係していますか? 詳細については、次のトピックをご覧ください。

  • Exchange 2013 と Exchange 2016 の共存環境におけるクライアント接続

  • Exchange 2010 と Exchange 2016 の共存環境におけるクライアント接続

  • 混合の Exchange バージョンと Exchange 2016 の共存環境におけるクライアント接続

Exchange Serverでの楕円曲線暗号化証明書のサポート

ECC 証明書 (楕円曲線暗号化証明書) は、暗号化に楕円曲線アルゴリズムを使用するデジタル証明書の一種であり、従来の RSA 証明書と比較して、キーの長さが短いほどセキュリティが強化されます。

Exchange Server April 2024 修正プログラム更新プログラム (HU) 以降、Exchange Server 2016 および Exchange Server 2019 では、一部のサービスで楕円曲線暗号 (ECC) 証明書の使用がサポートされています。 2024 年 11 月のセキュリティ更新プログラム (SU) Exchange Serverで重要な調整を行い、既知の問題を解決し、追加のシナリオ (POP3 や IMAP など) で ECC 証明書のサポートを有効にしました。 ECC 証明書のサポートを有効にする前に、最新のExchange Server更新プログラムをインストールしてください。

警告

現在、次のシナリオでは ECC 証明書の使用はサポートされていません。 今後、これらのシナリオをサポートするための更新プログラムに取り組んでいます。

• フェデレーション信頼証明書は RSA 証明書である必要があります
• Exchange Server OAuth 証明書は RSA 証明書である必要があります
• AD FS 要求ベースの認証を使用するが構成されている場合、ECC 証明書を使用できません

次のセクションの表を確認して、ECC 証明書で使用できるサービスを確認します。

ECC 証明書のサポートは既定で無効になっており、レジストリ値を作成することで有効にすることができます。 コマンドは、organization内のすべてのExchange Serverで実行する必要があります。 変更がアクティブになるまでに最大 15 分かかることがあります。

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics" -Name "EnableEccCertificateSupport" -Value 1 -Type String

2024 年 4 月の修正プログラム更新プログラム (HU) Exchange Serverで導入されたオーバーライドは、ECC 証明書のサポートを完全に有効にしないため、使用しなくなりました。 オーバーライドを削除することをお勧めします。 New-SettingOverride コマンドが実行された後、新しい Exchange 管理シェル (EMS) を開きます。

Get-SettingOverride | Where-Object {($_.SectionName -eq "ECCCertificateSupport") -and ($_.Parameters -eq "Enabled=true")} | Remove-SettingOverride
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force

Exchange サービスの証明書要件

証明書を割り当てることができる Exchange サービスを、次の表で説明します。

サービス	説明	サポートされている ECC 証明書
IIS (HTTP)	既定では、次のサービスが、メールボックス サーバーのクライアント アクセス (フロント エンド) サービス内にある既定の Web サイトで提供され、Exchange に接続するためにクライアントによって使用されます。 自動検出 Exchange ActiveSync Exchange 管理センター Exchange Web サービス オフライン アドレス帳 (OAB) の配布 Outlook Anywhere (RPC over HTTP) Outlook MAPI over HTTP Web 上の Outlook リモート PowerShell* 1 つの Web サイトに関連付けられるのは 1 つの証明書のみであるため、クライアントがこれらのサービスに接続するために使用するすべての DNS 名を証明書に含める必要があります。 これは、SAN 証明書またはワイルドカード証明書を使用して行うことができます。	はい
POP または IMAP	POP または IMAP で使用する証明書は、IIS で使用する証明書とは異なるものにすることができます。 ただし管理を簡単にするため、POP または IMAP に使用されているホスト名を IIS 証明書にも含めて、これらのすべてのサービスで同じ証明書を使用することをお勧めします。	はい
SMTP	クライアントまたはメッセージング サーバーからの SMTP 接続は、Exchange サーバー上のフロント エンド トランスポート サービスで構成されている 1 つ以上の受信コネクタによって承認されています。 詳細については、「受信コネクタ」を参照してください。 SMTP 接続の TLS 暗号化を要求するには、受信コネクタごとに個別の証明書を使用できます。 証明書には、受信コネクタに接続するために SMTP のクライアントやサーバーによって使用されている DNS 名を含める必要があります。 証明書の管理を簡単にするため、TLS トラフィックのサポートを必要とするすべての DNS 名前を 1 つの証明書に含めることを検討してください。 送信元サーバーと宛先サーバー間の SMTP 接続が暗号化および認証される 相互 TLS 認証を必要とするには、「 ドメイン セキュリティ」を参照してください。	はい
EdgeSync	詳細については、「Exchange Serverの Edge サブスクリプション」を参照してください。	いいえ
ユニファイド メッセージング (UM)	詳細については、「Deploying Certificates for UM」を参照してください。 注: UM は Exchange 2019 では使用できません。	はい
Microsoft 365 または Office 365 を使用したハイブリッド展開	詳細については、「Certificate Requirements for Hybrid Deployments」を参照してください。	はい
Secure/Multipurpose Internet Mail Extensions (S/MIME)	詳細については、「S/MIME によるメッセージの署名と暗号化」を参照してください。	いいえ

^* Kerberos 認証と Kerberos 暗号化は、Exchange 管理センターと Exchange 管理シェルの両方からのリモート PowerShell アクセスに使用されます。 そのため、(負荷分散された名前空間ではなく) Exchange サーバーに直接接続する限り、リモート PowerShell で使用するように証明書を構成する必要はありません。 リモート PowerShell を使用して、ドメインのメンバーではないコンピューターから Exchange サーバーに接続したり、インターネットから接続したりするには、リモート PowerShell で使用するように証明書を構成する必要があります。

Exchange 証明書のベスト プラクティス

組織のデジタル証明書の構成は、組織の特定の要件によって異なりますが、ベスト プラクティスに関する情報が含まれており、要件に合うデジタル証明書の構成を選択できます。

• 可能な限り少数の証明書を使用する: 非常に可能性が高い、これは SAN 証明書またはワイルドカード証明書の使用を意味します。 Exchange との相互運用性の面では、両方とも機能的に同等です。 SAN 証明書とワイルドカード証明書のどちらを使用するかを決定する際に重要なのは、「 デジタル証明書の概要」で説明されている、証明書の種類ごとの主要な機能や制限事項 (実際のまたは認識されているもの) です。

  たとえば、すべての共通名が contoso.com のレベルと同じである場合は、SAN 証明書とワイルドカード証明書のどちらを使用しても構いません。 ただし、autodiscover.contoso.com、autodiscover.fabrikam.com、autodiscover.northamerica.contoso.com に対して証明書を使用する必要がある場合は、SAN 証明書を使用する必要があります。

• クライアントと外部サーバーの接続に商用 CA の証明書を使用する: 証明書または証明書発行者を信頼するようにほとんどのクライアントを構成できますが、Exchange サーバーへのクライアント接続に商用 CA の証明書を使用する方がはるかに簡単です。 クライアントでは、商用 CA によって発行されている証明書を信頼するための構成は必要ありません。 多くの商用 CA は、特に Exchange 用に構成されている証明書を提供しています。 EAC または Exchange 管理シェル を使用して、ほとんどの商用 CA で機能する証明書要求を生成できます。

• 適切な商用 CA を選択します。CA 間で証明書の価格と機能を比較します。 以下に例を示します。

  • Exchange サーバーに接続するクライアント (オペレーティング システム、ブラウザー、モバイル デバイス) によって、CA が信頼されていることを確認します。

  • 必要な証明書の種類を、CA がサポートしていることを確認します。 たとえば、すべての CA が SAN 証明書をサポートしているわけではなく、CA が SAN 証明書で使用できる共通名の数を制限している場合や、CA が SAN 証明書の共通名の数に基づいて追加料金を請求する場合があります。

  • SAN 証明書が発行された後、課金されずにその証明書にさらに共通名を追加できる猶予期間を CA が提供しているどうかを確認します。

  • 証明書のライセンスにより、必要な数のサーバーで証明書を使用できることを確認します。 1 台のサーバーでしか証明書を使用できない CA もあります。

• Exchange 証明書ウィザードを使用する: 証明書を作成するときの一般的なエラーは、使用するサービスに必要な 1 つ以上の一般的な名前を忘れる場合です。 Exchange 管理センターの証明書ウィザードを使用すると、証明書要求に一般的な名前の正しい一覧を含めることができます。 ウィザードを使用すると、証明書を使用するサービスを指定し、それらのサービスの証明書に必要な一般的な名前を含めます。 Exchange 2016 または Exchange 2019 サーバーの初期セットを展開し、展開に使用するさまざまなサービスに使用するホスト名を決定したら、証明書ウィザードを実行します。

• 可能な限り少数のホスト名を使用する: SAN 証明書のホスト名の数を最小限に抑えることで、証明書管理に関係する複雑さが軽減されます。 証明書の使用目的によっては、必ずしも SAN 証明書に個々の Exchange サーバーのホスト名を含める必要はありません。 通常は、証明書を使用して Exchange に接続する、内部クライアント、外部クライアント、外部サーバーに提示される DNS 名のみを含める必要があります。

  Contoso という名前の単純なExchange Server organizationの場合、これは、必要となる最小ホスト名の架空の例です。

  • mail.contoso.com: このホスト名は、Outlook、Outlook on the web、OAB 配布、Exchange Web サービス、Exchange 管理センター、Exchange ActiveSyncなど、Exchange へのほとんどの接続を対象としています。

  • autodiscover.contoso.com: この特定のホスト名は、Outlook、Exchange ActiveSync、Exchange Web Services クライアントなど、自動検出をサポートするクライアントで必要です。 詳しくは、「自動検出サービス」をご覧ください。

既定の自己署名証明書のプロパティ

次の表に、Exchange サーバーの Exchange 管理センター または Exchange 管理シェル あるいはその両方に表示される既定の自己署名証明書に関連するプロパティのいくつかを示します。

プロパティ	Microsoft Exchange	Microsoft Exchange Server Auth Certificate	WMSVC
件名	CN=<ServerName> (例: CN=Mailbox01)	CN=Microsoft Exchange Server Auth Certificate	CN=WMSvc-<ServerName> (例: CN=WMSvc-Mailbox01)
サブジェクトの別名 (CertificateDomains)	<ServerName> (Mailbox01 など) <ServerFQDN> (たとえば、Mailbox01.contoso.com)	none	WMSvc-<ServerName> (例: WMSvc-Mailbox01)
秘密キーを持つ (HasPrivateKey)	はい (True)	はい (True)	はい (True)
PrivateKeyExportable*	False	True	True
EnhancedKeyUsageList*	サーバー認証 (1.3.6.1.5.5.7.3.1)	サーバー認証 (1.3.6.1.5.5.7.3.1)	サーバー認証 (1.3.6.1.5.5.7.3.1)
IISServices*	IIS://<ServerName>/W3SVC/1, IIS://<ServerName>/W3SVC/2 (例: IIS://Mailbox01/W3SVC/1, IIS://Mailbox01/W3SVC/2)	none	none
IsSelfSigned	True	True	True
発行者	CN=<ServerName> (例: CN=Mailbox01)	CN=Microsoft Exchange Server Auth Certificate	CN=WMSvc-<ServerName> (例: CN=WMSvc-Mailbox01)
NotBefore	Exchange がインストールされた日付/時刻。	Exchange がインストールされた日付/時刻。	IIS Web マネージャー サービスがインストールされた日付/時刻。
有効期限が切れる (NotAfter)	NotBeforeから5年後。	NotBeforeから5年後。	NotBeforeから10年後。
公開キーのサイズ (PublicKeySize)	2048	2048	2048
RootCAType	レジストリ	なし	レジストリ
サービス	IMAP、POP、IIS、SMTP	SMTP	なし

^* これらのプロパティは、Exchange 管理シェル の標準ビューには表示されません。 表示するには、 Format-Table または Format-List コマンドレットでプロパティ名 (正確な名前またはワイルドカード一致) を指定する必要があります。 以下に例を示します。

• Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-List *

• Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-Table -Auto FriendlyName,*PrivateKey*

詳細については、「 Get-ExchangeCertificate」を参照してください。

Windows 証明書マネージャーに表示される既定の自己署名証明書の詳細については、次の表をご覧ください。

プロパティ	Microsoft Exchange	Microsoft Exchange Server Auth Certificate	WMSVC
署名アルゴリズム	sha256RSA1	sha256RSA1	sha256RSA1
署名ハッシュ アルゴリズム	sha2561	sha2561	sha2561
キー使用法	デジタル署名、キー暗号化 (a0)	デジタル署名、キー暗号化 (a0)	デジタル署名、キー暗号化 (a0)、データ暗号化 (b0 00 00 00)
基本的な制約	Subject Type=End Entity Path Length Constraint=None	Subject Type=End Entity Path Length Constraint=None	該当なし
拇印アルゴリズム	sha2561	sha2561	sha2561

¹ Exchange 2016 累積的な更新プログラム 22 以降および Exchange 2019 累積的な更新プログラム 11 以降の新規インストールに適用されます。 詳細については、「セットアップ時に SHA-1 ハッシュを使用して作成された 2019 および 2016 証明書をExchange Serverする」を参照してください。

通常、Exchange 証明書の管理には Windows 証明書マネージャーを使用しません (Exchange 管理センター または Exchange 管理シェル を使用します)。 WMSVC 証明書は Exchange 証明書ではないことにご注意ください。