Exchange 2007 서버에서 인증서 사용

 

적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

마지막으로 수정된 항목: 2008-05-19

Microsoft Exchange Server 2007에서는 인증서를 사용하여 다양한 전자 메일 통신 경로를 안전하게 보호합니다. 이 항목에서는 다음 내용을 통해 Exchange 2007에서 인증서를 사용하는 방법을 자세히 소개합니다.

• Exchange 2007에서의 인증서 사용 방법

• 타사 공용 CA(인증 기관)에서 발급한 인증서 구매 여부 결정 방법 및 기본 자체 서명 인증서만으로 충분한 경우

• Exchange 2007 구성 요소의 인증서 특성 사용 방법 및 인증서 속성과 X.509 인증서 확장 필드와의 관계

• 인증서 신뢰 및 유효성 검사

• Exchange 2007 인증서 만들기, 가져오기 및 사용 방법

• Exchange 구성 요소가 개인 컴퓨터 저장소에서 인증서를 선택하는 방법

이 항목의 각 섹션에는 Exchange 2007 인증서 관련 설명서에 대한 참조와 링크가 포함되어 있습니다.

승인   본 내용의 대부분은 지원 엔지니어인 Stuart Presley가 수집하여 제공하는 Microsoft 내부 문서 및 설명서 내용을 수정한 것입니다.

목차

• Exchange 2007 Components That Use Certificates to Encrypt or Authenticate Sessions

• How to Determine When to Use Certificates Issued by Public CAs and When to Use Self-Signed Certificates

• Understanding Certificate Attributes and How Exchange 2007 Uses Them

• Certificate Trust and Validation

• Creating, Importing, and Enabling Certificates

• Certificate Selection

• For More Information

인증서를 사용하여 세션을 암호화하거나 인증하는 Exchange 2007 구성 요소

Exchange 2007에서는 X.509 인증서를 사용하여 HTTPS, SMTP, POP, IMAP와 같은 프로토콜을 위한 통신 보안 TLS(전송 계층 보안) 및 SSL(Secure Sockets Layer) 전송 채널을 협상합니다.

TLS는 네트워크 상에서 통신하는 두 응용 프로그램 간에 통신 개인 정보 및 보안을 제공하도록 지원하는 IETF(Internet Engineering Task Force) 표준 프로토콜입니다. TLS는 통신을 암호화하며, 클라이언트가 서버를 인증하거나 선택적으로 서버가 클라이언트를 인증하도록 할 수 있습니다. TLS는 TLS가 기반으로 하고 있는 SSL 프로토콜을 보다 안전하게 바꾼 것이라 할 수 있습니다. SSL은 더 이른 시기에 Netscape에서 개발되었습니다. 두 프로토콜의 기능은 동일하며 대부분의 구현에서는 이전 버전의 SSL만 사용하는 클라이언트에게 이전 버전과의 호환성을 제공하기 위해 두 프로토콜을 모두 지원합니다.

TLS 보안 통신은 기밀(암호화) 목적만을 위해 사용하거나 기밀과 인증 목적을 위해 사용할 수 있습니다. 자체 발급되거나 X.509 CA에서 발급되는 것으로 알려진 X.509 인증서는 자체 서명이 가능합니다. X.509 CA는 조직 내에 배포되는 PKI(공개 키 인프라) 또는 인증서를 발급하는 타사 공용 인증 기관입니다. 구체적으로 언급하지 않는 경우 이 항목에서는 두 솔루션을 모두 CA(인증 기관)라고 부르고, 타사 공용 CA는 공용 CA라고 부릅니다.

다음은 인증서를 사용하여 세션을 암호화하거나 인증하는 Exchange 2007 구성 요소입니다.

• SMTP   파트너 조직 간의 도메인 보안을 위해 암호화 및 인증에 인증서를 사용합니다. 인증서는 허브 전송 서버와 Edge 전송 서버 간의 직접 신뢰 연결을 위해 사용되며, 여러 허브 전송 서버 사이에서 SMTP 세션을 암호화하기 위해 사용됩니다. Exchange 2007에서 직접 신뢰란 Active Directory 디렉터리 서비스 또는 ADAM(Active Directory Application Mode) 디렉터리 서비스에 있는 인증서는 유효한 것으로 간주하는 인증 기능입니다. Active Directory는 신뢰할 수 있는 저장소 메커니즘으로 간주됩니다. 또한 인증서는 조직 간의 편의적 TLS 세션에 사용되기도 합니다. 자세한 내용은 Exchange 2007의 TLS 기능 및 관련 용어을 참조하십시오.

• EdgeSync 동기화   Exchange 2007에서 만든 자체 서명 인증서는 Microsoft Exchange EdgeSync 서비스가 Active Directory의 데이터를 Edge 전송 서버의 ADAM 인스턴스로 복제한 후에, Edge 전송 서버의 ADAM 인스턴스와 내부 Active Directory 서버 간의 LDAP 통신 세션을 암호화하는 데 사용됩니다. 자체 서명 인증서는 생성자가 직접 서명한 인증서입니다. Microsoft Exchange EdgeSync 서비스는 Active Directory의 구성 데이터를 가입한 Edge 전송 서버로 정기적으로 복제하는 데이터 동기화 서비스입니다. 자세한 내용은 EdgeSync 동기화 프로세스 이해를 참조하십시오.

• POP3 및 IMAP4   POP3(Post Office Protocol 버전 3) 및 IMAP4(Internet Message Access Protocol 버전 4rev1) 클라이언트와 Exchange 서버 간의 세션 인증 및 암호화에 인증서를 사용합니다. 자세한 내용은 POP3 및 IMAP4 보안 관리를 참조하십시오.

• 통합 메시징   허브 전송 서버와 UM(통합 메시징) IP 게이트웨이 및 Microsoft Office Communications Server 2007에 대한 SMTP 세션 암호화에 인증서를 사용합니다. 자세한 내용은 통합 메시징 VoIP 보안 이해를 참조하십시오.

• 자동 검색   클라이언트와 클라이언트 액세스 서버 간의 HTTP 경로를 암호화하는 데 인증서를 사용합니다. 자세한 내용은 백서: Exchange 2007 자동 검색 서비스(영문)를 참조하십시오.

• 클라이언트 액세스 응용 프로그램   외부에서 Outlook 사용, Microsoft Outlook Web Access, Microsoft Exchange ActiveSync 지원 장치 등 다양한 HTTP 클라이언트와 클라이언트 액세스 서버 간의 경로를 암호화하는 데 인증서를 사용합니다. 자세한 내용은 클라이언트 액세스 보안 관리를 참조하십시오.

Exchange 2007에서 각 데이터 경로를 암호화하고 인증하는 방법에 대한 자세한 내용은 데이터 경로 보안 참조를 참조하십시오.

Return to top

공용 CA에서 발급한 인증서를 사용하는 경우와 자체 서명 인증서를 사용하는 경우를 결정하는 방법

이 섹션에서는 Exchange 2007의 인증서 사용 방법에 대해 간단히 설명하고자 합니다. 이 섹션을 읽은 후에는 사용하도록 설정한 Exchange 구성 요소 및 지원할 클라이언트에 따라 공용 CA로부터 어떠한 종류의 인증서를 구매해야 하는지 파악할 수 있을 것입니다. 또한 이 섹션에서는 인증서 결정에 따른 보다 기술적인 내용에 대해 일반적으로 설명합니다.

이 섹션은 공용 CA에 관한 전반적인 인증서 요구 사항을 신속히 결정할 수 있도록 하기 위한 것이므로 불가피하게 섹션을 간단하게 작성했음을 이해해 주시기 바랍니다. 이를 위해 Exchange 2007에서의 인증서 사용을 설명하는 데 인증서 및 관련 기술에 대한 내용을 일반화였습니다. 이 섹션에 설명된 개념을 이해할 수 없을 경우 이 항목의 나머지 부분 및 참조된 설명서를 읽어 보십시오.

일반적으로 Kerberos, Direct Trust 또는 NTLM 인증을 사용하는 Exchange 2007 구성 요소의 경우 암호화에 자체 서명 인증서를 사용할 수 있습니다. 이 항목에서는 이러한 구성 요소를 내부 Exchange 2007 구성 요소라고 부릅니다. 내부란 데이터 경로가 Exchange 2007 서버 사이와 Active Directory에서 정의한 회사 네트워크 내에 존재한다는 의미입니다.

