도메인 보안을 위해 Edge 전송 서버에 PKI 사용

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

마지막으로 수정된 항목: 2012-07-23

도메인 보안은 인증을 위해 상호 TLS(전송 계층 보안)에 의존합니다. 성공적인 상호 TLS 인증은 도메인 보안에 사용되는 TLS 인증서에 대한 유효성 검사를 받은 트러스트된 X.509 인증서 체인에 의존합니다.

따라서 도메인 보안을 배포할 수 있으려면 인증서 트러스팅 및 인증서 유효성 검사를 수용하도록 Edge 전송 서버 및 X.509 PKI(공개 키 인프라)를 구성해야 합니다.

루트 인증 기관 구성

지정된 X.509 인증서의 유효성을 검사하려면 인증서를 발급한 루트 CA(인증 기관)을 트러스트해야 합니다. 루트 CA는 CA 계층 구조의 맨 위에 있는 가장 많이 트러스트된 CA입니다. 루트 CA는 자체 서명 인증서를 갖고 있습니다. 인증서 인증에 의존하는 응용 프로그램을 실행할 경우 각 인증서는 로컬 컴퓨터의 트러스트된 루트 컨테이너에 있는 인증서에서 끝나는 인증서 체인을 갖고 있어야 합니다. 트러스트된 루트 컨테이너는 루트 인증 기관의 인증서를 포함합니다.

도메인 보안 전자 메일을 보내려면 받는 서버의 X.509 인증서에 대한 유효성을 검사할 수 있어야 합니다. 마찬가지로 누군가가 도메인 보안 전자 메일을 사용자의 조직에 보낼 경우 보내는 서버에서 사용자의 인증서에 대한 유효성을 검사할 수 있어야 합니다.

도메인 보안을 구현하기 위해 사용할 수 있는 트러스트된 루트 CA에는 두 가지 유형, 즉, 기본 제공 타사 루트 CA와 개인 루트 CA가 있습니다.

타사 루트 인증 기관

Microsoft Windows에는 기본 제공 타사 루트 CA 집합이 포함되어 있습니다. 이러한 타사 루트 CA에 의해 발급된 인증서를 트러스트할 경우 이러한 CA가 발급한 인증서를 확인할 수 있다는 것을 의미합니다. 사용자의 조직과 파트너 조직에서 기본 Windows 설치를 사용하는 중이며 기본 제공 타사 루트 CA를 트러스트할 경우 트러스트는 자동입니다. 이 시나리오에서는 추가 트러스트 구성이 필요하지 않습니다.

개인 트러스트된 루트 인증 기관

개인 트러스트된 루트 CA는 개인 또는 내부 PKI에 의해 배포된 루트 CA입니다. 예를 들어 사용자의 조직이나 사용자가 도메인 보안 전자 메일을 교환하는 조직에서 고유한 루트 인증서를 가진 내부 PKI를 배포한 경우 추가 트러스트 구성을 설정해야 합니다.

개인 루트 CA가 사용될 경우 Edge 전송 서버에서 Windows 트러스트된 루트 인증서 저장소를 업데이트해야만 도메인 보안이 제대로 작동합니다.

직접 루트 트러스트와 상호 인증의 두 가지 방법으로 트러스트를 구성할 수 있습니다. 중요한 점은 전송 서비스에서 인증서를 선택할 때마다 사용 전에 인증서의 유효성을 검사한다는 것입니다. 따라서 개인 루트 CA를 사용하여 인증서를 발급하는 중이면 도메인 보안 전자 메일을 보내거나 받는 각 Edge 전송 서버에서 트러스트된 루트 인증서 저장소에 개인 루트 CA를 포함해야 합니다.

직접 루트 트러스트

개인 루트 CA에 의해 발급된 인증서를 트러스트하려면 Edge 전송 서버 컴퓨터의 트러스트된 루트 인증서 저장소에 해당 루트 인증서를 수동으로 추가하면 됩니다. 로컬 인증서 저장소에 인증서를 수동으로 추가하는 방법에 대한 자세한 내용은 MMC(Microsoft Management Console)에서 인증서 관리자 스냅인에 대한 도움말 파일을 참조하십시오.

상호 인증

상호 인증은 하나의 CA가 다른 CA에 의해 생성된 인증서에 서명할 경우 발생합니다. 상호 인증은 하나의 PKI에서 다른 PKI와의 트러스트를 작성하는 데 사용됩니다. 도메인 보안의 컨텍스트에서 고유한 PKI를 갖고 있는 경우 내부 PKI를 가진 파트너의 루트 기관에 대한 직접 수동 트러스트를 사용하는 대신에 루트 기관 아래에서 파트너 CA에 대한 상호 인증서를 만들 수 있습니다. 이 경우 최종적으로 상호 인증서의 체인이 트러스트된 루트에 다시 연결되므로 트러스트가 설정됩니다.

