TLS の証明書または証明書の要求の作成

  • [アーティクル]

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2011-11-04

ここでは、ExchangeCertificate コマンドレットを Exchange 管理シェルで使用して、X.509 トランスポート層セキュリティ (TLS) の証明書または証明書の要求を作成する方法について説明します。

important重要 :
このトピックを読む前に、Microsoft Exchange Server 2007 での全般的な証明書の使用について理解しておく必要があります。「Exchange 2007 Server での証明書の使用」を参照してください。

暗号では、New-ExchangeCertificate コマンドレットによって生成される証明書と関連の秘密キーは TLS キーです。New-ExchangeCertificate コマンドレットでは、証明書に関するメタデータを指定できるので、異なるサービスが同じ証明書と秘密キーを使用することができます。TLS を使用する Exchange サービスの証明書または証明書の要求を作成する前に、SSL および TLS サービスの証明書で使用されるメタデータについて理解しておく必要があります。このメタデータは、生成される証明書では "フィールド" と呼ばれます。

特定のコンピュータのコンピュータ証明書のフィールドを表示するには、Get-ExchangeCertificate コマンドレットを Exchange 管理シェルで使用します。または、Microsoft 管理コンソール (MMC) で証明書マネージャ スナップインを使用します。証明書マネージャ スナップインを使用する方法の詳細については、「Microsoft 管理コンソールに証明書マネージャを追加する方法」を参照してください。

TLS サービスの証明書で使用されるフィールドについて

New-ExchangeCertificate コマンドレットを使って、サード パーティまたはその他の公開キー基盤 (PKI) 証明機関 (CA) に対して証明書の要求を生成する場合は、CA が要求する証明書フィールドと証明書形式について検証してください。

ここでは、最も重要な証明書フィールドについて説明し、証明書および証明書の要求を生成するためのベスト プラクティスをいくつか示します。

サブジェクト名

TLS 証明書のサブジェクト名は、DNS に対応するサービスによって使用されるフィールドです。"サブジェクト名" フィールドは、証明書を特定のサーバーまたはドメイン名にバインドします。

サブジェクト名は、1 つ以上の相対識別名 (RDN) で構成される X.500 の識別名です。次の表は、組織またはサーバー エンティティを識別するために、よく使われる相対識別名を示しています。

名前 短縮形 種類 最大サイズ 頻度 最大\証明書での推奨\要求 サブジェクトの順序

国/地域名

C

ASCII

2

1\1

1

ドメイン コンポーネント

DC

ASCII

255

多

1

都道府県

S

Unicode

128

1

2

場所

L

Unicode

128

1

3

組織

O

Unicode

64

1\1

4

組織単位

OU

Unicode

64

多\多

5

共通名

CN

Unicode

64

多\1

6

国/地域名コードは ISO 3166-1 コードです。詳細については、英語の国名とコード要素を参照してください (このサイトは英語の場合があります)。

note注 :
このトピックにあるサードパーティの Web サイトに関する情報は、必要な技術情報を参照する際に役立つように提供されています。 この URL は、将来予告なしに変更されることがあります。

ドメイン コンポーネントおよび国/地域名は、規則により同時に使用することはできません。国/地域名で名前を参照するか、DNS (ドメイン ネーム システム) で名前を参照することをお勧めします。また、ドメイン コンポーネントの最大サイズ (255 文字) は、すべてのドメイン コンポーネント値の合計です。

important重要 :
証明書は複数の "共通名" フィールドを含むことができますが、一部のサービスは、共通サービスが 1 つのみという前提で実装されます。そのため、複数の共通名を使用すると、相互運用性の問題が発生する可能性があります。作成する証明書または証明書の要求には、1 つの共通名のみを含めることをお勧めします。

相対識別名の実装

サブジェクト名は、コンマ区切りの名前で構成される 1 つのパラメータとして New-ExchangeCertificate コマンドレットで表されます。それぞれの名前は、相対識別名の省略形で識別されます。たとえば、次のサブジェクト名は、国/地域名 = US、組織 = Contoso Corp、共通名 = mail1.contoso.com を表します。

-SubjectName "C=US o=contoso corp, CN=mail1.contoso.com"

同じサーバーを表すことができるサブジェクト名の他の例には、次のものがあります。

-SubjectName  "O=contoso corp, CN=mail1.contoso.com"
-SubjectName "DC=contoso, DC=com, CN=mail1.contoso.com"
-SubjectName "DC= contoso, DC=com, O=contoso corp, CN=mail1.contoso.com"

