デジタル証明書と SSLDigital certificates and SSL

製品: Exchange Server 2013Applies to: Exchange Server 2013

Secure Sockets Layer (SSL) は、クライアントとサーバー間の通信をセキュリティで保護するための方法です。Secure Sockets Layer (SSL) is a method for securing communications between a client and a server. Exchange Server 2013 の場合、SSL は、サーバーとクライアント間の通信をセキュリティで保護するために使用されます。For Exchange Server 2013, SSL is used to help secure communications between the server and clients. クライアントには、携帯電話、組織のネットワーク内のコンピューター、組織のネットワーク外のコンピューターが含まれます。Clients include mobile phones, computers inside an organization's network, and computers outside an organization's network.

既定では、Exchange 2013 をインストールすると、Outlook Web App、Exchange ActiveSync、Outlook Anywhere を使用するときに、SSL を使用してクライアント通信が暗号化されます。By default, when you install Exchange 2013, client communications are encrypted using SSL when you use Outlook Web App, Exchange ActiveSync, and Outlook Anywhere.

SSL では、デジタル証明書を使用する必要があります。SSL requires you to use digital certificates. このトピックでは、さまざまな種類のデジタル証明書の概要と、これらの種類のデジタル証明書を使用するように Exchange 2013 を構成する方法について説明します。This topic summarizes the different types of digital certificates and information about how to configure Exchange 2013 to use these types of digital certificates.

デジタル証明書の概要Overview of digital certificates

デジタル証明書は、ユーザーまたはコンピューターの id を確認するためにオンラインパスワードと同じように機能する電子ファイルです。Digital certificates are electronic files that work like an online password to verify the identity of a user or a computer. クライアント通信に使用される SSL 暗号化チャネルを作成するために使用されます。They're used to create the SSL encrypted channel that's used for client communications. 証明書は、証明書の所有者の身元を保証する証明機関 (CA) によって発行されるデジタルステートメントで、暗号化を使用することで、当事者は安全な方法で通信することができます。A certificate is a digital statement that's issued by a certification authority (CA) that vouches for the identity of the certificate holder and enables the parties to communicate in a secure manner using encryption.

デジタル証明書は次の 2 つの働きをします。Digital certificates do the following:

  • その所有者 (ユーザー、web サイト、およびルーターなどのネットワークリソース) が実際に要求されているかどうかを認証します。They authenticate that their holders (people, websites, and even network resources such as routers) are truly who or what they claim to be.

  • オンラインでやり取りされるデータを盗難や改ざんから保護します。They protect data that's exchanged online from theft or tampering.

デジタル証明書は、信頼されたサードパーティの CA または証明書サービスを使用して Windows 公開キー基盤 (PKI) によって発行されるか、自己署名されたものになることがあります。Digital certificates can be issued by a trusted third-party CA or a Windows public key infrastructure (PKI) using Certificate Services, or they can be self-signed. それぞれの種類の証明書には、長所と短所があります。Each type of certificate has advantages and disadvantages. デジタル証明書の種類によって改ざん防止が可能であり、偽造することはできません。Each type of digital certificate is tamper-proof and can't be forged.

証明書はさまざまな目的で使用するために発行できます。Certificates can be issued for several uses. これらの使用方法には、web ユーザー認証、web サーバー認証、セキュリティで保護されたインターネットメール内線 (S/MIME)、インターネットプロトコルセキュリティ (IPsec)、トランスポート層セキュリティ (TLS)、およびコード署名があります。These uses include web user authentication, web server authentication, Secure/Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol security (IPsec), Transport Layer Security (TLS), and code signing.

証明書には公開キーが含まれ、その公開キーを対応する秘密キーを保持するユーザー、コンピューター、サービスの ID に結び付けます。A certificate contains a public key and attaches that public key to the identity of a person, computer, or service that holds the corresponding private key. 公開キーと秘密キーは、データを送信する前に暗号化するために、クライアントとサーバーによって使用されます。The public and private keys are used by the client and the server to encrypt the data before it's transmitted. Windows ベースのユーザー、コンピューター、およびサービスについては、信頼されたルート証明書ストアにルート証明書のコピーがあり、証明書に有効な証明書のパスが含まれている場合に、CA の信頼が確立されます。For Windows-based users, computers, and services, trust in a CA is established when there's a copy of the root certificate in the trusted root certificate store and the certificate contains a valid certification path. 証明書を有効にするには、証明書が失効していて、有効期限が切れていないことが必要です。For the certificate to be valid, the certificate must not have been revoked and the validity period must not have expired.

証明書の種類Types of certificates