사용자가 회사 방화벽 밖에서 인증 및 암호화를 필요로 하는 Exchange 구성 요소에 액세스할 때마다 공용 CA에서 발급한 인증서를 배포하는 것이 좋습니다. 예를 들어, Exchange ActiveSync, POP3, IMAP4, 외부에서 Outlook 사용 등 클라이언트 액세스 서버 역할에서 지원하는 다양한 클라이언트는 모두 공용 CA에서 발급하는 인증서를 통해 보호해야 합니다. 이 항목에서는 이러한 구성 요소를 외부 Exchange 2007 구성 요소라고 부릅니다. 외부란 클라이언트와 Exchange 2007 서버 간의 데이터 경로가 회사 방화벽을 통과하여 인터넷까지 확장된다는 의미입니다.

자체 서명 인증서를 사용하는 내부 구성 요소

앞에서 언급한 것처럼 Exchange 2007의 여러 구성 요소에서 인증서를 사용합니다. 일반적으로 인증서를 통해 보호되는 모든 내부 Exchange 데이터 경로에는 공용 CA에서 발급한 인증서가 필요하지 않습니다.

모든 내부 SMTP 및 UM 트래픽은 Exchange 2007 서버 설치 프로그램을 실행할 때 설치되는 자체 서명 인증서로 보호됩니다. New-ExchangeCertificate cmdlet를 사용하여 이러한 인증서를 매년 갱신하더라도, 기본 내부 Exchange 메시징 구성 요소를 실행하는 데 공용 CA에서 발급한 인증서는 필요하지 않습니다.

Exchange 2007에는 TLS 인증서를 만들고 요청하며 관리하는 cmdlet 집합이 있습니다. 이러한 cmdlet에 대한 자세한 내용은 이 항목 뒷부분의 Certificate Cmdlets를 참조하십시오. 기본적으로 이러한 인증서는 자체 서명되어 있습니다. 이 항목의 앞부분에서 설명했듯이 자체 서명 인증서란 만든 사람이 서명하는 인증서입니다. Exchange 2007의 자체 서명 인증서는 기존 Windows CAPI(Certificate API)를 사용하여 Microsoft Exchange를 실행 중인 컴퓨터에서 만들어집니다. 이렇게 만든 인증서는 자체 서명 인증서이므로 일반적으로 CA에서 생성된 인증서보다 신뢰성이 약간 떨어집니다. 따라서 자체 서명 인증서는 다음과 같은 내부 시나리오에만 사용하는 것이 좋습니다.

• 허브 전송 서버 간 SMTP 세션: SMTP 세션 암호화에만 인증서가 사용됩니다. 인증은 Kerberos 프로토콜에서 제공됩니다.

• 허브 전송 서버와 Edge 전송 서버 간 SMTP 세션: SMTP 세션 암호화 및 직접 신뢰 인증에 인증서가 사용됩니다.

• Edge 전송 서버와 Active Directory 간 EdgeSync 동기화: Microsoft Exchange EdgeSync 서비스가 Active Directory의 데이터를 Edge 전송 서버의 ADAM 인스턴스로 복제한 후, Edge 전송 서버의 ADAM 인스턴스와 내부 Active Directory 서버 간의 LDAP 통신 세션을 암호화하는 데 인증서가 사용됩니다.

• 통합 메시징 통신: UM 서버와 UM IP 게이트웨이, IP PBX(Private Branch eXchange) 및 Office Communications Server 2007을 실행하고 있는 컴퓨터 간의 SIP(Session Initiation Protocol)와 RTP(Realtime Transport Protocol) 트래픽을 암호화하는 데 인증서가 사용됩니다. 또한 음성 메일이나 팩스 메시지를 UM 서버에서 허브 전송 서버로 전송하는 경우 SMTP 트래픽을 암호화하는 데에도 인증서가 사용됩니다.

• 내부 클라이언트만 액세스하는 클라이언트 액세스 서버

외부 클라이언트가 Exchange에 액세스하려면 공용 CA에서 발급한 인증서 필요

자체 서명 인증서는 인증에 사용되지 않으므로 내부 Exchange 구성 요소에서는 이 인증서를 사용할 수 있습니다. 하지만 대부분의 Exchange 구성 요소에 대한 인증은 Kerberos나 NTLM에서 제공됩니다. Edge 전송 서버와 허브 전송 서버 간의 통신에는 직접 신뢰 인증이 사용되고, 이 직접 신뢰 인증은 인증서를 통해 제공되며 Edge 전송 서버의 공개 키가 신뢰할 수 있는 저장소인 Active Directory에 저장된다는 사실을 바탕으로 합니다. 그렇지 않을 경우, 자체 서명 인증서를 통해 사용 후 삭제되는 키를 제공함으로써 Exchange 구성 요소 간의 데이터 경로를 암호화합니다.

단, 외부 클라이언트가 인터넷을 통해 Exchange가 호스팅되어 있는 네트워크에 액세스하려면 기존 인증서 신뢰에 대한 확인이 필요합니다. 신뢰 확인을 위해서는 공용 CA에서 발급하는 인증서를 사용하는 것이 가장 좋습니다. 사실 인증서 인증이 필요한 경우에 자체 서명 인증서를 사용하는 것은 바람직하지 않으며, 가능한 한 사용하지 않는 것이 좋습니다. 다음의 경우 공용 CA의 인증서를 사용하는 것이 좋습니다.

• POP3 및 IMAP4 클라이언트의 Exchange 액세스

• Outlook Web Access

• 외부에서 Outlook 사용

• Exchange ActiveSync

• 자동 검색

• 도메인 보안

이러한 모든 경우에는 기본적으로 모든 클라이언트에 의해 트러스트된 공용 CA를 사용하는 것이 가장 좋습니다.

인증서를 발급할 타사 공용 CA의 사양에 따라 인증서 요청을 생성하려면 New-ExchangeCertificate cmdlet를 사용합니다.

자세한 내용은 다음 항목을 참조하십시오.

• New-ExchangeCertificate

• TLS에 대한 인증서 또는 인증서 요청 만들기

• Exchange 2007 학습 내용 - 타사 CA에서 인증서 생성

  참고

  Wiki와 블로그의 콘텐츠 및 URL은 예고 없이 변경될 수 있습니다.

이 섹션의 나머지 부분에서는 구매해야 할 공용 인증서의 유형 결정 방법과 함께, 조직에서 Exchange 2007에 액세스하는 데 사용하는 클라이언트 보호를 위해 여러 개의 인증서를 구매해야 하는지에 대해 설명합니다.

배포를 위해 사용할 공용 CA 발급 인증서 유형 및 수 결정

다음 항목에 따라 조직에 알맞은 공용 CA 발급 인증서 선택이 달라집니다.

• 클라이언트에서 인증서에 와일드카드 이름을 사용할 수 있는지 여부    지원할 클라이언트 종류가 무엇인지 자문해 봅니다. 앞에서 언급했듯이 이 경우 "클라이언트"란 인터넷을 통해 Exchange에 액세스하는 클라이언트입니다.

• 조직의 네임스페이스   인터넷 연결 IIS(인터넷 정보 서비스) 네임스페이스의 구성은 어떠합니까?

• 인증서 원본   인증서를 어디에서 가져옵니까? 선택한 공용 CA에서는 주체 또는 SAN(주체 대체 이름) 필드에 와일드카드 문자를 사용하도록 지원합니까? 그렇지 않다면 SAN 사용은 가능합니까?

다음 섹션에서는 이러한 항목에 대해 보다 자세히 설명합니다.

클라이언트에서 인증서에 와일드카드 이름을 사용할 수 있는지 여부

와일드카드 이름은 X.509 인증서의 주체 또는 SAN 확장에 사용할 수 있습니다. 와일드카드 이름에 대한 자세한 내용은 이 항목 뒷부분에 있는 Understanding Certificate Attributes and How Exchange 2007 Uses Them의 "CertificateDomains"를 참조하십시오.

조직에서 지원할 클라이언트 종류를 결정한 후에는, 클라이언트가 연결되는 서버 인증서에 와일드카드 이름이 사용된 인증서를 클라이언트가 사용할 수 있는지를 결정하면 도움이 됩니다.

