안녕하세요. 네오입니다.

오늘은 하나의 IIS 에서 여러 사이트가 HTTPS(SSL) 서비스를 이용 하도록 구성하는 방법에 대해 이야기 해 보겠습니다.


외부 사용자가 접근하는 Product 환경에서는 도메인(또는 서브도메인) 별로 하나 이상의 전용 서버를 이용 할 것입니다. 그러면 하나의 IIS 에서 여러 사이트를 실행 할 필요가 없으므로, IP:Port 한 쌍을 하나의 사이트에 바인딩 하여 간단히 구성을 마칠 수 있습니다. 물리 서버가 귀했던 옛날이라면 모를까, 요즘 Product 환경에서 하나의 서버로 여러 HTTPS 사이트를 서비스 하는 경우는 없을 것입니다.


그러나 여러 도메인을 동시에 개발 하는 개발자는 자신의 PC 한 대에 여러 사이트를 구축 해야 하는 경우가 있습니다. 이 경우, 하나의 IIS 상에 SSL 를 이용 하는 사이트를 여러 개 구성 하게 되죠. 그러나 IIS 에 등록한 두 개 이상의 사이트에 443 포트를 바인딩 하면 웹 사이트의 실행이 멈추는 것을 볼 수 있습니다. 아래에서는 테스트 환경을 구축 할 때 발생 하는 이러한 문제의 원인과 해결 방안을 다루고 있습니다.

IIS 7.0

우선 IIS 7.0 버전을 기준으로 이야기를 해 보겠습니다.

SSL 을 이용하는 사이트가 1개인 경우

Local PC 또는 Dev Server 에 구축 할 사이트 중, SSL 을 이용하는 사이트가 1개 뿐이라면 자체서명된 서버 인증서를 이용하여 443 포트로 https 서비스를 제공 하면 됩니다. 자체서명된 SSL을 통해 https 바인딩 테스트 하기 페이지에서 안내 하는 과정을 따라 하면 쉽게 사이트를 구축 할 수 있습니다.

SSL 을 이용하는 사이트가 2개 이상인 경우

두 번째 사이트에 443 포트로 HTTPS 바인딩을 하면 IIS 에서 오류를 내기 시작합니다. 두번째 사이트의 실행을 중지 시켜 버리는 것이죠. Host header 까지 보고 바인딩을 하는 HTTP 와 달리, HTTPS 의 경우 요청을 처리 할 때 host header 를 보지 않기 때문입니다. Bind multiple sites on same IP address and Port in SSL 문서에 이 내용이 잘 다루어져 있습니다. 아래에서 해당 문서의 내용을 간략히 요약 해 보았습니다. SSL 웹 사이트 – 주체 대체 이름, Subject Alternative Name (SAN) 문서는 이와 비슷한 내용을 다루는 한글 문서입니다.

Bind multiple sites on same IP address and Port in SSL 요약

닭이 먼저냐, 달걀이 먼저냐?

IIS 에 443 포트로 HTTPS 가 바인딩 된 두 개의 사이트가 있고, 두 사이트는 각각 다른 인증서를 사용 한다고 가정 해 봅시다. 이 상황에서 443 포트로 요청이 들어 온다면 어떻게 될까요? 우선 IIS 는 암호화 된 상태로 443 포트로 들어온 request 를 인증서의 키로 복호화 합니다. 이 복호화를 마치면 host name 을 알 수 있게 되죠. IIS 는 복호화를 하기 위해 사이트에서 인증서를 찾아야 합니다. 어라, 그런데 443 포트에 연결 된 사이트가 두개네요? 그러면 IIS는 두 사이트의 인증서 중 어느 인증서를 사용 하여 복호화를 해야 할 지 알 수 없는 상태가 됩니다. 복호화를 해야 host name 을 알아 내서 어느 사이트로 들어 온 요청인 지 알 수 있는 데, 복호화를 하려면 어느 사이트로 들어 온 요청인 지를 알고 인증서 키를 찾아야 하는 문제... 이것이 두 개 사이트가 동일 포트로 HTTPS 를 바인딩 했을 때 발생 하는 닭과 달걀 문제입니다. 근본적으로 SSL 통신 시에는 host name 을 바인딩 하지 않기 때문에 발생하는 문제이죠.

이 문제는 두 가지 방법으로 해결 할 수 있습니다.

Wild Card Certificate

첫 번째, 도메인이 같은 경우 wild card certificate 를 사용 합니다. 와일드 카드 인증서를 사용하는 방법은 상세히 설명한 문서가 많기 때문에 여기서는 따로 설명 하지 않겠습니다. 원문을 보셔도 좋을 것 같습니다.
참고로 도메인이 같은 경우의 예는
www.tistory.com / notice.tistory.com / webindepth.tistory.com
과 같이 subdomain 이하가 다른 경우를 들 수 있습니다. 

SAN(Subject Alternative Name) Certificate