デジタル証明書には、自己署名証明書、Windows PKI で生成された証明書、およびサードパーティの証明書という3つの主要な種類があります。There are three primary types of digital certificates: self-signed certificates, Windows PKI-generated certificates, and third-party certificates.

自己署名入りの証明書Self-signed certificates

Exchange 2013 をインストールすると、自己署名証明書がメールボックスサーバーに自動的に構成されます。When you install Exchange 2013, a self-signed certificate is automatically configured on the Mailbox servers. 自己署名証明書は、それを作成したアプリケーションによって署名されます。A self-signed certificate is signed by the application that created it. 証明書の件名と名前が一致する。The subject and the name of the certificate match. 発行者と件名は、証明書に定義されています。The issuer and the subject are defined on the certificate. この自己署名証明書は、クライアントアクセスサーバーとメールボックスサーバー間の通信を暗号化するために使用されます。This self-signed certificate is used to encrypt communications between the Client Access server and the Mailbox server. クライアントアクセスサーバーは、メールボックスサーバー上の自己署名証明書を自動的に信頼するため、メールボックスサーバー上でサードパーティの証明書は必要ありません。The Client Access server trusts the self-signed certificate on the Mailbox server automatically, so no third-party certificate is needed on the Mailbox server. Exchange 2013 をインストールすると、自己署名証明書もクライアントアクセスサーバー上に作成されます。When you install Exchange 2013, a self-signed certificate is also created on the Client Access server. この自己署名証明書により、一部のクライアントプロトコルは通信に SSL を使用できるようになります。This self-signed certificate will allow some client protocols to use SSL for their communications. Exchange ActiveSync と Outlook Web App では、自己署名証明書を使用して SSL 接続を確立できます。Exchange ActiveSync and Outlook Web App can establish an SSL connection by using a self-signed certificate. Outlook Anywhere は、クライアントアクセスサーバー上の自己署名証明書では機能しません。Outlook Anywhere won't work with a self-signed certificate on the Client Access server. 自己署名証明書は、クライアントコンピューターまたはモバイルデバイスの信頼されたルート証明書ストアに手動でコピーする必要があります。Self-signed certificates must be manually copied to the trusted root certificate store on the client computer or mobile device. クライアントが SSL 経由でサーバーに接続し、サーバーが自己署名証明書を提示した場合、クライアントは証明書が信頼できる機関によって発行されたことを確認するように求められます。When a client connects to a server over SSL and the server presents a self-signed certificate, the client will be prompted to verify that the certificate was issued by a trusted authority. クライアントは、発行機関を明示的に信頼する必要があります。The client must explicitly trust the issuing authority. クライアントが信頼を確認すると、SSL 通信を続行できます。If the client confirms the trust, then SSL communications can continue.

注意

既定では、メールボックスサーバーにインストールされたデジタル証明書は自己署名証明書です。By default, the digital certificate installed on the Mailbox server or servers is a self-signed certificate. 組織内のメールボックスサーバー上の自己署名証明書を、信頼できるサードパーティの証明書に置き換える必要はありません。You don't need to replace the self-signed certificate on the Mailbox servers in your organization with a trusted third-party certificate. クライアントアクセスサーバーは、メールボックスサーバーで自己署名証明書を自動的に信頼し、メールボックスサーバー上の証明書に他の構成は必要ありません。The Client Access server automatically trusts the self-signed certificate on the Mailbox server and no other configuration is needed for certificates on the Mailbox server.

多くの場合、小規模な組織では、サードパーティの証明書を使用しない、または独自の証明書を発行する独自の PKI をインストールしないことを決定します。Frequently, small organizations decide not to use a third-party certificate or not to install their own PKI to issue their own certificates. これらのソリューションはコストがかかるため、独自の証明書階層を作成するために、または両方の理由で、管理者にとっての実績や知識が欠如しているため、この決定を下すことがあります。They might make this decision because those solutions are too expensive, because their administrators lack the experience and knowledge to create their own certificate hierarchy, or for both reasons. 自己署名証明書を使用する場合、コストは最小限に抑えられ、セットアップは簡単です。The cost is minimal and the setup is simple when you use self-signed certificates. ただし、自己署名証明書を使用する場合、証明書ライフサイクル管理、更新、信頼管理、および取り消しのインフラストラクチャを確立するのは、はるかに困難です。However, it's much more difficult to establish an infrastructure for certificate life-cycle management, renewal, trust management, and revocation when you use self-signed certificates.

Windows 公開キー基盤の証明書Windows public key infrastructure certificates

