HTTP에서 HTTPS로 전환하기 위한 완벽 가이드

HTTPS 설정은 경험이 부족한 사용자에게는 어려울 수 있다. 여러 단계를 거쳐야 하고 암호화와 서버 구성에 관한 지식이 필요하기 때문에 복잡한 작업으로 여겨진다.

여기서는 HTTPS 설정에 필요한 구성 요소와 단계에 대해 설명한다. 호스팅 공급 업체가 HTTPS 인증서를 제공하는 경우는 설정이 더 쉽다(제어판에서 모든 작업을 쉽고 빠르게 수행할 수 있다). 리눅스와 유닉스 아파치 HTTP 서버와 엔진엑스^Nginx뿐만 아니라 윈도우 IIS^{Internet Information Server}의 관리자나 cPanel 사용자를 위한 지침도 소개한다. 기본적인 내용부터 시작해보자.

 

HTTP, HTTPS, HTTP/2, SSL, TLS – 도대체 뭐가 뭔지?

클라이언트와 서버 간 통신 과정을 설명하는 데 사용되는 약어가 많다. 이러한 약어의 개념을 모르는 사람은 혼동해서 사용하기 쉽다.

HTTP^{Hypertext Transfer Protocol}는 클라이언트와 서버 양쪽에서 통신할 수 있도록 구현해야 하는 기본 통신 프로토콜로, 요청과 응답, 세션, 캐싱, 인증 등을 다룬다. 프로토콜과 HTML 관련 작업은 CERN에서 팀 버너스 리^{Tim Berners-Lee}와 그 팀이 1989년에 시작했다. 첫 번째 공식 프로토콜 버전(HTTP 1.0)은 1996년에 발표됐고, 곧이어 1997년에 현재 널리 사용되는 버전(HTTP 1.1)이 나왔다.

HTTP는 브라우저와 서버 사이에서 정보를 평문으로 전송하므로 정보가 전달되는 네트워크에서 전송되는 정보를 엿볼 수 있다. 이런 보안 문제로 인해 클라이언트와 서버가 먼저 암호화 통신 채널을 설정한 다음 평문 HTTP 메시지를 전송함으로써 정보 유출을 막는 HTTPS^{HTTP Secure}가 소개되었다.

암호화 채널은 이전에 SSL^{Secure Socket Layer}이라고 불렸던 TLS^{Transport Layer Security} 프로토콜을 사용해서 만든다. 흔히 SSL과 TLS를 혼용했으나 SSL 3.0은 TLS 1.0으로 대체되었다. SSL은 넷스케이프가 개발한 프로토콜인 반면 TLS는 IETF 표준이다. 현재 SSL(1.0, 2.0, 3.0)의 모든 버전은 여러 가지 보안 문제로 사용되지 않고 대부분의 브라우저에서 경고를 표시한다. 현재 TLS 버전(1.0, 1.1, 1.2)을 사용하고 있으며 1.3 버전은 초안이다.

1996년과 1997년에 현재의 안정적인 인터넷 버전(HTTP 1.1, SSL과 TLS는 선택)이 등장했으며 현재 대부분의 웹사이트가 이 버전에서 운영되고 있다. HTTP는 민감하지 않은 트래픽(예: 뉴스 기사)에 이용되고 HTTPS는 민감한 트래픽(예: 인증, 전자상거래)에 이용된다. 하지만 프라이버시에 관심이 높아지면서 구글 크롬과 같은 웹 브라우저는 이제 HTTP 웹사이트를 ‘안전하지 않음’으로 표시하고 HTTP의 앞날에 경고를 보내고 있다.

HTTP 프로토콜의 다음 업그레이드 버전인 HTTP/2는 점점 많은 웹사이트에 적용되고 있으며 지연을 줄이고 성능과 보안 향상을 위해 새 기능(압축, 멀티플렉싱, 우선순위 지정)을 추가했다.

HTTP 버전 1.1에서는 보안 연결이 선택이지만(HTTP와 HTTPS는 서로 독립적) HTTP/2에서는 사실상 필수다. 표준으로는 HTTP/2에서 TLS를 선택적으로 정의했지만 대부분의 브라우저 공급 업체는 HTTP/2와 TLS만 지원한다고 명시했다.

HTTPS에서 제공하는 것

HTTPS로 전환을 고민하는 이유부터 살펴보자. HTTPS는 다음 세 가지 주요 이유 때문에 사용한다.

• 기밀성 HTTPS는 인터넷과 같은 공공 매체에서 두 참여자 간의 통신을 보호한다. 예를 들어, HTTPS가 없다면 와이파이^Wi-Fi 액세스 포인트^{Access Point}를 운영하는 사람은 액세스 포인트를 사용하는 사람이 온라인에서 무언가를 구입할 때 신용카드와 같은 개인정보를 볼 수도 있다.

• 무결성 HTTPS는 변조되지 않은 정보로 목적지에 도달하게 한다. 예를 들어, 와이파이가 웹사이트에 광고를 추가하거나, 대역폭을 절약하고자 이미지 품질을 저하시키거나, 읽는 기사의 내용을 변조할 수 있지만 HTTPS는 웹사이트를 변조할 수 없도록 한다.

• 인증 HTTPS를 통해 웹사이트의 진위 여부를 확인할 수 있다. 예를 들어, 와이파이 액세스 포인트을 운영하는 사람이 가짜 웹사이트를 브라우저에 보낼 수도 있다. HTTPS는 example.com이라는 웹사이트가 실제로 example.com인지 확인한다. 일부 인증서는 yourbank.com이 YourBank.Inc라는 걸 알리기 위해 해당 웹사이트의 법적 신원을 검사하기도 한다.

암호 기술의 핵심

기밀성, 무결성, 인증이 HTTPS에만 한정된 것은 아니다. 이러한 특징은 암호 기술의 핵심 개념이다. 이제부터는 각 특징에 대해서 들여다보자.

기밀성

기밀성^{Confidentiality}은 프라이버시다. 즉, 기밀성은 인증되지 않은 제3자가 정보를 읽지 못하도록 보호한다. 그 과정은 보통 평문^plaintext이라고 하는 읽을 수 있는(들을 수 있거나 볼 수 있는) 정보 형식을 암호문^ciphertext이라고 하는 뒤죽박죽 된 읽을 수 없는 정보 형식으로 변환하는 작업을 거친다. 이 과정을 암호화^encryption라고 한다. 반대의 과정(암호문을 다시 읽을 수 있는 평문으로 전환)을 복호화^decryption라고 한다. 정보를 암호화하고 복호화하는 방법(암호 함수^{cipher functions} 또는 알고리즘)은 많다.

두 명의 당사자가 통신하려면 다음 두 가지에 동의해야 한다.

1. 통신에 사용할 알고리즘(암호 함수)
2. 선택한 방법으로 사용할 매개변수 또는 암호, 규칙(예: 시크릿^secret)

암호화에는 두 가지 주요 방법이 있다.

