IIS 8.0 중앙집중식 SSL 인증서 지원: SSL 확장성 및 관리용이성

호환성

내용

• 문제점
• 해결방법
• 단계별 지침
  • 중앙집중식 SSL 인증서 지원 기능 구성하기
  • 보안 웹 사이트 생성하기
  • 보안 사이트 테스트
• 요약

문제점

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

• SSL 확장성: 공유 호스팅과 같은 다중 이용자 환경에서는 윈도우 서버에서 호스트 할 수 있는 보안 사이트의 수에 제한이 존재하기 때문에 결과적으로 사이트 밀도가 낮을 수 밖에 없었습니다.
• SSL 관리: 인증서들이 각각의 윈도우 서버에 반복적으로 저장되기 때문에 윈도우 서버마다 개별적으로 관리가 이뤄져야 했습니다. 따라서, 인증서를 갱신하는 단순한 작업 조차도 모든 서버에서 매번 반복될 수 밖에 없었습니다. 가령, 반드시 필요한 수 천개의 인증서가 존재하는 경우 등에는 새로운 윈도우 서버를 추가하는 작업에만 몇 시간이 걸릴 수도 있었습니다.

해결방법

윈도우 서버 8의 중앙집중식 SSL 인증서 지원 기능을 이용하면 인증서를 파일 공유에 중앙집중적으로 저장하거나 접근할 수 있습니다. 그리고, 윈도우 서버 2008에서 처음 도입된 공유 구성(Shared Configuration) 기능과 비슷하게 필요한 시점에 파일 공유에서 인증서를 로드하도록 서버 팜의 윈도우 서버들을 구성할 수 있습니다.

이 기능을 활용하면 SSL 바인딩 관리가 매우 간단해집니다. SSL을 사용하려면 DNS 이름과 인증서의 CN 이름이 반드시 일치해야만 하는데 비슷한 규칙을 인증서의 파일 이름까지 확대해서 적용할 수 있습니다. 가령, www.contoso.com은 www.contoso.com.pfx이라는 이름의 인증서를 사용하게 되는 식입니다. 윈도우 서버 8은 이 규칙을 바탕으로 중앙집중식 SSL 인증서 지원 기능을 이용하는 보안 사이트의 갯수와 관계 없이 단 하나의 SSL 바인딩만 사용할 수 있게 되었습니다. SNI 값이나 요청된 웹 사이트의 호스트명으로부터 적절한 인증서가 추론되어 해당 값과 파일 이름이 일치하는 인증서가 얻어지게 됩니다.

단계별 지침

전제조건:

• 중앙집중식 SSL 인증서 기능을 포함한 IIS 8.0이 설치된 윈도우 서버 8이 필요합니다. 중앙집중식 SSL 인증서 기능은 IIS의 선택적 구성 요소이기 때문에, 기본 설치 과정에는 포함되어 있지 않습니다.
  • 이 기능을 설치하려면 서버 관리자에서에서 Security 노드 하위의 Centralized SSL Certificate Support 항목을 선택합니다:
    
• 비밀번호가 NULL인 (또는, 전역 비밀번호를 갖고 있는) 예제 인증서들이 필요합니다.
  • 인증서 이름은 반드시 [CN 이름].pfx의 형태를 갖고 있어야만 합니다 (예. www.contoso.com.pfx).
  • 만약, 사용하고자 하는 인증서가 와일드카드 인증서라면, 와일드카드 문자로 "_" 문자를 사용합니다. (예. _.contoso.com.pfx).
  • 만약, 인증서가 여러 개의 CN 이름을 갖고 있다면, 각각 별도의 파일로 만들어야 합니다. (예. www.contoso1.com.pfx, www.contoso2.com.pfx 등)
• 두 개의 파일 공유: 공유 구성을 위한 파일 공유와 중앙집중식 SSL 인증서를 위한 파일 공유가 필요합니다.
  • IIS 서버의 공유 구성에 사용될 파일 공유가 필요합니다.
  • 중앙집중식 SSL 인증서 기능에 사용될 예제 인증서들을 복사할 파일 공유가 필요합니다.
• 예제 사이트 및 예제 인증서에 적용하기 위한 \windows\system32\drivers\etc\hosts 파일을 구성해야만 합니다. 가령, 인증서의 CN 이름이 centralCert0 라면, 호스트 파일에 다음과 같은 내용이 포함되어 있어야만 합니다:

  127.0.0.1 centralCert0

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

• 현재 이 기능에 대한 알려진 버그는 존재하지 않습니다.

중앙집중식 SSL 인증서 지원 기능 구성하기:

1. IIS(인터넷 정보 서비스) 관리자를 실행합니다.
2. 좌측 연결 패인에서 서버 노드를 선택합니다:
   
3. 관리(Management) 영역에서, Centralized Certificates를 더블 클릭합니다:
   
4. 작업(Actions) 패인에서 Edit Feature Settings을 선택합니다:
   
5. 그리고, 다음과 같은 정보들을 입력합니다:
   • Enable Centralized Certificates: 체크합니다.
   • Physical path: 예: \\ccdemo\centralcert
     • 이 UNC 경로는 인증서들이 저장되어 있는 파일 공유의 경로입니다.
   • User name: 해당 파일 공유에 읽기 권한을 갖고 있는 사용자 계정을 지정합니다.
   • Password/Confirm password.
   • Certificate Private Key Password:
     • 이 항목은 옵션입니다. 인증서에 비밀번호가 존재하지 않으면 이 항목은 비워두십시요.
     • 만약 인증서가 전역 비밀번호를 갖고 있다면 해당 비밀번호를 입력하십시요.
   