証明書の2番目の種類は、Windows PKI で生成された証明書です。The second type of certificate is a Windows PKI-generated certificate. PKI は、デジタル証明書、証明機関、および登録機関 (RAs) のシステムで、公開キー暗号化を使用して、電子トランザクションに関係する各当事者の有効性を確認および認証します。A PKI is a system of digital certificates, certification authorities, and registration authorities (RAs) that verify and authenticate the validity of each party that's involved in an electronic transaction by using public key cryptography. Active Directory を使用する組織に PKI を実装する場合は、証明書ライフサイクル管理、更新、信頼管理、および失効のためのインフラストラクチャを提供します。When you implement a PKI in an organization that uses Active Directory, you provide an infrastructure for certificate life-cycle management, renewal, trust management, and revocation. ただし、サーバーとインフラストラクチャを展開して、Windows PKI で生成された証明書を作成および管理するために必要な追加のコストがあります。However, there is some additional cost involved in deploying servers and infrastructure to create and manage Windows PKI-generated certificates.

Windows PKI を展開するには、証明書サービスが必要であり、コントロールパネルの [プログラムの追加と削除] を使用してインストールできます。Certificate Services are required to deploy a Windows PKI and can be installed through Add Or Remove Programs in Control Panel. ドメイン内の任意のサーバーに証明書サービスをインストールすることができます。You can install Certificate Services on any server in the domain.

ドメインに参加している Windows CA から証明書を取得する場合、CA を使用して、自分のサーバーまたはネットワーク上のコンピューターに発行する証明書を要求または署名することができます。If you obtain certificates from a domain-joined Windows CA, you can use the CA to request or sign certificates to issue to your own servers or computers on your network. これにより、サードパーティの証明書ベンダーに似た PKI を使用できるようになりますが、費用は低くなります。This enables you to use a PKI that resembles a third-party certificate vendor, but is less expensive. これらの PKI 証明書は、他の種類の証明書としてパブリックに展開することはできません。These PKI certificates can't be deployed publicly, as other types of certificates can be. ただし、PKI CA が秘密キーを使用して要求者の証明書に署名すると、リクエスターが確認されます。However, when a PKI CA signs the requestor's certificate by using the private key, the requestor is verified. この CA の公開キーは、証明書の一部です。The public key of this CA is part of the certificate. 信頼されたルート証明書ストアでこの証明書を持つサーバーは、その公開キーを使用して要求者の証明書を復号化し、リクエスターを認証できます。A server that has this certificate in the trusted root certificate store can use that public key to decrypt the requestor's certificate and authenticate the requestor.

PKI で生成された証明書を展開する手順は、自己署名証明書の展開に必要なものと似ています。The steps for deploying a PKI-generated certificate resemble those required for deploying a self-signed certificate. さらに、Microsoft Exchange への SSL 接続を確立できるようにする必要があるコンピューターまたはモバイルデバイスの信頼されたルート証明書ストアに、信頼されたルート証明書のコピーを PKI からインストールする必要があります。You must still install a copy of the trusted root certificate from the PKI to the trusted root certificate store of the computers or mobile devices that you want to be able to establish an SSL connection to Microsoft Exchange.

Windows PKI を使用すると、組織は独自の証明書を発行することができます。A Windows PKI enables organizations to publish their own certificates. クライアントは、内部ネットワーク上の Windows PKI に対して証明書の要求と受信を行うことができます。Clients can request and receive certificates from a Windows PKI on the internal network. Windows PKI は、証明書の更新または取り消しを行うことができます。The Windows PKI can renew or revoke certificates.

信頼されたサードパーティ証明書Trusted third-party certificates

サードパーティまたは商用証明書は、サードパーティまたは商用 CA によって生成され、ネットワークサーバーで使用するために購入された証明書です。Third-party or commercial certificates are certificates that are generated by a third-party or commercial CA and then purchased for you to use on your network servers. 自己署名された証明書と PKI ベースの証明書に関する問題の1つは、証明書がクライアントコンピューターまたはモバイルデバイスによって自動的に信頼されないため、証明書をクライアントの信頼されたルート証明書ストアにインポートする必要があることです。コンピューターとデバイス。One problem with self-signed and PKI-based certificates is that, because the certificate is not automatically trusted by the client computer or mobile device, you must make sure that you import the certificate into the trusted root certificate store on client computers and devices. サードパーティまたは商用証明書ではこの問題はありません。Third-party or commercial certificates do not have this problem. 証明書が既に信頼されたルート証明書ストアに存在するため、ほとんどの商用 CA 証明書は既に信頼されています。Most commercial CA certificates are already trusted because the certificate already resides in the trusted root certificate store. 発行者は信頼されているため、証明書も信頼されています。Because the issuer is trusted, the certificate is also trusted. サードパーティの証明書を使用すると、展開が大幅に簡素化されます。Using third-party certificates greatly simplifies deployment.

