디지털 인증서 및 SSL

적용 대상: Exchange Server 2013

SSL(Secure Sockets Layer)은 클라이언트와 서버 간의 통신 보안을 유지하는 방법입니다. Exchange Server 2013의 경우 서버와 클라이언트 간의 보안 통신에 SSL이 사용됩니다. 클라이언트에는 휴대폰, 조직 네트워크의 내부 컴퓨터 및 외부 컴퓨터가 포함됩니다.

기본적으로 Exchange 2013을 설치하면 Outlook Web App, Exchange ActiveSync 및 외부에서 Outlook 사용을 사용할 때 클라이언트 통신이 SSL을 통해 암호화됩니다.

SSL을 사용하려면 디지털 인증서가 필요합니다. 이 항목에서는 다양한 종류의 디지털 인증서에 대해 간략하게 소개하고, 이러한 종류의 디지털 인증서를 사용하도록 Exchange 2013을 구성하는 방법을 설명합니다.

디지털 인증서 개요

디지털 인증서는 사용자 또는 컴퓨터의 ID를 확인하기 위해 온라인 암호처럼 작동하는 전자 파일입니다. 클라이언트 통신에 사용되는 SSL 암호화 채널을 만드는 데 사용됩니다. 인증서는 CA(인증 기관)에서 발급한 디지털 문으로, 인증서 소유자의 ID를 보증하고 당사자가 암호화를 사용하여 안전한 방식으로 통신할 수 있도록 합니다.

디지털 인증서를 사용하여 다음을 수행할 수 있습니다.

• 그들은 자신의 소유자 (사람, 웹 사이트, 라우터와 같은 네트워크 리소스)가 진정으로 누구 또는 그들이 주장하는 것을 인증합니다.

• 온라인으로 교환되는 데이터의 도난 또는 변조를 방지합니다.

디지털 인증서는 신뢰할 수 있는 타사 CA 또는 Windows PKI(공개 키 인프라)에서 인증서 서비스를 사용하여 발급하거나 자체 서명될 수 있습니다. 인증서의 종류마다 각각의 장단점이 있습니다. 각 종류의 디지털 인증서는 위조할 수 없도록 변조 방지되어 있습니다.

인증서는 여러 가지 사용 목적으로 발급될 수 있습니다. 이러한 사용 목적으로는 웹 사용자 인증, 웹 서버 인증, S/MIME(Secure/Multipurpose Internet Mail Extensions), IPsec(인터넷 프로토콜 보안), TLS(전송 계층 보안), 코드 서명이 해당됩니다.

인증서는 공개 키를 포함하며 해당 개인 키를 소유하는 사용자, 컴퓨터 또는 서비스의 ID에 이러한 공개 키를 첨부합니다. 클라이언트와 서버에서 데이터를 전송하기 전에 데이터를 먼저 암호화할 때 공개 키와 개인 키가 사용됩니다. Windows 기반 사용자, 컴퓨터, 서비스의 경우 신뢰할 수 있는 루트 인증서 저장소에 루트 인증서 사본이 있고 인증서에 올바른 인증 경로가 있으면 CA에 대한 신뢰가 설정됩니다. 인증서가 유효하려면 인증서가 해지되지 않고 유효 기간이 만료되지 않아야 합니다.

인증서 종류

디지털 인증서의 주요 종류에는 자체 서명된 인증서, Windows PKI 생성 인증서 및 타사 인증서와 같이 세 가지가 있습니다.

자체 서명된 인증서

Exchange 2013을 설치하면 사서함 서버에서 자체 서명된 인증서가 자동으로 구성됩니다. 자체 서명된 인증서는 해당 인증서를 만든 응용 프로그램에서 서명합니다. 인증서 제목과 이름이 일치합니다. 발급자와 제목은 인증서에 정의되어 있습니다. 이 자체 서명된 인증서는 클라이언트 액세스 서버와 사서함 서버 간의 통신을 암호화하는 데 사용됩니다. 클라이언트 액세스 서버는 사서함 서버의 자체 서명된 인증서를 자동으로 신뢰하므로 사서함 서버에서 타사 인증서가 필요하지 않습니다. Exchange 2013을 설치하면 클라이언트 액세스 서버에서도 자체 서명된 인증서가 만들어집니다. 일부 클라이언트 프로토콜은 이 자체 서명된 인증서를 통해 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 생성 인증서를 배포하는 단계는 자체 서명된 인증서를 배포하는 데 필요한 단계와 유사합니다. Microsoft Exchange에 대한 SSL 연결을 설정하려는 컴퓨터 또는 모바일 디바이스의 신뢰할 수 있는 루트 인증서 저장소에 PKI에서 신뢰할 수 있는 루트 인증서 복사본을 설치해야 합니다.