• 대칭 양쪽 당사자가 공통 비밀 키를 공유한다.
• 비대칭 당사자 중 한쪽이 비밀 키와 공개 키의 쌍, 공개 키 인프라(PKI) 기반을 갖는다.

대칭형 방식은 양쪽 당사자가 공유한 시크릿에 의존하는데, 전송자는 정보를 암호화하는 데 사용하고 수신자는 동일한 방식과 키를 사용해 복호화한다(‘대칭 키 암호화’ 그림 참조). 이 방법의 문제는 양쪽 당사자가 서로 물리적인 만남 없이 시크릿을 협상(교환)하는 방법이라서 일종의 보안 통신 채널이 필요하다.

공개 키와 개인 키의 개념을 기반으로 하는 비대칭 방식은 대칭 방식의 문제를 해결한다. 두 가지 키 중 하나로 평문을 암호화하면 다른 보완 키를 사용해야만 복호화할 수 있다. 이를테면 서로 안전하게 통신하고 싶은 두 당사자 앨리스와 밥이 있다고 가정하자(앨리스와 밥은 모든 튜토리얼과 보안 매뉴얼에 항상 등장하는 허구의 인물이므로 여기서는 그러한 전통을 따랐다). 앨리스와 밥은 공개 키와 개인 키의 쌍을 가졌다. 개인 키는 각 소유자만 알고 있으며 공개 키는 누구든 사용할 수 있다.

앨리스가 밥에게 메시지를 보내고 싶다면, 앨리스는 밥의 공개 키를 얻어 평문을 암호화하고 암호문을 밥에게 보낸다. 밥은 자신의 개인 키를 사용해 암호문을 복호화한다.

밥이 앨리스에게 회신하고 싶다면, 앨리스의 공개 키를 얻어서 평문을 암호화해 암호문을 보낸다. 엘리스는 자신의 개인 키를 사용해 그 암호문을 복호화한다.

언제 대칭 암호화를 사용하고, 언제 비대칭 암호화를 사용할까? 비대칭 암호화는 클라이언트와 서버 간 시크릿을 교환할 때 사용한다. 실생활에서는 양방향 비대칭 통신이 필요하지 않다. 당사자 중 한쪽이(서버라고 하자) 일련의 키를 가지고 있으므로 암호화된 메시지를 받을 수 있다는 것만으로 충분하다. 이는 공개 키로 암호화한 정보는 개인키를 사용해야만 복호화되기 때문에 클라이언트에서 서버로 향하는 단방향으로만 정보를 보호한다. 그러므로 서버에서만 그 정보를 복호화할 수 있다. 반대 방향은 보호되지 않는다. 서버의 개인 키로 암호화된 정보는 공개 키를 가진 누구든지 복호화할 수 있다. 상대편(클라이언트라고 하자)은 서버의 공개 키를 사용해 무작위로 생성된 세션 시크릿을 암호화해 통신을 시작한다. 그 다음 암호문을 다시 서버로 보내고, 서버는 다시 자신의 개인 키로 복호화하면 그 시크릿을 갖게 된다.

대칭 암호화는 비대칭 암호화보다 훨씬 빠르기 때문에 전송 중인 실제 데이터를 보호하는 데 사용된다. 앞서 교환한 시크릿으로 정보를 가진 두 당사자(클라이언트와 서버)만 해당 정보를 암호화하고 복호화할 수 있다.

이 때문에 핸드셰이크^handshake의 첫 비대칭 부분이 키 교환이라고 불리며, 실제 암호화된 통신은 사이퍼 메서드^{cipher methods}라는 알고리즘을 사용한다.

무결성

HTTPS로 해결하는 또 다른 문제는 데이터 무결성^integrity이다. 즉, (1)전체 정보가 잘 도착했으며, (2)전송 중에 누가 변조하지 않았음을 보장한다. 정보가 잘 전송되었음을 보장하기 위해 메시지 다이제스트^{message digest} 알고리즘을 사용한다. 교환된 각 메시지의 메시지 인증 코드^{message authentication codes, MAC} 계산은 암호화 해싱 프로세스다. 예를 들어 MAC(태그라고도 한다) 획득은 실질적으로 다음의 작업이 불가능(보통 사용하는 용어는 ‘실행 불가능^infeasible’)하게 하는 방식이다.

• 태그에 영향을 끼치지 않고 메시지 변경하기
• 두 개의 다른 메시지에 동일한 태그 생성하기
• 프로세스를 거꾸로 돌려 태그에서 원래 메시지 획득하기

인증

인증^{authentication}은 어떨까? 공개 키 인프라의 실제 애플리케이션이 갖는 문제는 양쪽 당사자가 (물리적으로 떨어져 있는) 상대편이 실제로 누구인지 알 방법이 없다는 것이다. 그래서 상대편의 신원을 보증하기 위해 상호 신뢰할 수 있는 제3자, 즉 인증 기관^{certificate authority, CA}이 필수다. 인증 기관은 example.com이라는 도메인 이름(고유한 식별자)이 공개 키 XXX와 연결되어 있음을 기술한 인증서를 발행한다. 경우에 따라서는(조금 뒤 설명하는 EV와 OV 인증서) 인증 기관은 그 도메인을 특정 회사가 통제하는지도 확인한다. 이 정보는 인증 기관 X(인증서 발행)에서 보증하고, 이 보증은 날짜 Y(시작일)와 날짜 Z(만료일)사이에서 유효하다. 이 모든 정보는 HTTPS 인증서라는 문서 하나에 들어간다. 이해를 돕기 위해 나라에서 국민에게 발행하는 ID나 여권을 예로 들면, 해당 정부를 신뢰하는 모든 신뢰 당사자는 ID를 가진 사람의 신원 또한 수용한다(가짜 ID인 경우는 이 예의 범위 밖이다).

인증 기관은 인증서를 서명하기 위해 신뢰된 조직이다. 윈도우와 맥OS, iOS, 안드로이드 등의 운영체제뿐만 아니라 파이어폭스 브라우저는 신뢰된 인증서 목록을 갖고 있다. 사용하는 브라우저에서 신뢰하는 인증 기관을 확인할 수 있다.

• 파이어폭스 설정 → 개인 정보 및 보안 → 인증서 → 인증서 보기 → 인증 기관
• 윈도우 제어판 → 인터넷 옵션 → 내용 → 인증서 → 신뢰할 수 있는 인증 기관/중간 인증 기관
• 맥 응용 프로그램 → 유틸리티 → 키체인 접근 → 카테고리 내 인증서

목록에 없는 다른 인증 기관도 추가할 수 있는데, 이는 자체 서명된 인증서와 같은 사설 인증서를 사용할 때 유용하다(뒤에서 다룬다).

