sign in join

IIS 8.0 서버 이름 표시(SNI, Server Name Indication): SSL 확장성

등록일시: 2012-06-29 14:20,  수정일시: 2016-09-02 08:40
조회수: 13,823
이 문서는 IIS 기술을 널리 알리고자 하는 개인적인 취지로 제공되는 번역문서입니다. 이 문서에 대한 모든 저작권은 마이크로소프트에 있으며 요청이 있을 경우 언제라도 게시가 중단될 수 있습니다. 번역 내용에 오역이 존재할 수 있고 주석은 번역자 개인의 의견일 뿐이며 마이크로소프트는 이에 관한 어떠한 보장도 하지 않습니다. 번역이 완료된 이후에도 대상 제품 및 기술이 개선되거나 변경됨에 따라 원문의 내용도 변경되거나 보완되었을 수 있으므로 주의하시기 바랍니다.
본 문서에서는 윈도우 서버 8의 서버 이름 표시(SNI, Server Name Indication) 기능에 관해서 살펴봅니다. 다만, 본문의 원문은 IIS 8이 정식으로 배포되기 이전인 2012년 2월 29일에 공개된 문서로, 일부 내용에 변경사항이 존재할 수 있습니다. 본 문서는 2012년 6월 현재, IIS 8을 미리 살펴보기 위한 사전정보일 뿐입니다.

호환성

버전 비고
IIS 8.0 서버 이름 표시는 IIS 8.0에서 도입되었습니다.
IIS 7.5 IIS 7.5에서는 서버 이름 표시가 지원되지 않습니다.
IIS 7.0 IIS 7.0에서는 서버 이름 표시가 지원되지 않습니다.

내용

문제점

더 많은 전자상거래 사이트들이 생겨나고 더 많은 업무들이 온라인에 민감한 문서를 저장하거나 공유하기 시작하면서 보안 사이트를 호스트하고 확장할 수 있는 능력이 점점 더 중요해지고 있습니다. 윈도우 서버 8 이전에는 보안 사이트를 호스팅하기 위해서 다음과 같은 두 가지 문제점을 해결해야만 했습니다: *

  • SSL 확장성: 공유 호스팅과 같은 다중 이용자 환경에서는 윈도우 서버에서 호스트 할 수 있는 보안 사이트의 수에 제한이 존재하기 때문에 결과적으로 사이트 밀도가 낮을 수 밖에 없었습니다.
  • IPv4 부족: IP:Port 바인딩에 의해서만 네트워크 종점(End-Point)의 식별이 가능했기 때문에 이용자가 표준 SSL 포트인 443을 사용하고자 하는 경우, 보안 사이트를 호스트하려면 이용자별로 각각의 IP 주소를 할당해야만 하는 경우가 종종 발생합니다.

* 본문에서 얘기하고자 하는 문제점은 이런 것입니다. 자신이 IIS 서버를 관리하는 서버 관리자라고 생각해보십시오. 이 IIS 서버에는 IP가 하나 할당되어 있고요. 그리고, 고객의 요청에 따라 www.domain_a.com 사이트를 설정해서 서비스를 제공해주고 있었습니다. 그런데 어느 날, 새로운 고객을 유치하게 되어 www.domain_b.com 사이트를 설정해서 서비스를 제공해줘야 할 상황이 생겼습니다.

자, 서버는 한 대 뿐이고 할당된 IP도 단 하나 뿐입니다. 그런데, 서비스를 제공해줘야 할 사이트는 두 개가 된거죠. 정상적인 경우라면 두 사이트 중 하나는 80번 포트를 사용할 수가 없는 상황이지만(한 사이트가 다른 사이트에 80번 포트를 양보해야 하니까요), IIS가 오래 전부터 가상 호스트 기능을 제공해왔으므로 아무런 문제 없이 서비스를 제공할 수 있습니다.

지면 관계상 가상 호스트 기능을 간단하게 설명드리면 이렇습니다. IIS는 [IP]:[Port]의 조합으로 사이트를 식별하는 것이 아니라 [IP]:[Port]:[Hostname or Domain]의 조합으로 사이트를 식별하기 때문에, 80번 포트 하나에 대해서 여러 개의 다른 호스트명이나 도메인명의 사이트를 서비스 할 수 있는 것입니다. (마치, 데이터베이스 테이블의 기본키 같죠?) 가상 호스트 기능은 다른 웹 서버 제품들도 대부분 지원하고 있는 것으로 알고 있습니다. 그리고, 이를 정상적으로 사용하려면 브라우저에서도 이를 지원해줘야만 하는데 대부분의 브라우저들이 이 기능을 지원해주기 때문에 저희는 지금도 아무런 문제 없이 그 이점을 누리고 있는 것이구요.