証明書に関連付けられているコストがあっても、証明書を公式に展開する必要がある大規模な組織または組織の場合、ベストソリューションは、サードパーティの証明書または商用の証明書を使用することです。For larger organizations or organizations that must publicly deploy certificates, the best solution is to use a third-party or commercial certificate, even though there is a cost associated with the certificate. Smb 証明書は、小規模および中規模の組織にとって最適なソリューションではない場合があり、利用可能な他の証明書オプションの1つを使用することを決定する場合があります。Commercial certificates may not be the best solution for small and medium-size organizations, and you might decide to use one of the other certificate options that are available.

証明書の種類を選択するChoosing a certificate type

インストールする証明書の種類を選択するときは、いくつかの点を考慮する必要があります。When you choose the type of certificate to install, there are several things to consider. 証明書が有効になるように署名する必要があります。A certificate must be signed to be valid. 自己署名または CA による署名が可能です。It can be self-signed or signed by a CA. 自己署名証明書には制限があります。A self-signed certificate has limitations. たとえば、一部のモバイルデバイスでは、ユーザーが信頼されたルート証明書ストアにデジタル証明書をインストールすることはできません。For example, not all mobile devices let a user install a digital certificate in the trusted root certificate store. モバイルデバイスに証明書をインストールできるかどうかは、モバイルデバイスの製造元とモバイルサービスプロバイダーによって異なります。The ability to install certificates on a mobile device depends on the mobile device manufacturer and the mobile service provider. 一部の製造元およびモバイルサービスプロバイダーは、信頼されたルート証明書ストアへのアクセスを無効にします。Some manufacturers and mobile service providers disable access to the trusted root certificate store. この場合、自己署名証明書も Windows PKI CA からの証明書も、モバイルデバイスにインストールすることはできません。In this case, neither a self-signed certificate nor a certificate from a Windows PKI CA can be installed on the mobile device.

既定の Exchange 証明書Default Exchange certificates

既定では、Exchange はクライアントアクセスサーバーとメールボックスサーバーの両方に自己署名証明書をインストールして、すべてのネットワーク通信が暗号化されるようにします。By default, Exchange installs a self-signed certificate on both the Client Access server and the Mailbox server so that all network communication is encrypted. すべてのネットワーク通信を暗号化するには、すべての Exchange サーバーに使用できる x.509 証明書が必要です。Encrypting all network communication requires that every Exchange server have an X.509 certificate that it can use. クライアントアクセスサーバーでこの自己署名証明書を、クライアントによって自動的に信頼された証明書に置き換える必要があります。You should replace this self-signed certificate on the Client Access server with one that is automatically trusted by your clients.

"自己署名" とは、証明書が作成され、Exchange サーバー自体によってのみ署名されたことを意味します。"Self-signed" means that a certificate was created and signed only by the Exchange server itself. 一般的に信頼された CA によって作成および署名されていないため、既定の自己署名証明書は、同じ組織内の他の Exchange サーバーを除くすべてのソフトウェアによって信頼されることはありません。Because it wasn't created and signed by a generally trusted CA, the default self-signed certificate won't be trusted by any software except other Exchange servers in the same organization. 既定の証明書は、すべての Exchange サービスに対して有効になっています。The default certificate is enabled for all Exchange services. この名前には、インストール先の Exchange サーバーのサーバー名に対応するサブジェクトの別名 (SAN) が含まれています。It has a subject alternative name (SAN) that corresponds to the server name of the Exchange server that it's installed on. また、サーバーのサーバー名と完全修飾ドメイン名 (FQDN) の両方を含む San の一覧もあります。It also has a list of SANs that include both the server name and the fully qualified domain name (FQDN) of the server.

Exchange 組織内の他の Exchange サーバーはこの証明書を自動的に信頼していますが、web ブラウザー、Outlook クライアント、携帯電話、その他の電子メールクライアントなど、外部の電子メールサーバーに加えられたクライアントは自動的に信頼されません。Although other Exchange servers in your Exchange organization trust this certificate automatically, clients like web browsers, Outlook clients, mobile phones, and other email clients in addition to external email servers won't automatically trust it. そのため、この証明書を Exchange クライアントアクセスサーバーの信頼されたサードパーティ証明書に置き換えることを検討してください。Therefore, consider replacing this certificate with a trusted third-party certificate on your Exchange Client Access servers. 独自の内部 PKI があり、すべてのクライアントがそのエンティティを信頼している場合は、自分で発行した証明書を使用することもできます。If you have your own internal PKI, and all your clients trust that entity, you can also use certificates that you issue yourself.