대개 일반적인 상황에서 서버 쪽에서만 클라이언트에 신원을 증명한다. 예를 들어, 전자상거래 웹사이트와 고객의 관계에서 해당 웹사이트만 인증서가 필요하다. 전자 정부와 같은 경우는 서비스를 요청하는 서버와 클라이언트 모두 자신의 신원을 증명해야 한다. 이는 양쪽 당사자 모두 다른 당사자를 인증하는 데 인증서를 사용해야 한다는 뜻이다(이 설정 또한 이 글의 범위 밖이다).

HTTPS 인증서 유형

HTTPS 인증서에는 여러 유형이 있으며 다음과 같이 나눌 수 있다.

1. 신원 검증

1. DV^{Domain validated} 가장 일반적인 유형의 인증서인 DV 인증서는 도메인이 특정 공개 키와 일치하는지 확인한다. 브라우저는 서버와 보안 연결을 수립하고 닫힌 자물쇠를 표시한다. 이 표시를 클릭하면 ‘현재 웹사이트는 소유자 정보를 제공하지 않고 있습니다’를 보여준다. 도메인 외의 다른 특별한 요구 사항은 없다. DV 인증서는 해당 도메인에 대한 알맞은 공개 키인지를 간단히 확인하며, 브라우저에서는 법적 신원을 보여주지는 않는다. DV 인증서는 무료이거나 저렴(10달러/년)하다(아래 Let’s Encrypt와 Cloudflare 부분 참고).

2. EV^{Extended validation} EV 인증서는 웹사이트의 법적 신분을 검증한다. EV 인증서는 가장 신뢰할 수 있는 유형의 인증서다. 인증 기관에서 도메인을 관리하는 이의  법적 신원을 확인한 후 얻을 수 있다. 법적 신원은 다음의 조합으로 확인한다.

• 도메인 관리(예: DV 인증서)
• 회사가 등록되었고 현재 유지 상태인지 확인할 수 있는 공인된 사업 기록
• D&B(Dunn and Bradstreet), 세일즈포스 connect.data.com, 전화번호부 등에 등재된 자영업 정보
• 확인 전화
• 인증서의 모든 도메인 이름 검사(와일드카드는 EV 인증서에서 명시적으로 금지). 닫힌 자물쇠 표시뿐만 아니라 EV HTTPS 인증서는 URL 앞에 검증된 법적 신원의 이름(등록된 회사)을 표시한다. iOS 사파리와 같은 일부 기기는 검증된 법적 신원만 표시하고 전체 URL은 무시한다. 해당 표시를 클릭하면 이름과 주소 같은 조직에 대한 자세한 정보를 보여준다. 비용은 연간 150달러에서 300달러 정도다.

3. OV^{Organization validated} EV처럼 OV 인증서는 웹사이트의 법적 신분을 검증한다. 하지만 EV 인증서와 달리 OV HTTPS 인증서는 UI에서 확인된 법적 이름을 표시하지는 않는다. 결과적으로 OV 인증서는 높은 검증 요구 사항 대비 사용자에게 보여주는 이점이 없기 때문에 인기가 덜하다. 가격은 연 40달러에서 100달러 정도다.

2. 다루는 도메인 수

이전 HTTPS 인증서는 일반적으로 CN 필드에서 하나의 도메인을 다뤘다. 나중에 ‘주체 대체 이름^{Subject Alternative Name, SAN}’ 필드가 추가되어 하나의 인증서에서 추가적인 도메인을 다루도록 허용했다. 요즘 만드는 모든 HTTPS 인증서는 동일하다. 단일 도메인 인증서에도 해당 단일 도메인에 대한 SAN(그리고 그 도메인의 www 버전에 대한 두 번째 SAN)이 있다. 하지만 많은 인증서 공급 업체는 여전히 과거의 관행을 이유로 단일 도메인과 다중 도메인 HTTPS 인증서를 팔고 있다.

1. 단일 도메인 가장 흔한 인증서 유형으로 example.com과 www.example.com와 같은 도메인 이름에 유효하다.

2. 다중 도메인(UCC/SAN) UCC^{Unified Communications Certificate} 또는 SAN 인증서로 알려진 인증서 유형으로 도메인의 목록을 다룰 수 있다(지정된 제한까지). 단일 도메인에 대한 제한은 없으며 다른 도메인과 하위 도메인을 혼합할 수 있다. 가격은 보통 정해진 도메인의 수(3~5개)에 추가 비용을 지불하면 더 많이(최대 한도까지) 포함할 수 있는 옵션을 제공한다. 웹사이트의 인증서를 검사하는 클라이언트는 주 도메인뿐만 아니라 모든 추가 도메인을 확인하기 때문에 웹사이트와 관련된 도메인 사용을 권장한다.

3. 와일드카드 이 유형의 인증서는 주 도메인뿐만 아니라 하위 도메인(*.example.com)의 수를 제한 없이 다룬다(예: example.com, www.example.com, mail.example.com, ftp.example.com 등). 제한 사항은 주 도메인의 하위 도메인만 다룬다는 점이다.

다음 표에서 사용 가능한 다양한 HTTPS 인증서를 정리했다.

인증서 유형	DV (Domain validated)	OV (Organization validated)	EV (Extended validation)
	HTTPS	HTTPS에서 법적 소유자 검증	HTTPS 검증 법적 소유자 정보가 브라우저에 표시
단일 도메인	example.com, www.example.com
다중 도메인	mail.example.com, example.net, example.org 등. 사전 정의된 목록, 지정된 최대 제한까지 (보통100)
와일드카드	*.example.com는 example.com의 모든 하위 도메인을 뜻한다.		N/A. 모든 이름은 인증서에 명시적으로 포함해야 하고 CA에서 검사해야 한다.

구성

요약하면 HTTPS의 네 가지 구성 요소는 다음의 암호화를 필요로 한다.

1. 초기 키 교환 비대칭(개인 키와 공개 키) 알고리즘을 사용한다.

2. 신원 인증서(인증 기관에서 발행한 HTTPS 인증서) 이 인증서는 비대칭(개인 키와 공개 키) 알고리즘을 사용한다.

3. 실제 메시지 암호화 대칭(미리 공유한 시크릿) 알고리즘을 사용한다.

4. 메시지 다이제스트 암호 해싱 알고리즘을 사용한다.

이들 각 구성 요소는 서로 다른 키 크기를 사용하는 일련의 알고리즘(이들 알고리즘 중 일부는 사용하지 않음)이 있다. 일부 핸드셰이크의 경우 클라이언트와 서버가 사용할 방식의 조합(수십 개의 공개 키(키 교환) 알고리즘 중 하나, 수십 개의 대칭 키(암호) 알고리즘 가운데 하나와 3개의 메시지 다이제스트(해싱) 알고리즘(2개는 사용 안 함) 가운데 하나를 선택해 수백 가지 조합)에 대한 동의를 요구한다.

