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 フィールドに複数のホスト名が一覧表示されます。 次に例を示します。
|
利便性。 複数の個別のドメイン内にある複数のホストに対して同じ証明書を使用できます。 クライアント、デバイス、サービスのほとんどは、SAN 証明書をサポートしています。 監査とセキュリティ。 SAN 証明書を使用できるホストを正確に把握できます。 |
綿密な計画が必要です。 証明書の作成時に、ホストの一覧を提供する必要があります。 区画化はありません。 証明書内のすべてのホストに影響を与えずに、一部の指定されたホストの証明書を選択的に取り消すことはできません。 |
| ワイルドカード証明書一致 | 証明書の Subject フィールドには、ワイルドカード文字 (*) の後に単一のドメインまたはサブドメインが続く共通名が含まれています。 たとえば、*.contoso.com や *.eu.contoso.com のようにします。 *.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 自己署名証明書には次の機能があります。
|
| Microsoft Exchange Server Auth Certificate | この Exchange 自己署名証明書は、OAuth を使用したサーバー間の認証と統合に使用されます。 詳細については、「 Exchange Server と SharePoint および Skype for Business の統合を計画する」を参照してください。 |
| 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 Server での楕円曲線暗号化証明書のサポート
Exchange Server April 2024 修正プログラム更新プログラム (HU) 以降、Exchange Server 2016 および Exchange Server 2019 では、一部のサービスで楕円曲線暗号 (ECC) 証明書の使用がサポートされています。
ECC 証明書 (楕円曲線暗号化証明書) は、暗号化に楕円曲線アルゴリズムを使用するデジタル証明書の一種であり、従来の RSA 証明書と比較して、キーの長さが短いほどセキュリティが強化されます。
警告
現在、次のシナリオでは ECC 証明書の使用はサポートされていません。 今後、これらのシナリオをサポートするための更新プログラムに取り組んでいます。
- エッジ トランスポート サーバーロールで ECC 証明書を割り当てることはできません
- POP および IMAP サービスに ECC 証明書を割り当てることができますが、使用されません
- フェデレーション信頼証明書は RSA 証明書である必要があります
- Exchange Server OAuth 証明書は RSA 証明書である必要があります
- AD FS 要求ベースの認証を使用するが構成されている場合、ECC 証明書を使用できません
次のセクションの表を確認して、ECC 証明書で使用できるサービスを確認します。
ECC 証明書のサポートは既定で無効になっており、オーバーライドを作成することで有効にすることができます。
New-SettingOverride コマンドが実行された後、新しい Exchange 管理シェル (EMS) を開きます。
New-SettingOverride -Name "ECC Support" -Parameters @("Enabled=true") -Component "Global" -Reason "Support ECC" -Section "ECCCertificateSupport"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force
Exchange サービスの証明書要件
証明書を割り当てることができる Exchange サービスを、次の表で説明します。
| サービス | 説明 | サポートされている ECC 証明書 |
|---|---|---|
| IIS (HTTP) | 既定では、次のサービスが、メールボックス サーバーのクライアント アクセス (フロント エンド) サービス内にある既定の Web サイトで提供され、Exchange に接続するためにクライアントによって使用されます。
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 認証を必要とするには、「 ドメイン セキュリティ」を参照してください。 |
はい |
| ユニファイド メッセージング (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 組織の場合、これは、必要となる最小ホスト名の架空の例です。
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 |
Subject Type=End Entity |
該当なし |
| 拇印アルゴリズム | sha2561 | sha2561 | sha2561 |
1 Exchange 2016 累積的な更新プログラム 22 以降および Exchange 2019 累積的な更新プログラム 11 以降の新規インストールに適用されます。 詳細については、「 セットアップ時に SHA-1 ハッシュを使用して作成された Exchange Server 2019 および 2016 証明書」を参照してください。
通常、Exchange 証明書の管理には Windows 証明書マネージャーを使用しません (Exchange 管理センター または Exchange 管理シェル を使用します)。 WMSVC 証明書は Exchange 証明書ではないことにご注意ください。