サービス別の証明書要件Certificate requirements by service

証明書は、Exchange のいくつかの用途に使用されます。Certificates are used for several things in Exchange. 多くのお客様は、複数の Exchange サーバー上で証明書を使用することもあります。Most customers also use certificates on more than one Exchange server. 一般に、証明書の数が少ないほど、証明書の管理が簡単になります。In general, the fewer certificates you have, the easier certificate management becomes.

IISIIS

次の Exchange サービスはすべて、指定された Exchange クライアントアクセスサーバー上で同じ証明書を使用します。All the following Exchange services use the same certificate on a given Exchange Client Access server:

  • Outlook Web AppOutlook Web App

  • Exchange 管理センター (EAC)Exchange admin center (EAC)

  • Exchange Web サービスExchange Web Services

  • Exchange ActiveSyncExchange ActiveSync

  • Outlook AnywhereOutlook Anywhere

  • 自動検出Autodiscover

  • Outlook アドレス帳の配布Outlook Address Book distribution

Web サイトに関連付けることができるのは1つの証明書のみであり、既定ではこれらすべてのサービスが1つの web サイトで提供されるため、これらのサービスのクライアントが使用するすべての名前が証明書に含まれている必要があります (または、証明書内のワイルドカード名の下にあります)。).Because only a single certificate can be associated with a website, and because all these services are offered under a single website by default, all the names that clients of these services use must be in the certificate (or fall under a wildcard name in the certificate).

POP/IMAPPOP/IMAP

POP または IMAP に使用する証明書は、IIS で使用される証明書とは別に指定できます。Certificates that are used for POP or IMAP can be specified separately from the certificate that's used for IIS. ただし、管理を簡素化するには、IIS 証明書に POP または IMAP のサービス名を含めることをお勧めします。また、これらのすべてのサービスに対して1つの証明書を使用することをお勧めします。However, to simplify administration, we recommend that you include the POP or IMAP service name in your IIS certificate and use a single certificate for all these services.

SMTPSMTP

構成する受信コネクタごとに個別の証明書を使用できます。A separate certificate can be used for each receive connector that you configure. そのコネクタに接続するために SMTP クライアント (または他の SMTP サーバー) が使用する名前を証明書に含める必要があります。The certificate must include the name that SMTP clients (or other SMTP servers) use to reach that connector. 証明書の管理を簡単にするために、1つの証明書で TLS トラフィックをサポートする必要があるすべての名前を含めることを検討してください。To simplify certificate management, consider including all names for which you have to support TLS traffic in a single certificate.

デジタル証明書とプロキシDigital certificates and proxying

プロキシは、1つのサーバーが別のサーバーにクライアント接続を送信する方法です。Proxying is the method by which one server sends client connections to another server. Exchange 2013 の場合、クライアントアクセスサーバーがクライアントのメールボックスのアクティブコピーを含むメールボックスサーバーに対して受信クライアント要求をプロキシすると、このような処理が行われます。In the case of Exchange 2013, this happens when the Client Access server proxies an incoming client request to the Mailbox server that contains the active copy of the client's mailbox.

クライアントアクセスサーバーがプロキシ要求を行う場合、SSL は認証ではなく暗号化に使用されます。When Client Access servers proxy requests, SSL is used for encryption but not for authentication. メールボックスサーバー上の自己署名証明書は、クライアントアクセスサーバーとメールボックスサーバー間のトラフィックを暗号化します。The self-signed certificate on the Mailbox server encrypts the traffic between the Client Access server and the Mailbox server.

リバースプロキシと証明書Reverse proxies and certificates