Windows PKI는 조직이 자체의 인증서를 게시할 수 있도록 합니다. 클라이언트에서는 내부 네트워크의 Windows PKI를 통해 인증서를 요청하고 받을 수 있습니다. Windows PKI는 인증서를 갱신하거나 해지할 수 있습니다.

신뢰할 수 있는 타사 인증서

제3자 인증서나 상업용 인증서는 타사 또는 영리 CA가 생성한 인증서를 사용자 네트워크 서버에 사용할 수 있도록 구입한 것입니다. 자체 서명된 인증서와 PKI 기반 인증서의 한 가지 문제점은 인증서가 클라이언트 컴퓨터나 모바일 장치에서 자동으로 신뢰되지 않기 때문에 클라이언트 컴퓨터와 장치의 신뢰할 수 있는 루트 인증서 저장소로 인증서를 가져와야 한다는 것입니다. 제3자 인증서나 상업용 인증서에는 이러한 문제가 없습니다. 영리 CA가 발급한 인증서는 대부분 신뢰할 수 있는 루트 인증서 저장소에 이미 있기 때문에 이미 신뢰된 상태입니다. 발급자를 신뢰할 수 있으면 해당 인증서도 신뢰할 수 있습니다. 제3자 인증서를 사용하면 배포 과정이 매우 간편해집니다.

대규모 조직 또는 인증서를 공개적으로 배포해야 하는 조직의 경우 인증서 관련 비용이 들더라도 타사 인증서나 상업용 인증서를 사용하는 것이 가장 좋습니다. 소규모나 중간 규모의 조직에서는 상업용 인증서가 가장 좋은 방법이 아닐 경우도 있으므로 사용 가능한 다른 인증서 옵션 중 하나를 사용하도록 결정할 수 있습니다.

인증서 종류 선택

설치할 인증서 종류를 선택할 때 고려해야 할 몇 가지 요소가 있습니다. 인증서는 유효한 것으로 서명되어야 합니다. 서명은 자체 서명일 수도 있고 CA에 의해 이뤄질 수도 있습니다. 자체 서명된 인증서에는 제한이 있습니다. 예를 들어 일부 모바일 장치의 경우 신뢰할 수 있는 루트 인증서 저장소에 디지털 인증서를 설치할 수 없을 수도 있습니다. 모바일 장치에 인증서를 설치할 수 있는지 여부는 모바일 장치 제조업체와 모바일 서비스 공급자에 따라 달라집니다. 일부 제조업체와 모바일 서비스 공급자는 신뢰할 수 있는 루트 인증서 저장소에 액세스할 수 없도록 설정합니다. 이 경우 자체 서명된 인증서와 Windows PKI CA 인증서 모두 모바일 장치에 설치할 수 없습니다.

기본 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

• EAC(Exchange 관리 센터)

• Exchange 웹 서비스

• Exchange ActiveSync

• Outlook Anywhere

• Autodiscover

• Outlook 주소록 배포

웹 사이트에는 인증서를 하나만 연결할 수 있고, 이러한 모든 서비스는 기본적으로 단일 웹 사이트에서 제공되므로 이러한 서비스의 클라이언트가 사용하는 모든 이름은 인증서에 있거나 인증서의 와일드카드 이름에 속해야 합니다.

POP/IMAP

POP 또는 IMAP에 사용되는 인증서는 IIS에 사용되는 인증서와 별개로 지정할 수 있습니다. 그러나 관리를 단순화하기 위해 POP 또는 IMAP 서비스 이름을 IIS 인증서에 포함시키고 이러한 모든 서비스에 단일 인증서를 사용하는 것이 좋습니다.

SMTP

구성하는 각 수신 커넥터에 별개의 인증서를 사용할 수 있습니다. 인증서는 SMTP 클라이언트 또는 다른 SMTP 서버가 해당 커넥터에 연결하기 위해 사용하는 이름을 포함해야 합니다. 인증서 관리를 단순화하기 위해 TLS 트래픽을 지원해야 하는 모든 이름을 단일 인증서에 포함하는 것을 고려하십시오.