내부 PKI를 갖고 있고 상호 인증을 사용하는 경우 도메인 보안 전자 메일을 수신하는 각 Edge 전송 서버에서 루트 인증서 저장소를 수동으로 업데이트해야 합니다. 이렇게 하면 각 Edge 전송 서버는 상호 인증서를 통해 트러스트된 파트너로부터 전자 메일을 수신할 때 인증서의 유효성을 검사할 수 있습니다.

로컬 인증서 저장소에 인증서를 수동으로 추가하는 방법에 대한 자세한 내용은 MMC에서 인증서 관리자 스냅인에 대한 도움말 파일을 참조하십시오.

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

전송 서비스는 인증서를 검색할 때마다 인증서 체인과 인증서의 유효성을 검사합니다. 인증서 유효성 검사는 인증서의 많은 특성이 확인되는 프로세스입니다. 이러한 특성의 대부분은 인증서를 요청하는 응용 프로그램이 로컬 컴퓨터에서 확인할 수 있습니다. 예를 들어 인증서의 용도, 인증서의 만료 날짜 및 이와 유사한 특성을 PKI의 컨텍스트 외부에서 확인할 수 있습니다. 그러나 인증서가 해지되지 않은 확인은 인증서를 발급한 CA를 통해 유효성을 확인해야 합니다. 따라서 대부분의 CA는 일반인이 해지 상태의 유효성을 검사하는 데 사용할 수 있도록 CRL(인증서 해지 목록)을 제공합니다.

도메인 보안을 사용하려면 도메인 보안 전자 메일을 주고받는 Edge 전송 서버는 사용자가 사용하거나 파트너가 사용하는 CA에 대한 CRL을 사용할 수 있어야 합니다. 해지 검사에 실패할 경우 받는 Exchange 서버는 메시지의 임시 프로토콜 거부를 발급합니다. 일시적 해지 오류가 발생할 수 있습니다. 예를 들어 CRL을 게시하는 데 사용되는 웹 서버가 실패할 수 있습니다. 또는 Edge 전송 서버와 CRL 배포 지점 간의 일반적인 네트워크 연결 문제로 인해 해지 검사에 실패할 수 있습니다. 보내는 서버에서 나중에 다시 시도하기 때문에 일시적 해지 오류로 인해 일시적인 메일 배달 지연만 발생합니다. 그러나 도메인 보안 전자 메일 전송을 위해 CRL 유효성 검사가 필요합니다.

다음 시나리오가 가능하도록 해야 합니다.

• Edge 전송 서버에서 외부 CA에 대한 CRL에 액세스할 수 있어야 함   사용자가 도메인 보안 전자 메일을 교환하는 각 파트너는 조직의 Edge 전송 서버가 연결할 수 있는 공개적으로 사용 가능한 CRL을 갖고 있어야 합니다. 경우에 따라 CRL을 단지 LDAP(Lightweight Directory Access Protocol)와 함께 사용할 수도 있고 대부분의 경우 공용 CA를 사용하면 CRL은 HTTP를 통해 게시됩니다. Edge 전송 서버가 CRL에 연결할 수 있도록 적절한 아웃바운드 포트 및 프록시가 구성되었는지 확인해야 합니다. MMC의 인증서를 열고 CRL 배포 지점 필드를 봄으로써 주어진 CRL 배포 지점이 허용하는 프로토콜을 결정할 수 있습니다.

• 인증서를 발급한 CA에 대한 CRL을 공개적으로 사용할 수 있도록 해야 함   Edge 전송 서버가 사용자의 조직에서 인증서를 검색하더라도 인증서의 유효성을 검사하기 위해 인증서 체인의 유효성을 검사한다는 점이 중요합니다. 따라서 CA에 대한 CRL을 사용자의 Edge 전송 서버에서 사용할 수 있어야 합니다. 또한 도메인 보안 전자 메일을 교환하는 모든 파트너는 인증서를 발급한 CA에 대한 CRL에 액세스할 수 있어야 합니다.

WinHTTP용 프록시 설정 구성

Exchange 2010 전송 서버는 모든 HTTP 및 HTTPS 트래픽을 관리하는 원본 Microsoft Windows HTTP 서비스(WinHTTP)에 의존합니다. 허브 전송 서버와 Edge 전송 서버는 HTTP를 사용하여 Microsoft Exchange 2010 표준 스팸 방지 필터 업데이트 및 CRL 유효성의 업데이트에 액세스할 수 있습니다.

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

PKI 및 프록시 구성 테스트

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

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