SMTP メールを送信するために使用する登録済みの DNS 名がある場合は、DC=contoso, DC=com, CN=mail1.contoso.com など、ドメイン コンポーネントの規則および証明書名の DNS 名を使用することをお勧めします。

ただし、CA プロバイダに対して証明書の要求を生成する場合は、"サブジェクト名" フィールドに関する CA の要件と、PKI に関するユーザー独自のニーズを理解しておく必要があります。場合によっては、国/地域名コード ("C") を使用する必要があります。この場合は、相対識別名を X.500 登録機関に登録しなければなりません。

国際サブジェクト名

ASCII 以外の文字を含むサブジェクト名では、SubjectName パラメータを次のように二重引用符で囲んで入力します。

-SubjectName "C=ES,O=Diversión de Bicicleta,CN=mail1.DiversiondeBicicleta.com"

サブジェクト名とドメイン名

規則では、共通名は完全修飾ドメイン名 (FQDN) を含むことができます。これは広く使用されており、推奨の手法ですが、次の 2 つの問題について理解しておく必要があります。

最初に、"共通名" フィールドの最大サイズは 64 文字です。これは、FQDN の最大サイズより少ない文字数です。そのため、FQDN が 64 文字を超える場合は、ドメイン名をサブジェクトの別名に入力する必要があります。DomainName パラメータは、生成される証明書のサブジェクトの別名に対応するパラメータです。

次に、FQDN は ASCII 文字セットのサブセットに制限されます。ただし、共通名 (CN) は Unicode をサポートします。そのため、DNS 名に似ているが無効な DNS 名である CN を使って、有効な証明書を作成することが考えられます。証明書の CN に ASCII 以外の文字が含まれている場合、FQDN 内で CN を検索するソフトウェアは、正しい結果を返すことができません。たとえば、CN=mail.mïcrosoft.com であるサブジェクト名を使って証明書を作成すると、この名前は FQDN としては無視されます。これは、Unicode 文字 (発音記号 (x00ef) の文字 ï) が含まれるためです。肉眼では、発音記号 (x00ef) の文字 ï と ASCII 文字 i (x0069) にはわずかな違いしかないため、Unicode CN を FQDN と間違うことがあります。Exchange 証明タスクでは、サブジェクトの CN が有効な FQDN であることは要求または強制されません。このために、既定ではコマンドレットにサーバーの FQDN が既定の CN として含まれます。

証明書のドメイン名

TLS は DNS ベースのプロトコルであるため、証明書には DNS 名が含まれている必要があります。クライアントは、接続先となると考えられる DNS 名を使って、接続先のサーバーの DNS 名を確認します。これが該当するのは、HTTPS を使用して Web サイトに接続する Web ブラウザ、およびインターネットまたはイントラネット経由で電子メールを送信する SMTP サーバーです。

1 台のサーバーは、次のような理由で複数の DNS 名をサポートすることができます。

  • SMTP サーバーは許可された複数のドメインをサポートできる。
  • クライアントは、サーバー名、ドメイン名、FQDN ローカル名、または負荷分散名により電子メール サーバーにアクセスできる。

TLS 接続が確立されたときに、クライアントが検索中の名前を見つけた場合、クライアントは証明書の他の名前を無視します。複数のドメイン名およびサーバー名を、TLS 証明書の "サブジェクトの別名" フィールドに追加できます。New-ExchangeCertificate コマンドレットの DomainName パラメータを使用して、複数のサブジェクトの別名を含む証明書を作成することができます。DomainName パラメータは複数値にできるので、複数の名前を使用することができます。

X.509 証明書では、0、1、またはそれ以上の DNS 名をサブジェクトの別名 (SubjectAltName) 証明書拡張に含むことができます。SubjectAltName 拡張の DNS 名は、DNS 名の制限と完全に一致します。DNS 名は 255 文字を超えてはならず、A ～ Z、a ～ z、0 ～ 9、およびダッシュ (-) で構成されている必要があります。

ドメイン セキュリティ機能の名前照合ロジック

ドメイン セキュリティ機能の証明書の名前照合ロジックによって、受信した証明書にあるドメイン名が、そのドメインにメールを送信したときのドメイン名と一致しているかどうかが確認されます。例として、woodgrovebank.com という受信者ドメインの FQDN を考えてみます。証明書の名前照合ロジックによって、証明書内のすべての DNS 名が検索され、1 つの DNS 名が一致する限り、その証明書は指定されたドメインについて一致するものとして確認されます。