클라이언트에서 인증서에 와일드카드 이름을 사용할 수 있을 경우, 조직에 사용하기 위한 전체 인증서 계획이 매우 간단해 집니다. 모든 클라이언트에서 인증서에 와일드카드 이름을 사용할 수 있으며 조직에서 하나의 도메인 이름을 사용할 경우, 인증서 배포 전략에서 네임스페이스를 계획할 필요가 없습니다. 대신, 와일드카드 문자로 네임스페이스를 지원하는 하나의 인증서를 만들 수 있습니다. 예를 들어, Outlook Web Access를 실행하고 있는 클라이언트에서는 메일 액세스에 mail.contoso.com/owa를 사용하고, POP3 클라이언트에서는 메일 액세스에 pop.contoso.com을 사용할 경우, 와일드카드 주체가 *.contoso.com인 단일 인증서에서 두 클라이언트를 모두 지원합니다.

다음은 인증서에 와일드카드 이름을 사용할 수 있는 Microsoft 클라이언트입니다.

• Outlook

  참고

  클라이언트 액세스 역할이 실행 중인 Exchange 서버에 와일드카드 인증서가 배포된 경우 자동 검색 설정을 구성하려면 Outlook 2007 클라이언트 연결을 허용하도록 구성해야 합니다. 이 문제에 대해 자세히 알아보고 이를 해결하려면 외부에서 Outlook 사용 기능을 사용할 때 와일드카드 인증서로 인해 클라이언트 연결 문제 발생을 참조하십시오.

• Internet Explorer(Outlook Web Access)

• Exchange Edge 전송 서버(도메인 보안)

조직이 지원하는 클라이언트에서 서버 인증서에 와일드카드 이름을 사용할 수 없으며, 지원해야 할 클라이언트 네임스페이스가 여러 개일 경우 다음 중 하나를 수행해야 합니다.

1. SAN 확장에 mail.contoso.com, pop.contoso.com, mobile.contoso.com과 같은 여러 이름이 포함된 인증서를 구매합니다.

2. 클라이언트에서 연결할 네임스페이스의 각 엔터티에 대한 인증서를 구매합니다.

조직의 네임스페이스 계획

모든 클라이언트에는 연결할 URL이나 FQDN(정규화된 도메인 이름)이 있어야 합니다. 그리고 클라이언트에서 연결하는 각 경로에는 호스트 이름, NetBIOS 이름, FQDN 또는 클라이언트에서 연결하고 있는 호스트의 일반 이름이 포함된 올바른 인증서가 연결되어야 합니다. 인증서에 포함할 이름 목록을 결정하는 프로세스가 네임스페이스 계획입니다.

일반적으로 서로 다른 다양한 클라이언트를 지원하며 여러 대의 서버로 여러 지역을 연결하는 대규모 조직의 네임스페이스 계획은 소규모 조직의 경우보다 훨씬 복잡합니다.

따라서 Exchange 2007에 대한 인바운드 연결을 보호하기 위해 사용하는 인증서의 SAN 확장에 어떠한 호스트 이름을 포함할지 파악하려면 인증서 네임스페이스 계획을 이해해야 합니다.

자세한 내용은 Exchange Server 2007의 네임스페이스 계획 이해를 참조하십시오.

인증서 구매 장소

앞에서 말했듯이 외부 클라이언트 액세스의 경우에는 공용 타사 CA에서 인증서를 구매하는 것이 좋습니다.

인증 기관을 평가할 때 다음과 같은 기준을 고려합니다.

• 인증서에 와일드카드 이름을 사용할 수 있는 CA입니까? 클라이언트에서 인증서에 와일드카드 이름을 사용할 수 있을 경우, 와일드카드 이름을 지원하는 CA로부터 인증서를 구입하는 것이 안전한 클라이언트를 배포하는 가장 간단한 방법입니다.

• SAN 확장을 지원하는 CA입니까? 다음 조건에 해당할 경우, SAN에 여러 개의 이름을 사용할 수 있는 인증서를 사용하는 것이 합리적일 수 있습니다.

  • 인증서에 와일드카드 이름을 사용할 수 없는 클라이언트를 지원해야 하는 경우

  • 클라이언트에서 연결해야 할 호스트 경로가 여러 개인 경우

  Microsoft는 공용 CA와 파트너 관계를 맺어 통합 통신 인증서를 제공하고 있습니다. 통합 통신 인증서를 지원하는 CA의 최신 목록을 보려면 Microsoft 기술 자료 문서 929395, Exchange 2007 및 Communications Server 2007용 통합 통신 인증 파트너(영문)를 참조하십시오.

• 높은 수준의 신뢰성 확인을 제공하는 CA입니까? 일부 CA의 경우 가격이 지나치게 저렴하며, 인증서 하나에 연간 수백 달러인 CA도 있습니다. 조직에 대한 인바운드 트래픽을 인증하는 데에는 인증서의 무결성을 중시하기 때문에 가격 하나만 가지고 공용 CA를 선택하는 것은 좋지 않습니다. 각 CA의 평판은 물론 제공하는 서비스를 주의 깊게 평가하고 비교한 후 결정합니다.

Return to top

인증서 특성 및 Exchange 2007의 인증서 사용 방법 이해

인증서의 다양한 특성을 이해하면 Exchange에서 인증서를 어떻게 사용하는지 이해하는 데 도움이 됩니다. 또한 Exchange 조직에서 인증서 요구 사항을 계획할 때와 문제 해결에도 도움이 됩니다.

X.509 인증서에는 두 가지 유형의 특성이 있습니다.

• 인증서 필드는 X.509 인증서 자체의 서명된 데이터 내에 있는 특성으로, 이러한 필드는 서명에 의해 무결성이 보호되며, 인증서를 다시 서명하거나 다시 발급하지 않는 한 필드 값을 변경할 수 없습니다.

• 인증서 속성은 인증서나 개인 키의 메타데이터인 특성으로, 인증서의 지문과 같이 일부 속성은 인증서나 개인 키마다 고유합니다. 단, 인증서를 다시 서명하지 않아도 여러 속성을 변경할 수 있습니다.

  예를 들어, Enable-ExchangeCertificate cmdlet를 사용하면 인증서를 만든 후에 인증서 속성에 서비스를 추가할 수 있습니다. IIS(예: Outlook Web Access 또는 Exchange ActiveSync), SMTP(예: 직접 신뢰 또는 도메인 보안), IMAP, POP 및 통합 메시징에서 인증서를 사용하도록 설정할 수 있습니다. 특정 서비스에 인증서를 사용하도록 설정하면 인증서 속성이 업데이트됩니다. 자세한 내용은 Enable-ExchangeCertificate을 참조하십시오.

지정된 인증서에 대해 |FL 인수를 사용하여 Get-ExchangeCertificate cmdlet를 실행하면 이러한 특성을 볼 수 있습니다. Exchange 2007 RTM 버전을 실행하는 경우, |FL* 인수로 cmdlet를 실행해야 모든 특성 데이터가 표시됩니다.

Get-ExchangeCertificate cmdlet 출력에 지정된 일부 필드 및 속성은 MMC(Microsoft Management Console)에서 인증서 관리자를 사용하여 볼 수 있는 X.509 확장 필드에 매핑됩니다. 인증서 관리자에 대한 자세한 내용은 Microsoft Management Console에 인증서 관리자를 추가하는 방법을 참조하십시오. Get-ExchangeCertificate cmdlet에 대한 자세한 내용은 Get-ExchangeCertificate를 참조하십시오.

인증서 필드

앞부분에서 설명한 대로 인증서 필드는 X.509 인증서 자체의 서명된 데이터 내에 있는 특성입니다. 이 섹션에서는 Microsoft Exchange 서비스에서 사용되며 Get-ExchangeCertificate cmdlet 출력에 표시되는 인증서 필드에 대해 설명합니다.

이러한 필드 중 일부는 New-ExchangeCertificate cmdlet를 사용하여 새 인증서나 인증서 요청을 만들 때 설정할 수 있는 매개 변수이기도 합니다. New-ExchangeCertificate cmdlet에 대한 자세한 내용은 New-ExchangeCertificate를 참조하십시오.

이 섹션의 각 인증서 필드는 Get-ExchangeCertificate cmdlet의 출력에 따라 나열됩니다. 그리고 이 섹션에 있는 각 Exchange 인증서 필드 이름은 X.509 인증서 확장 이름에 매핑됩니다.

Issuer

이 필드에는 인증서 발급자를 나타내는 일반 이름이 포함됩니다. 설치 과정 동안 Exchange에서 만들었거나 New-ExchangeCertificate cmdlet에서 만든 자체 서명 인증서에는 cn=hostname이 표시되며, 여기서 hostname이란 로컬 서버의 이름입니다.

CA에서 발급하는 인증서의 Issuer 필드에는 대개 CA의 전체 일반 이름이 표시됩니다.