디지털 인증서 및 프록시

한 서버가 다른 서버로 클라이언트 연결을 보낼 때 사용되는 방법이 프록시입니다. Exchange 2013의 경우에는 클라이언트 액세스 서버가 들어오는 클라이언트 요청을 클라이언트 사서함의 활성 복사본이 포함된 사서함 서버로 프록시 처리할 때 이 작업이 수행됩니다.

클라이언트 액세스 서버가 요청을 프록시 처리할 경우 SSL이 암호화에 사용되지만 인증에는 사용되지 않습니다. 사서함 서버의 자체 서명된 인증서는 클라이언트 액세스 서버와 사서함 서버 간의 트래픽을 암호화합니다.

역방향 프록시 및 인증서

대부분의 Exchange 배포에서는 역방향 프록시를 사용하여 인터넷에 Exchange 서비스를 게시합니다. SSL 암호화를 종료하고 서버에서 암호화되지 않은 형태로 트래픽을 검사한 다음 역방향 프록시 서버에서 해당 서버 뒤에 있는 Exchange 서버로의 새 SSL 암호화 채널을 열도록 역방향 프록시를 구성할 수 있습니다. 이를 SSL 브리징이라고 합니다. 역방향 프록시 서버를 구성하는 또 다른 방법은 SSL 연결이 역방향 프록시 서버를 통과하여 그 뒤에 있는 Exchange 서버로 직접 이동하게 하는 것입니다. 둘 중 하나의 배포 모델을 사용하면 인터넷상의 클라이언트는 Exchange 액세스를 위한 호스트 이름(예: mail.contoso.com)을 사용하여 역방향 프록시 서버에 연결됩니다. 그런 다음 역방향 프록시 서버는 다른 호스트 이름(예: Exchange 클라이언트 액세스 서버의 시스템 이름)을 사용하여 Exchange에 연결됩니다. 대부분의 일반적인 역방향 프록시 서버가 클라이언트에 사용되는 원래 호스트 이름을 Exchange 클라이언트 액세스 서버의 내부 호스트 이름과 일치시킬 수 있으므로 Exchange 클라이언트 액세스 서버의 시스템 이름을 인증서에 포함할 필요가 없습니다.

SSL 및 분할 DNS

분할 DNS는 원래 DNS 요청이 시작된 위치에 따라 동일한 호스트 이름에 다른 IP 주소를 구성할 수 있게 하는 기술입니다. 이는 분할 수평 DNS, 분할 보기 DNS 또는 분할 브레인 DNS로도 알려져 있습니다. 분할 DNS를 사용하면 클라이언트가 인터넷에서 연결되는지 아니면 인트라넷에서 연결되는지 여부에 상관없이 동일한 호스트 이름을 통해 Exchange에 연결할 수 있게 하여 Exchange에 대해 관리해야 할 호스트 이름 수를 줄일 수 있습니다. 분할 DNS에서는 인트라넷에서 시작된 요청이 인터넷에서 시작된 요청과 다른 IP 주소를 수신할 수 있습니다.

소규모 Exchange 배포의 경우에는 인트라넷의 사용자와 인터넷의 사용자가 모두 동일한 DNS 끝점에 액세스할 수 있으므로 일반적으로 분할 DNS가 필요하지 않습니다. 그러나 대규모 배포의 경우 이 구성을 사용하면 나가는 인터넷 프록시 서버 및 역방향 프록시 서버에 너무 많은 부하가 발생합니다. 대규모 배포의 경우 외부 사용자가 mail.contoso.com에 액세스하고 내부 사용자가 internal.contoso.com에 액세스하는 등의 경우에 분할 DNS를 구성합니다. 이 구성에 분할 DNS를 사용하면 사용자는 위치에 따라 다른 호스트 이름을 사용하지 않아도 됩니다.

원격 Windows PowerShell

Kerberos 인증 및 Kerberos 암호화는 EAC(Exchange 관리 센터)와 Exchange 관리 셸 모두에서 원격 Windows PowerShell 액세스에 사용됩니다. 따라서 원격 Windows PowerShell에 사용하기 위해 SSL 인증서를 구성할 필요가 없습니다.