多くの Exchange 展開では、リバースプロキシを使用してインターネット上の Exchange サービスを公開しています。Many Exchange deployments use reverse proxies to publish Exchange services on the Internet. リバースプロキシを構成して、SSL 暗号化を終了し、サーバー上でのトラフィックをチェックした後、リバースプロキシサーバーからその背後にある Exchange サーバーへの新しい SSL 暗号化チャネルを開くことができます。Reverse proxies can be configured to terminate SSL encryption, examine the traffic in the clear on the server, and then open a new SSL encryption channel from the reverse proxy servers to the Exchange servers behind them. これは、SSL ブリッジと呼ばれます。This is known as SSL bridging. リバースプロキシサーバーを構成するもう1つの方法は、SSL 接続がリバースプロキシサーバーの背後にある Exchange サーバーに直接到達できるようにすることです。Another way to configure the reverse proxy servers is to let the SSL connections pass straight through to the Exchange servers behind the reverse proxy servers. どちらの展開モデルでも、インターネット上のクライアントは、mail.contoso.com などの Exchange アクセスのホスト名を使用してリバースプロキシサーバーに接続します。With either deployment model, the clients on the Internet connect to the reverse proxy server using a host name for Exchange access, such as mail.contoso.com. その後、リバースプロキシサーバーは、Exchange クライアントアクセスサーバーのコンピューター名など、別のホスト名を使用して Exchange に接続します。Then the reverse proxy server connects to Exchange using a different host name, such as the machine name of the Exchange Client Access server. ほとんどの一般的なリバースプロキシサーバーは、クライアントが使用する元のホスト名と Exchange クライアントアクセスサーバーの内部ホスト名を一致させることができるため、証明書に Exchange クライアントアクセスサーバーのコンピューター名を含める必要はありません。.You don't have to include the machine name of the Exchange Client Access server on your certificate because most common reverse proxy servers are able to match the original host name that's used by the client to the internal host name of the Exchange Client Access server.

SSL と分割 DNSSSL and split DNS

Split DNS は、元の DNS 要求の発生元の場所に応じて、同じホスト名に異なる IP アドレスを構成できるようにするテクノロジです。Split DNS is a technology that allows you to configure different IP addresses for the same host name, depending on where the originating DNS request came from. スプリット ホライズン DNS、スプリット ビュー DNS、またはスプリット ブレイン DNS とも呼ばれます。This is also known as split-horizon DNS, split-view DNS, or split-brain DNS. スプリット DNS を使用すると、クライアントの接続経路 (インターネットまたはイントラネット) に関わらず同じホスト名を使用して Exchange に接続することを許可することで、Exchange で管理する必要のあるホスト名の数を減らすことができます。Split DNS can help you reduce the number of host names that you must manage for Exchange by allowing your clients to connect to Exchange through the same host name whether they're connecting from the Internet or from the intranet. Split DNS は、イントラネットから発信された要求が、インターネットから発信される要求とは異なる IP アドレスを受信することを許可します。Split DNS allows requests that originate from the intranet to receive a different IP address than requests that originate from the Internet.

小規模な Exchange 展開では、ユーザーがイントラネットまたはインターネットのどちらから接続している場合でも、ユーザーは同じ DNS エンドポイントにアクセスできるため、分割 DNS は通常は不要です。Split DNS is usually unnecessary in a small Exchange deployment because users can access the same DNS endpoint whether they're coming from the intranet or the Internet. ただし、大規模な展開では、この構成によって、送信インターネットプロキシサーバーとリバースプロキシサーバーの負荷が大きくなります。However, with larger deployments, this configuration will result in too high of a load on your outgoing Internet proxy server and your reverse proxy server. 大規模な展開の場合は、外部ユーザーが mail.contoso.com および内部ユーザーにアクセスする internal.contoso.com に、分割 DNS を構成します。For larger deployments, configure split DNS so that, for example, external users access mail.contoso.com and internal users access internal.contoso.com. この構成に対して split DNS を使用すると、ユーザーがどこにいるかによって、異なるホスト名を使用することを覚えておく必要がなくなります。Using split DNS for this configuration ensures that your users won't have to remember to use different host names depending on where they're located.

リモート Windows PowerShellRemote Windows PowerShell

Kerberos 認証と Kerberos 暗号化は、Exchange 管理センター (EAC) と Exchange 管理シェルの両方から、リモートの Windows PowerShell へのアクセスに使用されます。Kerberos authentication and Kerberos encryption are used for remote Windows PowerShell access, from both the Exchange admin center (EAC) and the Exchange Management Shell. そのため、リモート Windows PowerShell で使用するために SSL 証明書を構成する必要はありません。Therefore, you won't have to configure your SSL certificates for use with remote Windows PowerShell.

デジタル証明書のベストプラクティスDigital certificates best practices

組織のデジタル証明書の構成は、組織の特定の要件によって異なりますが、ベスト プラクティスに関する情報が含まれており、要件に合うデジタル証明書の構成を選択できます。Although the configuration of your organization's digital certificates will vary based on its specific needs, information about best practices has been included to help you choose the digital certificate configuration that's right for you.

ベストプラクティス: 信頼されたサードパーティの証明書を使用するBest practice: Use a trusted third-party certificate

