TLS 인증서 이해

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

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

특정 컴퓨터에 있는 컴퓨터 인증서의 필드를 보려면 Exchange 관리 셸의 Get-ExchangeCertificate cmdlet을 사용할 수 있습니다. 또는 MMC(Microsoft Management Console)에서 인증서 관리자 스냅인을 사용할 수 있습니다.

TLS 인증서와 관련된 관리 작업에 대한 자세한 내용은 인증서를 참조하십시오.

목차

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

인증서 선택

TLS 인증서 만들기

참조

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입니다. 자세한 내용은 영어 국가 이름과 코드 요소를 참조하십시오.

도메인 구성 요소 및 국가/지역은 규칙에 따라 함께 사용할 수 없습니다. 따라서 국가/지역별로 또는 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과 일치하는 것으로 수락되지 않습니다.

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

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

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

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

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

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

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

인증서 선택

Exchange는 SMTP 연결 유형에 따라 다양한 인증서 선택 프로세스를 적용합니다.

허브 전송 서버가 조직 내의 다른 허브 전송 서버 또는 Edge 전송 서버와 통신하는 경우 익명 TLS 인증서가 사용됩니다. 자세한 내용은 인바운드 익명 TLS 인증서 선택 및 아웃바운드 익명 TLS 인증서 선택를 참조하십시오.

SMTP 호스트나 클라이언트가 Edge 또는 허브 전송 서버에 연결하는 경우에는 STARTTLS 인증서 선택 프로세스가 사용됩니다. 자세한 내용은 인바운드 STARTTLS 인증서 선택를 참조하십시오.

TLS 인증서 만들기

Exchange 2010는 설치하는 동안 설치 시 Exchange에 알려진 모든 서버 및 도메인 이름을 사용하는 자체 서명된 인증서를 만듭니다. 이 인증서를 복제하여 추가 서버에서 사용할 수 있고, 또는 이 인증서를 타사 CA에서 발급한 인증서와 교체할 수도 있습니다. 다음 항목에서는 각 작업에 대한 단계별 지침을 제공합니다.

참조

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

  • Windows Server 2008 PKI 및 인증서 보안

  • Housley, Russ and 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, 2nd Edition. New York: John Wiley & Son, Inc., 1996.

 © 2010 Microsoft Corporation. 모든 권리 보유.