디지털 인증서 모범 사례

조직의 디지털 인증서 구성이 특정 요구에 따라 다르지만 조직에 적합한 디지털 인증서 구성을 선택하는 데 도움이 되도록 모범 사례에 대한 정보가 포함되었습니다.

모범 사례: 신뢰할 수 있는 타사 인증서 사용

신뢰할 수 없는 인증서에 대한 오류를 클라이언트가 받지 않도록 하려면 Exchange 서버에 사용되는 인증서는 클라이언트가 신뢰하는 누군가에 의해 발급되어야 합니다. 대부분의 클라이언트는 모든 인증서 또는 인증서 발급자를 신뢰하도록 구성할 수 있지만 Exchange 서버에서 신뢰할 수 있는 타사 인증서를 사용하는 것이 더 간단합니다. 이는 대부분의 클라이언트가 이미 해당 루트 인증서를 신뢰하기 때문입니다. Exchange에 대해 특별히 구성된 인증서를 제공하는 여러 타사 인증서 발급자가 있습니다. EAC를 사용하여 대부분의 인증서 발급자에 대해 작동하는 인증서 요청을 생성할 수 있습니다.

인증 기관 선택 방법

CA(인증 기관)는 인증서를 발급하고 인증서의 유효성을 확인하는 회사입니다. 클라이언트 소프트웨어(예: 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 2013 서버 집합을 배포했으며 배포를 위한 개별 서비스에 사용할 호스트 이름을 결정했으면 인증서 마법사를 실행합니다. 이상적으로는 Active Directory를 배포하는 각 Exchange 사이트에 대해 인증서 마법사를 한 번 실행하면 됩니다.

구매하는 인증서의 SAN 목록에서 호스트 이름을 잊어버릴까 걱정하는 대신에 유예 기간을 무료로 제공하는 인증 기관을 사용할 수 있습니다. 이 기간 동안 인증서를 반환하고 몇 가지 추가 호스트 이름을 가진 동일한 새 인증서를 요청할 수 있습니다.

모범 사례: 최대한 적은 호스트 이름 사용

가능한 적은 인증서를 사용하는 것 외에도 또한 가능한 적은 호스트 이름을 사용해야 합니다. 이 방법으로 비용을 절약할 수 있습니다. 대부분의 인증서 공급자는 인증서에 추가하는 호스트 이름 수에 기초하여 요금을 부과합니다.

갖추어야 하는 호스트 이름 수를 줄이고 결과적으로 인증서 관리를 단순화하기 위해 수행할 수 있는 가장 중요한 단계는 인증서의 주체 대체 이름에 개별 서버 호스트 이름을 포함하지 않는 것입니다.

Exchange 인증서에 포함해야 하는 호스트 이름은 Exchange에 연결하기 위해 클라이언트 응용 프로그램이 사용하는 호스트 이름입니다. 다음은 Contoso라는 회사에 필요한 일반적인 호스트 이름의 목록입니다.

• Mail.contoso.com: 이 호스트 이름은 Microsoft Outlook, Outlook Web App, Outlook Anywhere, 오프라인 주소록, Exchange 웹 서비스, POP3, IMAP4, SMTP, Exchange 제어판 및 ActiveSync를 포함하여 Exchange에 대한 대부분의 연결을 포함합니다.

• Autodiscover.contoso.com: 이 호스트 이름은 Microsoft Office Outlook 2007 이상 버전, Exchange ActiveSync 및 Exchange Web Services 클라이언트를 포함하여 자동 검색을 지원하는 클라이언트에서 사용됩니다.

• Legacy.contoso.com: 이 호스트 이름은 Exchange 2007 및 Exchange 2013과의 공존 시나리오에서 필요합니다. 클라이언트의 사서함이 Exchange 2007 및 Exchange 2013에 있을 경우 레거시 호스트 이름을 구성하면 사용자가 업그레이드 프로세스 도중 두 번째 URL을 몰라도 됩니다.

와일드카드 인증서 이해

와일드카드 인증서는 하나의 도메인과 여러 하위 도메인을 지원하도록 고안되었습니다. 예를 들어 *.contoso.com 와일드카드 인증서를 구성하면 mail.contoso.com, web.contoso.com 및 autodiscover.contoso.com 작동하는 인증서가 생성됩니다.