Exchange Server 디지털 인증서 및 암호화
암호화 및 디지털 인증서는 모든 조직에서 중요한 고려 사항입니다. 기본적으로 Exchange Server TLS(전송 계층 보안)를 사용하여 내부 Exchange 서버 간 및 로컬 서버의 Exchange 서비스 간 통신을 암호화하도록 구성됩니다. 그러나 Exchange 관리자는 내부 및 외부 클라이언트(컴퓨터 및 모바일 디바이스) 및 외부 메시징 서버와의 통신에 대한 암호화 요구 사항을 고려해야 합니다.
참고
Exchange Server 2019에는 클라이언트 및 서버 연결의 보안을 개선하기 위한 중요한 변경 내용이 포함되어 있습니다. 암호화를 위한 기본 구성은 오직 TLS 1.2만 활성화하며 이전 알고리즘(즉, DES, 3DES, RC2, RC4 및 MD5)에 대한 지원은 비활성화합니다. 또한 비 타원 곡선 알고리즘보다 타원 곡선 키 교환 알고리즘을 우선적으로 구성합니다. Exchange Server 2016 및 그 이상의 버전에서 모든 암호화 설정은 운영 체제에 지정된 구성에서 상속됩니다. 자세한 내용은 Exchange Server TLS 지침을 참조하십시오.
이 항목에서는 사용할 수 있는 다양한 유형의 인증서, Exchange의 인증서에 대한 기본 구성 및 Exchange에서 사용해야 하는 추가 인증서에 대한 권장 사항에 대해 설명합니다.
Exchange Server 인증서에 필요한 절차는 Exchange Server 인증서 절차를 참조하세요.
디지털 인증서 개요
디지털 인증서는 사용자 또는 컴퓨터의 ID를 확인하기 위해 온라인 암호처럼 작동하는 전자 파일입니다. 클라이언트 통신에 사용되는 암호화된 채널을 만드는 데 사용됩니다. 인증서는 CA(인증 기관)에서 발급한 디지털 문으로, 인증서 소유자의 ID를 보증하고 암호화를 사용하여 당사자가 안전한 방식으로 통신할 수 있도록 합니다.
디지털 인증서는 다음 서비스를 제공합니다.
암호화: 도난 또는 변조로부터 교환되는 데이터를 보호하는 데 도움이 될 수 있습니다.
인증: 소유자(사람, 웹 사이트 및 라우터와 같은 네트워크 디바이스)가 진정으로 자신이 주장하는 사람 또는 대상인지 확인합니다. 일반적으로 인증은 원본이 대상의 ID를 확인하는 단방향이지만 상호 TLS 인증도 가능합니다.
인증서는 여러 가지 사용 목적으로 발급될 수 있습니다. 예를 들어 웹 사용자 인증, 웹 서버 인증, S/MIME(보안/다목적 인터넷 메일 확장), IPsec(인터넷 프로토콜 보안) 및 코드 서명이 있습니다.
인증서는 공개 키를 포함하며 해당 개인 키를 소유하는 사용자, 컴퓨터 또는 서비스의 ID에 이러한 공개 키를 첨부합니다. 퍼블릭 및 프라이빗 키는 클라이언트와 서버에서 데이터를 전송하기 전에 암호화하는 데 사용됩니다. Windows 사용자, 컴퓨터 및 서비스의 경우 루트 인증서가 신뢰할 수 있는 루트 인증서 저장소에 정의되고 인증서에 유효한 인증 경로가 포함될 때 CA에 대한 신뢰가 설정됩니다. 인증서가 해지되지 않았거나(CA의 인증서 해지 목록 또는 CRL에 없음) 만료되지 않은 경우 유효한 것으로 간주됩니다.
다음 표에는 세 가지 기본 유형의 디지털 인증서가 설명되어 있습니다.
| 유형 | 설명 | 장점 | 단점 |
|---|---|---|---|
| 자체 서명된 인증서 | 인증서는 인증서를 만든 애플리케이션에 의해 서명됩니다. | 비용(무료). | 인증서는 클라이언트 컴퓨터 및 모바일 디바이스에서 자동으로 신뢰할 수 없습니다. 인증서를 모든 클라이언트 컴퓨터 및 디바이스의 신뢰할 수 있는 루트 인증서 저장소에 수동으로 추가해야 하지만 모든 모바일 디바이스에서 신뢰할 수 있는 루트 인증서 저장소를 변경할 수 있는 것은 아닙니다. 모든 서비스가 자체 서명된 인증서로 작동하는 것은 아닙니다. 인증서 수명 주기 관리를 위한 인프라를 설정하기가 어렵습니다. 예를 들어 자체 서명된 인증서는 해지할 수 없습니다. |
| 내부 CA에서 발급한 인증서 | 인증서는 조직의 PKI(공개 키 인프라)에서 발급됩니다. 예를 들어 AD CS(Active Directory Certificate Services)가 있습니다. 자세한 내용은 Active Directory 인증서 서비스 개요를 참조하세요. | 조직에서 자체 인증서를 발급할 수 있습니다. 상업용 CA의 인증서보다 저렴합니다. |
PKI를 배포하고 유지 관리하기 위한 복잡성이 증가했습니다. 인증서는 클라이언트 컴퓨터 및 모바일 디바이스에서 자동으로 신뢰할 수 없습니다. 인증서를 모든 클라이언트 컴퓨터 및 디바이스의 신뢰할 수 있는 루트 인증서 저장소에 수동으로 추가해야 하지만 모든 모바일 디바이스에서 신뢰할 수 있는 루트 인증서 저장소를 변경할 수 있는 것은 아닙니다. |
| 상용 CA에서 발급한 인증서 | 인증서는 신뢰할 수 있는 상용 CA에서 구입합니다. | 모든 클라이언트, 디바이스 및 서버가 인증서를 자동으로 신뢰하기 때문에 인증서 배포가 간소화되었습니다. | 비용. 필요한 인증서 수를 최소화하기 위해 미리 계획해야 합니다. |
인증서 소유자가 자신이 주장하는 사람임을 증명하려면 인증서가 다른 클라이언트, 디바이스 또는 서버에 대한 인증서 소유자를 정확하게 식별해야 합니다. 이 작업을 수행하는 세 가지 기본 메서드는 다음 표에 설명되어 있습니다.
| 방법 | 설명 | 장점 | 단점 |
|---|---|---|---|
| 인증서 주체 일치 | 인증서의 주체 필드에는 호스트의 CN(일반 이름)이 포함됩니다. 예를 들어 www.contoso.com 발급된 인증서를 웹 사이트에 https://www.contoso.com사용할 수 있습니다. | 모든 클라이언트, 디바이스 및 서비스와 호환됩니다. 구획화. 호스트에 대한 인증서를 해지해도 다른 호스트에는 영향을 주지 않습니다. |
필요한 인증서 수입니다. 지정된 호스트에 대해서만 인증서를 사용할 수 있습니다. 예를 들어 서비스가 동일한 서버에 설치된 경우에도 ftp.contoso.com www.contoso.com 인증서를 사용할 수 없습니다. 복잡성. 웹 서버에서 각 인증서에는 자체 IP 주소 바인딩이 필요합니다. |
| SAN(인증서 주체 대체 이름) 일치 | 주체 필드 외에도 인증서의 주체 대체 이름 필드에는 여러 호스트 이름 목록이 포함됩니다. 예시:
|
편의. 여러 개별 도메인의 여러 호스트에 대해 동일한 인증서를 사용할 수 있습니다. 대부분의 클라이언트, 디바이스 및 서비스는 SAN 인증서를 지원합니다. 감사 및 보안. SAN 인증서를 사용할 수 있는 호스트를 정확히 알고 있습니다. |
더 많은 계획이 필요합니다. 인증서를 만들 때 호스트 목록을 제공해야 합니다. 구획화가 부족합니다. 인증서의 모든 호스트에 영향을 주지 않고 지정된 호스트 중 일부에 대한 인증서를 선택적으로 해지할 수 없습니다. |
| 와일드카드 인증서 일치 | 인증서의 주체 필드에는 와일드카드 문자(*)와 단일 도메인 또는 하위 도메인으로 공통 이름이 포함됩니다. 예를 들어 *.contoso.com 또는 *.eu.contoso.com. *.contoso.com 와일드카드 인증서는 다음 용도로 사용할 수 있습니다.
|
유연성. 인증서를 요청할 때 호스트 목록을 제공할 필요가 없으며 나중에 필요할 수 있는 호스트 수에 따라 인증서를 사용할 수 있습니다. | 다른 최상위 도메인(TLD)에서는 와일드카드 인증서를 사용할 수 없습니다. 예를 들어 *.contoso.net 호스트에는 *.contoso.com 와일드카드 인증서를 사용할 수 없습니다. 와일드카드 수준에서 호스트 이름에 대해서만 와일드카드 인증서를 사용할 수 있습니다. 예를 들어 www.eu.contoso.com *.contoso.com 인증서를 사용할 수 없습니다. 또는 *.eu.contoso.com 인증서를 www.uk.eu.contoso.com 사용할 수 없습니다. 이전 클라이언트, 디바이스, 애플리케이션 또는 서비스는 와일드카드 인증서를 지원하지 않을 수 있습니다. 와일드카드는 EV(확장 유효성 검사) 인증서에서 사용할 수 없습니다. 신중한 감사 및 제어가 필요합니다. 와일드카드 인증서가 손상된 경우 지정된 도메인의 모든 호스트에 영향을 줍니다. |
Exchange의 인증서
서버에 Exchange 2016 또는 Exchange 2019를 설치하면 Exchange에서 자체 서명된 인증서 2개가 만들어지고 설치됩니다. IiS(인터넷 정보 서비스)의 웹 관리 서비스용 Microsoft Windows에서 세 번째 자체 서명된 인증서를 만들고 설치합니다. 이러한 세 인증서는 EAC(Exchange 관리 센터) 및 Exchange 관리 셸에 표시되며 다음 표에 설명되어 있습니다.
| 이름 | 설명 |
|---|---|
| Microsoft Exchange | 이 Exchange 자체 서명된 인증서에는 다음과 같은 기능이 있습니다.
|
| Microsoft Exchange Server 인증 인증서 | 이 Exchange 자체 서명된 인증서는 OAuth를 사용하여 서버 간 인증 및 통합에 사용됩니다. 자세한 내용은 SharePoint 및 비즈니스용 Skype Exchange Server 통합 계획을 참조하세요. |
| Wmsvc | 이 Windows 자체 서명 인증서는 IIS의 웹 관리 서비스에서 웹 서버 및 관련 웹 사이트 및 애플리케이션의 원격 관리를 사용하도록 설정하는 데 사용됩니다. 이 인증서를 제거하면 유효한 인증서를 선택하지 않으면 웹 관리 서비스가 시작되지 않습니다. 이 상태의 서비스를 사용하면 Exchange 업데이트를 설치하거나 서버에서 Exchange를 제거할 수 없습니다. 이 문제를 해결하는 방법에 대한 지침은 이벤트 ID 1007 - IIS 웹 관리 서비스 인증을 참조하세요. |
이러한 자체 서명된 인증서의 속성은 기본 자체 서명된 인증서의 속성 섹션에 설명되어 있습니다 .
Exchange의 인증서와 관련하여 고려해야 할 주요 문제는 다음과 같습니다.
조직의 Exchange 서버와 서비스 간에 네트워크 트래픽을 암호화하기 위해 Microsoft Exchange 자체 서명 인증서를 바꿀 필요가 없습니다.
내부 및 외부 클라이언트를 통해 Exchange 서버에 대한 연결을 암호화하려면 추가 인증서가 필요합니다.
Exchange 서버와 외부 메시징 서버 간의 SMTP 연결을 강제로 암호화하려면 추가 인증서가 필요합니다.
Exchange Server 대한 계획 및 배포의 다음 요소는 인증서 요구 사항에 대한 중요한 동인입니다.
부하 분산: 부하 분산 장치 또는 역방향 프록시 서버에서 암호화된 채널을 종료하고, 계층 4 또는 계층 7 부하 분산 장치를 사용하고, 세션 선호도 또는 세션 선호도를 사용하지 않을 계획입니까? 자세한 내용은 Exchange 2016의 부하 분산을 참조하세요.
네임스페이스 계획: 어떤 버전의 Exchange가 있고, 바인딩되거나 언바운드 네임스페이스 모델을 사용하고 있으며, 분할 브레인 DNS (내부 및 외부 액세스에 따라 동일한 호스트에 대해 다른 IP 주소 구성)를 사용하고 있나요? 자세한 내용은 Exchange 2016의 네임스페이스 계획을 참조하세요.
클라이언트 연결: 클라이언트에서 사용하는 서비스(웹 기반 서비스, POP, IMAP 등)와 관련된 Exchange 버전은 무엇인가요? 자세한 내용은 아래 항목을 참조하세요.
Exchange 서비스에 대한 인증서 요구 사항
인증서를 할당할 수 있는 Exchange 서비스는 다음 표에 설명되어 있습니다.
| 서비스 | 설명 |
|---|---|
| IIS(HTTP) | 기본적으로 다음 서비스는 사서함 서버의 클라이언트 액세스(프런트 엔드) 서비스의 기본 웹 사이트에서 제공되며, 클라이언트에서 Exchange에 연결하는 데 사용됩니다.
단일 인증서를 웹 사이트와만 연결할 수 있으므로 클라이언트가 이러한 서비스에 연결하는 데 사용하는 모든 DNS 이름을 인증서에 포함해야 합니다. SAN 인증서 또는 와일드카드 인증서를 사용하여 이 작업을 수행할 수 있습니다. |
| POP 또는 IMAP | POP 또는 IMAP에 사용되는 인증서는 IIS에 사용되는 인증서와 다를 수 있습니다. 그러나 관리를 간소화하려면 IIS 인증서에 POP 또는 IMAP에 사용되는 호스트 이름도 포함하고 이러한 모든 서비스에 동일한 인증서를 사용하는 것이 좋습니다. |
| SMTP | 클라이언트 또는 메시징 서버의 SMTP 연결은 Exchange 서버의 프런트 엔드 전송 서비스에 구성된 하나 이상의 수신 커넥터에서 허용됩니다. 자세한 내용은 수신 커넥터를 참조하세요. SMTP 연결에 TLS 암호화를 요구하려면 각 수신 커넥터에 대해 별도의 인증서를 사용할 수 있습니다. 인증서에는 수신 커넥터에 연결하기 위해 SMTP 클라이언트 또는 서버에서 사용하는 DNS 이름이 포함되어야 합니다. 인증서 관리를 간소화하려면 단일 인증서에서 TLS 트래픽을 지원해야 하는 모든 DNS 이름을 포함하는 것이 좋습니다. 원본 서버와 대상 서버 간의 SMTP 연결이 모두 암호화되고 인증되는 상호 TLS 인증을 요구하려면 도메인 보안을 참조하세요. |
| UM(통합 메시징) | 자세한 내용은 UM용 인증서 배포를 참조하세요. 참고: Exchange 2019에서는 UM을 사용할 수 없습니다. |
| Microsoft 365 또는 Office 365 하이브리드 배포 | 자세한 내용은 하이브리드 배포에 대한 인증서 요구 사항을 참조하세요. |
| S/MIME(Secure/Multipurpose Internet Mail Extensions) | 자세한 내용은 메시지 서명 및 암호화에 대한 S/MIME를 참조하세요. |
* Kerberos 인증 및 Kerberos 암호화는 Exchange 관리 센터와 Exchange 관리 셸 모두에서 원격 PowerShell 액세스에 사용됩니다. 따라서 부하 분산 네임스페이스가 아닌 Exchange 서버에 직접 연결하는 한 원격 PowerShell에서 사용할 인증서를 구성할 필요가 없습니다. 원격 PowerShell을 사용하여 도메인의 구성원이 아닌 컴퓨터에서 Exchange 서버에 연결하거나 인터넷에서 연결하려면 원격 PowerShell에서 사용할 인증서를 구성해야 합니다.
Exchange 인증서에 대한 모범 사례
조직의 디지털 인증서 구성이 특정 요구에 따라 다르지만 조직에 적합한 디지털 인증서 구성을 선택하는 데 도움이 되도록 모범 사례에 대한 정보가 포함되었습니다.
가능한 한 적은 수의 인증서를 사용합니다. 이는 SAN 인증서 또는 와일드카드 인증서를 사용하는 것을 의미합니다. Exchange와의 상호 운용성 측면에서 둘 다 기능적으로 동일합니다. SAN 인증서와 와일드카드 인증서를 사용할지 여부에 대한 결정은 디지털 인증서 개요에 설명된 대로 각 인증서 유형에 대한 주요 기능 또는 제한 사항(실제 또는 인식됨)에 관한 것입니다.
예를 들어 모든 일반 이름이 동일한 수준의 contoso.com 있는 경우 SAN 인증서 또는 와일드카드 인증서를 사용하는지는 중요하지 않습니다. 그러나 autodiscover.contoso.com, autodiscover.fabrikam.com 및 autodiscover.northamerica.contoso.com 인증서를 사용해야 하는 경우 SAN 인증서를 사용해야 합니다.
클라이언트 및 외부 서버 연결에 상업용 CA의 인증서 사용: 대부분의 클라이언트가 인증서 또는 인증서 발급자를 신뢰하도록 구성할 수 있지만 Exchange 서버에 대한 클라이언트 연결에 상업용 CA의 인증서를 사용하는 것이 훨씬 쉽습니다. 클라이언트에서 상업용 CA에서 발급한 인증서를 신뢰하기 위해 구성이 필요하지 않습니다. 많은 상용 CA는 Exchange용으로 특별히 구성된 인증서를 제공합니다. EAC 또는 Exchange 관리 셸을 사용하여 대부분의 상용 CA에서 작동하는 인증서 요청을 생성할 수 있습니다.
올바른 상용 CA 선택: CA 간의 인증서 가격 및 기능을 비교합니다. 예시:
EXCHANGE 서버에 연결하는 클라이언트(운영 체제, 브라우저 및 모바일 디바이스)에서 CA를 신뢰할 수 있는지 확인합니다.
CA가 필요한 인증서 종류를 지원하는지 확인합니다. 예를 들어 모든 CA가 SAN 인증서를 지원하는 것은 아니며, CA는 SAN 인증서에서 사용할 수 있는 일반 이름 수를 제한하거나 CA가 SAN 인증서의 일반 이름 수에 따라 추가 요금을 부과할 수 있습니다.
CA가 유예 기간을 제공하는지 확인하여 청구되지 않고 발급된 후 SAN 인증서에 일반 이름을 추가할 수 있습니다.
인증서의 라이선스를 통해 필요한 수의 서버에서 인증서를 사용할 수 있는지 확인합니다. 일부 CA에서는 한 서버에서만 인증서를 사용할 수 있습니다.
Exchange 인증서 마법사 사용: 인증서를 만들 때 발생하는 일반적인 오류는 사용하려는 서비스에 필요한 하나 이상의 일반 이름을 잊어버리는 것입니다. Exchange 관리 센터의 인증서 마법사를 사용하면 인증서 요청에 올바른 일반 이름 목록을 포함할 수 있습니다. 마법사를 사용하면 인증서를 사용할 서비스를 지정할 수 있으며 해당 서비스에 대한 인증서에 포함해야 하는 일반 이름이 포함됩니다. Exchange 2016 또는 Exchange 2019 서버의 초기 집합을 배포하고 배포에 사용할 다른 서비스에 사용할 호스트 이름을 결정하면 인증서 마법사를 실행합니다.
가능한 한 적은 수의 호스트 이름 사용: SAN 인증서에서 호스트 이름 수를 최소화하면 인증서 관리와 관련된 복잡성이 줄어듭니다. 인증서에 대한 의도된 사용이 필요하지 않은 경우 SAN 인증서에 개별 Exchange 서버의 호스트 이름을 포함할 의무가 없다고 생각하지 않습니다. 일반적으로 인증서를 사용하여 Exchange에 연결하는 내부 클라이언트, 외부 클라이언트 또는 외부 서버에 표시되는 DNS 이름만 포함하면 됩니다.
Contoso라는 간단한 Exchange Server 조직의 경우 필요한 최소 호스트 이름의 가상 예제입니다.
mail.contoso.com: 이 호스트 이름은 Outlook, 웹용 Outlook, OAB 배포, Exchange 웹 서비스, Exchange 관리 센터 및 Exchange ActiveSync 포함하여 Exchange에 대한 대부분의 연결을 다룹니다.
autodiscover.contoso.com: 이 특정 호스트 이름은 Outlook, Exchange ActiveSync 및 Exchange Web Services 클라이언트를 포함하여 자동 검색을 지원하는 클라이언트에서 필요합니다. 자세한 내용은 자동 검색 서비스를 참조하세요.
기본 자체 서명된 인증서의 속성
Exchange 관리 센터 및/또는 Exchange 서버의 Exchange 관리 셸에 표시되는 기본 자체 서명된 인증서의 더 흥미로운 속성 중 일부는 다음 표에 설명되어 있습니다.
| 속성 | Microsoft Exchange | Microsoft Exchange Server 인증 인증서 | Wmsvc |
|---|---|---|---|
| 제목 | CN=<ServerName> (예: CN=Mailbox01) |
CN=Microsoft Exchange Server Auth Certificate |
CN=WMSvc-<ServerName> (예: CN=WMSvc-Mailbox01) |
| 주체 대체 이름(CertificateDomains) | <ServerName> (예: Mailbox01) <ServerFQDN> (예: Mailbox01.contoso.com) |
없음 | WMSvc-<ServerName> (예: WMSvc-Mailbox01) |
| 프라이빗 키 포함(HasPrivateKey) | 예 (True) | 예 (True) | 예 (True) |
| PrivateKeyExportable* | False | True | True |
| EnhancedKeyUsageList* | 서버 인증(1.3.6.1.5.5.7.3.1) | 서버 인증(1.3.6.1.5.5.7.3.1) | 서버 인증(1.3.6.1.5.5.7.3.1) |
| IISServices* | IIS://<ServerName>/W3SVC/1, IIS://<ServerName>/W3SVC/2 (예: IIS://Mailbox01/W3SVC/1, IIS://Mailbox01/W3SVC/2) |
없음 | 없음 |
| IsSelfSigned | True | True | True |
| 발급자 | CN=<ServerName> (예: CN=Mailbox01) |
CN=Microsoft Exchange Server Auth Certificate |
CN=WMSvc-<ServerName> (예: CN=WMSvc-Mailbox01) |
| NotBefore | Exchange가 설치된 날짜/시간입니다. | Exchange가 설치된 날짜/시간입니다. | IIS 웹 관리자 서비스가 설치된 날짜/시간입니다. |
| 만료 날짜(NotAfter) | 5년 후 NotBefore. |
5년 후 NotBefore. |
10년 후 NotBefore |
| 공개 키 크기(PublicKeySize) | 2048 | 2048 | 2048 |
| RootCAType | 레지스트리 | 없음 | 레지스트리 |
| 서비스 | IMAP, POP, IIS, SMTP | SMTP | 없음 |
* 이러한 속성은 Exchange 관리 셸의 표준 보기에 표시되지 않습니다. 이를 보려면 Format-Table 또는 Format-List cmdlet을 사용하여 속성 이름(정확한 이름 또는 와일드카드 일치)을 지정해야 합니다. 예시:
Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-List *Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-Table -Auto FriendlyName,*PrivateKey*
자세한 내용은 Get-ExchangeCertificate를 참조하세요.
Windows Certificate Manger에 표시되는 기본 자체 서명된 인증서에 대한 자세한 내용은 다음 표에 설명되어 있습니다.
| 속성 | Microsoft Exchange | Microsoft Exchange Server 인증 인증서 | Wmsvc |
|---|---|---|---|
| 서명 알고리즘 | sha256RSA1 | sha256RSA1 | sha256RSA1 |
| 서명 해시 알고리즘 | sha2561 | sha2561 | sha2561 |
| 주요 사용량 | 디지털 서명, 키 암호화(a0) | 디지털 서명, 키 암호화(a0) | 디지털 서명, 키 암호화(a0), 데이터 암호화(b0 00 00 00) |
| 기본 제약 조건 | Subject Type=End Entity |
Subject Type=End Entity |
해당 없음 |
| 지문 알고리즘 | sha2561 | sha2561 | sha2561 |
1 Exchange 2016 누적 업데이트 22 이상 및 Exchange 2019 누적 업데이트 11 이상의 새로운 설치에 적용됩니다. 자세한 내용은 설치 중에 만든 Exchange Server 2019 및 2016 인증서에서 SHA-1 해시 사용을 참조하세요.
일반적으로 Windows 인증서 관리자를 사용하여 Exchange 인증서를 관리하지 않습니다(Exchange 관리 센터 또는 Exchange 관리 셸 사용). WMSVC 인증서는 Exchange 인증서가 아닙니다.