クライアントが信頼されていない証明書に関するエラーを受信しないようにするには、Exchange サーバーで使用される証明書が、クライアントが信頼するユーザーによって発行される必要があります。To prevent clients from receiving errors regarding untrusted certificates, the certificate that's used by your Exchange server must be issued by someone that the client trusts. ほとんどのクライアントは、すべての証明書または証明書の発行元を信頼するように構成できますが、Exchange サーバー上で信頼されたサードパーティの証明書を使用する方が簡単です。Although most clients can be configured to trust any certificate or certificate issuer, it's simpler to use a trusted third-party certificate on your Exchange server. これは、ほとんどのクライアントが既にルート証明書を信頼しているためです。This is because most clients already trust their root certificates. Exchange 専用に構成された証明書を提供するサードパーティの証明書発行者がいくつかあります。There are several third-party certificate issuers that offer certificates configured specifically for Exchange. EAC を使用して、ほとんどの証明書発行者と連携する証明書要求を生成できます。You can use the EAC to generate certificate requests that work with most certificate issuers.

[方法] 証明機関を選択するHow to select a certification authority

証明機関 (CA) は、証明書の有効性を発行し、保証する会社です。A certification authority (CA) is a company that issues and ensures the validity of certificates. クライアントソフトウェア (たとえば、Microsoft Internet Explorer などのブラウザーや、Windows や Mac OS などのオペレーティングシステム) には、信頼されている CAs の組み込みリストがあります。Client software (for example, browsers such as Microsoft Internet Explorer, or operating systems such as Windows or Mac OS) have a built-in list of CAs they trust. このリストは、通常、CAs を追加および削除するように構成できますが、その構成は煩雑になることがよくあります。This list can usually be configured to add and remove CAs, but that configuration is often cumbersome. 証明書を購入する CA を選択するときは、次の条件を使用します。Use the following criteria when you select a CA to buy your certificates from:

  • Exchange サーバーに接続するクライアントソフトウェア (オペレーティングシステム、ブラウザー、および携帯電話) によって CA が信頼されていることを確認します。Ensure the CA is trusted by the client software (operating systems, browsers, and mobile phones) that will connect to your Exchange servers.

  • Exchange server で使用するための「統合コミュニケーション証明書」をサポートしていることを伝える CA を選択します。Choose a CA that says it supports "Unified Communications certificates" for use with Exchange server.

  • 使用する証明書の種類を CA がサポートしていることを確認してください。Make sure that the CA supports the kinds of certificates that you'll use. サブジェクトの別名 (SAN) 証明書を使用することを検討してください。Consider using subject alternative name (SAN) certificates. すべての CAs が SAN 証明書をサポートしているわけではなく、その他の Ca は必要な数のホスト名をサポートしていません。Not all CAs support SAN certificates, and other CAs don't support as many host names as you might need.

  • 証明書用に購入したライセンスで、使用する予定のサーバーの数に証明書を入れることができることを確認します。Make sure that the license you buy for the certificates allows you to put the certificate on the number of servers that you intend to use. Ca によっては、証明書を1台のサーバーにのみ配置できるものがあります。Some CAs only allow you to put a certificate on one server.

  • CAs 間の証明書の価格を比較します。Compare certificate prices between CAs.

ベストプラクティス: SAN 証明書を使用するBest practice: Use SAN certificates

Exchange 展開でのサービス名の構成方法によっては、Exchange サーバーが複数のドメイン名を表す証明書を必要とする場合があります。Depending on how you configure the service names in your Exchange deployment, your Exchange server may require a certificate that can represent multiple domain names. Contoso.com などの*ワイルドカード証明書はこの問題を解決することができますが、多くのお客様は、どのサブドメインにも使用できる証明書を管理することによるセキュリティへの影響を感じることがあります。Although a wildcard certificate, such as one for *.contoso.com, can resolve this problem, many customers are uncomfortable with the security implications of maintaining a certificate that can be used for any subdomain. より安全な方法として、必要な各ドメインを証明書内の San として一覧表示する方法があります。A more secure alternative is to list each of the required domains as SANs in the certificate. 既定では、このアプローチは、Exchange によって証明書要求が生成されるときに使用されます。By default, this approach is used when certificate requests are generated by Exchange.

ベストプラクティス: Exchange 証明書ウィザードを使用して証明書を要求するBest practice: Use the Exchange certificate wizard to request certificates