6. 이제 중앙집중식 SSL 인증서 지원 기능을 사용할 준비가 완료되었습니다. IIS 관리자가 인증서를 읽고 해당 인증서에 가장 적합한 정보를 가져오게 된다는 점에 주목하십시요. 이 정보는 성능 향상을 위해 캐시됩니다.
7. 중앙집중식 SSL 인증서 지원 기능과 관련된 한 가지 주목할만한 관리 기능은 인증서들을 만료 일자 기준으로 그룹핑할 수 있는 기능입니다:
   
8. 이 관리 기능을 이용하면 다음과 같은 기준들을 적용하여 인증서들을 일목요연하게 살펴볼 수 있습니다:
   • 만료
   • 내일 만료됨
   • 이번 주에 만료됨
   • 다음 주에 만료됨
   • 다음 달에 만료됨
   • 이후
   

보안 웹 사이트 생성하기:

1. IIS(인터넷 정보 서비스) 관리자를 실행합니다.
2. 좌측 연결 패인에서 사이트(Sites) 노드를 선택합니다:
   
3. 웹 사이트 추가(Add Website) 메뉴를 선택합니다:
   
4. 일반적인 사이트를 생성할 때처럼 필요한 정보들을 입력합니다:
   • 사이트 이름: centralCert0
   • 실제 경로: c:\inetpub\wwwroot
   • 종류: https
   • 호스트 이름: centralcert0
     • 윈도우 서버8에서는 SSL에 대한 호스트 이름을 지정할 수 있습니다. (역주: 이전 버전에서는 항목이 비활성화 되었습니다.)
     • 이 구성의 실제 값은 사용되는 예제 인증서에 따라 달라집니다.
   • Require Server Name Indication: 체크 안 함
     • 여러분이 원한다면 Require Server Name Indication 항목을 체크할 수도 있습니다. 중앙집중식 인증서 저장에 SNI를 반드시 사용해야만 하는 것은 아니지만, SNI를 사용하더라도 정상적으로 동작할 것입니다.
     • 개발자 프리뷰 릴리즈에서는, 중앙집중식 인증서 저장 기능을 사용하려면 SNI 기능도 필요했었습니다. 이 제한은 베타 릴리즈에서 제거되었습니다.
   • Use Centralized Certificate Store: 체크
     • 명시적으로 사용할 적절한 특정 인증서를 선택할 필요가 없다는 점에 주의하십시요.
     • 명명 규칙을 기반으로, 적절한 인증서가 자동으로 선택됩니다. 본문에서는, IIS가 중앙집중식 SSL 인증서 파일 공유에서 centralcert0.pfx를 일어오려고 시도할 것입니다.
   
5. 사이트가 정상적으로 생성되었는데 확인합니다:
   
6. 모든 작업이 완료되었습니다. 중앙집중식 SSL 인증서 지원을 이용한 보안 사이트가 생성되었습니다. 관리 과정 자체는 전통적인 공유 구성이나 SSL 바인딩을 관리하는 과정과 매우 비슷합니다. 차이점들로는:
   • 인증서들이 파일 공유에 중앙집중적으로 저장됩니다.
   • SSL 사이트에 호스트명을 지정할 수 있습니다.
   • SSL 바인딩이 명시적인 1 대 1 관계로 관리되지 않습니다.

보안 사이트 테스트:

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

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

SSL 바인딩이 *:443이라는 값을 갖고 있는 hostname:port 형식이라는 점을 주목하시기 바랍니다. 또한, 이 바인딩과 연결된 인증서 해시가 없다는 사실을 확인할 수 있는데 그 이유는 인증서의 명명규약을 기반으로 필요할 때마다 실시간으로 적절한 인증서가 로드되기 때문입니다.

시나리오

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

• 중앙집중식 SSL 인증서 지원 기능은 다중 이용자 환경의 확장성을 위해서 설계된 기능입니다. 이 기능을 이용하여 수 천개의 보안 사이트를 구성해 보십시요.
• 수천 개의 인증서를 설정한 다음, 권한이 상승된 명령줄 창에 다음 명령을 입력해보십시요. 보안 사이트의 갯수와 관계 없이 단 한개의 바인딩만 존재하는 것을 확인하실 수 있을 것입니다:

  netsh http show sslcert

• 서버 팜에 새로운 서버를 추가해보십시요. 공유 구성 및 중앙집중식 SSL 인증서 지원 기능을 이용하는 경우, 이 작업은 다음과 같은 세 단계의 과정을 밟게 됩니다:
  1. 공유 구성을 사용하도록 새로운 서버를 구성합니다.
  2. 중앙집중식 SSL 인증서 지원을 사용하도록 새로운 서버를 구성합니다.
  3. SSL 바인딩을 생성합니다. 권한이 상승된 명령줄 창에서 다음과 같은 명령을 입력하십시요.

     add sslcert hostnameport=*:443 appid={00112233-4455-6677-8899-AABBCCDDEFF}

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

요약

본문에서는 윈도우 서버 8의 중앙집중식 SSL 인증서(Centralized SSL Certificate) 기능을 살펴보았습니다.