바인딩 종류를 "https" 로 지정하면 인증서를 선택할 수 있는데, 여기서 조금전에 생성한 인증서를 선택한다.
아마 이런 에러가 뜰텐데, 원래는 안떠야 하는데, 왜 뜨는지 모르겠음. 인증서 체인에 문제가 있다는건, 최종 인증 서버에 도달하는 정보가 누락되어 있다는 얘긴데... 오류는 나지만, 무시하고 넘어가면, 그래도 사용은 가능함.
이렇게 "https" 로 페이지를 불러보면 https 로 페이지가 불러와 짐. 사설인증서 이므로 경고 페이지가 나오겠지만, 그냥 무시하고 진행. 이 상태에서는 "http" 도 가능하고 "https" 도 가능한 상태. 참고로 ...
"SSL 설정" 에서...
"SSL 필요" 를 체크해 놓으면...
이렇게 "https" 통신만 가능하고 "http" 통신은 차단해 버릴 수가 있음.
=======================
=======================
=======================
출처: http://webindepth.tistory.com/8
안녕하세요. 네오입니다.
오늘은 하나의 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 바인딩 테스트 하기 페이지에서 안내 하는 과정을 따라 하면 쉽게 사이트를 구축 할 수 있습니다.
IIS 에 443 포트로 HTTPS 가 바인딩 된 두 개의 사이트가 있고, 두 사이트는 각각 다른 인증서를 사용 한다고 가정 해 봅시다. 이 상황에서 443 포트로 요청이 들어 온다면 어떻게 될까요? 우선 IIS 는 암호화 된 상태로 443 포트로 들어온 request 를 인증서의 키로 복호화 합니다. 이 복호화를 마치면 host name 을 알 수 있게 되죠. IIS 는 복호화를 하기 위해 사이트에서 인증서를 찾아야 합니다. 어라, 그런데 443 포트에 연결 된 사이트가 두개네요? 그러면 IIS는 두 사이트의 인증서 중 어느 인증서를 사용 하여 복호화를 해야 할 지 알 수 없는 상태가 됩니다. 복호화를 해야 host name 을 알아 내서 어느 사이트로 들어 온 요청인 지 알 수 있는 데, 복호화를 하려면 어느 사이트로 들어 온 요청인 지를 알고 인증서 키를 찾아야 하는 문제... 이것이 두 개 사이트가 동일 포트로 HTTPS 를 바인딩 했을 때 발생 하는 닭과 달걀 문제입니다. 근본적으로 SSL 통신 시에는 host name 을 바인딩 하지 않기 때문에 발생하는 문제이죠.
이 문제는 두 가지 방법으로 해결 할 수 있습니다.
Wild Card Certificate
첫 번째, 도메인이 같은 경우 wild card certificate 를 사용 합니다. 와일드 카드 인증서를 사용하는 방법은 상세히 설명한 문서가 많기 때문에 여기서는 따로 설명 하지 않겠습니다. 원문을 보셔도 좋을 것 같습니다.
그런데, 정말 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 포트에 바인딩 할 수 있습니다.
고백하자면 저도 아직 이 기능을 사용 해 본 적은 없기 때문에(^^;) 아래에 링크를 남기는 것으로 설명을 대신 하겠습니다.
혹시 IIS 8.0 의 SNI 기능에 대해 더 설명이 필요하다면 댓글을 남겨 주세요. 추가 설명을 덧붙이도록 하겠습니다.
마치며...
IIS 8.0 에서 (상대적으로) 편리한 SNI 기능이 도입 되었다고 해도, 운영 환경에서 하나의 물리 서버에서 여러 개의 도메인을 서비스 하는 경우는 앞으로 점점 감소할 것으로 예상 합니다. 웹 서비스 시스템을 구성 할 때에 규모가 큰 서비스일 경우에는 도메인 당 여러 서버로 구성 된 서버 팜을 할당 하는 것이 일반적이고, 규모가 작은 서비스일 경우에는 클라우드 환경을 이용 하는 추세이기 때문입니다.
이상으로 하나의 IIS 에서 여러 사이트가 SSL 을 이용 하는 방법을 살펴 보았습니다. 결론적으로 IIS 7.0 이용자라면 포트 번호를 다르게 설정 하는 것이 가장 효율적인 방법이라고 봅니다. 반면 IIS 8.0 이용자는 SNI 기능을 이용하는 것이 좋을 것 같습니다.
IIS 테스트 환경을 구성하다가 어려움을 겪은 분이나, SSL 를 이용하는 사트를 구성하면서 의문을 가진 분께 이 글이 도움이 되었기를 바랍니다.
본 가이드는 인증서 파일 설정시 참고 예제이며, 고객사 서버에 SSL 설치/적용 성공을 보증하지 않습니다 설정 과정에서 발생하는 다양한 문제에 대한 해결은 보증 대상이 아닙니다 (인증서 자체 오류시 무제한 재발급) 웹서버 자체 설정/작동 관련 사항은 웹서버 매뉴얼 또는 공급사 기술지원을 이용하시기 바랍니다
이 문서는 IIS 7.0 을 바탕으로 생성되었으며 IIS 7.0 / IIS 8.0 을 이용한 SSL 설정 가이드 입니다.
※ 주의하셔야 할 사항 = 하나의 웹 사이트에 단 한개의 인증서만 적용 가능합니다. = 하나의 웹 사이트에 다중으로 인증서 적용은 불가능하게 되어 있습니다. = 주 호스트 도메인 신청 시 기본 www 호스트에 대해서도 SSL 접속이 가능합니다. = (ex. 신청 도메인 - comodossl.co.kr 일 경우 www.comodossl.co.kr 접속 가능) = 포트를 다르게 주었을 경우 (https://도메인주소:포트번호) 확인하셔야 합니다.
*메뉴얼에 기재된 도메인은 예제에 사용된 도메인으로 실제 적용 시에는 고객님이 사용하시는 도메인으로 진행하시기 바랍니다.
[1] IIS 관리자에서 설치하기
1. [관리도구] -> [인터넷 정보 서비스(IIS) 관리] 콘솔을 실행합니다.
2. IIS 관리자에서 [서버 인증서] 메뉴 선택
3. 3. [기능 열기] 선택
4. 서버 인증서 [가져오기] 선택
5. 인증서 파일의 경로 지정 및 암호입력(인증서 압축파일에 포함된 pfx.txt에서 해당 패스워드 확인)
6. 인증서 적용할 웹사이트에서 [바인딩 편집] 선택
7. 사이트 바인딩 설정창에서 [추가] 선택
8. 프로토콜 [종류]에서 https 선택한 후 [SSL 인증서] 부분에서 해당하는 인증서 찾아 적용
9. https 서비스 포트(기본 443) 방화벽에서 오픈
[2] MMC 인증서 관리 콘솔에서 설치하기
1. 시작 -> 실행 -> mmc 입력 후 확인
2. 콘솔창 상단메뉴 -> 파일 -> [스냅인 추가/제거] 선택
3. 사용 가능한 스냅인 목록에서 [인증서] 선택하여 [추가]
4. 관리할 인증서 대상에 [컴퓨터 계정] 선택 후 다음
5. 관리할 컴퓨터 대상에 [로컬 컴퓨터] 선택 후 마침 및 확인
6. 인증서(로컬 컴퓨터) 트리에서 개인용 -> 인증서 -> 모든 작업 -> 가져오기 선택
7. 인증서 가져오기 마법사에서 다음
8. 가져올 인증서 파일 찾아서 지정 (파일종류: 개인 정보 교환(*.pfx) 선택)
9. 개인 키 암호 입력(인증서 압축파일에 포함된 pfx.txt에서 해당 패스워드 확인)
10. 모든 인증서를 다음 저장소에 저장
11. 가져오기 완료
12. 관리도구 -> IIS(인터넷 정보 서비스) 관리자 실행
13. 인증서 적용할 웹사이트에서 [바인딩 편집] 선택
14. 사이트 바인딩 설정창에서 [추가] 선택
15. 프로토콜 [종류]에서 https 선택한 후 [SSL 인증서] 부분에서 해당하는 인증서 찾아 적용
[1] IIS6 Secure Binding 적용 방법 [2] IIS6 Secure Binding 삭제 방법 [3] IIS7/8 Secure Binding 적용 방법 [4] IIS7/8 SecureBindings 삭제 방법
※ 주의하셔야 할 사항 = 하나의 사이트에 여러개의 도메인으로 포워딩 되어 있어도 인증서는 사이트 하나에 한개만 적용 가능합니다. = 한사이트에 다중으로 인증서 적용은 불가능하게 되어 있습니다. = SecureBindings 역시 한사이트에 한개의 도메인만 가능합니다. 이유:식별자값이 하나만존재 = IIS 5.0 버전 및 싱글 도메인 인증서 는 SecureBindings 기능을 지원하지 않아 사이트의 포트를 각각 다르게 주셔야 합니다. = 포트를 다르게 주었을 경우 (https://도메인주소:포트번호) 확인하셔야 합니다.
*메뉴얼에 기재된 도메인은 예제에 사용된 도메인으로 실제 적용 시에는 고객님이 사용하시는 도메인으로 진행하시기 바랍니다.
[1] IIS6 Secure Binding 적용 방법 (IIS 5.0 지원안함)
1. 시작 -> 실행 -> cmd 입력 후 확인 입력 후 확인
2. IIS 관리자에서 [식별자], [호스트헤더 값] 확인 최초 인증서 설치한 사이트에 443 포트가 적용된것을 확인 합니다.
3. 커맨드창에서 다음 명령행 입력 cscript.exe C:\Inetpub\AdminScripts\adsutil.vbs set /w3svc/식별자/SecureBindings ":443:호스트 헤더 값" 최초 인증서 설치한것을 제외하고 모든 도메인에 대해서 명령어를 입력해 줍니다.
4. 'SecureBindings 적용 후' 443 포트 확인합니다.
[2] IIS6 SecureBindings 삭제 방법
1. 커맨드창에서 다음 명령행 입력 cscript.exe C:\Inetpub\AdminScripts\adsutil.vbs delete /w3svc/식별자/SecureBindings
2. SecureBindings 삭제 후 SSL 포트
[3] IIS7/8 SecureBindings 적용 방법
1. 새로운 커맨드라인(Command-line) 관리도구 Appcmd.exe 를 이용 (위치: C:\Windows\System32\inetsrv)
2. appcmd set site /site.name:"사이트 이름" /+bindings.[protocol='https',bindingInformation='*:443:호스트 헤더 값'] 예) appcmd set site /site.name:"한비로" /+bindings.[protocol='https',bindingInformation='*:443:www.hanbiro.com'] appcmd set site /site.name:"한비로웹호스팅" /+bindings.[protocol='https',bindingInformation='*:443:mypage.hanbiro.com']
[4] IIS7/8 SecureBindings 삭제 방법
1. 새로운 커맨드라인(Command-line) 관리도구 Appcmd.exe 를 이용 (위치: C:\Windows\System32\inetsrv)
2. appcmd set site "사이트이름" --bindings.[protocol='https',bindingInformation='*:443:호스트 헤더 값'] 예) appcmd set site "한비로" --bindings.[protocol='https',bindingInformation='*:443:www.hanbiro.com'] appcmd set site "한비로웹호스팅" --bindings.[protocol='https',bindingInformation='*:443:mypage.hanbiro.com']
=======================
=======================
=======================
출처: https://www.xpressengine.com/tip/23142747
1. 개요
IIS에서 HTTPS 사용을 위한 SSL설정 - 인증서 설치 및 백업
보안등급 향상 방법 설명
2. 순서
3~5 SSL 설정 - 개인키 생성 및 CSR구문 생성, 인증기관에서 인증서 발급, 인증서 설치
6 개인키 백업 및 복원
7 보안등급 향상 방법
8 참조
3. 개인키 생성 및 CSR 생성
3.1 시작 > 모든 앱 > Windows 관리 도구 > IIS (인터넷 정보 서비스) 관리자 > 서버 인증서
3.2 서버 인증서 > 인증서 요청 만들기
--- 일반 이름은 도메인 네임으로, 비트 길이는 2048로 해주시면 됩니다.
3.3 인증서 요청 파일 이름 지정 후 마침
3.4 생성된 인증서 요청파일을 메모장등으로 열어보면 아래와 같은 형식(CSR구문)으로 저장되어 있습니다.
-----BEGIN NEW CERTIFICATE REQUEST-----
ABCD~~~~~~~==
-----END NEW CERTIFICATE REQUEST-----
3.5 만들어진 개인키는 MMC(Microsoft Management Console)에서 확인할 수 있으며, 확인, 백업 및 복원 방법은 후술 하겠습니다.
4. 인증기관(CA)에서 인증서 발급
--- 이하 Startssl의 인증서 발급과정을 예로 들어 설명하겠습니다.
4.1 startssl.com에서 메일 인증 / 도메인 인증을 거친 후 서버용 인증서 신청
4.2 적용하고자 하는 도메인 (서브 도메인 포함) 입력
- 와일드 카드 사용 이나 100개 이상 서브도메인을 쓰려면 유료 서비스를 이용하라고 하네요.
4.3 CSR 제출
- 3.4에서 확인한 인증서 요청파일의 내용을 붙여넣기 하시면 됩니다.
4.4 Submit 후 도메인네임.zip 파일로 된 인증서를 다운받을 수 있습니다.
- IIS용은 2_도메인네임.crt(인증서 파일)과 1_Intermediate.crt(CA 인증서)로 구성 되어 있습니다.
4.5 인증서 파일을 분실한 경우 startssl.com에 로그인 하여 아래와 같이 인증서 파일을 재발급 받을 수 있습니다.
- 개인키는 재발급 되지 않으니 꼭 백업하시기 바랍니다. (6. 개인키 백업/복원 참조)
5. 인증서 설치
5.1 IIS (인터넷 정보 서비스) 관리자 > 서버 인증서
5.2 인증서 요청 완료
- 인증기관의 응답이 포함된 파일 이름에는 4.4에서 발급받은 2_도메인네임.crt(인증서파일)
- 이름에는 확인하기 편리한 아무 이름이나 기입하고 확인 클릭
- 만약 서버 이전 등으로 인해 서버에 개인키가 저장되어 있지 않은 경우 인증서만 설치하면 서버인증서 리스트에 표시 되지 않습니다. 꼭 개인키를 백업 하시기 바랍니다.
(6. 개인키 백업/복원 참조)
5.3 사이트에 적용
- 적용할 사이트 선택 > 바인딩.
- https / SSL 인증서 선택
- SSL 항상 사용하는 경우 ; SSL 필요 체크하여 인증서 없는 접근을 차단
6. 개인키 백업 및 복원
--- 발급 받은 인증서와 CA인증서는 startssl.com에 로그인 후 재발급 받을 수 있으나 개인키는 재발급이 되지 않기에 꼭 백업을 해야 합니다. (인증서파일은 재발급 받을 수 있다지만, 역시 개인키과 같이 백업해 두는 것이 좋겠지요.)
웹서비스에 https 를 적용할 경우 SSL 인증서를 VeriSign 이나 Thawte, GeoTrust 등에서 인증서를 발급받아야 하지만 비용이 발생하므로 실제 운영 서버가 아니면 발급 받는데 부담이 될 수 있다.
이럴때 OpenSSL 을 이용하여 인증기관을 만들고 Self signed certificate 를 생성하고 SSL 인증서를 발급하는 법을 정리해 본다.
발급된 SSL 인증서는 apache httpd 등의 Web Server 에 설치하여 손쉽게 https 서비스를 제공할 수 있다.
Self Signed Certificate(SSC)란 ?
인증서(digital certificate)는 개인키 소유자의 공개키(public key)에 인증기관의 개인키로 전자서명한 데이타다. 모든 인증서는 발급기관(CA) 이 있어야 하나 최상위에 있는 인증기관(root ca)은 서명해줄 상위 인증기관이 없으므로 root ca의 개인키로 스스로의 인증서에 서명하여 최상위 인증기관 인증서를 만든다. 이렇게 스스로 서명한 ROOT CA 인증서를 Self Signed Certificate 라고 부른다.
IE, FireFox, Chrome 등의 Web Browser 제작사는 VeriSign 이나 comodo 같은 유명 ROOT CA 들의 인증서를 신뢰하는 CA로 미리 등록해 놓으므로 저런 기관에서 발급된 SSL 인증서를 사용해야 browser 에서는 해당 SSL 인증서를 신뢰할수 있는데
OpenSSL 로 만든 ROOT CA와 SSL 인증서는 Browser가 모르는 기관이 발급한 인증서이므로 보안 경고를 발생시킬 것이나 테스트 사용에는 지장이 없다.
공개키 기반(PKI)은 private key(개인키)와 public key(공개키)로 이루어져 있다. 인증서라고 하는 것은 내 공개키가 맞다고 인증기관(CA)이 전자서명하여 주는 것이며 나와 보안 통신을 하려는 당사자는 내 인증서를 구해서 그 안에 있는 공개키를 이용하여 보안 통신을 할 수 있다.
CSR 은 인증기관에 인증서 발급 요청을 하는 특별한 ASN.1 형식의 파일이며(PKCS#10 - RFC2986) 그 안에는 내 공개키 정보와 사용하는 알고리즘 정보등이 들어 있다. 개인키는 외부에 유출되면 안 되므로 저런 특별한 형식의 파일을 만들어서 인증기관에 전달하여 인증서를 발급 받는다.
SSL 인증서 발급시 CSR 생성은 Web Server 에서 이루어지는데 Web Server 마다 방식이 상이하여 사용자들이 CSR 생성등을 어려워하니 인증서 발급 대행 기관에서 개인키까지 생성해서 보내주고는 한다.
ROOT CA 인증서 생성
openssl 로 root ca 의 개인키와 인증서를 만들어 보자
CA 가 사용할 RSA key pair(public, private key) 생성
개인키 분실에 대비해 AES 256bit 로 암호화한다. AES 이므로 암호(pass phrase)를 분실하면 개인키를 얻을수 없으니 꼭 기억해야 한다.
개인키의 유출 방지를 위해 group 과 other의 permission 을 모두 제거한다.
chmod 600 /etc/pki/tls/private/lesstif.com.key*
개인키를 보호하기 위해 Key-Derived Function 으로 개인키 자체가 암호화되어 있다. 인터넷 뱅킹등에 사용되는 개인용 인증서는 당연히 저렇게 보호되어야 하지만 SSL 에 사용하려는 키가 암호가 걸려있으면 httpd 구동때마다 pass phrase 를 입력해야 하므로 암호를 제거한다.
CSR(Certificate Signing Request) 생성을 위한 host_openssl.conf 로 저장