예를 들어 ECDHE-RSA-AES256-GCM-SHA384 설정은 해당 키를 ECDHE^{Elliptic Curve Diffie-Hellman Ephemeral} 키 교환 알고리즘을 사용해 교환한다는 뜻이다. 인증 기관은 RSA^{Rivest-Shamir-Adleman} 알고리즘을 사용해 인증서를 서명한다. 대칭 메시지 암호화는 256비트 키와 GCM 운영 모드를 갖는 AES^{Advanced Encryption Standard} 암호를 사용한다. 메시지 무결성은 384비트 다이제스트를 사용하는 SHA 보안 해싱 알고리즘을 사용해 검증한다(포괄적인 알고리즘 조합 목록을 사용할 수 있다.) 따라서 몇 가지 구성을 선택할 수 있다.

암호화 스위트

사용할 암호화 스위트^{cipher suite}를 결정하는 일은 호환성과 보안 사이의 균형이다.

• 이전 브라우저와 호환성은 이전 암호화 스위트를 지원하는 서버가 필요하다.
• 하지만 대다수의 이전 암호화 스위트는 더 이상 안전하지 않다.

OpenSSL은 암호 강도가 가장 안전한 것에서 가장 약한 것 순서로 위에서 아래로 지원 조합을 나열한다. 클라이언트와 서버 간의 초기 핸드셰이크 동안 양쪽 당사자가 지원하는 조합과 일치하는 것을 발견할 때까지 협상하기 때문에 이런 방식으로 설계했다. 가장 보안이 좋은 조합을 먼저 시도하고 다른 방법이 없다면 점차 더 약한 조합을 쓴다.

서버에서 사용할 암호화 방법을 조언할 때 매우 유용하고 권장하는 자료는 뒤에서 실제 서버 구성에 다룰 모질라 SSL 구성 생성기다.

키 유형

ECC^{Elliptic Curve Cryptography} 인증서는 RSA 인증서보다 더 빠르고 CPU를 덜 쓰는데, 특히 모바일 클라이언트에는 이런 점이 중요하다. 하지만 아마존의 클라우드프론트^CloudFront나 헤로쿠^Heroku와 같은 일부 서비스는 이 글을 쓰는 시점에 아직 ECC 인증서를 지원하지 않는다. 256 비트 ECC 키면 충분하다.

RSA^{Rivest Shamir Adleman} 인증서는 더 느리지만 오래된 다양한 서버와 호환된다. RSA 키는 더 크므로 2048비트 RSA 키가 최소한이다. 4096비트 이상의 RSA 키는 성능에 좋지 않다. 이 인증서는 2048비트 중간 인증 기관에서 서명할 수도 있어 추가적인 보안에 상당한 손상을 준다.

앞서 기술한 내용이 가변적이라는 점과 키 크기의 제약 사항을 주목했을 것이다. 한 서버에서 과부하를 주는 요인이 다른 서버에서는 그렇지 않을 수 있기 때문이다. 성능에 미치는 영향을 확인하는 최선의 방법은 실제 웹사이트와 실제 방문자로 서버의 부하를 모니터링하는 것이다. 시간의 흐름에 따라 성능이 바뀔 것이다.

절차

HTTPS 인증서를 얻으려면 다음 단계를 거쳐야 한다.

1. 개인 키와 공개 키 쌍을 만들고 조직과 공개 키에 관한 정보를 포함하는 CSR^{Certificate Signing Request}을 준비한다.

2. 인증 기관에 연결해 CSR 기반 HTTPS 인증서를 요청한다.

3. 서명된 HTTPS 인증서를 획득하고 웹 서버에 인증서를 설치한다.

개인 키와 공개 키, CSR과 서명된 HTTPS 인증서 등 공개 키 인프라(PKI)의 다른 구성 요소를 포함하는 일련의 파일이 존재한다. 복잡성을 더 높이는 방편으로 동일성 여부를 확인하는 데 다른 당사자는 다른 이름(그리고 파일 확장자)을 사용한다.

정보를 저장하기 위한 두 가지 인기 있는 형식에는 DER과 PEM이 있다. DER은 바이너리이며, PEM은 base64 인코딩된(텍스트) DER 파일이다. 기본적으로 윈도우는 DER 형식을 직접 사용하며, 오픈소스 진영(리눅스, 유닉스)은 PEM 형식을 사용한다. 두 가지 형식 서로 간에는 변환할 수 있는 도구(OpenSSL)가 있다.

설명 과정에서 예제로 사용할 파일은 다음과 같다.

• example.com.key 이 PEM 형식 파일은 개인 키를 포함한다. 확장자 .key는 표준이 아니므로 일부에서는 사용한다. 시스템 슈퍼 유저만이 보호하고 접근할 수 있다.

• example.com.pub 이 PEM 형식 파일은 공개 키를 포함한다. 이 파일은 개인 키에서 생성될 수 있기 때문에 실제로는 필요하지 않다. 여기서는 설명 목적으로 포함시켰다.

• example.com.csr 이 파일은 인증서 서명 요청이다. 조직 정보와 서버의 공개 키를 포함하는 PEM 형식 파일을 HTTPS 인증서를 발행하는 인증 기관에 보내야 한다.

• example.com.crt 이 HTTPS 인증서는 인증 기관이 서명한 것이다. 이 파일은 PEM 형식 파일이며 서버의 공개 키와 조직 정보, 인증 기관 서명, 유효기간, 만료 날짜 등이 들어 있다. 확장자 .crt는 표준이 아니다. 다른 일반적인 확장자는 .cert와 .cer을 포함한다.

파일 이름(그리고 확장자)는 표준이 아니다(원하는 어떤 것도 가능하다). 어떤 구성 요소가 무슨 기능을 하는지 분명하게 보여야 한다고 생각하기 때문에 이 명명 규칙을 선택했다. 명령과 서버 구성 파일에서 적합한 키 인증서를 참조한다면 프로세스 전체에서 어떤 명명 규칙이든 사용할 수 있다.

개인 키는 특정 길이(여기서는 2048비트 사용)의 문자열을 무작위로 생성한 것으로 다음과 같다.

‘개인 키를 비공개로 유지하자.’ 이 말은 매우 제한된 권한(600)으로 보호하고 누구에게도 드러내지 말라는 의미다.

여기에 대응하는 공개 키는 다음과 같다.

CSR^{Certificate Signing Request}은 다음과 같다.

이 특정 CSR은 서버의 공개 키와 영국 런던을 기반으로 하는 기업 ACME에 관한 자세한 정보, 도메인 이름 example.com를 포함한다.

마지막으로 서명된 HTTPS 인증서는 다음과 같다.

모든 부분은 연결되어 있으며 서로 일치해야 한다. 마지막 인증서는 설명 목적으로만 생성한 것이다. 공인된 인증 기관에서 서명하지 않았기 때문에 자체 서명 인증서라고 한다.

다음은 cPanel과 리눅스, FreeBSD, 윈도우에서 설정 단계를 설명한다. 이는 모든 종류의 인증서에 유효한 범용 절차다. 무료 DV 인증서를 얻고 싶다면 아래 나오는 Let’s Encrypt와 Cloudflare 부분에서 따라야 하는 절차에 대해 설명할 것이다.