Exchange には、証明書を使用する多くのサービスがあります。There are many services in Exchange that use certificates. 証明書を要求するときの一般的なエラーは、サービス名の正しいセットを含めずに要求を行うことです。A common error when requesting certificates is to make the request without including the correct set of service names. Exchange 管理センターの証明書ウィザードは、証明書要求に正しい名前の一覧を含めるのに役立ちます。The certificate wizard in the Exchange admin center will help you include the correct list of names in the certificate request. このウィザードを使用すると、証明書が動作するサービスを指定できます。また、選択したサービスに基づいて、証明書に必要な名前を指定して、それらのサービスで使用できるようにすることもできます。The wizard lets you specify which services the certificate has to work with and, based on the services selected, includes the names that you must have in the certificate so that it can be used with those services. 最初の Exchange 2013 サーバーのセットを展開したときに証明書ウィザードを実行し、展開のさまざまなサービスに使用するホスト名を決定します。Run the certificate wizard when you've deployed your initial set of Exchange 2013 servers and determined which host names to use for the different services for your deployment. Exchange を展開する Active Directory サイトごとに1回だけ証明書ウィザードを実行することが理想的です。Ideally you'll only have to run the certificate wizard one time for each Active Directory site where you deploy Exchange.

購入した証明書の SAN リストにあるホスト名を忘れないようにするのではなく、無料で提供されている証明機関を使用して、証明書を取得して同じ新しい証明書をいくつか要求することができます。追加のホスト名。Instead of worrying about forgetting a host name in the SAN list of the certificate that you purchase, you can use a certification authority that offers, at no charge, a grace period during which you can return a certificate and request the same new certificate with a few additional host names.

ベストプラクティス: 使用するホスト名をできるだけ少なくします。Best practice: Use as few host names as possible

可能な限り少数の証明書を使用するだけでなく、可能な限り多くのホスト名も使用する必要があります。In addition to using as few certificates as possible, you should also use as few host names as possible. この演習では、コストを節約できます。This practice can save money. 多くの証明書プロバイダーでは、証明書に追加するホスト名の数に基づいて料金が請求されます。Many certificate providers charge a fee based on the number of host names you add to your certificate.

必要なホスト名の数を減らすために実行できる最も重要な手順は、証明書のサブジェクトの別名に個々のサーバーのホスト名を含めないようにすることです。The most important step you can take to reduce the number of host names that you must have and, therefore, the complexity of your certificate management, is not to include individual server host names in your certificate's subject alternative names.

Exchange 証明書に含める必要があるホスト名は、Exchange に接続するためにクライアントアプリケーションによって使用されるホスト名です。The host names you must include in your Exchange certificates are the host names used by client applications to connect to Exchange. Contoso という会社に必要な一般的なホスト名の一覧を次に示します。The following is a list of typical host names that would be required for a company named Contoso:

  • Mail.contoso.com: このホスト名には、Microsoft Outlook、Outlook Web App、outlook Anywhere、オフラインアドレス帳、Exchange Web サービス、POP3、IMAP4、SMTP、Exchange コントロールパネル、ActiveSync など、Exchange へのほとんどの接続が含まれています。Mail.contoso.com: This host name covers most connections to Exchange, including Microsoft Outlook, Outlook Web App, Outlook Anywhere, the Offline Address Book, Exchange Web Services, POP3, IMAP4, SMTP, Exchange Control Panel, and ActiveSync.

  • Autodiscover.contoso.com: このホスト名は、Microsoft Office Outlook 2007 以降のバージョン、exchange ActiveSync、および Exchange Web サービスクライアントを含む、自動検出をサポートするクライアントによって使用されます。Autodiscover.contoso.com: This host name is used by clients that support Autodiscover, including Microsoft Office Outlook 2007 and later versions, Exchange ActiveSync, and Exchange Web Services clients.

  • Legacy.contoso.com: このホスト名は、exchange 2007 と exchange 2013 との共存シナリオで必要です。Legacy.contoso.com: This host name is required in a coexistence scenario with Exchange 2007 and Exchange 2013. Exchange 2007 と Exchange 2013 上にメールボックスを持つクライアントがある場合は、レガシホスト名を構成することで、ユーザーはアップグレードプロセス中に2番目の URL を学習する必要がなくなります。If you'll have clients with mailboxes on Exchange 2007 and Exchange 2013, configuring a legacy host name prevents your users from having to learn a second URL during the upgrade process.

ワイルドカード証明書についてUnderstanding wildcard certificates

ワイルドカード証明書は、1つのドメインと複数のサブドメインをサポートするように設計されています。A wildcard certificate is designed to support a domain and multiple subdomains. たとえば、contoso.com の*ワイルドカード証明書を構成すると、mail.contoso.com、web.contoso.com、および autodiscover.contoso.com に対して動作する証明書が生成されます。For example, configuring a wildcard certificate for *.contoso.com results in a certificate that will work for mail.contoso.com, web.contoso.com, and autodiscover.contoso.com.