Issuer 또한 X.509 인증서 확장 이름입니다.

Issuer 필드에는 New-ExchangeCertificate cmdlet에 설정할 수 있는 해당 매개 변수가 없습니다. Issuer 필드는 인증서를 발급하는 엔터티에서 지정합니다.

Subject

이 필드는 인증서의 제목을 나타냅니다. Subject는 일반적으로 인증서를 사용하는 서비스에 액세스하는 데 사용되는 단일 이름을 나타내는 X.500 문자열입니다. New-ExchangeCertificate cmdlet로 만든 인증서인 경우 제목을 명시적으로 제공하지 않으면, New-ExchangeCertificate cmdlet를 실행할 때 Subject가 DomainName 매개 변수에 첫 번째 값으로 나열됩니다. 다음과 같은 X.500 필드가 존재할 수 있습니다.

• C = 국가

• ST = 시/도

• L = 위치

• O = 조직

• OU = 조직 구성 단위

• CN = 일반 이름

이러한 필드 중 일부는 타사 CA의 인증서를 요청할 때 필요합니다. Subject 필드에 대한 자세한 내용은 TLS에 대한 인증서 또는 인증서 요청 만들기를 참조하십시오.

브리징을 위해 Exchange 앞에 Microsoft Internet Security and Acceleration(ISA) Server 2006을 실행하는 경우, 제목 및 ISA Server 동작에 대한 자세한 내용을 보려면 블로그 기사 여러 SAN 항목이 포함된 인증서로 인한 ISA Server 웹 게시 실패 가능성(영문)을 참조하십시오.

Exchange에서 사용자 인수를 사용하지 않고 자체 서명 인증서를 만드는 경우, 제목이 CN=hostname인 인증서가 만들어집니다.

Subject 또한 X.509 인증서 확장 이름입니다.

Subject 필드는 New-ExchangeCertificate cmdlet에서 SubjectName 매개 변수를 지정하여 설정할 수 있습니다.

CertificateDomains

CertificateDomains 필드는 인증서와 연결된 모든 DNS 도메인 이름을 나타냅니다. DNS 도메인 이름은 제목의 일반 이름(cn=) 특성이나 인증서의 SAN 확장에 있을 수 있습니다. Get-ExchangeCertificate cmdlet 출력에는 Subject 필드의 도메인 집합 및 SAN에 있는 모든 도메인이 표시됩니다.

CertificateDomains 필드에 있는 값에는 서버 액세스에 사용되는 호스트 이름이나 FQDN이 포함될 수 있습니다. 인증서를 사용하려면 클라이언트가 서버에 연결하는 데 사용하는 FQDN이 해당 인증서의 CertificateDomains 필드에 표시되어야 합니다.

예를 들어, 클라이언트가 서버 이름이 mail.fourthcofee.com인 POP3를 사용하여 서버에 연결되고 있는 경우, 이 POP3 설정과 관련된 인증서의 CertificateDomains 필드에는 mail.fourthcofee.com이 있을 수 있습니다.

*.fourthcofee.com과 같은 와일드카드 이름을 가진 인증서를 찾을 수도 있으며, 이는 적합한 도메인입니다. 단, 일부 레거시 클라이언트 및 모바일 장치에서는 인증서에 와일드카드 이름을 사용할 수 없으므로 와일드카드 도메인을 사용할 수 없을 수 있습니다.

인증서에서 SAN과 와일드카드 이름을 사용하는 방법에 대한 자세한 내용은 TLS에 대한 인증서 또는 인증서 요청 만들기를 참조하십시오. 또한 Exchange 팀 블로그 Exchange 2007 학습 내용 - 타사 CA에서 인증서 생성(영문)에는 여러 개의 SAN으로 인증서 요청을 만드는 방법에 대한 유용한 정보가 포함되어 있습니다.

X.509 인증서 확장 이름은 Subject Alternative Name이지만, 앞에서 언급한 대로 Get-ExchangeCertificate cmdlet 출력에서 제목 인증서 확장에 포함된 값을 CertificateDomains 필드의 이름 목록에 추가하기도 합니다.

CertificateDomains 필드는 New-ExchangeCertificate cmdlet의 DomainName 및 Subject 매개 변수를 지정하여 설정할 수 있습니다.

NotBefore 및 NotAfter

NotBefore 및 NotAfter 필드의 값은 인증서를 사용할 수 있는 유효한 날짜 범위를 나타냅니다. 현재 날짜가 NotAfter 날짜 이후인 경우 만료된 인증서로 간주합니다. Microsoft Exchange에서는 만료된 인증서를 계속 사용할 수 있지만, 클라이언트가 경고를 생성하고 서버에서 이벤트 로그에 해당 이벤트를 기록합니다.

NotBefore 값에 매핑되는 X.509 인증서 확장 이름은 Valid from입니다. NotAfter에 매핑되는 X.509 인증서 확장 이름은 Valid to입니다.

NotBefore 및 NotAfter 필드에는 New-ExchangeCertificate cmdlet에 설정할 수 있는 해당 매개 변수가 없습니다. 이러한 필드는 인증서를 발급하는 엔터티에서 정의됩니다. Exchange 설치 프로그램에서 생성되거나 New-ExchangeCertificate cmdlet로 만든 자체 서명 인증서는 1년 동안 사용할 수 있습니다.

CertificateRequest

이 값은 요청 상태로 있는 인증서에만 존재합니다. 인증서 요청은 올바른 X.509 인증서가 아니므로 Exchange에서 사용되지 않습니다.

New-ExchangeCertificate cmdlet의 GenerateRequest 매개 변수 스위치를 지정하여 CertificateRequest 필드를 사용하도록 설정합니다.

인증서 속성

앞의 설명대로 인증서 속성은 인증서나 개인 키의 메타데이터인 특성입니다. 인증서의 지문과 같이 일부 속성은 인증서나 개인 키마다 고유하지만, 인증서를 다시 서명하지 않고도 여러 속성을 변경할 수 있습니다.

Thumbprint 속성을 제외하고는 X.509 인증서 확장에 해당하는 Exchange 인증서 속성이 없습니다.

이 섹션에서는 인증서 속성에 대해 설명합니다.

IsSelfSigned

IsSelfSigned 속성은 인증서의 자체 서명 여부를 나타냅니다. 자체 서명 인증서는 일반적으로 루트 인증서로, 루트 인증서란 인증서 체인에 다른 인증서가 없는 인증서를 뜻합니다. Exchange의 자체 서명 인증서는 대개 다음과 같은 종류의 인증서를 나타냅니다.

• 유효한 인증서가 없는 서버에 Exchange를 설치할 때 생성된 인증서

• New-ExchangeCertificate cmdlet를 실행하여 생성된 인증서

허브 전송, Edge 전송, 통합 메시징 또는 클라이언트 액세스 서버 역할을 설치할 때 Exchange 설치 프로그램에서 자체 서명 인증서가 생성됩니다. 호스트 컴퓨터의 개인 인증서 저장소에 유효한 인증서가 있을 경우, Exchange 설치 프로그램에서 생성된 자체 서명 인증서가 아닌 기존 인증서가 사용됩니다. 유효한 값은 True 또는 False입니다.

RootCAType

RootCAType 속성은 인증서를 발급하는 CA 유형을 나타냅니다. IsSelfSigned 매개 변수가 True로 설정된 경우, RootCAType 속성 값은 None이어야 합니다. 그렇지 않으면 해당 인증서로 인해 인증서 선택 과정에서 예상치 못한 결과가 발생할 수 있습니다. 가능한 다른 값은 다음과 같습니다.

• Registry   인증서 저장소에 수동으로 설치된 내부 개인 PKI 루트 CA입니다.

• ThirdParty   공용 타사 루트 CA입니다.

• GroupPolicy   그룹 정책과 함께 배포된 내부 개인 PKI 루트 CA입니다.

• Enterprise   Active Directory와 함께 배포된 내부 개인 PKI 루트 CA입니다.

• Unknown   Exchange에서 설치된 인증서 유형을 결정할 수 없습니다.

루트 CA 인증서가 컴퓨터에 설치된 방법을 이해하면 일관성이 없는 트러스트 정책을 진단하는 데 도움이 될 수 있습니다. 정책이 일관성이 없을 경우 일부 서버에서는 인증서의 유효성이 검사되지만 다른 서버에서는 검사되지 않는 일이 발생할 수도 있습니다.