1단계: 개인 키와 CSR 만들기

다음 예제에서 호환성을 위해 2048비트 RSA 인증서를 사용한다. 서버 공급 업체에서 이를 지원한다면(예: 헤로쿠나 AWS를 사용하지 않는 경우) ECC를 사용하는 편이 좋다.

CPANEL

1. 호스트의 cPanel에 로그인한다.

2. 아래로 스크롤해서 ‘Security’을 찾고 ‘SSL/TLS’를 클릭한다.

   

    

3. 이제 ‘SSL/TLS Manager’ 홈으로 넘어왔다. ‘Private Keys(KEY)’를 클릭해 새로운 개인 키를 만든다.

   

    

4. 페이지를 ‘Generate, Paste or Upload a new Private Key’로 리디렉션한다. ‘Key Size’ 드롭다운 메뉴에서 ‘2048-bit’를 선택하고 ‘Generate’를 클릭한다.

   

    

5. 새 개인 키가 생성되고 확인 화면이 나타난다.

   

    

6. ‘Private Keys’ 홈으로 다시 돌아가면 새로운 키 목록을 보게 된다.

   

    

7. ‘SSL/TLS Manager’ 홈으로 다시 돌아간다. ‘Certificate Signing Requests(CSR)’를 클릭해 새로운 인증서 요청을 만든다.

   

    

8. 이제 ‘Generate New Certificate Signing Request’ 양식이 표시된다. 이전에 만든 개인 키를 선택하고 필드를 채운다. 모든 질문에 알맞은 답을 적고(서명된 인증서에 공개), HTTPS 인증서를 요청하는 도메인 이름과 정확히 일치해야 하는 ‘Domains’ 섹션에 특별히 주의한다. 최상위 수준 도메인만(example.com) 포함한다(CA는 보통 www 하위 도메인(예: www.example.com) 역시 추가한다). 작업을 마치고 나면 ‘Generate’ 버튼을 클릭한다.

   

    

9. 새로운 CSR이 생성되고 확인 화면이 표시된다.

   

    

10. ‘Certificate Signing Request’ 홈으로 돌아가면 새로운 CSR 목록이 보인다.

    

     

리눅스, FREEBSD

OpenSSL이 설치되었는지 다음 명령을 사용해 확인한다.

아직 설치되지 않았다면 명령줄을 열고 해당 플랫폼에 대한 OpenSSL을 설치한다.

• 데비안, 우분투 및 클론
  
  sudo apt-get install openssl
•  레드햇, CentOS 및 클론
  sudo yum install openssl

• FreeBSD

  make -C /usr/ports/security/openssl install clean

그 다음 다음 명령으로 개인 키와 CSR을 생성한다.

개인 키가 생성되고 CSR에 대한 몇 가지 질문을 요청받는다.

모든 질문에 알맞은 답을 제공하고(서명된 인증서에 공개), HTTPS 인증서를 요청하는 도메인 이름과 정확히 일치해야 하는 ‘Common Name’ 섹션에 특별히 주의한다. 최상위 수준 도메인만(example.com) 포함한다. CA는 보통 www 하위 도메인(예: www.example.com) 역시 추가한다.

 

윈도우의 IIS(INTERNET INFORMATION SERVER)

1. 시작 → 관리 도구 → IIS(인터넷 정보 서비스) 관리자를 실행하고 서버 이름을 클릭한다. 가운데 열에서 ‘Server Certificates’를 더블 클릭한다.

   

2. 오른쪽 열에서 ‘Create Certificate Request’를 클릭한다.

   

3. 도메인 이름과 일치해야 하는 ‘Common Name’에 주의하면서 조직의 세부 내용을 입력하고 ‘Next’를 클릭한다.

   

4. ‘Cryptographic Service Provider’에서는 기본값을 사용하고, ‘Bit length’를 2048로 설정한다.

   

5. 생성된 CSR을 저장할 위치를 지정하고 ‘Finish’를 클릭한다.

   

2단계: HTTPS 인증서 얻기

웹사이트 인증서를 얻기 위해 먼저 HTTPS 인증서 공급 업체로부터 HTTPS 인증서 크레딧(DV, OV, EV, 단일 사이트, 멀티 사이트, 와일드 카드)을 구매한다. 인증서 크레딧 구매 뒤 선택한 도메인에 구매한 크레딧을 쓸 인증서 서명 요청을 해야 한다. BEGIN CERTIFICATE REQUEST와 END CERTIFICATE REQUEST를 포함해 전체 CSR 텍스트 제공(필드에 붙여 넣기 하거나 업로드)을 요청받는다. EV나 OV 인증서를 받고 싶다면 인증서 요청자의 법적 신원을 제공해야 한다. 또한 확인을 위해 회사와 관련된 추가 문서를 제출해야 한다. 인증서 등록 기관은 요청(그리고 모든 지원 문서)을 검증한 다음 서명된 HTTPS 인증서를 발행한다.

HTTPS 인증서 얻기

호스팅 공급 업체나 HTTPS 등록 기관에 따라 제품과 등록 절차가 다를 수 있으나 일반적으로 비슷한 방식이다.

1. HTTPS 인증서 공급 업체를 찾는다.
2. 인증서 유형(DV, OV, EV, 단일 사이트, 멀티 사이트, 와일드 카드)을 선택하고 ‘Add to cart’를 클릭한다. 선호하는 지급 방법을 지정하고 지불을 완료한다.
3. 도메인에 새로운 HTTPS 인증서를 활성화한다. 인증서 서명 요청을 붙여 넣거나 업로드할 수 있다. 시스템은 CSR에서 인증서 세부 사항을 뽑아낸다.
4. ‘Domain Control Validation’이라는 방식을 선택하라는 요청을 받는다. 이메일이나 HTML 파일(HTTP 기반) 업로드, 도메인 영역 파일(DNS 기반)에 TXT 레코드를 추가를 통해 수행한다.
5. 검증이 완료되고 HTTPS 인증서가 발행될 때까지 잠깐 기다린다. 서명된 HTTPS 인증서를 다운로드한다.

자체 서명 인증서

인증 기관을 통하지 않고 스스로 인증서를 서명할 수도 있다. 이 인증서는 다른 인증서만큼이나 암호화 방법으로 우수하기 때문에 테스트 목적으로는 좋으나, 브라우저에서는 신뢰하지 않으므로 보안 경고를 표시한다. 어떤 것이라도 클레임이 포함할 수 있지만 제 3의 당사자의 검증은 통과하지 못한다. 사용자가 해당 웹사이트를 신뢰한다면 인증서를 저장하고 향후 방문에서 신뢰하도록 브라우저에서 예외를 추가할 수 있다.

앞의 예제 인증서는 자체 서명된 인증서다. example.com 도메인용으로 사용할 수 있으며 유효기간 내에서 잘 동작한다.