この例では、証明書の名前照合ロジックによって woodgrovebank.com のようにドメインが正確に一致する証明書が受け入れられます。また、証明書でのワイルドカード文字を含むドメイン名の使用もサポートされているので、*.woodgrovebank.com という DNS 名を含む証明書も一致するものとして受け入れられます。ワイルドカード文字のドメイン名の詳細については、後の「ワイルドカード文字のドメイン名」を参照してください。

証明書の名前照合ロジックでは、DNS で 1 階層下のノードも検索されます。したがって、mail1.woodgrovebank.com も woodgrovebank.com に一致するものとして受け入れられます。ただし、2 階層下のノードの DNS 名は受け入れられません。たとえば、mail1.us.woodgrovebank.com は、woodgrovebank.com に一致するものとして受け入れられません。

Exchange で証明書を選択する方法の詳細については、「SMTP TLS 証明書の選択」を参照してください。

インターネット SMTP のドメイン名のベスト プラクティス

インターネットで SMTP TLS を実行するエッジ トランスポート サーバーの証明書または証明書の要求を作成するときに、要求に含める必要があるドメイン名のセットは次のとおりです。

  • サーバーの完全修飾インターネット ドメイン名   これは、エッジ トランスポート サーバーおよびハブ トランスポート サーバー間で使用される内部的な FQDN とは異なる場合があり、インターネット (パブリック) DNS サーバーで公開される A レコードに一致する必要があります。この名前は、New-ExchangeCertificate コマンドレットの SubjectName パラメータで CN として入力します。
  • 組織で許可されるすべてのドメイン名**   New-ExchangeCertificate** コマンドレットの IncludeAcceptedDomain パラメータを使用して、生成される証明書のサブジェクトの別名を書き込みます。
  • 上のいずれかの項目が含まれていない場合はコネクタの FQDN**   New-ExchangeCertificate** コマンドレットの DomainName パラメータを使用して、生成される証明書のサブジェクトの別名を書き込みます。

クライアント アクセス サーバーのドメイン名のベスト プラクティス

クライアント アクセス サーバーの証明書または証明書の要求を作成するときに、要求に含める必要があるドメイン名のセットは次のとおりです。

  • サーバーのローカル名または NetBIOS 名 (owa1 など)。
  • 組織で許可されるすべてのドメイン名 (contoso.com など)。
  • サーバーの完全修飾ドメイン名 (owa1.contoso.com など)。
  • ドメインの自動検出ドメイン名 (Autodiscover.contoso.com など)。
  • 使用している場合は、サーバーの負荷分散の ID (owa.contoso.com など)。

ワイルドカード文字のドメイン名

ワイルドカード文字のドメイン名は、複数のサブドメインを表す特別な種類のドメイン名です。ワイルドカード文字のドメイン名を使用すると、1 つのワイルドカード ドメイン文字によってそのドメインのすべてのサブドメインを表すことができるので、証明書を簡略化することができます。これらは、DNS ノードでアスタリスク文字 (*) によって表されます。たとえば、*.contoso.com は、contoso.com および contoso.com のすべてのサブドメインを表します。ワイルドカード文字を使って、許可されるすべてのドメインの証明書または証明書の要求を作成すると、要求を大幅に簡略化することができます。

既存の証明書の複製

Exchange 2007 では、インストール時点において Exchange に既知のすべてのサーバー名およびドメイン名をインストール時に使用する、自己署名証明書が作成されます。これらの証明書の有効期間は 12 か月です。場合によっては、サブジェクト名およびサブジェクトの別名を他のコンピュータに使用できる場合、これらの証明書を複製すると有効です。複製できるのは証明書のメタデータのみであり、キー セットは複製されません。

エッジ トランスポート サーバーの役割がインストールされているコンピュータで次のコマンドレットを実行するには、そのコンピュータのローカルの Administrators グループのメンバであるアカウントを使用してログオンする必要があります。

既存の証明書から新しい証明書を複製するには、次のコマンドを実行して、ドメインの現在の証明書を最初に確認する必要があります。

Get-ExchangeCertificate -DomainName mail1.contoso.com

mail1.contoso.com は、複製された証明書を作成するサーバー名または FQDN です。

出力に含まれる最初の証明書は、サーバーの既定の SMTP TLS 証明書です。

証明書を複製するには、次のコマンドを実行します。

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate

ここで、Thumbprint の値は、Get-ExchangeCertificate の出力で表示された最初の証明書からのものです。

このコマンドは、拇印によって識別される既存の証明書から名前を抽出し、それを新しい自己署名証明書で使用します。

サード パーティ証明書サービスに対する要求の生成