예를 들어, Registry 값은 누군가가 어느 한 서버에 수동으로 인증서를 설치했음을 나타냅니다. 해당 인증서가 조직의 다른 서버에 설치되지 않은 경우에는 이로 인해 일관성 문제가 발생할 수 있습니다. 그룹 정책이나 Active Directory를 사용하여 인증서를 모든 컴퓨터에 분산하는 것이 좋습니다.

Services

Services 속성은 이 인증서가 사용될 수 있는 서비스를 나타냅니다. 유효한 값은 SMTP, POP, IMAP, UM 및 IIS입니다.

Enable-ExchangeCertificate cmdlet에서 Services 매개 변수를 지정하여 Services 필드에서 값을 설정할 수 있습니다. 자세한 내용은 Enable-ExchangeCertificate을 참조하십시오.

Status

Status 속성은 인증서가 유효한지 여부를 나타냅니다. Status 필드는 인증서 문제를 해결할 때 매우 유용합니다. 지정된 인증서의 Status 값이 Valid가 아닌 경우, Exchange에서는 이 인증서를 어떠한 서비스에도 사용하지 않습니다. Status 속성의 값은 다음과 같습니다.

• 알 수 없음   일반적으로 CRL(인증서 해지 목록)을 사용할 수 없거나 이 서버가 인증서에 연결될 수 없기 때문에 인증서 상태를 확인할 수 없는 경우를 나타냅니다. 컴퓨터가 인증서 해지 기관에 연결될 수 있는지 확인해야 합니다. 자세한 내용은 WinHTTP용 프록시 설정 구성 방법을 참조하십시오.

• 유효함   인증서가 올바로 작동하고 있습니다.

• 해지됨   CRL을 통해 이 인증서가 해지되었음을 알 수 있습니다. 새 인증서를 생성해야 합니다.

• 잘못된 날짜   시스템 시간이 부정확하거나, 인증서가 만료되었거나 파일을 서명한 시스템 시간이 부정확한 상태임을 나타냅니다. 다음 조건에 해당하는지 확인하십시오.

  • 로컬 컴퓨터 시계가 정확합니다.

  • 인증서가 만료되지 않았습니다.

  • 보내는 시스템 시계가 정확합니다.

  인증서가 만료된 경우 새 인증서를 생성해야 합니다.

• 신뢰되지 않음   자체 서명 인증서가 아님을 나타냅니다. 하지만 로컬 컴퓨터에서 신뢰하지 않는 CA에서 서명한 인증서입니다. 컴퓨터의 신뢰할 수 있는 루트 인증 기관 저장소에 CA 인증서를 추가해야 합니다. 로컬 인증서 저장소에 인증서를 수동으로 추가하는 방법에 대한 자세한 내용은 MMC의 인증서 관리자에 대한 도움말 파일을 참조하십시오.

• 유효하지 않음   인증서 경로의 어딘가에서 신뢰할 수 없는 인증서, 유효하지 않은 또는 해지된 인증서와 같은 일부 다른 문제로 인해 이 인증서가 무효화되었습니다.

자세한 문제 해결 내용은 다음 항목을 참조하십시오.

• 인증서 유효성 검사 오류를 수정하는 방법

• PKI 및 프록시 구성 테스트 방법

• WinHTTP용 프록시 설정 구성 방법

HasPrivateKey

HasPrivateKey 속성은 설치된 인증서에 개인 키가 있는지 여부를 나타냅니다. Microsoft Exchange Transport Service, Microsoft Exchange POP3 서비스 및 Microsoft Exchange IMAP4 서비스에서는 개인 키가 없는 인증서를 사용하지 않으므로 이는 매우 중요한 문제입니다.

Thumbprint

Thumbprint 속성은 인증서를 식별하는 고유한 문자열입니다. 여러 Exchange 서버에 동일한 인증서가 설치된 경우 지문을 통해 식별할 수 있습니다. 여러 Edge 전송 서버에서 mail.fourthcoffee.com과 같은 동일한 FQDN으로 메일을 수락하는 경우 일반적으로 여러 Exchange 서버에 동일한 인증서가 설치됩니다. 각 서버마다 새 인증서를 요청하는 것보다 여러 서버에 동일한 인증서를 설치하는 것이 비용 면에서 훨씬 효과적입니다. 단, 해당 인증서에는 내보낼 수 있는 개인 키가 있어야 합니다.

Thumbprint 속성은 다음 cmdlet에 대한 인증서를 지정하는 데 사용됩니다.

• Get-ExchangeCertificate

• Remove-ExchangeCertificate

• Export-ExchangeCertificate

• Enable-ExchangeCertificate

Thumbprint 속성에 매핑되는 X.509 인증서 확장 이름은 Thumbprint라고도 합니다.

Return to top

인증서 신뢰 및 유효성 검사

인증서를 인증 작업에 사용하려면 인증서의 유효성을 검사하고 신뢰할 수 있어야 합니다.

지정된 X.509 인증서의 유효성을 검사하려면 인증서를 발급한 루트 CA를 신뢰해야 합니다. 루트 CA는 가장 신뢰할 수 있는 CA로서, 최상위 CA입니다. 루트 CA는 자체 서명 인증서를 갖고 있습니다. 인증서 인증에 의존하는 응용 프로그램을 실행할 경우 각 인증서는 로컬 컴퓨터의 신뢰할 수 있는 루트 컨테이너에 있는 인증서에서 끝나는 인증서 체인을 갖고 있어야 합니다. 신뢰할 수 있는 루트 컨테이너에는 루트 CA의 인증서가 포함되어 있습니다.

인증서는 다른 인증서를 통해 CA에 연결되며, 이 인증서 또한 CA에서 발급한 것일 수 있으므로 CA에 연결됩니다. 이렇게 인증서가 체인으로 연결되는 것을 인증 경로라고 부릅니다. 인증서가 유효하려면 인증 경로에 있는 모든 인증서가 유효해야 합니다. 또한 체인의 최상위에 있는 인증서는 신뢰할 수 있는 루트 CA여야 합니다.

두 가지 유형의 신뢰할 수 있는 루트 CA인 타사 공용 루트 CA와 개인 루트 CA를 사용하여 인증서 인증을 사용하는 응용 프로그램을 구현할 수 있습니다.

타사 공용 루트 인증 기관

Windows, Windows Mobile 등 다양한 타사 운영 체제에는 기본 제공 타사 공용 루트 CA 집합이 들어 있습니다. 이러한 타사 공용 루트 CA에서 발급하는 인증서를 신뢰하면 해당 CA가 발급한 인증서의 유효성을 검사할 수 있습니다.

다음 조건에 해당할 경우 자동으로 트러스트됩니다.

• 조직에서 Windows 기본 설치를 사용합니다.

• 조직에서 사용하는 클라이언트 소프트웨어와 모바일 장치에서도 기본 제공 타사 공용 루트 CA를 신뢰합니다.

이 경우 추가 트러스트 구성이 필요하지 않습니다.

신뢰할 수 있는 개인 루트 인증 기관

신뢰할 수 있는 개인 루트 CA는 개인 또는 내부 PKI에 의해 배포된 루트 CA입니다. 예를 들어, 조직에서 자체 루트 인증서를 가진 내부 PKI를 배포한 경우 추가 트러스트 구성을 수행해야 합니다.

일반적으로 조직에 대한 외부 연결을 지원하는 클라이언트 응용 프로그램에 개인 PKI에서 발급한 인증서를 사용하는 것은 바람직하지 않습니다.

개인 루트 CA를 사용하는 경우, 인증서 인증이 필요한 모든 장치, 클라이언트 및 Windows 운영 체제에 있는 Windows 신뢰할 수 있는 루트 인증서 저장소를 업데이트해야 합니다.

직접 루트 트러스트와 상호 인증의 두 가지 방법으로 트러스트를 구성할 수 있습니다.

직접 루트 트러스트

개인 루트 CA에서 발급한 인증서를 트러스트하려면, Windows를 실행하고 있는 컴퓨터의 신뢰할 수 있는 루트 인증서 저장소에 해당 루트 인증서를 수동으로 추가하면 됩니다. 경우에 따라 루트 인증서를 모바일 클라이언트의 신뢰할 수 있는 루트 저장소에도 추가할 수도 있습니다. Windows를 실행하고 있는 컴퓨터의 로컬 인증서 저장소에 인증서를 수동으로 추가하는 방법에 대한 자세한 내용은 MMC의 인증서 관리자에 대한 도움말 파일을 참조하십시오. Windows Mobile 장치에 인증서를 설치하는 방법에 대한 자세한 내용은 Windows Mobile 기반 장치에 루트 인증서를 설치하는 방법(영문)을 참조하십시오.

