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

  • 아티클

 

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

마지막으로 수정된 항목: 2011-11-04

이 항목에서는 Exchange 관리 셸에서 ExchangeCertificate cmdlet를 사용하여 X.509 TLS(전송 계층 보안) 인증서 또는 인증서 요청을 만드는 방법에 대해 설명합니다.

중요

이 항목을 읽기 전에 Microsoft Exchange Server 2007에서 인증서를 사용하는 일반적인 방법에 대해 숙지하시기 바랍니다. Exchange 2007 서버에서 인증서 사용을 참조하십시오.

암호화 용어와 관련하여 New-ExchangeCertificate cmdlet에 의해 생성되는 인증서 및 관련 개인 키를 TLS 키라고 합니다. New-ExchangeCertificate cmdlet를 사용하면 인증서에 대한 메타데이터를 지정하여 여러 서비스에서 같은 인증서 및 개인 키를 사용할 수 있습니다. TLS를 사용하는 Exchange 서비스에 대한 인증서 또는 인증서 요청을 만들기 전에 먼저 SSL 및 TLS 서비스용 인증서에서 사용되는 메타데이터에 대해 이해하고 있어야 합니다. 이 메타데이터는 결과 인증서에서 "필드"로 참조됩니다.

지정된 컴퓨터에 있는 컴퓨터 인증서의 필드를 보기 위해 Exchange 관리 셸에서 Get-ExchangeCertificate cmdlet를 사용할 수 있습니다. 또는 MMC(Microsoft Management Console)에서 인증서 관리자 스냅인을 사용할 수 있습니다. 인증서 관리자 스냅인을 사용하는 방법에 대한 자세한 내용은 Microsoft Management Console에 인증서 관리자를 추가하는 방법을 참조하십시오.

TLS 서비스용 인증서에서 사용되는 필드 이해

New-ExchangeCertificate cmdlet를 사용하여 타사 또는 기타 PKI(공개 키 인프라) CA(인증 기관)로부터의 인증서 요청을 생성하는 경우 CA에서 필요로 하는 인증서 필드 및 인증서 형식의 유효성을 검사해야 합니다.

이 섹션에서는 가장 중요한 인증서 필드에 대해 설명하고 인증서 및 인증서 요청 생성에 대한 몇 가지 유용한 정보를 제공합니다.

주체 이름

TLS 인증서의 주체 이름은 DNS 인식 서비스에서 사용되는 필드입니다. 주체 이름 필드는 인증서를 특정 서버 또는 도메인 이름에 바인딩합니다.

주체 이름은 RDN으로도 알려진 하나 이상의 관련 고유 이름으로 구성된 X.500 고유 이름입니다. 다음 표에서는 조직이나 서버 항목을 확인하는 데 자주 사용되는 관련 고유 이름을 보여줍니다.

이름 약어 형식 최대 크기 빈도 certificate\request의 Max.\Recommended 제목 순서

국가/지역

C

ASCII

2

1\1

1

도메인 구성 요소

DC

ASCII

255

많음

1

시/도

S

유니코드

128

1

2

구/군/시

L

유니코드

128

1

3

조직

O

유니코드

64

1\1

4

조직 구성 단위

OU

유니코드

64

많음\많음

5

일반 이름

CN

유니코드

64

많음\1

6

국가/지역 코드는 ISO 3166-1입니다. 자세한 내용은 English country names and code elements를 참조하십시오.

참고

UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

도메인 구성 요소 및 국가/지역은 규칙에 따라 함께 사용할 수 없습니다. 따라서 국가/지역별로 또는 DNS(Domain Name System) 이름별로 이름을 참조하는 것이 좋습니다. 또한 도메인 구성 요소의 최대 크기(255자)는 모든 도메인 구성 요소 값의 합계임을 유의해야 합니다.

중요

