TLS 証明書について
適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3
トピックの最終更新日: 2016-11-28
暗号では、New-ExchangeCertificate コマンドレットによって生成される証明書と関連の秘密キーは TLS キーです。New-ExchangeCertificate コマンドレットでは、証明書に関するメタデータを指定できるので、異なるサービスが同じ証明書と秘密キーを使用することができます。TLS を使用する Exchange サービスの証明書または証明書の要求を作成する前に、SSL および TLS サービスの証明書で使用されるメタデータについて理解しておく必要があります。このメタデータは、生成される証明書では "フィールド" と呼ばれます。
特定のコンピューターのコンピューター証明書のフィールドを表示するには、Get-ExchangeCertificate コマンドレットを Exchange 管理シェルで使用します。または、Microsoft 管理コンソール (MMC) で証明書マネージャー スナップインを使用します。
TLS 証明書に関連する管理タスクについては、「証明書」を参照してください。
目次
TLS サービスの証明書で使用されるフィールド
証明書の選択
TLS 証明書を作成する
参照
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 コードです。詳細については、「英語の国名と国コード (英語)」を参照してください。
ドメイン コンポーネントおよび国/地域名は、規則により同時に使用することはできません。国/地域名で名前を参照するか、DNS (ドメイン ネーム システム) 名で名前を参照することをお勧めします。また、ドメイン コンポーネントの最大サイズ (255 文字) は、すべてのドメイン コンポーネント値の合計です。
重要
証明書は複数の "共通名" フィールドを含むことができますが、一部のサービスは、共通名が 1 つのみという前提で実装されます。そのため、複数の共通名を使用すると、相互運用性の問題が発生する可能性があります。作成する証明書または証明書の要求には、1 つの共通名のみを含めることをお勧めします。
相対識別名を指定する
New-ExchangeCertificate コマンドレットを使用して証明書要求を作成する場合、サブジェクト名は、コンマ区切りの名前で構成される 1 つのパラメーターとして表されます。それぞれの名前は、相対識別名の省略形で識別されます。たとえば、次のサブジェクト名は、国/地域名 = 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 に一致するものとして受け入れられません。
インターネット SMTP のドメイン名のベスト プラクティス
インターネットで SMTP TLS を実行するエッジ トランスポート サーバーの証明書または証明書の要求を作成するときに、要求に含める必要があるドメイン名のセットは次のとおりです。
サーバーの完全修飾インターネット ドメイン名 これは、エッジ トランスポート サーバーおよびハブ トランスポート サーバー間で使用される内部的な FQDN とは異なる場合があり、インターネット (パブリック) DNS サーバーで公開される A レコードに一致する必要があります。この名前は、New-ExchangeCertificate コマンドレットの SubjectName パラメーターで CN として入力します。
組織のすべての承認済みドメイン名** New-ExchangeCertificate** コマンドレットの IncludeAcceptedDomains パラメーターを使用して、生成される証明書のサブジェクトの別名を書き込みます。
上のいずれかの項目が含まれていない場合はコネクタの FQDN** New-ExchangeCertificate** コマンドレットの DomainName パラメーターを使用して、生成される証明書のサブジェクトの別名を書き込みます。
ワイルドカード文字のドメイン名
ワイルドカード文字のドメイン名は、複数のサブドメインを表す特別な種類のドメイン名です。ワイルドカード文字のドメイン名を使用すると、1 つのワイルドカード ドメイン文字によってそのドメインのすべてのサブドメインを表すことができるので、証明書を簡略化することができます。これらは、DNS ノードでアスタリスク文字 (*) によって表されます。たとえば、*.contoso.com は、contoso.com および contoso.com のすべてのサブドメインを表します。ワイルドカード文字を使って、許可されるすべてのドメインの証明書または証明書の要求を作成すると、要求を大幅に簡略化することができます。
証明書の選択
Exchange は、SMTP 接続の種類に応じて異なる証明書の選択プロセスに従います。
ハブ トランスポート サーバーが相互に、または組織内のエッジ トランスポート サーバーと通信している場合、匿名 TLS 証明書が使用されます。詳細については、「受信匿名 TLS 証明書の選択」および「送信匿名 TLS 証明書の選択」を参照してください。
SMTP ホストまたはクライアントがエッジまたはハブ トランスポート サーバーに接続する場合、STARTTLS 証明書選択プロセスが使用されます。詳細については、「受信用 STARTTLS 証明書の選択」を参照してください。
TLS 証明書を作成する
Exchange 2010 ではインストール中に、インストール時点において Exchange に既知のすべてのサーバー名およびドメイン名を使用する自己署名証明書が作成されます。追加のサーバーで使用するためにこの証明書の複製を作成できます。この証明書をサード パーティ CA によって発行された証明書に置き換えることもできます。次のトピックでは、各タスクの詳細な手順を示します。
参照
暗号および証明書のテクノロジと概念の詳細については、以下の出版物を参照してください。
Russ Housley、Tim Polk 共著。『Planning for PKI:Best Practices Guide for Deploying Public Key Infrastructure』。New York:John Wiley & Son, Inc., 2001
Schneier, Bruce。『Applied Cryptography:Protocols, Algorithms, and Source Code in C』第 2 版。New York:John Wiley & Son, Inc., 1996
© 2010 Microsoft Corporation.All rights reserved.