상호 인증

상호 인증은 하나의 CA가 다른 CA에서 생성된 인증서에 서명할 경우 발생합니다. 상호 인증은 하나의 PKI에서 다른 PKI와의 트러스트를 작성하는 데 사용됩니다. 고유한 PKI가 있을 경우 다른 개인 PKI의 루트 CA에 대해 직접 수동 트러스트를 사용하는 대신, 루트 CA 밑에 있는 다른 CA에 대해 상호 인증서를 만들 수 있습니다. 이 경우 상호 인증서가 결국 신뢰할 수 있는 루트 CA에 다시 연결되므로 트러스트가 설정됩니다.

인증서 해지 목록에 대한 액세스 구성

SMTP/TLS 시나리오의 Microsoft Exchange Transport Service나 HTTPS 시나리오의 IIS와 같은 특정 서비스에서 인증서를 검색하는 경우, 해당 서비스는 인증서 체인 및 인증서 자체의 유효성을 검사합니다. 인증서 유효성 검사는 인증서의 많은 특성이 확인되는 프로세스입니다. 이러한 특성의 대부분은 인증서를 요청하는 응용 프로그램이 로컬 컴퓨터에서 확인할 수 있습니다. 예를 들어 인증서의 용도, 인증서의 만료 날짜 및 이와 유사한 특성을 PKI의 컨텍스트 외부에서 확인할 수 있습니다. 그러나 인증서가 해지되지 않은 확인은 인증서를 발급한 CA를 통해 유효성을 확인해야 합니다. 따라서 대부분의 CA는 일반인이 해지 상태의 유효성을 검사하는 데 사용할 수 있도록 CRL(인증서 해지 목록)을 제공합니다.

인증서를 사용하여 인증 작업을 수행하려면 클라이언트를 인증하는 서비스에서 해당 CA에 대한 CRL을 사용할 수 있어야 합니다. 해지를 확인하지 못하는 경우 인증 서비스가 실패합니다.

인증 서버는 외부 CA에 대한 CRL에 액세스할 수 있어야 합니다.

모든 공용 CA에는 조직의 서버에서 연결할 수 있는 공개 가능한 CRL이 있습니다. 경우에 따라 개인 내부 PKI용 CRL은 LDAP(Lightweight Directory Access Protocol)에서만 사용할 수 있으나, 대부분의 경우 공용 CA에서는 CRL이 HTTP를 통해 게시됩니다. 서버와 클라이언트가 CRL에 연결될 수 있도록 적절한 아웃바운드 포트 및 프록시가 구성되어야 합니다. MMC의 인증서를 열고 CRL 배포 지점 필드를 봄으로써 주어진 CRL 배포 지점이 허용하는 프로토콜을 결정할 수 있습니다.

인증서를 발급하는 CA에 대한 CRL을 공개 상태로 설정해야 하는 경우도 있습니다. 예로 들어, 도메인 보안을 배포하는 경우 Edge 전송 서버에서 조직의 인증서를 검색하더라도 인증서 체인의 유효성 검사를 통해 해당 인증서의 유효성을 검사한다는 사실을 이해해야 합니다. 따라서 CA에 대한 CRL을 사용자의 Edge 전송 서버에서 사용할 수 있어야 합니다. 또한 도메인 보안 전자 메일을 교환하는 모든 파트너는 인증서를 발급한 CA에 대한 CRL에 액세스할 수 있어야 합니다.

WinHTTP용 프록시 설정 구성

Exchange 2007 서버는 원본 Windows HTTP 서비스(WinHTTP)를 사용하여 모든 HTTP 및 HTTPS 트래픽을 관리합니다. 예를 들어, 허브 전송 서버와 Edge 전송 서버 모두 HTTP를 사용하여 Exchange 2007 Standard 스팸 방지 필터 업데이트용 업데이트 및 Microsoft Forefront Security for Exchange Server 스팸 방지 업데이트 서비스에 액세스할 수도 있습니다. 모든 Exchange 서버 역할에서는 CRL 유효성 검사를 위해 WinHTTP를 사용합니다.

자세한 내용은 WinHTTP용 프록시 설정 구성 방법을 참조하십시오.

PKI 및 프록시 구성 테스트

특정 Exchange 서버에 대한 PKI 및 프록시 구성을 확인하려면 Certutil.exe를 사용하여 서버 인증서의 인증서 체인을 확인합니다. Certutil.exe는 Windows Server 운영 체제에서 인증서 서비스의 일부로 설치되는 명령줄 도구입니다. 자세한 내용은 PKI 및 프록시 구성 테스트 방법을 참조하십시오.

Return to top

인증서 만들기, 가져오기 및 사용

Exchange 2007에 설치되어 작동하는 인증서는 여러 가지 방법을 통해 얻을 수 있으므로, 필요에 따라 방법을 선택하면 됩니다. Exchange 2007에서는 기본 구성을 보호할 수 있도록 자체 서명 인증서 집합을 만듭니다. 시스템 보안을 보장하려면 시간이 흐름에 따라 이 인증서 집합을 갱신해야 합니다. Exchange에서는 인증서 기관에 대한 서명 요청을 자동으로 생성하지 않습니다. 새 자체 서명 인증서를 만들거나 인증 기관에 대한 인증서 요청을 만드는 작업에는 모두 동일한 cmdlet가 사용됩니다.

이 섹션에서는 Exchange 2007에서 사용하는 인증서에 대해 수행할 수 있는 작업에 대해 간략하게 설명합니다. ExchangeCertificate cmdlet에 익숙지 않은 경우 이 섹션을 읽어 보십시오. 이 문서의 뒷부분에는 POP3를 예로 사용한 응용 프로그램별 예와 절차가 제시되어 있습니다. 또한 응용 프로그램별 설명서에 대한 링크도 제공됩니다.

인증서 Cmdlet

이전 버전의 Exchange Server에서는 모든 인증서 관리가 IIS와 MMC의 인증서 관리자를 통해 이루어졌습니다. Exchange 2007에서는 Exchange와 관련된 대부분의 인증서 관리 작업을 Exchange 관리 셸에서 다음과 같은 ExchangeCertificate cmdlet를 사용하여 수행할 수 있습니다.

• New-ExchangeCertificate   이 cmdlet는 자체 서명 인증서 및 인증 기관에 대한 인증서 요청을 생성합니다.

• Import-ExchangeCertificate   이 cmdlet는 이전에 내보낸 인증서를 가져오고, CA에서 생성한 인증서 파일을 가져옵니다.

• Export-ExchangeCertificate   이 cmdlet는 백업용 또는 복수 서버에서 사용할 인증서를 내보냅니다.

• Enable-ExchangeCertificate   이 cmdlet는 인증서에 대해 특정 서비스를 사용하도록 설정합니다.

• Get-ExchangeCertificate   이 cmdlet는 인증서의 특성을 표시합니다.

• Remove-ExchangeCertificate   이 cmdlet는 Exchange Server 및 로컬 인증서 저장소에서 인증서를 제거합니다.

인증 기관에 대한 인증서 요청을 만드는 방법에 대한 자세한 내용은 TLS에 대한 인증서 또는 인증서 요청 만들기를 참조하십시오.

다음 섹션에서는 간단한 예를 통해 ExchangeCertificate cmdlet를 사용하여 일반적인 인증서 작업을 수행할 수 있는 방법을 설명합니다. 자세한 내용 및 예를 보려면 전역 cmdlet 아래에 있는 ExchangeCertificate cmdlet 도움말을 참조하십시오.

자체 서명 인증서 생성

호스트 이름이 Server1이고 도메인이 fourthcoffee.com인 서버에 대해 SMTP 서비스에서 사용할 자체 서명 인증서를 생성하려면 다음 명령을 실행합니다.

New-ExchangeCertificate -DomainName "server1.fourthcoffee.com", "server1" -Services "SMTP"

자체 서명 인증서 복제

기존의 자체 서명 인증서를 갱신해야 할 경우 다음 명령을 실행하여 인증서를 복제합니다.

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

thumbprint 자리 표시자는 갱신할 인증서의 지문입니다. 새 인증서에 대한 서비스도 다음과 같은 명령으로 지정할 수 있습니다.

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate -Services SMTP,POP,IMAP

그러면 다음 명령을 실행하여 이 인증서를 사용하도록 설정할 수 있습니다.

Enable-ExchangeCertificate <thumbprint>

인증서 요청 만들기 및 신뢰할 수 있는 인증서 설치

