디지털 인증서 및 SSL 이해
적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3
마지막으로 수정된 항목: 2016-11-28
SSL(Secure Sockets Layer)은 클라이언트와 서버 간의 통신 보안을 유지하는 방법입니다. Microsoft Exchange Server 2010 클라이언트 액세스 서버의 경우 서버 및 클라이언트 간의 통신 보안을 유지하는 데 도움이 되도록 SSL이 사용됩니다. 클라이언트에는 모바일 장치, 조직 네트워크의 내부 컴퓨터 및 외부 컴퓨터가 포함됩니다. 여기에는 VPN(가상 사설망)이 연결된 클라이언트와 연결되지 않은 클라이언트가 포함됩니다.
기본적으로 Exchange 2010을 설치할 때 Microsoft Office Outlook Web App, Exchange ActiveSync 및 Outlook Anywhere를 사용하면 클라이언트 통신이 SSL을 통해 암호화됩니다. 기본적으로 POP3(Post Office Protocol version 3) 및 IMAP4(Internet Message Access Protocol Version 4 rev1)는 SSL을 통해 통신할 수 없게 구성됩니다.
SSL을 사용하려면 디지털 인증서가 필요합니다. 이 항목에서는 다양한 유형의 디지털 인증서 개요 및 이러한 유형의 디지털 인증서를 사용하기 위한 클라이언트 액세스 서버 구성 방법에 대한 정보를 제공합니다.
참고
CNG(Cryptography Next Generation) 인증서는 MicrosoftExchange Server 2010에서 지원되지 않습니다.
목차
디지털 인증서 개요
디지털 인증서 및 프록싱
디지털 인증서 모범 사례
클라이언트 제한 사항
디지털 인증서 개요
디지털 인증서는 사용자나 컴퓨터를 식별하기 위한 온라인 암호 같은 역할을 하는 전자 파일로, 클라이언트 통신에 사용되는 SSL 암호화된 채널을 만드는 데 사용됩니다. 인증서는 CA(인증 기관)에서 인증서 소유자의 신원을 보증하기 위해 발급한 디지털 내역서이며 이 인증서를 통해 해당 당사자들은 암호화를 사용하여 안전한 방식으로 통신할 수 있습니다.
디지털 인증서를 사용하여 다음을 수행할 수 있습니다.
인증서 소유자, 즉 사용자, 웹 사이트, 심지어는 라우터 같은 네트워크 리소스가 실제로 해당 본인 또는 대상이 맞는지 인증합니다.
온라인으로 교환되는 데이터의 도난 또는 변조를 방지합니다.
디지털 인증서는 신뢰할 수 있는 타사 CA 또는 Microsoft Windows PKI(공개 키 인프라)에서 인증서 서비스를 사용하여 발급하거나 자체 서명될 수 있습니다. 인증서의 종류마다 각각의 장단점이 있습니다. 각 종류의 디지털 인증서는 위조할 수 없도록 변조 방지되어 있습니다.
인증서는 여러 가지 사용 목적으로 발급될 수 있습니다. 이러한 사용 목적으로는 웹 사용자 인증, 웹 서버 인증, S/MIME(Secure/Multipurpose Internet Mail Extensions), IPsec(인터넷 프로토콜 보안), TLS(전송 계층 보안), 코드 서명이 해당됩니다.
인증서는 공개 키를 포함하며 해당 개인 키를 소유하는 사용자, 컴퓨터 또는 서비스의 ID에 이러한 공개 키를 첨부합니다. 클라이언트와 서버에서 데이터를 전송하기 전에 데이터를 먼저 암호화할 때 공개 키와 개인 키가 사용됩니다. Windows 기반 사용자, 컴퓨터, 서비스의 경우 신뢰할 수 있는 루트 인증서 저장소에 루트 인증서 사본이 있고 인증서에 올바른 인증 경로가 있으면 CA에 대한 신뢰가 설정됩니다. 인증서가 유효하려면 인증서가 해지되지 않고 유효 기간이 만료되지 않아야 합니다.
인증서 종류
디지털 인증서의 주요 종류에는 자체 서명 인증서, Windows PKI 생성 인증서 및 타사 인증서와 같이 세 가지가 있습니다.
자체 서명 인증서
Exchange 2010을 설치할 때 자체 서명 인증서가 자동으로 구성됩니다. 자체 서명 인증서는 해당 인증서를 만든 응용 프로그램에서 서명합니다. 인증서 제목과 이름이 일치합니다. 발급자와 제목은 인증서에 정의되어 있습니다. 자체 서명 인증서를 사용하면 몇몇 클라이언트 프로토콜이 SSL을 사용하여 통신할 수 있습니다. Exchange ActiveSync 및 Outlook Web App에서는 자체 서명 인증서를 사용하여 SSL 연결을 설정할 수 있습니다. 외부에서 Outlook 사용은 자체 서명 인증서를 사용하여 작동하지 않습니다. 자체 서명 인증서는 클라이언트 컴퓨터나 모바일 장치의 신뢰할 수 있는 루트 인증서 저장소에 수동으로 복사되어야 합니다. 클라이언트가 SSL을 통해 서버에 연결할 때 서버가 자체 서명 인증서를 제시하면 클라이언트가 신뢰할 수 있는 기관에서 인증서가 발급되었는지 확인하는 메시지를 표시합니다. 클라이언트는 발급 기관을 명시적으로 신뢰해야 합니다. 클라이언트에서 트러스트를 확인하는 경우 SSL 통신을 계속할 수 있습니다.
소규모 조직에서는 관리자가 인증서 계층 구조를 직접 만들 수 있는 지식과 경험이 부족하거나 아니면 비용 때문에 또는 두 가지 이유 모두로 인해 타사 인증서를 사용하지 않도록 결정하거나 인증서를 직접 발급하기 위한 PKI를 설치하지 않도록 결정하는 경우가 많습니다. 자체 서명 인증서를 사용할 경우 설치가 간단하고 비용도 최소한으로 유지됩니다. 그러나 자체 서명 인증서를 사용하면 인증서 수명 주기 관리, 갱신, 신뢰 관리 및 해지를 위한 인프라를 설정하기가 훨씬 더 어렵습니다.
Windows 공개 키 인프라 인증서
두 번째 인증서 종류는 Windows PKI 생성 인증서입니다. PKI는 공개 키 암호화를 사용하여 전자 거래에서 각 당사자의 유효성을 확인 및 인증하는 디지털 인증서, 인증 기관 및 RA(등록 기관)로 구성되는 시스템입니다. Active Directory를 사용하는 조직에 PKI를 구현할 때는 인증서 수명 주기 관리, 갱신, 신뢰 관리 및 해지를 위한 인프라를 제공합니다. 그러나 Windows PKI 생성 인증서를 만들고 관리하려면 서버 및 인프라를 배포해야 하므로 약간의 추가 비용이 듭니다.
인증서 서비스는 Windows PKI를 배포하는 데 필요하며 제어판의 프로그램 추가/제거를 통해 설치할 수 있습니다. 도메인의 어떤 서버에나 인증서 서비스를 설치할 수 있습니다.
도메인 가입 Windows CA에서 인증서를 얻으면 해당 CA를 사용하여 네트워크에서 사용 중인 서버나 컴퓨터에 발급할 인증서를 요청하거나 서명할 수 있습니다. 따라서 타사 인증서 공급업체와 비슷하지만 비용이 저렴한 PKI를 사용할 수 있습니다. 다른 종류의 인증서를 공개적으로 배포할 수 있는 것처럼 이러한 PKI를 배포할 수는 없지만 PKI CA가 개인 키를 사용하여 요청자의 인증서에 서명하고 해당 요청자가 확인됩니다. 이 CA의 공개 키는 인증서에 포함되어 있습니다. 신뢰할 수 있는 루트 인증서 저장소에 이 인증서가 있는 서버는 해당 공개 키를 사용하여 요청자의 인증서를 해독하고 요청자를 인증할 수 있습니다.
PKI 생성 인증서를 배포하는 단계는 자체 서명 인증서를 배포하는 절차와 비슷하지만, PKI의 신뢰할 수 있는 루트 인증서 복사본을 Microsoft Exchange에 SSL 연결을 설정하려는 컴퓨터나 모바일 장치의 신뢰할 수 있는 루트 인증서 저장소에 설치해야 합니다.
Windows PKI는 조직이 자체의 인증서를 게시할 수 있도록 합니다. 클라이언트에서는 내부 네트워크의 Windows PKI를 통해 인증서를 요청하고 받을 수 있습니다. Windows PKI는 인증서를 갱신하거나 해지할 수 있습니다.
신뢰할 수 있는 타사 인증서
제3자 인증서나 상업용 인증서는 타사 또는 영리 CA가 생성한 인증서를 사용자 네트워크 서버에 사용할 수 있도록 구입한 것입니다. 자체 서명 인증서와 PKI 기반 인증서의 한 가지 문제점은 인증서가 클라이언트 컴퓨터나 모바일 장치에서 자동으로 신뢰되지 않기 때문에 클라이언트 컴퓨터와 장치의 신뢰할 수 있는 루트 인증서 저장소로 인증서를 가져와야 한다는 것입니다. 제3자 인증서나 상업용 인증서에는 이러한 문제가 없습니다. 영리 CA가 발급한 인증서는 대부분 신뢰할 수 있는 루트 인증서 저장소에 이미 있기 때문에 이미 신뢰된 상태입니다. 발급자를 신뢰할 수 있으면 해당 인증서도 신뢰할 수 있습니다. 제3자 인증서를 사용하면 배포 과정이 매우 간편해집니다.
대규모 조직 또는 인증서를 공개적으로 배포해야 하는 조직의 경우 인증서 관련 비용이 들더라도 타사 인증서나 상업용 인증서를 사용하는 것이 가장 좋습니다. 소규모나 중간 규모의 조직에서는 상업용 인증서가 가장 좋은 방법이 아닐 경우도 있으므로 사용 가능한 다른 인증서 옵션 중 하나를 사용하도록 결정할 수 있습니다.
맨 위로 이동
인증서 종류 선택
설치할 인증서 종류를 선택할 때 고려해야 할 몇 가지 요소가 있습니다. 인증서는 유효한 것으로 서명되어야 합니다. 서명은 자체 서명일 수도 있고 CA에 의해 이뤄질 수도 있습니다. 자체 서명 인증서에는 제한이 있습니다. 예를 들어 일부 모바일 장치의 경우 신뢰할 수 있는 루트 인증서 저장소에 디지털 인증서를 설치할 수 없을 수도 있습니다. 모바일 장치에 인증서를 설치할 수 있는지 여부는 모바일 장치 제조업체와 모바일 서비스 공급자에 따라 달라집니다. 일부 제조업체와 모바일 서비스 공급자는 신뢰할 수 있는 루트 인증서 저장소에 액세스할 수 없도록 설정합니다. 이 경우 자체 서명 인증서와 Windows PKI CA 인증서 모두 모바일 장치에 설치할 수 없습니다.
대부분의 모바일 장치에는 여러 가지 신뢰할 수 있는 타사 상업용 인증서가 사전 설치되어 있습니다. 최적의 사용자 환경을 위해서는 신뢰할 수 있는 타사 CA의 Exchange ActiveSync Mobile 6.0 이상 및 디지털 인증서를 실행하는 장치를 사용하여 Windows에 대해 인증서 기반 인증을 구현합니다.
기본 Exchange 인증서
기본적으로 Exchange는 기본 자체 서명 인증서를 설치하므로 모든 네트워크 통신이 암호화됩니다. 모든 네트워크 통신을 암호화하려면 모든 Exchange 서버는 사용할 수 있는 X.509 인증서가 있어야 합니다. 이 자체 서명 인증서를 클라이언트가 자동으로 신뢰하는 인증서로 대체해야 합니다.
“자체 서명”은 Exchange 서버 자체에서만 인증서를 만들고 서명했다는 것을 의미합니다. 일반적으로 신뢰할 수 있는 CA에 의해 만들어지고 서명되지 않았으므로 기본 자체 서명 인증서는 동일한 조직의 다른 Exchange 서버를 제외한 어떤 소프트웨어에서도 신뢰하지 않습니다. 기본 인증서는 모든 Exchange 서비스에 사용하도록 설정됩니다. 기본 인증서가 설치되는 Exchange 서버의 서버 이름에 해당하는 SAN(주체 대체 이름)이 기본 인증서에 포함됩니다. 또한 서버의 서버 이름 및 FQDN(정규화된 도메인 이름)을 둘 다 포함하는 SAN 목록이 포함됩니다.
Exchange 조직의 다른 Exchange 서버가 이 인증서를 자동으로 신뢰하지만 외부 전자 메일 서버 외에 웹 브라우저, Outlook 클라이언트, 휴대폰 및 기타 전자 메일 클라이언트와 같은 클라이언트는 이 인증서를 자동으로 신뢰하지 않습니다. 따라서 클라이언트 액세스 서버 역할이 설치된 Exchange 서버뿐만 아니라 외부 연결 허브 전송 서버에서도 신뢰할 수 있는 타사 인증서로 이 인증서를 대체하는 것을 고려하십시오. 고유한 내부 PKI가 있고 모든 클라이언트가 해당 엔터티를 신뢰할 경우 직접 발급한 인증서를 사용할 수도 있습니다.
서비스별 인증서 요구 사항
Exchange의 여러 항목에 인증서가 사용됩니다. 또한 대부분의 고객은 둘 이상의 Exchange 서버에서 인증서를 사용합니다. 일반적으로 인증서가 적을수록 쉽게 인증서를 관리할 수 있게 됩니다.
IIS
다음 Exchange 서비스 모두는 지정된 Exchange 서버에서 동일한 인증서를 사용합니다.
Outlook Web App
Exchange 제어판
Exchange 웹 서비스
Exchange ActiveSync
Outlook Anywhere
Autodiscover
Outlook 주소록 배포
단일 인증서만 웹 사이트와 연관시킬 수 있고 이러한 모든 서비스가 기본적으로 단일 웹 사이트 아래에서 제공되므로 이러한 서비스의 클라이언트가 사용하는 모든 이름은 인증서에 있거나 인증서의 와일드카드 이름에 속해야 합니다.
POP/IMAP
POP 또는 IMAP에 사용되는 인증서는 IIS에 사용되는 인증서와 별개로 지정할 수 있습니다. 그러나 관리를 단순화하기 위해 POP 또는 IMAP 서비스 이름을 IIS 인증서에 포함시키고 이러한 모든 서비스에 단일 인증서를 사용하는 것이 좋습니다.
SMTP
허브 전송 서버 또는 Edge 전송 서버에 구성하는 각 수신 커넥터에 별개의 인증서를 사용할 수 있습니다. 인증서는 SMTP 클라이언트 또는 다른 SMTP 서버가 해당 커넥터에 연결하기 위해 사용하는 이름을 포함해야 합니다. 인증서 관리를 단순화하기 위해 TLS 트래픽을 지원해야 하는 모든 이름을 단일 인증서에 포함하는 것을 고려하십시오.
라이브 페더레이션
Windows 공유 시나리오를 위해 Exchange Live와의 페더레이션에 사용되는 인증서는 모든 이름을 포함할 수 있습니다. 페더레이션 프로세스 도중 Exchange 서버에서 사용하게 할 인증서를 식별합니다. 이 인증서는 Windows Live가 신뢰하는 타사 인증 기관에 의해 발급되어야 합니다. Exchange Live가 신뢰하는 타사 인증 기관에서 다른 서비스에 대한 Windows 인증서를 가져올 경우 단일 인증서를 이러한 서비스뿐만 아니라 Windows Live와의 페더레이션에 사용할 수 있습니다.
통합 메시징
Exchange 통합 메시징 서버를 Microsoft Office Communications Server 2007 R2 서버 또는 타사 SIP 게이트웨이나 PBX(Private Branch eXchange) 전화 통신 장비에 연결하면 자체 서명 인증서 또는 신뢰할 수 있는 타사 인증서를 사용하여 보안 세션을 설정할 수 있습니다. 인증서가 인증서 SAN 목록에 모든 통합 메시징 서버의 FQDN을 가지고 있는 경우 통합 메시징 서버에서 단일 인증서를 사용할 수 있습니다. 그렇지 않으면 각 통합 메시징 서버에 대해 서로 다른 인증서를 만들어야 합니다. 이 경우 통합 메시징 서버의 FQDN은 제목 CN(일반 이름) 또는 SAN 목록에 있습니다. Exchange 통합 메시징은 Communications Server 2007 및 Communications Server 2007 R2에서 와일드카드 인증서를 지원하지 않습니다.
Office Communications Server 2007 R2를 사용한 Outlook Web App 인스턴트 메시징
Outlook Web App의 Exchange 2010에는 인스턴트 메시징 공급자에서 현재 상태 및 인스턴트 메시징 기능을 제어하는 추가 기능을 작성할 수 있도록 허용하는 프로그래밍 인터페이스가 포함되어 있습니다. 추가 기능은 Communications Server 2007 R2를 위한 것입니다. 이 추가 기능을 사용할 경우 인증서를 사용하여 Communications Server 2007 R2 서버 및 Exchange 2010 클라이언트 액세스 서버 간의 연결에 보안을 유지해야 합니다. Exchange 클라이언트 액세스 서버에 인증서가 설치되어야 합니다. 인증서 CN 또는 SAN의 호스트 이름 중 하나가 통신 서버의 호스트 권한 부여 목록에 있는 경우 모든 Exchange 2010 클라이언트 액세스 서버에서 여러 인증서 또는 단일 인증서를 사용할 수 있습니다. 이 값은 인증서에서 사용할 수 있는 호스트 이름이 될 수 있습니다(예: mail.contoso.com). 와일드카드 인증서는 Communications Server 2007 또는 2007 R2에 보안 연결을 설정하는 경우에는 지원되지 않습니다.
레거시 Exchange Server
Microsoft Exchange Server 2003 또는 Exchange Server 2007에서 Exchange 2010으로 전환하기 위한 모범 사례를 따를 경우 레거시 버전의 Exchange 및 Exchange 2010 둘 다에 사서함이 있으면 동시 사용 기간 동안 사용할 새 호스트 이름인 legacy.contoso.com을 선택하게 됩니다. 이 레거시 호스트 이름은 사용할 인증서에도 포함되어야 합니다. Exchange Server 2003 및 Exchange 2007에서 Exchange 2010으로 업그레이드하는 방법에 대한 자세한 내용은 Exchange 2003 클라이언트 액세스에서 업그레이드 및 Exchange 2007 클라이언트 액세스에서 업그레이드를 참조하십시오.
맨 위로 이동
디지털 인증서 및 프록싱
한 클라이언트 액세스 서버가 다른 클라이언트 액세스 서버로 클라이언트 연결을 보낼 때 사용되는 방법이 프록싱입니다. 한 클라이언트 액세스 서버가 다른 클라이언트 액세스 서버로 트래픽을 프록시 처리하는 두 가지 시나리오가 있습니다.
인터넷 연결 Active Directory 사이트의 클라이언트 액세스 서버는 인터넷에 연결되지 않은 사이트의 클라이언트 액세스 서버로 트래픽을 프록시 처리합니다. 이렇게 하면 클라이언트 요청의 모든 처리가 클라이언트의 사서함 서버에서 가능한 가깝게 수행됩니다.
Exchange 2010용 클라이언트 액세스 서버는 Exchange 2003 또는 Exchange 2007에 사서함이 있는 클라이언트로부터의 연결을 프록시 처리합니다. 이러한 클라이언트 연결은 Exchange 2007 클라이언트 액세스 서버로 프록시 처리됩니다. 이는 대부분의 Exchange 서비스에서 이전 버전의 Exchange를 실행하는 중인 사서함 서버에 대한 요청을 클라이언트 액세스 서버가 처리할 수 없기 때문입니다.
클라이언트 액세스 서버가 요청을 프록시 처리할 경우 SSL이 암호화에 사용되지만 인증에는 사용되지 않습니다. 대부분의 경우 자체 서명 인증서를 클라이언트 액세스 서버 프록싱에 사용할 수 있습니다. 조직에 특별한 보안 규칙이 필요한 경우 클라이언트 액세스 서버 프록싱에 신뢰할 수 있는 인증서를 요구하도록 설정할 수 있는 구성 키가 있습니다. 이 시나리오에서는 다음 키를 false로 설정하여 구성할 수 있습니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA\AllowInternalUntrustedCerts
레지스트리를 잘못 편집하면 운영 체제를 다시 설치해야 할 수도 있는 심각한 문제가 발생할 수 있습니다. 레지스트리를 잘못 편집하여 발생한 문제는 해결하지 못할 수 있습니다. 레지스트리를 편집하기 전에 중요한 데이터를 백업하십시오.
프록싱에 대한 자세한 내용은 프록시 및 리디렉션 이해를 참조하십시오.
역방향 프록시 및 인증서
대부분의 Exchange 배포에서는 역방향 프록시를 사용하여 인터넷에 Exchange 서비스를 게시합니다. 널리 사용되는 역방향 프록시 제품의 예로는 Microsoft ISA(Internet Security and Acceleration) Server 및 Checkpoint가 있습니다. 이러한 역방향 프록시를 구성하여 SSL 암호화를 종료하고 서버에서 트래픽을 암호화되지 않은 형태로 검사한 다음 역방향 프록시 서버에서 그 뒤에 있는 Exchange 서버로의 새 SSL 암호화 채널을 열 수 있습니다. 이를 SSL 브리징이라고 합니다. 역방향 프록시 서버를 구성하는 또 다른 방법은 SSL 연결이 역방향 프록시 서버를 통과하여 그 뒤에 있는 Exchange 서버로 직접 이동하게 하는 것입니다. 둘 중 하나의 배포 모델을 사용하면 인터넷상의 클라이언트는 Exchange 액세스를 위한 호스트 이름(예: mail.contoso.com)을 사용하여 역방향 프록시 서버에 연결됩니다. 그런 다음 역방향 프록시 서버는 다른 호스트 이름(예: Exchange 클라이언트 액세스 서버의 시스템 이름)을 사용하여 Exchange에 연결됩니다. 대부분의 일반적인 역방향 프록시 서버가 클라이언트에 사용되는 원래 호스트 이름을 Exchange 클라이언트 액세스 서버의 내부 호스트 이름과 일치시킬 수 있으므로 Exchange 클라이언트 액세스 서버의 시스템 이름을 인증서에 포함할 필요가 없습니다.
부하 분산 및 인증서
둘 이상의 클라이언트 액세스 서버가 있는 경우 클라이언트 액세스 서버 배열을 구성하는 것을 고려하십시오. 이 배열을 사용하면 모든 클라이언트는 단일 호스트 이름을 통해 Exchange 클라이언트 액세스 서버에 연결할 수 있습니다. 모든 클라이언트 액세스 서버가 동일한 Active Directory 사이트 내에 있는 경우 클라이언트 액세스 서버 컴퓨터를 하나의 클라이언트 액세스 서버 배열에 원하는 만큼 추가할 수 있습니다. 부하 분산 및 클라이언트 액세스 서버 배열에 대한 자세한 내용은 프록시 및 리디렉션 이해 및 클라이언트 액세스 서버 관리를 참조하십시오.
SSL 및 분할 DNS
분할 DNS는 원래 DNS 요청이 시작된 위치에 따라 동일한 호스트 이름에 다른 IP 주소를 구성할 수 있게 하는 기술입니다. 이는 분할 수평 DNS, 분할 보기 DNS 또는 분할 브레인 DNS로도 알려져 있습니다. 분할 DNS를 사용하면 클라이언트가 인터넷에서 연결되는지 아니면 인트라넷에서 연결되는지 여부에 상관없이 동일한 호스트 이름을 통해 Exchange에 연결할 수 있게 하여 Exchange에 대해 관리해야 할 호스트 이름 수를 줄일 수 있습니다. 분할 DNS에서는 인트라넷에서 시작된 요청이 인터넷에서 시작된 요청과 다른 IP 주소를 수신할 수 있습니다.
소규모 Exchange 배포의 경우에는 사용자가 인트라넷에서 시작되는지 아니면 인터넷에서 시작되는지 여부에 상관없이 동일한 DNS 끝점에 액세스할 수 있으므로 일반적으로 분할 DNS가 필요하지 않습니다. 그러나 대규모 배포의 경우 이 구성을 사용하면 나가는 인터넷 프록시 서버 및 역방향 프록시 서버에 너무 많은 부하가 발생합니다. 대규모 배포의 경우 외부 사용자가 mail.contoso.com에 액세스하고 내부 사용자가 internal.contoso.com에 액세스하도록 분할 DNS를 구성합니다. 이 구성에 분할 DNS를 사용하면 사용자는 자신이 있는 위치에 따라 다른 호스트 이름을 사용해야 한다는 것을 기억할 필요가 없습니다.
원격 PowerShell
Kerberos 인증 및 Kerberos 암호화는 둘 다 Exchange 관리 콘솔 및 Exchange 관리 셸에서의 원격 PowerShell 액세스에 사용됩니다. 따라서 원격 PowerShell에 사용하기 위해 SSL 인증서를 구성할 필요가 없습니다.
맨 위로 이동
디지털 인증서 모범 사례
조직의 디지털 인증서 구성이 특정 요구에 따라 다르지만 조직에 적합한 디지털 인증서 구성을 선택하는 데 도움이 되도록 모범 사례에 대한 정보가 포함되었습니다.
모범 사례: 신뢰할 수 있는 타사 인증서 사용
신뢰할 수 없는 인증서에 대한 오류를 클라이언트가 받지 않도록 하려면 Exchange 서버에 사용되는 인증서는 클라이언트가 신뢰하는 누군가에 의해 발급되어야 합니다. 대부분의 클라이언트는 모든 인증서 또는 인증서 발급자를 신뢰하도록 구성할 수 있지만 Exchange 서버에서 신뢰할 수 있는 타사 인증서를 사용하는 것이 더 간단합니다. 이는 대부분의 클라이언트가 이미 해당 루트 인증서를 신뢰하기 때문입니다. Exchange에 대해 특별히 구성된 인증서를 제공하는 여러 타사 인증서 발급자가 있습니다. Exchange 관리 콘솔을 사용하여 대부분의 인증서 발급자와 작동하는 인증서 요청을 생성할 수 있습니다.
인증 기관 선택 방법
인증 기관은 인증서를 발급하고 인증서의 유효성을 확인하는 회사입니다. 클라이언트 소프트웨어(예: Microsoft Internet Explorer 등의 브라우저나 Windows, Mac OS 등의 운영 체제)에는 신뢰할 수 있는 CA의 기본 제공 목록이 있습니다. 일반적으로 이 목록을 구성하여 CA를 추가 및 제거할 수 있지만 대개 해당 구성은 번거로운 일입니다. 인증서를 구입할 CA를 선택할 때 다음 기준을 사용합니다.
Exchange 서버에 연결되는 클라이언트 소프트웨어(운영 체제, 브라우저 및 휴대폰)가 CA를 신뢰하는지 확인합니다.
Exchange 서버에 사용할 “통합 통신 인증서”를 지원한다고 말하는 CA를 선택합니다.
사용할 인증서 종류를 CA가 지원하는지 확인합니다. SAN(주체 대체 이름) 인증서를 사용하는 것을 고려하십시오. 모든 CA가 SAN 인증서를 지원하는 것은 아니며 일부 CA는 필요한 만큼의 호스트 이름을 지원하지 않습니다.
인증서를 위해 구입한 라이선스에서 원하는 만큼의 서버 수에 인증서를 사용할 수 있도록 허용하는지 확인합니다. 일부 CA는 인증서를 하나의 서버에만 사용하도록 허용합니다.
CA 간의 인증서 가격을 비교합니다.
모범 사례: SAN 인증서 사용
Exchange 배포에서 서비스 이름을 구성하는 방법에 따라 Exchange 서버에는 여러 도메인 이름을 나타낼 수 있는 인증서가 필요할 수 있습니다. 와일드카드 인증서(예: *.contoso.com에 대한 인증서)는 이 문제를 해결할 수 있지만 대부분의 고객은 모든 하위 도메인에 사용할 수 있는 인증서를 유지 관리하는 것과 관련하여 발생할 수 있는 보안 문제를 꺼려 합니다. 보다 안전한 방법은 필요한 각 도메인을 인증서에 SAN으로 표시하는 것입니다. 기본적으로 이 방법은 Exchange에서 인증서 요청을 생성하는 경우 사용됩니다.
모범 사례: Exchange 인증서 마법사를 사용하여 인증서 요청
Exchange에는 인증서를 사용하는 많은 서비스가 있습니다. 인증서를 요청할 때의 일반적인 오류는 올바른 서비스 이름 집합을 포함하지 않고 요청하는 것입니다. Exchange 관리 콘솔의 인증서 요청 마법사를 사용하면 올바른 이름 목록을 인증서 요청에 포함할 수 있습니다. 이 마법사를 사용하면 인증서가 작업해야 하는 서비스를 지정할 수 있고 선택된 서비스에 기초하여 이러한 서비스와 함께 사용할 수 있도록 인증서에 있어야 하는 이름을 포함할 수 있습니다. 초기 Exchange 2010 서버 집합을 배포했으며 배포를 위한 다른 서비스에 사용할 호스트 이름을 결정했으면 인증서 마법사를 실행합니다. 이상적으로는 Active Directory를 배포하는 각 Exchange 사이트에 대해 인증서 마법사를 한 번 실행하면 됩니다.
구매하는 인증서의 SAN 목록에서 호스트 이름을 잊어버릴까 걱정하는 대신에 유예 기간을 무료로 제공하는 인증 기관을 사용할 수 있습니다. 이 기간 동안 인증서를 반환하고 몇 가지 추가 호스트 이름을 가진 동일한 새 인증서를 요청할 수 있습니다.
모범 사례: 가능한 적은 호스트 이름 사용
가능한 적은 인증서를 사용하는 것 외에도 또한 가능한 적은 호스트 이름을 사용해야 합니다. 이 방법으로 비용을 절약할 수 있습니다. 대부분의 인증서 공급자는 인증서에 추가하는 호스트 이름 수에 기초하여 요금을 부과합니다.
갖추어야 하는 호스트 이름 수를 줄이고 결과적으로 인증서 관리를 단순화하기 위해 수행할 수 있는 가장 중요한 단계는 인증서의 주체 대체 이름에 개별 서버 호스트 이름을 포함하지 않는 것입니다.
Exchange 인증서에 포함해야 하는 호스트 이름은 Exchange에 연결하기 위해 클라이언트 응용 프로그램이 사용하는 호스트 이름입니다. 다음은 Contoso라는 회사에 필요한 일반적인 호스트 이름의 목록입니다.
Mail.contoso.com 이 호스트 이름은 Exchange Microsoft Office, Outlook, Outlook Web App Anywhere, 오프라인 주소록, Outlook 웹 서비스, POP3, IMAP4, SMTP, Exchange 제어판, Exchange 등을 비롯한 ActiveSync에 대한 대부분의 연결을 포함합니다.
Autodiscover.contoso.com 이 호스트 이름은 Microsoft Office Outlook 2007 이상 버전, Exchange ActiveSync 및 Exchange 웹 서비스 클라이언트를 비롯한 Autodiscover를 지원하는 클라이언트에 사용됩니다.
Legacy.contoso.com 이 호스트 이름은 Exchange Server 2003 또는 Exchange 2007과의 동시 사용 시나리오에서 필요합니다. 레거시 버전의 Exchange 및 Exchange 2010 둘 다에 사서함이 있는 클라이언트가 있을 경우 레거시 호스트 이름을 구성하면 사용자가 업그레이드 프로세스 도중 두 번째 URL을 알 필요가 없습니다. 업그레이드 및 동시 사용에 대한 자세한 내용은 Exchange 2003 클라이언트 액세스에서 업그레이드 및 Exchange 2007 클라이언트 액세스에서 업그레이드를 참조하십시오.
와일드카드 인증서 이해
와일드카드 인증서는 하나의 도메인과 여러 하위 도메인을 지원하도록 고안되었습니다. 예를 들어, *.contoso.com에 대해 와일드카드 인증서를 구성하면 인증서가 mail.contoso.com, web.contoso.com, autodiscover.contoso.com에서 작동하게 됩니다.
맨 위로 이동
클라이언트 제한 사항
여러 Exchange 클라이언트에서는 지원되는 인증서가 제한됩니다. 아래에는 이러한 클라이언트와 해당 제한 사항이 요약되어 있습니다.
Windows XP 또는 이전 운영 체제에서의 Outlook Windows Anywhere에 사용되는 Outlook RPC over HTTP 구성 요소의 경우 인증서의 SAN 또는 일반 이름이 Outlook Anywhere에 구성된 인증서 사용자 이름과 일치해야 합니다. Outlook 2007 이상에서는 Autodiscover를 사용하여 이 인증서 사용자 이름을 가져옵니다. Exchange 2010 클라이언트 액세스 서버에서 이 값을 구성하려면 Set-OutlookProvider 명령과 함께 -CertPrincipalName 매개 변수를 사용합니다. Outlook 클라이언트가 Outlook Anywhere에 연결하기 위해 사용하는 외부 호스트 이름으로 이 매개 변수를 설정합니다.
Outlook 2010 이전의 Outlook 버전에서는 POP3 및 IMAP4 액세스에 SAN 인증서를 지원하지 않습니다. Outlook 2007 서비스 팩 2의 SAN 지원을 위해 핫픽스를 사용할 수 있습니다. 이 핫픽스는 여기에 있습니다.
모바일 장치 Windows Mobile 5.0을 실행하는 장치 및 일부 Palm 장치를 비롯한 일부 모바일 장치는 와일드카드 인증서를 지원하지 않습니다.
© 2010 Microsoft Corporation. 모든 권리 보유.