CA を使用して証明書を生成する場合は、CA の要件に応じて証明書の要求を提供する必要があります。

証明書の要求を生成するには、New-ExchangeCertificate コマンドレットを使用できます。証明書の要求を生成するには、GenerateRequest パラメータを Path パラメータと共に使用して、要求ファイルを作成する場所を定義します。その結果、PKCS #10 要求 (.req) ファイルが生成されます。PKCS #10 は、RFC 2314 (http://www.ietf.org/rfc/rfc2314.txt) で規定されている証明書要求の構文標準です (このサイトは英語の場合があります)。

note注 :
このトピックにあるサードパーティの Web サイトに関する情報は、必要な技術情報を参照する際に役立つように提供されています。 この URL は、将来予告なしに変更されることがあります。

次の例は、一般的な証明書の要求を示しています。

最初の例では、Contoso のサーバーである mail1 に対して証明書の要求を生成します。サブジェクト名の CN にはサーバーの FQDN が含まれ、サブジェクトの別名には Contoso の許可されているすべてのドメインが含まれます。

New-ExchangeCertificate -GenerateRequest -SubjectName "c=us, o=contoso corp, cn=mail1.contoso.com" -IncludeAcceptedDomains -Path c:\certificates\mail1.contoso.com.req

2 番目の例では、Contoso のサーバーである mail1 に対して証明書の要求を生成します。Contoso には、FQDN が contoso.com である各エッジ トランスポート サーバーに送信コネクタがあります。

New-ExchangeCertificate -GenerateRequest -SubjectName "C=US, O=contoso corp, CN=mail1.contoso.com" -IncludeAcceptedDomains -DomainName mail.contoso.com -Path c:\certificates\mail1.contoso.com.req

3 番目の例では、既存の Contoso.com 証明書から証明書の要求を作成します。

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -Path c:\ certificates\mail1.contoso.com.req

最後の例では、Contoso.com のすべてのサブドメインに対するワイルドカード文字を使って証明書の要求を作成する方法を示します。

New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -DomainName *.contoso.com -Path c:\ certificates\mail1.contoso.com.req

その他の例については、Microsoft Exchange チームのサード パーティの CA で証明書を生成する方法についてのページを参照してください (このサイトは英語の場合があります)。

note注 :
各ブログの内容とその URL は、将来予告なしに変更されることがあります。 各ブログの内容は、保証なしに "現状のまま" 提供され、権利を付与するものではありません。 含まれているスクリプト サンプルまたはコードの使用は、「Microsoft Terms of Use」に規定されている条件に従います (このサイトは英語の場合があります)。

証明書の要求から発行された証明書のインストール

CA に証明書の要求を送信すると、CA は証明書または証明書のチェーンを発行します。いずれの場合も、証明書は Import-ExchangeCertificate コマンドレットを使ってインストールする必要があるファイルとして配信されます。

important重要 :
証明書マネージャ スナップインを使用して、Exchange サーバー上の任意のサービスの証明書をインポートしないでください。証明書マネージャ スナップインを使って Exchange サーバー上の証明書をインポートすると、失敗します。そのため、TLS または他の Exchange 証明書サービスは機能しません。

次の例は、SMTP TLS の証明書をインポートする方法を示しています。

Import-ExchangeCertificate -Path c:\certificates\newcert.cer | Enable-ExchangeCertificate -Services SMTP

次の例は、証明書をインポートし、POP3 (Post Office Protocol Version 3) クライアントをサポートするクライアント アクセス サーバーに対して証明書を有効にする方法を示しています。

Import-ExchangeCertificate -Path c:\certificates\newcert.p7b | Enable-ExchangeCertificate -Services IIS,POP

詳細情報

Exchange 固有の Web サイトを現在運用している証明機関の詳細については、マイクロソフト サポート技術情報の記事 929395「統合通信は、Exchange 2007 と通信サーバー 2007 の Partner を証明書」を参照してください。

暗号および証明書のテクノロジと概念の詳細については、以下の出版物を参照してください。

  • Russ Housley、Tim Polk 共著。『Planning for PKI:Best Practices Guide for Deploying Public Key Infrastructure』。New York:John Wiley & Son, Inc., 2001
  • Carlisle Adams、Steve Lloyd 共著。『Applied Cryptography:Protocols, Algorithms, and Source Code in C』第 2 版。New York:John Wiley & Son, Inc., 1996
  • Microsoft Windows Server 2003 公開キー基盤の実装のベスト プラクティス (このサイトは英語の場合があります)

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。