공용 타사 인증서를 설치하는 프로세스는 좀 더 복잡합니다. 인증서 요청을 생성하고, 발급된 인증서 및 필요한 모든 CA 인증서를 가져온 후 발급된 인증서를 의도한 용도에 맞게 사용하도록 설정해야 합니다.

이 섹션에서는 인증서 사용을 위한 POP3 서비스 사용 설정 방법의 예를 설명합니다. 이 예에서 클라이언트는 popserver.fourthcoffee.com FQDN에 연결하여 POP3 서비스에 연결됩니다.

인증서 요청

결과 인증서는 공용 타사 CA에서 가져오므로 먼저 다음 명령을 실행하여 인증서를 요청해야 합니다.

New-ExchangeCertificate -DomainName popserver.fourthcoffee.com -SubjectName "c=us,o=contoso corp, cn=popserver.fourthcoffee.com" -PrivateKeyExportable:$True -GenerateRequest:$True -Path "C:\CertRequest.req"

올바로 인증서가 요청되면, 인증서 요청 파일(.cer 또는 .der)이 시스템 드라이브의 루트에 생성되고 Exchange 관리 셸에 해당 요청의 지문이 표시됩니다.

이전 명령에서는 이 인증서를 개인 키와 함께 내보내어 동일한 FQDN을 사용하여 액세스해야 할 수도 있는 여러 Exchange 서버에서 사용할 수 있도록 PrivateKeyExportable 매개 변수를 $True로 설정합니다. 예를 들어, POP3 연결을 지원하기 위해 여러 클라이언트 액세스 서버의 부하가 분산될 수도 있습니다.

이전 명령에서도 Subjectname 매개 변수가 X.500 이름으로 지정됩니다. 대부분의 타사 CA에서는 인증서의 주체 이름에 유효한 X.500 이름을 지정해야 합니다. 또한 적어도 organizationName (o=) 필드에 나열된 조직은 웹 서버의 **commonName (cn=)**에 표시되는 도메인 이름을 소유해야 합니다.

요청이 완료되면 요청 파일을 인증서 공급업체에 전송하여 인증서를 얻을 수 있습니다.

인증서 가져오기

CA에서 인증서를 반환하면 이를 Exchange 서버로 가져와야 합니다. New-ExchangeCertificate cmdlet를 사용하여 요청한 인증서를 올바로 가져오려면 다음 명령을 실행합니다.

Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

인증서를 가져오면 이 명령에서는 특정 서비스를 사용하도록 설정하는 데 사용할 수 있는 인증서 지문을 반환합니다.

인증서 사용

인증서를 사용하도록 설정하면 특정 인증서를 사용할 서비스를 지정할 수 있습니다. 다음 명령을 통해 발급된 인증서를 POP3 서비스에 사용할 수 있습니다.

Enable-ExchangeCertificate <thumprint> -Services:"POP"

다음 명령을 실행하면 인증서를 가져오는 동시에 이를 사용하도록 설정할 수 있습니다.

Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

인증서 설치 확인

필요한 모든 단계가 완료되었으며 인증서가 설치되어 작동하는지 확인하려면 다음 명령을 실행합니다.

Get- ExchangeCertificate <thumbprint> | fl *

이 명령의 출력에서는 다음과 유사한 데이터를 반환합니다.

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=3rdPartyCAExample.com
NotAfter           : 8/7/2008 10:04:02 AM
NotBefore          : 8/7/2007 10:04:02 AM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 83FAE8B2398F2A9E44485CBA85D548DF
Services           : POP
Status             : Valid
Subject            : C=us,o=contoso corp, CN=fourthcoffee.com 
Thumbprint         : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

이 명령의 출력을 검사하여 다음 내용이 맞는지 확인합니다.

• 표시될 것으로 예상한 도메인 이름이 CertificateDomains 필드에 나열되어 있습니다.

• HasPrivateKey 속성이 True로 설정되어 있습니다.

• RootCAType 속성이 올바르게 설정되어 있습니다. RootCAType 속성에 대한 자세한 내용은 이 문서 앞부분에 있는 Certificate Properties을 참조하십시오.

• 인증서에 사용하도록 필요한 서비스가 설정되어 있습니다.

• 상태가 Valid로 설정되어 있습니다.

인증서 서비스

인증서에 POP, IMAP, IIS, SMTP와 같은 서비스를 사용하도록 설정할 수 있습니다. 서비스는 인증서 자체의 필드가 아닌 인증서의 메타데이터 속성입니다. 따라서 인증서를 무효화하지 않고 서비스를 변경할 수 있습니다.

서비스를 사용하도록 설정하면 IIS 메타베이스, 파일 시스템 또는 IMAP4와 POP3 설정과 같은 다른 구성 요소의 구성이 변경됩니다. 이 섹션에서는 Enable-ExchangeCertificate cmdlet를 실행하여 지정된 서비스를 사용하도록 설정할 때 발생하는 구성 변경에 대해 설명합니다.

POP 및 IMAP

POP과 IMAP를 인증서에 추가 서비스로 추가하면 POPSettings 개체나 IMAPSettings 개체의 x509CertificateName 특성이 업데이트되면서 인증서 주체에 도메인이 포함됩니다.

예를 들어 POPSettings 개체가 업데이트되었는지 확인하려면 다음 명령을 실행합니다.

Get-POPSettings | fl *

IIS

IIS를 사용하도록 설정하면 이 특정 인증서를 사용하도록 기본 IIS 웹 사이트가 업데이트됩니다.

기본 IIS 웹 사이트에 대해서만 Enable-ExchangeCertificate cmdlet를 사용하면 IIS에 인증서를 사용할 수 있습니다. 기본 IIS 웹 사이트가 아닌 다른 웹 사이트에서 Outlook Web Access나 자동 검색을 호스팅하는 경우, IIS 관리자를 사용하여 특정 인증서를 해당 웹 사이트에 연결해야 합니다.

SMTP

인증서에 SMTP 서비스를 사용하도록 설정하면, 네트워크 서비스 계정에 Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys 디렉터리에 있는 해당 개인 키 파일에 대한 읽기 권한이 부여됩니다. 이를 통해 Microsoft Exchange Transport Service가 개인 키에 액세스한 후 이를 사용하여 TLS를 통해 보호되는 메시지의 암호를 해독하는 데 필요한 사용 권한이 제공됩니다.

Microsoft Exchange 통합 메시징 서비스

인증서에 Microsoft Exchange 통합 메시징 서비스를 사용하도록 설정하면 통합 메시징을 포함하도록 인증서 속성이 업데이트됩니다. 다음 조건에 해당할 경우 인증서가 사용됩니다.

• 통합 메시징 서버 역할이 컴퓨터에 설치되어 있습니다.

• 인증서의 CertificateDomains 인증서 필드에 로컬 컴퓨터의 실제 FQDN이 포함되어 있습니다.

Return to top

인증서 선택

인증서 선택이란 Exchange 구성 요소가 들어오는 연결에 사용해야 할 인증서를 결정하기 위해 수행하는 프로세스입니다. SMTP STARTTLS, POP3 및 IMAP4 모두 유사한 선택 프로세스를 통해 특정 세션에 사용할 인증서를 결정합니다. 이 프로세스는 상당히 명확하지만 컴퓨터에 인증서를 두 개 이상 설치한 경우에는 특히 혼란을 줄 수 있습니다.

이 섹션에서는 SMTP STARTTLS, SMTP X-AnonymousTLS, POP3 및 IMAP4에 대한 인증서 선택 프로세스에 대해 설명합니다. 전송에 특정한 인증서 선택에 대한 자세한 내용은 SMTP TLS 인증서 선택을 참조하십시오.

SMTP STARTTLS

STARTTLS는 보안 TLS 세션을 시작하는 SMTP 동사로, Exchange를 실행하고 있는 컴퓨터에 유효한 인증서가 있는 경우에만 Exchange에서 보급됩니다.

Exchange는 STARTTLS를 보급하거나 사용하기 위해 인증서의 CertificateDomains 필드에 있는 FQDN 및 일치하는 값을 바탕으로 인증서를 선택합니다. FQDN은 다음 내용을 기반으로 합니다.

• 아웃바운드 STARTTLS   송신 커넥터의 FQDN 값을 바탕으로 인증서를 선택합니다.

• 인바운드 STARTTLS   수신 커넥터의 FQDN 값을 바탕으로 인증서를 선택합니다.

  참고

  아웃바운드 STARTTLS 및 인바운드 STARTTLS의 경우, 커넥터의 FQDN이 지정되지 않으면 Exchange 서버의 실제 FQDN을 사용하여 일치 여부를 확인합니다.