그런데, 이 가상 호스트 기능은 어디까지나 HTTP 프로토콜에 관한 것이었습니다. 가령, IIS 6.0까지는 FTP 프로토콜에 대해서는 가상 호스트 기능을 지원해주지 않았었기 때문에 어쩔 수 없이 포트 번호를 임의로 부여해서 따로따로 사용해야 했었습니다. 사실 솔직하게 말씀드린다면 IIS에 내장된 FTP 자체를 그리 많이 사용하지 않기도 했구요. 그러다가, IIS 7.x 버전이 나오면서 드디어 FTP 프로토콜에서도 이 가상 호스트 기능이 제공되기 시작했습니다. 빙고! 이 기능은 이미 Taeyo.net의 다음 문서에서 살펴봤었죠.

Using Virtual Host Names

자, 이제 HTTP 프로토콜과 FTP 프로토콜 모두 가상 호스트 기능을 제공하게 되었습니다. 그런데, 아직 한 가지 중요한 프로토콜이 남아 있죠? 네, 그렇습니다. 바로 HTTPS 프로토콜이 그 주인공이죠. 이런 관점에서 살펴본다면 웹호스팅 서비스를 제공해주는 업체 입장에서는 HTTPS의 기본 포트인 443 포트가 매우 귀중한 자원이 아닐 수 없습니다. 그리고, 서버 가상화 등의 기술을 제외한다면 본문에서 살펴보게 될 IIS 8.0의 SNI 기능이 바로 이 문제에 대한 웹 서버 수준의 해답입니다.

해결방법

윈도우 서버 8의 IIS 8.0은 SSL 교섭(Negotiation) 과정의 일부로 가상 도메인을 포함시킬 수 있는 TLS 확장인, 서버 이름 표시(SNI, Server Name Indication) 기능를 지원해줍니다. 이 말이 의미하는 실질적인 내용은, 이제 네트워크 종점을 식별할 때 가상 도메인 이름이나 호스트명을 사용할 수 있게 되었다는 뜻입니다. 또한, SNI를 지원하기 위한 새로운 고확장성의 Web Hosting 저장소가 제공됩니다. 결과적으로 윈도우 서버 8의 보안 사이트 밀도는 훨씬 높아졌으며, 그럼에도 불구하고 단지 하나의 IP 주소만 사용합니다. *

다만, 이 기능을 사용하려면 고객들의 브라우저가 SNI를 지원해야 한다는 점을 반드시 기억하시기 바랍니다. 최신 브라우저들은 대부분 SNI를 지원하지만 윈도우 XP 상에서 실행되는 모든 버전의 인터넷 익스플로러는 SNI를 지원하지 않습니다.

* 이 서버 이름 표시(SNI, Server Name Indication) 기능은 IIS에서만 제공되는 고유의 기능은 아닙니다. 이 기능에 대한 보다 자세한 정보는 다음 문서를 참고하시기 바랍니다.

Server Name Indication - Wikipedia, the free encyclopedia

단계별 지침

전제조건:

  • 윈도우 서버 8에 IIS가 설치되어 있어야 합니다.
    • Web Hosting 인증서 저장소와 SNI는 모두 기본 IIS 설치 구성의 일부분입니다. 따라서, 서버 관리자를 사용해서 별도로 설치해야 할 추가적인 IIS 기능은 없습니다.
  • 예제 인증서가 필요합니다.
  • 미리 \windows\system32\drivers\etc\hosts 파일을 수정해서 예제 사이트 및 예제 인증서 관련 내용을 구성해놔야 합니다. 가령, 인증서의 CN 이름이 TAPTesting라면 호스트 파일에 다음과 같은 내용이 포함되어 있어야만 합니다:

    127.0.0.1 TAPTesting

알려진 버그에 대한 해결방법:

같은 머신에 전통적인 SSL 바인딩(IP:Port)과 SNI 바인딩(호스트명:Port)이 함께 구성되어 있는 경우, IIS 관리자가 의도하지 않게 SSL 바인딩을 제거하는 경우가 간혹 발생합니다. 이 문제점을 해결하려면 다음의 명령줄 도구를 이용해서 실제 SSL 바인딩을 확인하시기 바랍니다:

netsh http show sslcert