인증서에 둘 이상의 일반 이름 필드가 있을 수 있지만 일부 서비스에서는 하나의 일반 이름만 있다는 가정 하에 구현됩니다. 그러므로 여러 일반 이름을 사용하면 상호 운용성 문제가 발생할 수 있습니다. 만드는 인증서 또는 인증서 요청에는 하나의 일반 이름만 포함하는 것이 좋습니다.

관련 고유 이름 구현

주체 이름은 New-ExchangeCertificate cmdlet에 쉼표로 구분된 이름 집합으로 구성된 단일 매개 변수로 표시됩니다. 각 이름은 상대 고유 이름에 대한 약어로 식별됩니다. 예를 들어 다음 주체 이름에서는 국가/지역이 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(정규화된 도메인 이름)을 포함할 수 있습니다. 이는 널리 알려진 권장되는 사항이지만 다음 두 가지 사항을 반드시 이해하고 있어야 합니다.

첫 번째로 일반 이름 필드의 최대 크기는 64자입니다. 이는 FQDN의 최대 크기보다 더 적은 문자 수입니다. 따라서 64자보다 많은 FQDN의 경우 주체 대체 이름에 도메인 이름을 넣어야 합니다. DomainName 매개 변수는 결과 인증서에서 주체 대체 이름에 매핑되는 매개 변수입니다.

두 번째로 FQDN에 사용할 수 있는 문자는 ASCII 문자 집합의 하위 집합으로 제한됩니다. 그러나 CN(일반 이름)은 유니코드를 지원합니다. 따라서 DNS 이름처럼 보이나 유효한 DNS 이름이 아닌 CN을 사용하여 유효한 인증서를 만들 수 있습니다. 인증서 CN이 ASCII가 아닌 문자를 포함하는 경우 소프트웨어가 해당 CN에서 FQDN을 찾으면 올바른 결과를 반환하지 않습니다. 예를 들어, CN이 mail.mïcrosoft.com인 주체 이름을 가진 인증서를 만드는 경우 해당 이름이 유니코드 문자(분음 기호가 있는 ï 문자(x00ef))를 포함하기 때문에 FQDN으로 무시됩니다. 육안으로 볼 때 분음 기호가 있는 ï 문자(x00ef)와 ASCII 문자 i(x0069) 사이에 작은 차이가 있기 때문에 FQDN에 유니코드 CN을 사용할 경우 잘못 사용하기 쉽습니다. Exchange 인증서 작업에서 주체 CN이 유효한 FQDN이어야 하거나 유효한 FQDN이 되도록 해야 하는 것은 아닙니다. 이는 기본적으로 cmdlet에서 서버의 FQDN이 기본 CN으로 포함된다는 것을 의미합니다.

인증서 도메인 이름

TLS의 경우 TLS가 DNS 기반 프로토콜이기 때문에 인증서는 DNS 이름을 반드시 포함해야 합니다. 클라이언트는 연결 중일 것으로 예상한 DNS 이름을 사용하여 연결 중인 서버의 DNS 이름을 확인합니다. 이는 HTTPS를 통해 웹 사이트에 연결하는 웹 브라우저 및 인터넷이나 인트라넷을 통해 전자 메일을 전송하는 SMTP 서버의 경우에 해당합니다.

단일 서버는 다음과 같은 이유로 여러 DNS 이름을 지원할 수 있습니다.

  • SMTP 서버에서는 여러 개의 허용 도메인을 지원합니다.

  • 클라이언트는 서버 이름, 도메인 이름, FQDN 로컬 이름 또는 부하 분산 이름으로 전제 메일 서버에 액세스할 수 있습니다.

TLS 연결이 설정되면 클라이언트가 찾고 있던 이름을 찾은 경우 해당 클라이언트는 인증서에서 다른 이름을 무시합니다. 여러 도메인과 서버 이름은 TLS 인증서의 주체 대체 이름 필드에 추가될 수 있습니다. New-ExchangeCertificate cmdlet의 DomainName 매개 변수를 사용하여 여러 주체 대체 이름을 포함하는 인증서를 만들 수 있습니다. DomainName 매개 변수는 다중값이 되어 여러 이름을 허용할 수 있습니다.