OpenSSL을 사용할 수 있는 모든 플랫폼에서 자체 서명 인증서를 만들 수 있다.

자체 서명 인증서를 사용할 수 있다면 서버에 이 인증서를 설치해야 한다. 같은 공급 업체의 호스팅과 HTTPS 등록 서비스를 사용하고 있다면(많은 호스팅 공급 업체가 HTTPS 인증서를 판매한다), 웹사이트용으로 새로 구매한 HTTPS 인증서를 설치하고 활성화하는 자동화된 절차가 있을 것이다. 다른 곳에서 호스팅 중 이라면 인증서를 다운로드하고 인증서를 사용할 수 있도록 서버를 구성해야 한다.

3단계: 웹사이트에 HTTPS 인증서 설치하기

CPANEL

1. ‘SSL/TLS Manager’ 홈으로 다시 돌아간다. ‘Certificates(CRT)’를 클릭해서 새로운 인증서를 가져온다.

   

2. HTTPS 등록 기관에서 받은 인증서 파일의 내용을 붙여 넣기 하거나 ‘Browse’ 버튼을 사용해 인증서를 업로드한다.

   

3. HTTPS 인증서 내용을 붙여 넣을 때 내용이 분석되며, 확인을 위한 평문 값이 표시된다. 내용을 검토하고 ‘Save Certificate’ 버튼을 클릭한다.

   

4. 새로운 HTTPS 인증서를 저장하면 다음과 같은 확인 화면이 나타난다.

   

5. ‘Certificates(CRT)’ 홈으로 다시 돌아가면, 새로운 HTTPS 인증서 목록이 표시된다.

   

6. ‘SSL/TLS Manager’ 홈으로 돌아간다. ‘Install and Manage SSL for your website(HTTPS)’를 클릭해 기존 웹사이트에 새로운 인증서를 할당한다.

   

7. ‘Install an SSL Website’ 양식이 표시된다. ‘Browse Certificates’ 버튼을 클릭하고 HTTPS 인증서를 선택한다. 드롭다운 메뉴에서 웹사이트 도메인을 선택하고 ‘Certificate’와 ‘Private Key’ 필드가 채워졌는지 확인한다.

   

https://www.example.com으로 액세스할 수 있는지 확인한다. 웹사이트가 잘 동작하면 영구적으로 HTTP 트래픽을 HTTPS로 리디렉션하고 싶을 것이다. 그렇게 하려면 웹사이트 루트 폴더의 .htaccess 파일(아파치 웹 서버의 경우)에 몇 줄의 코드를 넣어야 한다.

.htaccess 파일이 이미 존재한다면 기존 RewriteEngine On 지시문 바로 다음 RewriteCond와 RewriteRule 줄만 붙여 넣는다.

리눅스, FREEBSD

생성한 개인 키(example.com.key)와 인증서 서명 요청(example.com.csr), 유효한 HTTPS 인증서(example.com.crt)를 적절한 위치에 넣는다.

• 데비안, 우분투 및 클론, FreeBSD
  
  cp example.com.crt /etc/ssl/certs/cp example.com.key /etc/ssl/private/cp example.com.csr /etc/ssl/private/
  

• 레드햇, CentOS 및 클론
  
  cp example.com.crt /etc/pki/tls/certs/cp example.com.key /etc/pki/tls/private/cp example.com.csr /etc/pki/tls/private/restorecon -RvF /etc/pki0
  

파일은 루트가 소유해야 하며 600이라는 퍼미션 설정으로 보호해야 한다.

• 데비안, 우분투 및 클론
  
  chown -R root. /etc/ssl/certs /etc/ssl/privatechmod -R 0600 /etc/ssl/certs /etc/ssl/private
  
• 레드햇, CentOS 및 클론
  
  chown -R root. /etc/pki/tls/certs /etc/pki/tls/privatechmod -R 0600 /etc/pki/tls/certs /etc/pki/tls/private
• FreeBSD
  
  chown -R root:wheel /etc/ssl/certs /etc/ssl/privatechmod -R 0600 /etc/ssl/certs /etc/ssl/private

아파치

웹사이트의 HTTPS 버전을 활성화하는 절차는 다음과 같다.

• mod_ssl이 서버에 설치되었는지 확인한다.
• 획득한 HTTPS 인증서(.crt) 파일을 서버로 업로드한다.
• 아파치 서버 구성 파일을 편집한다.

mod_ssl을 확인하는 것으로 시작한다. 운영체제에 따라 다음 구문 중 하나가 동작해야 한다.

mod_ssl이 설치됐으면 다음과 같은 결과가 표시된다.

약간 다른 유사한 결과가 나올 수도 있다.
mod_ssl이 없거나 활성화되지 않는 경우 운영체제에 따라 다음 작업을 시도해본다.

• 데비안, 우분투 및 클론
  
  
  sudo a2enmod sslsudo service apache2 restart
  

• 레드햇, CentOS 및 클론
  
  
  sudo yum install mod_sslsudo service httpd restart

• FreeBSD (SSL 옵션 선택)
  
  
  make -C /usr/ports/www/apache24 config install cleanapachectl restart

아파치 구성 파일을 편집한다(httpd.conf).

• 데비안, 우분투 /etc/apache2/apache2.conf
• 레드햇, CentOS /etc/httpd/conf/httpd.conf
• FreeBSD /usr/local/etc/apache2x/httpd.conf

이 구성은 앞서 언급한 것처럼 Mozilla SSL Configuration Generator를 사용해 생성했다(최신 구성을 확인하자). 인증서와 개인 키 경로 편집한 부분을 확인하자. 제공된 구성은 중간 설정을 사용해 생성했으며, 각 설정에 대한 제약 사항과 브라우저 구성을 보고 가장 알맞은 스위트를 결정하자.

HTTP에서 HTTPS로 리디렉션뿐만 아니라 비www에서 www 도메인으로(SEO에 유용) 리디렉션을 다루기 위해 생성된 코드에 몇 가지를 수정했다.

 

NGINX

nginx 구성 파일을 편집한다(nginx.conf).

• 데비안, 우분투, 레드햇, CentOS /etc/nginx/nginx.conf
• FreeBSD /usr/local/etc/nginx/nginx.conf

이 구성은 앞서 언급한 것처럼 Mozilla SSL Configuration Generator를 사용해 생성했다(최신 구성을 확인하자). 인증서와 개인 키 경로 편집한 부분을 확인하자. 제공된 구성은 중간 설정을 사용해 생성했으며, 각 설정에 대한 제약 사항과 브라우저 구성을 보고 가장 알맞은 스위트를 결정하자.

이 생성기는 자동으로 HTTP에서 HTTPS로 리디렉션을 처리하기 위한 코드를 생성하며, 기본으로 HTTP/2를 활성화한다.

윈도우 IIS(INTERNET INFORMATION SERVER)