FQDN이 결정되면 Exchange에서는 호스트 컴퓨터의 개인 인증서 저장소에서 유효한 모든 인증서를 검색합니다. 다음 모든 요구 사항을 충족할 경우 TLS 사용에 적합한 인증서입니다.

• Enhanced Key Usage 필드에 서버 인증 개체 식별자(OID라고도 함)가 포함되어 있거나 해당 필드가 Null입니다.

• PKI 인증서 확장에 1024비트 이상의 RSA 키가 나열되어 있습니다.

• 인증서에서 신뢰할 수 있는 루트까지 인증서 체인을 확인하거나 자체 서명 인증서입니다.

• 인증서와 인증서 체인이 해지 확인을 전달합니다.

• 개인 키가 있으며 사용할 수 있습니다.

• 개인 키가 이동식 장치에 저장되어 있지 않습니다.

• 개인 키가 암호로 보호되어 있지 않습니다.

유효한 인증서가 두 개 이상 있으면 Exchange에서는 다음 기준에 따라 인증서를 선택합니다.

• NotBefore 필드 값   유효한 최신 인증서를 선택합니다.

• 신뢰할 수 있는 CA에서 발급한 인증서 및 자체 서명 인증서   자체 서명 인증서보다 신뢰할 수 있는 CA에서 발급한 인증서를 선택합니다.

대부분의 경우 Exchange에서는 인증서의 보관 기간에 관계없이 자체 서명 인증서보다 신뢰할 수 있는 CA에서 발급한 인증서를 선택합니다. 유효한 인증서가 없으면 STARTTLS가 보급되지 않습니다.

SMTP X-AnonymousTLS

X-AnonymousTLS는 두 허브 전송 서버 간의 통신 및 허브 전송 서버와 Edge 전송 서버 간의 통신을 보호하는 데 사용됩니다. Exchange 2007 SP1의 인증서 선택 과정은 인증서가 없을 경우 세션에 대한 임시 암호화 키가 생성되도록 간소화되었습니다.

Exchange에서 내부 전송 인증서를 검색합니다. 유효한 내부 전송 인증서를 찾을 수 없으면 유효한 CA 인증서를 검색합니다.

따라서 인증에 Kerberos 프로토콜을 사용하는 허브 간 통신의 경우, 유효한 내부 전송 인증서가 없어도 SMTP 세션에 실패하지 않습니다. SMTP 세션은 임시 암호화 키를 사용하여 암호화됩니다. 이 경우 이벤트가 기록되며 이벤트를 생성하는 컴퓨터에서 인수 없이 New-ExchangeCertificate cmdlet를 실행하여 새 내부 전송 인증서를 만들어야 합니다.

Edge 전송 서버가 조직에 가입되는 허브-Edge 간 통신의 경우, 유효한 내부 전송 인증서가 없으면 세션에 실패하고 오류가 기록됩니다. 이 경우 이벤트를 생성하는 컴퓨터에서 인수 없이 New-ExchangeCertificate cmdlet를 실행한 후 Microsoft Exchange EdgeSync 서비스를 다시 실행해야 합니다.

POP3 및 IMAP4

SMTP STARTTLS에 대한 인증서 선택 프로세스처럼 POP3 및 IMAP4에 대한 프로세스에서도 Exchange는 CertificateDomains 필드의 일치하는 값을 바탕으로 FQDN을 선택하고 인증서를 찾아야 합니다. FQDN은 POP3나 IMAP4 서비스 설정의 X509CertificateName 특성을 바탕으로 선택됩니다. Get-POPSettings cmdlet 또는 Get-IMAPSettings cmdlet를 실행하여 X509CertificateName 특성을 볼 수 있습니다. 자세한 내용은 Get-POPSettings 및 Get-IMAPSettings를 참조하십시오.

Exchange 2007 SP1의 POP3 및 IMAP4에 대한 선택 프로세스는 SMTP STARTTLS에 대한 프로세스와 동일합니다.

통합 메시징   

Microsoft Exchange 통합 메시징 서비스를 보안 모드로 시작할 경우 로컬 개인 인증서 저장소를 쿼리하여 암호화 사용을 위해 TLS에서 사용할 유효한 인증서를 찾습니다. Microsoft Exchange 통합 메시징 서비스에서는 먼저 개인 PKI나 공용 CA에서 발급한 유효한 인증서를 찾습니다. 알맞은 인증서가 없으면 자체 서명 인증서를 찾습니다. PKI, 공용 또는 자체 서명 인증서가 없을 경우, Microsoft Exchange 통합 메시징 서비스에서는 보안 모드로 시작할 때 사용할 자체 서명 인증서를 만듭니다. UM 서버를 보안되지 않음 모드로 시작할 경우에는 인증서가 필요하지 않습니다.

보안 모드로 시작할 때 사용하는 인증서의 모든 세부 사항은 인증서를 사용할 때마다 또는 인증서가 변경될 때 기록됩니다. 기록되는 일부 세부 사항은 다음과 같습니다.

• 발급자 이름

• 일련 번호

• 지문

지문은 SHA1(Secure Hash Algorithm) 해시이며, 사용되는 인증서를 고유하게 식별하는 데 사용할 수 있습니다. Microsoft Exchange 통합 메시징 서비스에서 보안 모드로 시작하는 데 사용하는 인증서를 로컬 인증서 저장소에서 내보낸 다음, 네트워크의 통합 메시징 IP 게이트웨이와 IP PBX에서 신뢰할 수 있는 인증서 저장소로 이 인증서를 가져올 수 있습니다.

알맞은 인증서를 찾아 사용한 후에는 Microsoft Exchange 통합 메시징 서비스에서 사용 중인 인증서가 만료되기 한 달 전에 이벤트를 기록합니다. 이 기간 동안 인증서를 변경하지 않으면 Microsoft Exchange 통합 메시징 서비스에서 인증서가 만료될 때까지 그리고 인증서 만료 후에도 매일 이벤트를 기록합니다.

통합 메시징 서버에서 암호화된 채널을 설정하기 위해 상호 TLS에 사용할 인증서를 찾는 경우 신뢰할 수 있는 루트 인증서 저장소를 확인합니다. 발급자가 서로 다른 유효한 인증서가 여러 개일 경우 통합 메시징 서버는 만료 기간이 가장 오래 남은 유효한 인증서를 선택합니다. 인증서가 여러 개이면 통합 메시징 서버에서 발급자와 인증서 만료 날짜를 기준으로 인증서를 선택합니다. 통합 메시징 서버는 다음과 같은 선호 순서에 따라 유효한 인증서를 찾습니다.

1. 만료 기간이 가장 오래 남은 PKI 또는 공용 인증서

2. 만료 기간이 가장 적게 남은 PKI 또는 상업용 인증서

3. 만료 기간이 가장 오래 남은 자체 서명 인증서

4. 만료 기간이 가장 적게 남은 자체 서명 인증서

Return to top

자세한 내용

다음은 이 항목에서 참조한 설명서입니다.

• 여러 SAN 항목이 포함된 인증서로 인한 ISA Server 웹 게시 실패 가능성

• TLS에 대한 인증서 또는 인증서 요청 만들기

• TLS에 대한 인증서 또는 인증서 요청 만들기

• 데이터 경로 보안 참조

• Enable-ExchangeCertificate

• Exchange 2007 학습 내용 - 타사 CA에서 인증서 생성

• Export-ExchangeCertificate

• Get-ExchangeCertificate

• Get-IMAPSettings

• Get-POPSettings

• Microsoft Management Console에 인증서 관리자를 추가하는 방법

• WinHTTP용 프록시 설정 구성 방법

• PKI 및 프록시 구성 테스트 방법

• Import-ExchangeCertificate

• 학습 내용: 타사 CA에서 인증서 생성

• 클라이언트 액세스 보안 관리

• POP3 및 IMAP4 보안 관리

• New-ExchangeCertificate

• Remove-ExchangeCertificate

• SMTP TLS 인증서 선택

• Exchange 2007의 TLS 기능 및 관련 용어

• EdgeSync 동기화 프로세스 이해

• Exchange Server 2007의 네임스페이스 계획 이해

• 통합 메시징 VoIP 보안 이해

• Exchange 2007 및 Communications Server 2007용 통합 통신 인증 파트너

• 백서: Exchange 2007 자동 검색 서비스

Return to top