X.509 인증서는 주체 대체 이름(SubjectAltName) 인증서 확장에 DNS 이름을 포함하지 않거나 하나 이상 포함할 수 있습니다. SubjectAltName 확장의 DNS 이름은 DNS 이름 제한을 정확히 따릅니다. 이러한 DNS 이름은 255자를 초과하지 않아야 하며 A-Z, a-z, 0-9 및 대시(-)로 구성되어야 합니다.

도메인 보안 기능을 위한 이름 일치 논리

도메인 보안 기능을 위한 인증서 이름 일치 논리는 받은 인증서의 도메인 이름이 해당 도메인에 메일을 보낼 때 도메인 이름과 일치하는지 여부를 확인합니다. 받는 사람 도메인의 FQDN이 woodgrovebank.com인 경우를 예를 들어 봅니다. 인증서 이름 일치 논리는 인증서 내 모든 DNS 이름을 검색하여 일치하는 DNS 이름 하나를 찾으면 해당 인증서가 지정된 도메인과 일치하는 것으로 확인합니다.

이 예에서 인증서 이름 일치 논리는 woodgrovebank.com과 정확히 일치하는 도메인을 가진 인증서를 수락합니다. 또한 와일드카드 문자를 인증서의 도메인 이름에 사용할 수 있으므로 DNS 이름이 *.woodgrovebank.com인 인증서도 일치하는 것으로 수락합니다. 와일드카드 문자 도메인 이름에 대한 자세한 내용은 이 항목의 후반에 있는 "와일드카드 문자 도메인 이름"을 참조하십시오.

인증서 이름 일치 논리는 한 노드가 더 있는 DNS를 검색할 수도 있습니다. 따라서 mail1.woodgrovebank.com도 woodgrovebank.com과 일치하는 것으로 수락됩니다. 하지만, 노드가 3개 이상인 DNS 이름은 수락되지 않습니다. 예를 들어 mail1.us.woodgrovebank.com은 woodgrovebank.com과 일치하는 것으로 수락되지 않습니다.

Exchange에서 인증서가 선택되는 방법에 대한 자세한 내용은 SMTP TLS 인증서 선택을 참조하십시오.

인터넷 SMTP용 도메인 이름에 대한 유용한 정보

인터넷을 통해 SMTP TLS를 수행하는 Edge 전송 서버용 인증서 또는 인증서 요청을 만드는 경우 해당 요청에 포함해야 하는 도메인 이름 집합은 다음과 같습니다.

  • 서버의 정규화된 인터넷 도메인 이름   이는 Edge 전송 서버 및 허브 전송 서버 간에 사용되는 내부 FQDN과는 다를 수 있고 인터넷(공용) DNS 서버에 게시되는 A 레코드와 일치해야 합니다. 이 이름은 New-ExchangeCertificate cmdlet의 SubjectName 매개 변수에 CN으로 입력되어야 합니다.

  • 조직의 모든 허용 도메인 이름**   New-ExchangeCertificate** cmdlet의 IncludeAcceptedDomain 매개 변수를 사용하여 결과 인증서의 주체 대체 이름을 채웁니다.

  • FQDN이 이전 항목에서 다루어지지 않은 경우의 커넥터 FQDN**   New-ExchangeCertificate** cmdlet의 DomainName 매개 변수를 사용하여 결과 인증서의 주체 대체 이름을 채웁니다.

클라이언트 액세스 서버의 도메인 이름에 대한 유용한 정보