1. 시작 → 관리 도구 → IIS(인터넷 정보 서비스) 관리자를 실행하고 서버 이름을 선택한다. 가운데 열에서 ‘Server Certificates’를 더블클릭한다.

   

2. 오른쪽 열에서 ‘Complete Certificate Request’를 클릭한다.

   

3. 인증 기관에서 받은 서명된 인증서 파일(example.com.crt)을 선택한다. 나중에 인증서를 구별할 수 있도록 ‘Friendly name’ 필드에 원하는 이름을 입력한다. ‘Personal’ 인증서 저장소(IIS 8+)에 새로운 인증서를 넣고 ‘OK’를 클릭한다.

   

4. 인증서 처리가 끝났다면 ‘Server Certificates’ 아래에 인증서가 표시된다.

   

5. 서버 이름을 확장한다. ‘Sites’ 아래에서 HTTPS 인증서를 할당하고 싶은 웹사이트를 선택하고, 오른쪽 열에서 ‘Bindings’을 클릭한다.

   

6. ‘Site bindings’ 창에서 ‘Add’를 클릭한다.

   

7. 새 창에서 다음 항목을 선택한다.
   • ‘종류’ : ‘https’
   • ‘IP 주소’ : ‘지정하지 않은 모든 IP’
   • ‘포트’ : ‘443’

   ‘SSL 인증서’ 필드에서 이름으로 설치된 HTTPS 인증서를 선택하고 ‘OK’를 클릭한다.

   

8. 이제 이 웹사이트에서 HTTP와 HTTPS 모두 사용 가능하다.

   

    

혼합 콘텐츠 경고

주소 줄 옆에 경고 표시와 ‘안전하지 않음! 이 페이지의 일부 콘텐츠는 암호화되지 않았습니다(마이크로소프트 에지 브라우저)’를 볼 수 있다. 이 부분이 설치가 잘못됐다는 것은 아니다. 로컬이나 원격 서버에서 리소스(이미지, 스타일시트, 스크립트 등)에 대한 모든 링크는 http://로 시작하지 않는다. 모든 리소스는 루트(/images/image.png, /styles/style.css 등)에 대한 상대 경로나 현재 문서(../images/image.png)에 대한 상대 경로를 가리키거나, <script src=“https://code.jquery.com/jquery-3.1.0.min.js"></script>처럼 https://로 시작하는 완전한 URL이어야 한다.

이러한 팁은 혼합 콘텐츠^{mixed-content} 경고를 제거하고 닫힌 자물쇠를 느낌표 없이 표시한다.

서버 테스트

서버를 구성하고 웹사이트를 HTTPS에서 실행한 후 Qualys SSL Server Test를 사용해 보안 구성을 확인하는 것이 좋다. 이 테스트를 수행하면 웹사이트를 스캔하고 구성에 대한 포괄적인 평가와 취약점, 권장 설정을 알려준다. 다음의 조언이 서버 보안 구성을 더 개선시킬 것이다.

갱신

인증서는 지정한 기간 동안 유효하다(보통 1년 정도다). 갱신의 마지막 순간까지 기다리지 않도록 하자. 등록 기관에서는 갱신 날짜가 다가오면 메일을 보내기 시작한다. 첫 번째 알림을 받자마자 새로운 인증서를 발행하자. 절차는 거의 동일하다. 새로운 인증서 서명 요청을 만들고 새로운 HTTPS 인증서를 얻어서 서버에 설치한다. 인증서의 유효성은 서명 시점에 시작되고 만료일은 현재 인증서가 만료된 후 1년으로 설정된다. 따라서 이전 인증서와 새 인증서 모두가 유효한 시기가 있고, 이전 인증서가 만료된 후 완전한 새해가 시작된다. 겹치는 기간 동안 이전 인증서 만료 전에도 새로운 인증서는 정상 동작하기 때문에 웹사이트 서비스는 중단되지 않는다.

폐기

서버가 손상됐거나 누군가가 개인 키에 액세스할 수 있다고 생각되면 즉시 현재 HTTPS 인증서를 폐기해야 한다. 다른 등록 기관의 절차는 다를 수 있지만 일반적으로 등록 기관의 특수한 데이터베이스에서 손상된 인증서를 비활성으로 표시한 다음 새로운 HTTPS 인증서를 발행한다. 물론, 어느 누구도 여러분을 가장할 수 없도록 현재 인증서는 가능한 빨리 폐기하고 보안 위반의 원인을 조사하고 해결한 다음 새로운 인증서를 받도록 한다. 필요하면 등록 기관에 도움을 요청하자.

 

Let’s Encrypt

다음은 Let’s Encrypt 웹사이트에 나와 있는 내용이다.

Let’s Encrypt는 무료이며 자동화된 공개 인증 기관이다. 공공의 이익을 위해 운영된다. Let’s Encrypt는 Internet Security Research Group(ISRG)에서 제공하는 서비스다.

Let’s Encrypt의 핵심 원칙은 다음과 같다.

• 무료 도메인 이름을 소유한 누구나 Let’s Encrypt를 사용해 무료로 신뢰된 인증서를 얻을 수 있다.
• 자동 웹 서버에서 실행 중인 소프트웨어는 Let’s Encrypt와 상호작용해 어려움 없이 인증서를 사용할 수 있도록 안전하게 구성할 수 있으며 자동으로 갱신한다.
• 보안 Let’s Encrypt는 CA와 웹사이트 운영자 모두 서버를 안전하게 운영하도록 도움으로써 보안 TLS 보안 모범 사례를 제공하는 플랫폼 역할을 한다.
• 투명 발행되고 폐기된 모든 인증서는 기록이 공개되어 누구나 확인할 수 있다.
• 공개 다른 곳에서도 적용할 수 있도록 자동 발행과 갱신 프로토콜을 공개 표준으로 게시한다.
• 공공성 기본 인터넷 프로토콜처럼 Let’s Encrypt는 공동체 이익을 위한 공동 노력의 산물로 어떤 조직도 통제하지 못한다.

동작 방식

Let’s Encrypt와 다른 CA 사이의 동작 모드에는 일부 상당한 차이가 있다. 앞서 설명한 원칙 중 첫 세 가지(무료, 자동, 보안)가 중요한 차이점이다.

 

• 무료 Let’s Encrypt HTTPS의 인증서는 웹사이트 전체 수명 동안 완전히 무료다.
• 자동 Let’s Encrypt HTTPS 인증서는 1년의 유효기간을 갖는 보통의 HTTPS 인증서와 달리 유효기간이 90일이다. 인증서 갱신 자동화를 권장한다. 예를 들어, 서버 관리자는 전용 소프트웨어 서비스를 설정(또는 cron에서 소프트웨어를 주기적으로 호출)해 모든 호스팅 도메인에 초기 도메인 검증과 후속 갱신을 관리한다. 한 번 설정하고 잊어버리는 스타일을 추구하는 것이다.
• 보안 Let’s Encrypt HTTPS 인증서는 보안을 약화시키지 않고 발행되므로 오래되고 더 이질적인 플랫폼과 호환성에 문제를 야기한다. 호환성 페이지를 검토해 호환되지 않는 플랫폼을 제외했는지 확인하자.

