Share via

[Dongclee의 2012년 7월 첫 번째 포스팅] Windows Server 2012 Series 14 : Certificate Enrollment Web Service 와 Certificate Enrollment Policy Web Service를 사용하면 뭐가 더 좋을까요?

  • Article

안녕하세요?

벌써 2012년도 반이 훌쩍 지나가 버렸네요.. 요즘 너무 비가 오지 않아서 농작물 및 생물들이 생기가 없어 보입니다. 비가 너무 많이 와도 문제지만, 비가 너무 안 오니 진짜로 걱정이 더 많네요.. 우리 농민들이 늘 걱정없이 생업에 전념하기를 도시에 사는 보잘 것 없는 제가 빌어봅니다.

이번에 소개해 드릴 주제는 바로Certificate Enrollment Web Service (CES) 와 Certificate Enrollment Policy Web Service (CEP) 입니다. 이 기능은 사실 Windows Server 2008 에서부터 지원되어 왔었는데, 이번에 제가 Windows Server 2012의 새로운 기능을 살펴보면서, Windows Server 2012에 맞게 Step-By-Step 가이드를 만들어 보았습니다. CEP 및 CES의 필요성 및 기본적인 개요를 한 번 살펴보겠습니다.

Windows Server 2008 以前 운영 체제는 사용자 및 컴퓨터 인증서 발급에 필요한 인증 방법으로써 Kerberos를 사용합니다. 또한, 이러한 인증서 발급 요청은 트랜스포트 층을 통하여 전송됩니다. 이때, 인증 및 인증서 발급 요청은 DCOM 구성 요소를 사용합니다. DCOM를 사용한 인증서 발급 방법은 인증서 서비스를 활용하기 위한 여러 가지 시나리오를 적용할 수 없습니다. 예를 들어, “포리스트 사이의 인증서 자동 등록” 또는 “회사 내부 네트워크에 직접적으로 연결할 수 없는 컴퓨터들의 인증서 발급”은 기존 DCOM을 사용하는 프로토콜에서 불가능합니다. 왜냐하면, 회사 내부의 중요 서버인 CA 서버는 방화벽 내부에 위치하는 것이 통상적인 배치입니다. 그리고, 이러한 방화벽은 RPC 및 DCOM을 위한 포트는 보안상의 이유로 블로킹합니다. 이러한 방화벽 제어 때문에, 인증서 서비스를 다양한 시나리오에서 사용하기에 제약을 받을 수 있습니다. 물론, Windows Server의 CA는 이러한 DCOM구성 요소를 사용한 인증서 발급 외에, IIS를 사용한 Web Enrollment (ex, https://localhost/certsrv ) 방법을 대안으로 제시했습니다. 그러나, Web Enrollment 방법은 “인증서 갱신” 등을 포함한 여러 가지 기능 상의 제약점이 많습니다. 그래서, Web Enrollment 방법은 앞서 언급했던 전통적인 인증서 발급의 제약점을 해결하기 위한, 최종적인 방안이 아니라 Workaround수준의 방법입니다. 아래 그림이 기존의 인증서 발급을 위한 전통적인 방법입니다. 즉, CEP 및 CES를 사용하지 않는 인증서 발급 방법입니다.

이러한 전통적인 인증서 발급의 제약 사항을 제거하고, 인증서 서비스의 다양한 시나리오 적용을 위하여, Microsoft는 Windows Server 2008 R2 에서 WS-Trust 기반의 신규 인증서 등록 프로토콜을 지원합니다. 이러한 신규 인증서 등록 프로토콜을 지원하기 위하여, Windows Server 2008 R2에서 새로운 2가지 역할 서비스를 제공합니다. 새로운 2가지 역할 서비스는 바로 CEP 및 CES 입니다. CEP 및 CES 역할 서비스는 인증서 발급 요청 메시지를 TLS로 암호화하여 HTTPS로 전송할 수 있고, 인증서 발급을 위해 필요한 “인증 (Authentication)”을 위해 Kerberos에만 의존하지 않습니다. 즉, CEP 및 CES는 웹 서비스로 개발된 역할 서비스이기 때문에, RPC 및 DCOM과 같은 동적 포트를 사용하지 않고, 443과 같은 HTTPS 포트를 사용합니다. 즉, 443 포트를 사용하여, 클라이언트 컴퓨터는 CEP 및 CES에 인증서 발급 요청을 하고, 이러한 발급 요청을 CEP 및 CES는 방화벽 내부의 CA 서비스에 전달합니다. 이러한 구조를 이용하면, 포리스트 사이 및 웹을 통한 이러한 자동 인증서 발급과 같은 다양하고 보안성을 높힐 수 있는 인증서 발급 시나리오를 구성할 수 있습니다. 다만, CEP 및 CES 서비스를 사용할 수 있는 클라이언트는 Windows 7 및 Windows Server R2 이후 운영체제 입니다.아래 그림은 CEP/CES 서비스를 사용하여 HTTPS를 통한 인증서 발급 구조입니다.

혹시 이 블로그를 보시면서, 기존 Web Enrollment와 다른 점이 무엇일까 궁금해 하시는 분이 계실 깁니다. CEP 및 CES를 구성하시게 되면, 클라이언트 컴퓨터에서 웹 브라우저가 아닌 “인증서 스냅-인(MMC)”를 사용하여 인증서 발급 및 갱신할 수 있습니다. 첨부 문서를 보시면 이 점을 좀 더 명확하게 아실 수 있습니다.

추가적으로 CEP 및 CES를 구성하실 때, 필요한 port에 대해서 아래 그림에서 확인하실 수 있습니다.

위 그림을 보시면 CES 및 CEP를 DMZ 구간에 위치시키고, 실제 CA 서버와 DCOM 통신이 필요한 것은 클라이언트가 아니라 CEP임을 확인할 수 있습니다.

제가 앞서 인증서 서비스의 CRL을 확인하기 위한 OCSP 관련 블로그를 포스팅했는데, OCSP 와 더불어 CEP 및 CES까지 구성하신다면, Microsoft CA 서비스의 최종적인 Blueprint가 아닐까 하는 생각을 개인적으로 해봅니다.

무더운 날씨에 다들 건강 조심하시구, 다음 포스팅에서 뵙겠습니다.

Windows 2012 Certificate Enrollment Using CEP.pdf

Comments

  • Anonymous
    January 01, 2003
    안녕하세요 Rainy 님 퇴근 하기 전에 제 블로그에 들어와 보니 댓글이 있네요... 일단 칭찬의 말씀 감사하게 생각합니다. Windows Troubleshooting은 어떤 내용이신지요,,,, 이런 지면이라면, 덤프 분석이나 넷몬분석 같은 건 한계가 있을 것 같은데요,, 여하튼,, 일단 질문 남겨 놓으세요,, 제가 아는 한도 내에서 답을 드리겠습니다.

  • Anonymous
    July 23, 2012
    이동철님. 매번 포스팅이 올라올때마다 어디에서도 얻을 수 없는 지식을을 얻음에 감사드립니다. 근데 혹시 windows trouble shooting에 관하여 질문을 이동철님에게 드려도 실례가 되지 않을런지요? 조금 오랜 기간 몇가지 해결 못하여 포기한 것들이 있는데 혹시 조언을 들을 수 있을까 하여 질문드립니다.