웹 호스팅 저장소에 인증서 불러오기:

  1. 빈 MMC를 실행합니다.
  2. 파일(File) 메뉴에서 스냅인 추가/제거(Add/Remove Snap-in)를 선택합니다:
  3. 좌측 목록에서 인증서(Certificates)를 선택한 다음, 추가(Add) 버튼을 클릭합니다:
  4. 컴퓨터 계정(Computer account)을 선택합니다:
  5. 로컬 컴퓨터(Local computer)를 선택한 다음, 마침(Finish) 버튼을 클릭합니다:
  6. 확인(OK) 버튼을 클릭합니다:
  7. 좌측 트리뷰 패인에서 Web Hosting 저장소를 선택합니다:

    이 Web Hosting 저장소는 개인용(Personal) 저장소와 유사하게 동작하므로, 기존의 모든 도구를 이용해서 같은 방식으로 인증서를 가져오거나 내보낼 수 있습니다. Web Hosting 저장소와 개인용(Personal) 저장소의 결정적인 차이점은, Web Hosting 저장소가 보다 많은 숫자의 인증서를 대상으로 확장될 수 있도록 설계되었다는 것입니다.
  8. 예제 인증서를 Web Hosting 저장소로 가져옵니다.

보안 웹 사이트 생성하기:

  1. IIS 관리자를 실행합니다.
  2. 좌측의 연결 패인에서 사이트(Sites) 노드를 선택합니다:
  3. 사이트(Sites) 노드를 마우스 오른쪽 버튼으로 클릭하고, 웹 사이트 추가(Add Website)를 선택합니다:
  4. 일반적인 사이트를 생성할 때처럼 필요한 정보들을 입력합니다:
    • 사이트 이름: Test
    • 실제 경로: c:\inetpub\wwwroot
    • 종류: https
    • 호스트 이름: TAPTesting
      • 윈도우 서버8에서는 SSL에 대한 호스트 이름을 지정할 수 있습니다. *
      • 인증서 이름을 잘못 지정하는 실수를 피하려면 여기에 지정한 호스트 이름이 인증서의 CN 이름과 일치하는지 확인하십시요.
      • 이 구성의 실제 값은 사용되는 예제 인증서에 따라 달라집니다.
    • Use Server Name Indication: 체크
    • SSL 인증서: 인증서의 이름을 선택합니다. 이 예의 경우 TAPTesting입니다.
      • 개인용 및 Web Hosting 저장소의 인증서들이 여기에 나타난다는 점에 주의하십시요.
  5. 사이트가 정상적으로 생성되었는지 확인합니다:
  6. 작업이 완료되었습니다. SNI를 사용하는 보안 사이트가 생성되었습니다. 관리 과정 자체는 전통적인 SSL 바인딩을 관리하는 과정과 매우 비슷합니다. 유일한 차이점들은:
    • SSL 사이트에 호스트 이름을 지정할 수 있다는 점과,
    • 확장성을 위해 인증서가 Web Hosting 저장소에 저장되었다는 점입니다.

* 이전 버전에서는 바인딩의 종류가 https로 지정되면 호스트 이름 항목이 비활성화 되었습니다.

보안 사이트 테스트:

이제 브라우저를 실행시킨 다음, https://TAPTesting/로 이동해봅니다. 이미 전제조건에서 설명했던 것처럼 이 요청이 정상적으로 localhost로 전달되려면 호스트 파일이 수정되어 있어야 한다는 점에 주의하십시요:

그리고, 새로운 SSL 바인딩 형식을 살펴보려면 다음의 명령을 권한이 상승된 명령줄 창에 입력하십시요:

netsh http show sslcert

SSL 바인딩이 TAPTesting:443이라는 값을 갖고 있는 hostname:port 형식이라는 점에 주목하시기 바랍니다.

시나리오

다음과 같은 시나리오에서 배포를 수행하여 테스트 해보십시요:

  • SNI는 다중 이용자 환경의 확장성을 위해서 설계된 기능입니다. SNI를 이용하여 수 천개의 보안 사이트를 구성해 보십시요.
  • 기존의 윈도우 서버 버전과는 달리 윈도우 서버 8에서는 인증서가 필요한 시점에 메모리로 로드됩니다. SNI를 이용해서 수 천개의 수준의 보안 사이트를 구성한 다음, 보안 사이트 중 하나에 GET 요청을 전송하고 메모리 사용량을 살펴보십시요. 거의 무시할 수 있는 수준의 메모리만 사용되는 것을 확인할 수 있을 것입니다. 이전 버전의 윈도우 서버에서는 수 백개의 보안 사이트들이 구성된 상태에서 단 하나의 GET 요청만 전송하더라도 윈도우 서버가 모든 인증서를 로드했었습니다. 결과적으로 많은 메모리를 사용했었고 확장성도 제한될 수 밖에 없었습니다.
  • 윈도우 서버 8 상에서 SNI 보안 사이트와 전통적인 보안 사이트를 함께 구성해보십시요. 이 두 가지 기능들은 함께 사용할 수 있도록 설계되었습니다.

요약

본문에서는 윈도우 서버 8의 서버 이름 표시(SNI, Server Name Indication) 기능을 살펴봤습니다.

확인 취소 닫기