버추얼 호스팅(Virtual Hosting)은 사실 꽤나 오래된 주제다.
뭔고 하니 한 IP를 가진 서버에서 여러개의 웹서비스를 도메인별로 독립적으로 운영할때 쓰이는 기술이다.
예를 들어 1.2.3.4 라는 IP를 가진 서버를 소유하고 있는 상황에서
80번 포트를 공용으로 사용하면서 www.a.com 이라는 웹페이지와 www.b.com 이라는 웹페이지를 별도로 서비스하고 싶을때 버추얼 호스팅 기술이 쓰인다.
아마 인터넷 프로토콜에 대해서 조금 아는 사람이라면 의문이 들 수도 있을 것이다.
들어오는 접속을 어떻게 구분해서 각 도메인별로 처리할 수 있는 걸까?
비결은 HTTP 프로토콜 헤더의 Host 필드에 있다.
클라이언트에서는 서버에 TCP 접속이 성사되면 HTTP Request를 보내는데, 이때 Host 필드에 웹브라우저에 입력된 도메인을 넣어주도록 되어 있다.
대충 캡쳐해본 HTTP 프로토콜 Request 헤더 부분
사실 HTTP 1.0 표준에서는 Host 필드가 강제적인 규약이 아니었다.
하지만 현재 대부분의 웹브라우저에서 표준으로 쓰이고 있는 1.1 표준에서는 반드시 Host 필드를 서버에 전송해야 하도록 되어있다.
그 결과 오늘날 웹서버에서도 부담없이 버추얼 호스팅을 운영할 수 있다.
이로서 웹 호스팅 업체도 서버 관리 비용을 굉장히 절약할 수 있고, 그 결과 사용자도 보다 저렴하게 호스팅받을 수 있게 된 것이다.
하지만 얄궂게도 이런 축복받은 기술이 SSL과 같은 암호화 프로토콜과 접목되면 상황이 전혀 달라진다.
SSL은 그 특징상 어플리케이션 레이어 아래에서 동작하는데,
그렇기 때문에 HTTP 헤더들을 전송하기 전에 앞서 우선 서버와 클라이언트 간의 SSL 세션부터 열어야 한다.
문제는 SSL 세션을 열 때 웹브라우저에서 웹서버의 인증서를 검사하는 과정에서 발생한다.
웹서버의 인증서의
Common Name 필드는 반드시 해당 서버의 도메인을 가리키도록 되어있는데,
그렇지 않으면 잘못된 인증서라고 경고가 발생한다.
왜 이런 상황이 문제가 되는 걸까????
자... 예제로 한번 살펴보자.
일단 웹서버를 한대 운영하고 있다고 가정하자.
이 웹서버에는 www.a.com 과 www.b.com 두개의 웹사이트를 버추얼 호스팅을 이용하여 서비스하고 있다.
그리고 이 모든 웹사이트에 대해서 SSL 접속을 제공한다고 가정하자.
SSL 인증서는 www.a.com, www.b.com 이름으로 각각 발급받았다.
이 상황에서 한 클라이언트가 https://www.a.com/ 으로 접속을 시도하면 어떻게 될까?
SSL 접속 요청이 들어왔기 때문에, 웹서버에서는 HTTP 통신에 앞서 SSL 채널을 열려고 할 것이다.
이때 웹서버는 자신의 인증서를 클라이언트에게 보내줘야하는데 여기서 문제가 발생하는 것이다.
www.a.com 인증서를 보내줘야하나? 아니면 www.b.com 인증서를 보내줘야 하나???
현 상황에서는 HTTP 헤더를 전송하기 전이기 때문에, 당연히 HTTP Request 프로토콜의 Host 필드값을 알 수 없는 상태다.
따라서 서버 측에서 당췌 이놈이 어디를 노리고 접속을 시도하는 것인지 이 상황에서는 알 방법이 없다.
결국 서버에서는 기본값으로 세팅된 인증서를 보내줄 수 밖에 없다.
여기서 www.a.com 인증서를 기본값으로 세팅해놨다고 보자.
이 상황에서 www.a.com 으로 들어오는 접속은 별 문제없이 처리할 수 있을지 몰라도,
www.b.com 으로 접속이 들어와서 SSL 채널을 열려고 시도한다면 당연히 웹브라우저에서는 보안 경고를 출력해서 접속을 막는다.
혹시 다른 웹사이트에서 인증서를 훔쳐서 쓰고 있는 것 아냐? 라고 웹브라우저가 의심하는 상태
이 쯤 오면 웹서버 관리자는 슬슬 짜증이 올라오게 되어있다.
비싼 돈 주고 인증서는 여러장 발급받아놨는데, 정작 쓸 수 있는건 1개밖에 없으니 짜증날만 하지.
하지만 왜 내가 여기 글을 쓰겠는가?
대안이 있기 때문이지.
바로 인증서의
Subject Alternative Name (또는 줄여서 SAN) 필드를 이용해서 추가로 도메인을 인증서에 등록할 수 있다.
Subject Alternative Name 필드를 이용해서 여러개의 도메인을 등록한 인증서
참고로 SAN 필드를 이용한 다중 도메인 인증서는 UCC (Unified Communications Certificate) 또는
MDC (Multi-Domain Certificate) 라고 불리기도 하므로, 헷갈리지 말고 동일한 놈으로 취급해도 무방하다.
아쉽게도 버추얼 호스팅 상황에서 SSL을 적용하고 싶을 경우, 기존에 SAN 필드가 없는 상태로 발급받은 인증서는 폐기해야한다.
환불이나 업그레이드에 관련된 사항은 해당 인증기관에 연락해서 확인해봐야 할 것이다.
마지막으로 남은 문제는 어떤 인증기관(Certificate Authority)에서 UCC 인증서를 발급해주는가이다.
다행히도 오늘날 많은 인증기관에서 UCC 인증서를 발급해주고 있다.
하지만 대게 일반 인증서보다 더 비싸고, 도메인 갯수에 비례해서 돈을 더 받는 곳이 많다.
그래도 이게 어딘가? 일단 불가능에서 가능으로 바뀌었잖아.
개인적으로 UCC 인증서를 제공하고 있는 인증기관 중 추천하고 싶은 곳은 이전에도 언급한 이스라엘의 StartCom 이다.
$39.90 이라는 말도 안되는 저렴한 비용으로 2년간 도메인 갯수에 상관없이 무제한 인증서를 발급받을 수 있다.
참고로 VeriSign에서는 UCC 인증서를 발급받기 위해서는 반드시 그쪽에서 관리하는 PKI 프로그램에 가입해야 하는데, 이 비용만 해도 1년에 $3,000 이 넘는다...
StartCom과 비교해서 거의 150배 이상 차이나는군...
지금까지 버추얼 호스팅과 SSL이 접목되면 발생하는 문제, 그리고 그 해결책을 맛보기로 알아보았다.
다음번에는 EV 인증서에 대해서 한번 포스팅해볼까 계획 중.
libthreadsafequeue.tar.gz
TSST-ODD_Checksum.7z