클라이언트 액세스 서버용 인증서 또는 인증서 요청을 만드는 경우 해당 요청에 포함해야 하는 도메인 이름 집합은 다음과 같습니다.

  • 서버의 로컬 또는 NetBIOS 이름(예: owa1)

  • 조직의 모든 허용 도메인 이름(예: contoso.com)

  • 서버의 정규화된 도메인 이름(예: owa1.contoso.com)

  • 도메인의 Autodiscover 도메인 이름(예: Autodiscover.contoso.com)

  • 부하 분산 ID를 사용 중인 경우 서버의 해당 ID(예: owa.contoso.com)

와일드카드 문자 도메인 이름

와일드카드 문자 도메인 이름은 여러 하위 도메인을 나타내는 특수한 유형의 도메인 이름입니다. 와일드카드 문자 도메인 이름을 사용하면 단일 와일드카드 도메인 이름이 해당 도메인에 대한 모든 하위 도메인을 나타내므로 인증서를 단순화할 수 있습니다. 와일드카드 문자 도메인 이름은 DNS 노드에 별표(*)로 표시됩니다. 예를 들어 *.contoso.com은 contoso.com과 contoso.com의 모든 하위 도메인을 나타냅니다. 와일드카드 문자를 사용하여 모든 허용 도메인에 대한 인증서 또는 인증서 요청을 만들면 해당 요청을 매우 단순화할 수 있습니다.

기존 인증서 복제

Exchange 2007에서는 설치 시 Exchange에 대해 알려진 도메인 이름 및 모든 서버를 사용하는 자체 서명 인증서를 설치하는 동안 만듭니다. 이러한 인증서는 12개월 동안 유효합니다. 경우에 따라 다른 컴퓨터에서 주체 이름 및 주체 대체 이름을 사용할 수 있으면 이러한 인증서를 복제할 수 있습니다. 인증서 메타데이터만 복제할 수 있고 해당 키 집합은 복제할 수 없음에 유의해야 합니다.

Edge 전송 서버 역할이 설치된 컴퓨터에서 다음 cmdlet를 실행하려면 해당 컴퓨터의 로컬 관리자 그룹에 속한 계정을 사용하여 로그온해야 합니다.

기존 인증서에서 새 인증서를 복제하려면 다음 명령을 실행하여 도메인의 현재 인증서를 먼저 확인해야 합니다.

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 cmdlet를 사용할 수 있습니다. 또한 인증서 요청을 생성하기 위해 GenerateRequest 매개 변수를 Path 매개 변수와 함께 사용하여 요청 파일이 만들어질 위치를 정의합니다. 결과 파일은 PKCS #10 요청 파일(.req)이 됩니다. PKCS #10은 RFC 2314(http://www.ietf.org/rfc/rfc2314.txt)에서 지정하는 인증 요청 구문 표준입니다.

참고

UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

다음 예에서는 일부 일반적인 인증서 요청을 보여줍니다.

첫 번째 예에서는 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

두 번째 예에서는 Contoso 서버인 mail1에 대한 인증서 요청을 생성합니다. Contoso에는 mail.contoso.com의 FQDN이 있는 각 Edge 전송 서버에 송신 커넥터가 있습니다.

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

세 번째 예에서는 기존 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 팀 블로그 항목인 Lessons Learned: Generating a Certificate with a 3rd Party CA를 참조하십시오.

참고

UNRESOLVED_TOKEN_VAL(exBlog)

인증서 요청에서 발급된 인증서 설치

CA에 인증서 요청을 보내고 나면 CA에서 인증서 또는 인증서 체인을 발급합니다. 두 경우 모두에서 인증서는 Import-ExchangeCertificate cmdlet를 사용하여 설치해야 하는 파일로 제공됩니다.

중요

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 관련 웹 사이트를 운영하는 인증 기관에 대한 자세한 내용은 Microsoft 기술 자료 문서 929395, Exchange 2007 및 Communications Server 2007용 통합 통신 인증 파트너를 참조하십시오.

암호화 및 인증서 기술과 개념에 대한 자세한 내용은 다음 출판물을 참조하십시오.