두 번째, 도메인이 다른 경우 SAN(주체 대체 이름) 인증서를 사용 합니다. SAN 인증서는 자체서명된 SSL을 통해 https 바인딩 테스트 하기 페이지에서 설명한 "IIS 자체 서명 인증서" 로는 만들 수 없고, OpenSSL 과 같이 인증서를 만드는 프로그램을 이용 해야 합니다. SAN 인증서를 만들고 나면 원문이나 하나의 IIS에서 여러 웹사이트 SSL포트(443)를 같이 쓰기IIS 6/7/8 : 멀티 도메인 SSL 인증서 바인딩 적용 방법 문서에서 설명 하는 appcmd 명령어를 이용 하여 여러 사이트가 동시에 443 포트를 이용 하도록 구성 할 수 있습니다.

서로 다른 Port 를 사용하자

그런데, 정말 OpenSSL 을 이용해서 SAN 인증서를 만드는 수고를 해야 할 지는 한 번 짚고 넘어가야 할 것 같습니다.


도입부에서 말씀 드렸듯, Product 환경에서는 하나의 서버가 여러 HTTPS 사이트를 제공 할 이유가 없기 때문입니다.

  • 사용자가 많아서 도메인을 여러 개로 분리 한 상황이라면
    → 각 도메인 마다 하나의 서버를 운용 하는 것이 좋습니다. 사실 이 정도 규모의 서비스라면, 이미 각 서브도메인 마다 여러 개의 웹 서버를 두어 하나의 서버 팜을 구성 했겠죠.
  • 사용자는 적은데 도메인을 여러 개로 분리 했기 때문에 하나의 서버에서 운용 해야 한다면
    → 오버 엔지니어링이니 도메인을 통합 하는 것이 좋겠습니다.
  • 운용하는 서비스가 많아 도메인을 여러 개로 분리 했지만 서버를 추가로 마련 할 상황이 안 된다면
    → 영세한 회사일 테니 물리서버를 직접 운용하기보다 AWS, Azure 와 같은 Cloud 서비스를 이용 하는 것이 좋아 보입니다.
위에서 "도메인"은 "서브도메인" 으로 생각 하셔도 좋습니다. 결국 하나의 IIS 에서 여러 사이트가 443 포트를 공유 하는 문제는 주로 테스트 환경에서 마주치게 될 것입니다. 그런데 테스트를 위해서라면 굳이 443 포트를 이용 할 필요가 없죠. SSL 을 바인딩 할 각 사이트 마다 서로 다른 포트를 이용 하고, 브라우저에서 접근 할 때에 포트를 적어 주면 됩니다. www.tistory.com:4430 / notice.tistory.com:4431 / webindepth.tistory.com:4432 처럼 말이죠. 결국 테스트를 위해서는 이처럼 포트를 구분 하는 것이 가장 실용적인 방법이라고 생각 합니다.

IIS 8.0

IIS 7.0 에서는 여러 사이트가 443 포트를 동시에 사용하기 위해서는 위와 같이 번거로운 과정을 거쳐야 했습니다. Windows server 2012 의 IIS 8.0 부터는 이 불편함이 개선 되어서, SAN 인증서를 생성하고 바인딩 하는 과정 없이 SNI(Server Name Indication) 를 이용 하여 여러 사이트를 443 포트에 바인딩 할 수 있습니다.


고백하자면 저도 아직 이 기능을 사용 해 본 적은 없기 때문에(^^;) 아래에 링크를 남기는 것으로 설명을 대신 하겠습니다.


https://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability

https://www.digicert.com/ssl-support/ssl-host-headers-iis-8.htm

http://www.sherweb.com/blog/host-different-ssls-on-one-ip-with-iis-8-sni/


혹시 IIS 8.0 의 SNI 기능에 대해 더 설명이 필요하다면 댓글을 남겨 주세요. 추가 설명을 덧붙이도록 하겠습니다.

마치며...

IIS 8.0 에서 (상대적으로) 편리한 SNI 기능이 도입 되었다고 해도, 운영 환경에서 하나의 물리 서버에서 여러 개의 도메인을 서비스 하는 경우는 앞으로 점점 감소할 것으로 예상 합니다. 웹 서비스 시스템을 구성 할 때에 규모가 큰 서비스일 경우에는 도메인 당 여러 서버로 구성 된 서버 팜을 할당 하는 것이 일반적이고, 규모가 작은 서비스일 경우에는 클라우드 환경을 이용 하는 추세이기 때문입니다.

이상으로 하나의 IIS 에서 여러 사이트가 SSL 을 이용 하는 방법을 살펴 보았습니다. 결론적으로 IIS 7.0 이용자라면 포트 번호를 다르게 설정 하는 것이 가장 효율적인 방법이라고 봅니다. 반면 IIS 8.0 이용자는 SNI 기능을 이용하는 것이 좋을 것 같습니다.
IIS 테스트 환경을 구성하다가 어려움을 겪은 분이나, SSL 를 이용하는 사트를 구성하면서 의문을 가진 분께 이 글이 도움이 되었기를 바랍니다.