한계

Let’s Encrypt는 DV 인증서만 제공한다. OV와 EV는 지원하지 않으며 앞으로도 지원 계획은 없다. 단일 도메인이나 멀티 도메인 HTTPS 인증서는 제공하지만 와일드카드 인증서는 제공하지 않는다. 더 자세한 정보는 Let’s Encrypt FAQ에서 확인할 수 있다.

 

지원이 끝난 레거시 클라이언트(Windows XP SP3 이전)는 지원하지 않는다. 자세한 내용은 호환성 페이지를 확인하자.

Let’s Encrypt HTTPS 인증서 사용하기

CPANEL

1. 호스트의 cPanel에 로그인한다.
2. ‘Security’ 섹션으로 스크롤한 다음 ‘Let’s Encrypt for cPanel’을 클릭한다.

   

3. 이제 ‘Let’s Encrypt for cPanel’ 섹션으로 들어왔다. 두 가지 도메인 이름(example.com, www.example.com)을 모두 선택하고 ‘Issue Multiple’을 클릭한다.

   

4. 확인 화면이 나타난다. HTTPS 인증서의 ‘주체 대체 이름(SAN)’ 레코드에 들어간 최상위 수준(예: www 제외) 도메인 이름이 기본(Main)으로 선택되고, www 도메인 이름은 별칭으로 선택된다. ‘Issue’를 클릭해 계속 진행한다. 초기 검증이 더 오래(약 1-2분) 걸리기 때문에 페이지를 새로 고치지 말고 기다리자.

   

5. 처리가 끝나면 확인 메시지가 표시된다. ‘Go back’을 클릭해 설치된 HTTPS 인증서를 확인한다.

   

6. ‘Your domains with Let’s Encrypt certificates’ 아래에 도메인 목록이 표시된다. 인증서 세부 내용을 확인하고 브라우저에서 https://를 앞에 붙여 웹사이트를 열어 본다.

   

리눅스, FREEBSD, 기타

서버에 Let’s Encrypt를 설정하는 가장 쉬운 방법이 Certbot을 사용하는 것이다. 웹 서버와 운영체제를 선택하고 다음 지시만 따르면 된다.

윈도우 인터넷 정보 서버

윈도우의 IIS용 공식 클라이언트는 현재 없지만 해결책이 있다.

Let’s Encrypt용 네이티브 윈도우 클라이언트를 만드는 몇 가지 프로젝트가 있다.

• ACMESharp(PowerShell)은 처음으로 윈도우 클라이언트를 작성하려는 노력의 산물이다.
• letsencrypt-win-simple(명령줄용)은 가장 사용하기 쉽다.
• Certify는 ACMESharp 위에 GUI를 제공하지만 여전히 알파 버전이다.

Cloudflare

Cloudflare는 CDN(content delivery network)과 웹사이트 보안, DDoS(distributed denial of service) 공격에 대한 보호를 제공하는 서비스다. 모든 구독 플랜에 무료 HTTPS 인증서(공유 Cloudflare Universal SSL 인증서)를 제공한다. 고유한 HTTPS 인증서를 얻으려면 Business 플랜으로 업그레이드해야 한다. 간단히 계정을 만들고 웹사이트를 설정한 뒤 ‘Crypto’ 섹션을 방문하면 된다.

CertSimple

CertSimple은 EV 전용 HTTPS 인증서 공급 업체다. Let’s Encrypt가 DV HTTPS 인증서 시장에서 느리고 틀에 박힌 방식으로 일하는 다른 공급 업체에 비해 더 빠르고 쉬운 조직 검증 과정을 제공함으로써 시장을 개척했던 유사한 방식으로 EV HTTPS 시장을 재편하고 있다. 다음과 같은 장점을 제공한다.

• 간단한 적용 절차 소프트웨어를 설치하거나 명령줄 질문이 없다. 지불 전에 실시간 검증과 아주 상세한 확인을 거친다.
• 빠른 검증 시간 업계 표준 7-10시간 대비 평균 3시간
• 인증서 유효 시간 동안 재발행 무료 나중에 도메인 이름을 추가하거나 잃어버린 개인 키를 수정하기 쉽다.

트로이 헌트^{Troy Hunt}의 블로그에서 CertSimple의 프로세스에 대한 뛰어나고 깊이 있는 리뷰를 읽어볼 수 있다.

하나의 IP 주소를 기반으로 하는 여러 HTTPS 웹사이트

핸드셰이크 프로세스의 본질상 하나의 IP 주소를 가진 가상 호스트는 TLS에 문제가 된다. 가상 호스트는 클라이언트가 HTTP 요청 헤더의 일부로 도메인 이름을 포함함으로써 동작하지만, HTTPS가 사용될 때 TLS 핸드셰이크는 HTTP 헤더가 전송되기 전에 발생한다. 헤더를 포함해 평문 HTTP 를 전송하기 전에 보안 채널이 초기화되고 완전한 기능을 제공해야 한다. 따라서 서버는 클라이언트 연결에 맨 먼저 나타낼 HTTPS 인증서를 알지 못하므로 구성 파일에서 첫 번째 인증서를 나타낸다. 물론 이 인증서는 첫 번째 TLS 사용 웹사이트에만 올바로 동작한다.

몇 가지 해결책이 있다. 각 TLS 사용 도메인에 개별 IP를 제공하거나 하나의 인증서에 모든 도메인을 포함하는 것이다. 두 가지 모두 그 다지 현실적이지는 않다. IPv4 주소 공간은 이제 여유가 없고 하나의 큰 HTTPS 인증서를 갖는다는 의미는 이 서버에 하나의 웹사이트를 추가하고 싶다면 전체 멀티 도메인 인증서를 재발행해야 한다는 뜻이다.

SNI(Server Name Indication)라는 TLS 프로토콜에 대한 확장이 이런 제약 사항을 극복하는 방안으로 소개됐다. 서버와 클라이언트 양쪽에서 이를 지원해야 하며 SNI 지원이 요즘 널리 사용되기는 하지만 모든 가능한 클라이언트와의 호환성이 필요하다면 아직은 100% 완벽하지는 않다.

아파치와 nginx, IIS (8+)에 대한 SNI 실행에 관한 자세한 내용은 각각의 문서를 읽어보자.

유용한 자료

• 모질라 SSL 구성 생성기()
• SSL 서버 테스트, Qualys
• ‘보안/서버 사이드 TLS’, 모질라 위키
• ‘SSL과 TLS 배포 모범 사례’, SSL Labs
• SSL, TLS 관련 문서, Qualys SSL Labs
• ‘데이터베이스 검색과 대체용 PHP 스크립트(워드프레스 데이터베이스에서 HTTP의 모든 인스턴스를 HTTPS로 대체하기)’, Interconnect IT