노땅의 IT 세계

HTTP에서 HTTPS로 전환하기 위한 완벽 가이드
HTTPS 설정은 경험이 부족한 사용자에게는 어려울 수 있다. 여러 단계를 거쳐야 하고 암호화와 서버 구성에 관한 지식이 필요하기 때문에 복잡한 작업으로 여겨진다.
여기서는 HTTPS 설정에 필요한 구성 요소와 단계에 대해 설명한다. 호스팅 공급 업체가 HTTPS 인증서를 제공하는 경우는 설정이 더 쉽다(제어판에서 모든 작업을 쉽고 빠르게 수행할 수 있다). 리눅스와 유닉스 아파치 HTTP 서버와 엔진엑스Nginx뿐만 아니라 윈도우 IISInternet Information Server의 관리자나 cPanel 사용자를 위한 지침도 소개한다. 기본적인 내용부터 시작해보자.
 
HTTP, HTTPS, HTTP/2, SSL, TLS – 도대체 뭐가 뭔지?
클라이언트와 서버 간 통신 과정을 설명하는 데 사용되는 약어가 많다. 이러한 약어의 개념을 모르는 사람은 혼동해서 사용하기 쉽다.
HTTPHypertext Transfer Protocol는 클라이언트와 서버 양쪽에서 통신할 수 있도록 구현해야 하는 기본 통신 프로토콜로, 요청과 응답, 세션, 캐싱, 인증 등을 다룬다. 프로토콜과 HTML 관련 작업은 CERN에서 팀 버너스 리Tim Berners-Lee와 그 팀이 1989년에 시작했다. 첫 번째 공식 프로토콜 버전(HTTP 1.0)은 1996년에 발표됐고, 곧이어 1997년에 현재 널리 사용되는 버전(HTTP 1.1)이 나왔다.
HTTP는 브라우저와 서버 사이에서 정보를 평문으로 전송하므로 정보가 전달되는 네트워크에서 전송되는 정보를 엿볼 수 있다. 이런 보안 문제로 인해 클라이언트와 서버가 먼저 암호화 통신 채널을 설정한 다음 평문 HTTP 메시지를 전송함으로써 정보 유출을 막는 HTTPSHTTP Secure가 소개되었다.
암호화 채널은 이전에 SSLSecure Socket Layer이라고 불렸던 TLSTransport 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, 안드로이드 등의 운영체제뿐만 아니라 파이어폭스 브라우저는 신뢰된 인증서 목록을 갖고 있다. 사용하는 브라우저에서 신뢰하는 인증 기관을 확인할 수 있다.
• 파이어폭스 설정 → 개인 정보 및 보안 → 인증서 → 인증서 보기 → 인증 기관
• 윈도우 제어판 → 인터넷 옵션 → 내용 → 인증서 → 신뢰할 수 있는 인증 기관/중간 인증 기관
• 맥 응용 프로그램 → 유틸리티 → 키체인 접근 → 카테고리 내 인증서

신뢰 사슬Chain of trust (이미지 확대)
목록에 없는 다른 인증 기관도 추가할 수 있는데, 이는 자체 서명된 인증서와 같은 사설 인증서를 사용할 때 유용하다(뒤에서 다룬다).
대개 일반적인 상황에서 서버 쪽에서만 클라이언트에 신원을 증명한다. 예를 들어, 전자상거래 웹사이트와 고객의 관계에서 해당 웹사이트만 인증서가 필요하다. 전자 정부와 같은 경우는 서비스를 요청하는 서버와 클라이언트 모두 자신의 신원을 증명해야 한다. 이는 양쪽 당사자 모두 다른 당사자를 인증하는 데 인증서를 사용해야 한다는 뜻이다(이 설정 또한 이 글의 범위 밖이다).
HTTPS 인증서 유형
HTTPS 인증서에는 여러 유형이 있으며 다음과 같이 나눌 수 있다.
1. 신원 검증
1. DVDomain validated 가장 일반적인 유형의 인증서인 DV 인증서는 도메인이 특정 공개 키와 일치하는지 확인한다. 브라우저는 서버와 보안 연결을 수립하고 닫힌 자물쇠를 표시한다. 이 표시를 클릭하면 ‘현재 웹사이트는 소유자 정보를 제공하지 않고 있습니다’를 보여준다. 도메인 외의 다른 특별한 요구 사항은 없다. DV 인증서는 해당 도메인에 대한 알맞은 공개 키인지를 간단히 확인하며, 브라우저에서는 법적 신원을 보여주지는 않는다. DV 인증서는 무료이거나 저렴(10달러/년)하다(아래 Let’s Encrypt와 Cloudflare 부분 참고).
2. EVExtended validation EV 인증서는 웹사이트의 법적 신분을 검증한다. EV 인증서는 가장 신뢰할 수 있는 유형의 인증서다. 인증 기관에서 도메인을 관리하는 이의  법적 신원을 확인한 후 얻을 수 있다. 법적 신원은 다음의 조합으로 확인한다.
• 도메인 관리(예: DV 인증서)
• 회사가 등록되었고 현재 유지 상태인지 확인할 수 있는 공인된 사업 기록
• D&B(Dunn and Bradstreet), 세일즈포스 connect.data.com, 전화번호부 등에 등재된 자영업 정보
• 확인 전화
• 인증서의 모든 도메인 이름 검사(와일드카드는 EV 인증서에서 명시적으로 금지). 닫힌 자물쇠 표시뿐만 아니라 EV HTTPS 인증서는 URL 앞에 검증된 법적 신원의 이름(등록된 회사)을 표시한다. iOS 사파리와 같은 일부 기기는 검증된 법적 신원만 표시하고 전체 URL은 무시한다. 해당 표시를 클릭하면 이름과 주소 같은 조직에 대한 자세한 정보를 보여준다. 비용은 연간 150달러에서 300달러 정도다.
3. OVOrganization 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과 http://www.example.com와 같은 도메인 이름에 유효하다.
2. 다중 도메인(UCC/SAN) UCCUnified Communications Certificate 또는 SAN 인증서로 알려진 인증서 유형으로 도메인의 목록을 다룰 수 있다(지정된 제한까지). 단일 도메인에 대한 제한은 없으며 다른 도메인과 하위 도메인을 혼합할 수 있다. 가격은 보통 정해진 도메인의 수(3~5개)에 추가 비용을 지불하면 더 많이(최대 한도까지) 포함할 수 있는 옵션을 제공한다. 웹사이트의 인증서를 검사하는 클라이언트는 주 도메인뿐만 아니라 모든 추가 도메인을 확인하기 때문에 웹사이트와 관련된 도메인 사용을 권장한다.
3. 와일드카드 이 유형의 인증서는 주 도메인뿐만 아니라 하위 도메인(*.example.com)의 수를 제한 없이 다룬다(예: example.com, http://www.example.com, mail.example.com, ftp.example.com 등). 제한 사항은 주 도메인의 하위 도메인만 다룬다는 점이다.
다음 표에서 사용 가능한 다양한 HTTPS 인증서를 정리했다.
인증서 유형 DV OV EV
(Domain validated) (Organization validated) (Extended validation)
HTTPS HTTPS에서 법적 소유자 검증 HTTPS 검증 법적 소유자 정보가 브라우저에 표시
단일 도메인 example.com, http://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 설정은 해당 키를 ECDHEElliptic Curve Diffie-Hellman Ephemeral 키 교환 알고리즘을 사용해 교환한다는 뜻이다. 인증 기관은 RSARivest-Shamir-Adleman 알고리즘을 사용해 인증서를 서명한다. 대칭 메시지 암호화는 256비트 키와 GCM 운영 모드를 갖는 AESAdvanced Encryption Standard 암호를 사용한다. 메시지 무결성은 384비트 다이제스트를 사용하는 SHA 보안 해싱 알고리즘을 사용해 검증한다(포괄적인 알고리즘 조합 목록을 사용할 수 있다.) 따라서 몇 가지 구성을 선택할 수 있다.
암호화 스위트
사용할 암호화 스위트cipher suite를 결정하는 일은 호환성과 보안 사이의 균형이다.
• 이전 브라우저와 호환성은 이전 암호화 스위트를 지원하는 서버가 필요하다.
• 하지만 대다수의 이전 암호화 스위트는 더 이상 안전하지 않다.
OpenSSL은 암호 강도가 가장 안전한 것에서 가장 약한 것 순서로 위에서 아래로 지원 조합을 나열한다. 클라이언트와 서버 간의 초기 핸드셰이크 동안 양쪽 당사자가 지원하는 조합과 일치하는 것을 발견할 때까지 협상하기 때문에 이런 방식으로 설계했다. 가장 보안이 좋은 조합을 먼저 시도하고 다른 방법이 없다면 점차 더 약한 조합을 쓴다.
서버에서 사용할 암호화 방법을 조언할 때 매우 유용하고 권장하는 자료는 뒤에서 실제 서버 구성에 다룰 모질라 SSL 구성 생성기다.
키 유형
ECCElliptic Curve Cryptography 인증서는 RSA 인증서보다 더 빠르고 CPU를 덜 쓰는데, 특히 모바일 클라이언트에는 이런 점이 중요하다. 하지만 아마존의 클라우드프론트CloudFront나 헤로쿠Heroku와 같은 일부 서비스는 이 글을 쓰는 시점에 아직 ECC 인증서를 지원하지 않는다. 256 비트 ECC 키면 충분하다.
RSARivest Shamir Adleman 인증서는 더 느리지만 오래된 다양한 서버와 호환된다. RSA 키는 더 크므로 2048비트 RSA 키가 최소한이다. 4096비트 이상의 RSA 키는 성능에 좋지 않다. 이 인증서는 2048비트 중간 인증 기관에서 서명할 수도 있어 추가적인 보안에 상당한 손상을 준다.
앞서 기술한 내용이 가변적이라는 점과 키 크기의 제약 사항을 주목했을 것이다. 한 서버에서 과부하를 주는 요인이 다른 서버에서는 그렇지 않을 수 있기 때문이다. 성능에 미치는 영향을 확인하는 최선의 방법은 실제 웹사이트와 실제 방문자로 서버의 부하를 모니터링하는 것이다. 시간의 흐름에 따라 성능이 바뀔 것이다.
절차
HTTPS 인증서를 얻으려면 다음 단계를 거쳐야 한다.
1. 개인 키와 공개 키 쌍을 만들고 조직과 공개 키에 관한 정보를 포함하는 CSRCertificate 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비트 사용)의 문자열을 무작위로 생성한 것으로 다음과 같다.
—–BEGIN RSA PRIVATE KEY—–
MIIEowIBAAKCAQEAm+036O2PlUQbKbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9N
i8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4E
S17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWu
Q30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnf
b/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDil
Tt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQgNQIDAQABAoIBAEAO2KVM02wTKsWb
dZlXKEi5mrtofLhkbqvTgVE7fbOKnW8FJuqCl+2NMH31F1n03l765p4dNF4JmRhv
/+ne4vCgOPHR/cFsH4z/0d5CpHMlC7JZQ5JjR4QDOYNOpUG51smVamPoZjkOlyih
XGk/q72CxeU6F/gKIdLt6Dx03wBosIq9IAE8LwdMnioeuj18qaVg195OMeIOriIn
tpWP4eFya5rTpIFfIdHdIxyXsd6hF/LrRc9BMWTY1/uOLrpYjTf7chbdNaxhwH7k
buvKxBvCvmXmd6v/AeQQAXbUkdSnbTKDaB9B7IlUTcDJyPBJXvFS1IzzjN6vV+06
XBwHx5ECgYEAyRZLzwnA3bw8Ep9mDw8JHDQoGuQkFEMLqRdRRoZ+hxnBD9V9M0T6
HRiUFOizEVoXxf6zPtHm/T7cRD8AFqB+pA/Nv0ug6KpwUjA4Aihf5ADp0gem0DNw
YlVkCA6Bu7c9IUlE0hwF7RLB7YrryJVJit9AymmUTUUHCQTWW2yBhC8CgYEAxoHS
HGXthin5owOTNPwLwPfU2o7SybkDBKyW69uTi0KxAl3610DjyA/cV2mxIcFlPv1y
HualGd9eNoeCMBy/AUtjzI0K77yeRpjj321rj6k8c8bYWPHH539SiBXLWTY/WQ0w
pxfT3d/Z4QMh5d6p+p5f3UIrXESYQd+fAaG5tNsCgYEAksTdTB4YUT9EsWr6eN9G
jPlclFQUKV3OMvq77bfYvg8EJORz32nnDDmWS7SUjoOtemwutBlMeWbaKk25aMp3
5JNMXuV6apeMJ9Dd8GU7qBUqlIvVK31/96XPvzmnYzWZPqRVwO2HPcRFG3YcJmkg
JmZQyexJvCQ3wFNxiYUm+y0CgYBXQSMhFnCUg4jWbbDcHlnwRT+LnjHrN2arPE3O
eKLfGL6DotmqmjxFaStaRPv2MXMWgAMUsB8sQzG/WEsSaOBQaloAxJJlFIyhzXyE
bi1UZXhMD8BzQDu1dxLI/IN4wE6SDykumVuocEfuDxlsWDZxEgJjWD2E/iXK9seG
yRa+9wKBgEydVz+C1ECLI/dOWb20UC9nGQ+2dMa+3dsmvFwSJJatQv9NGaDUdxmU
hRVzWgogZ8dZ9oH8IY3U0owNRfO65VGe0sN00sQtMoweEQi0SN0J6FePiVCnl7pf
lvYBaemLrW2YI2B7zk5fTm6ng9BW/B1KfrH9Vm5wLQBchAN8Pjbu
—–END RSA PRIVATE KEY—–
‘개인 키를 비공개로 유지하자.’ 이 말은 매우 제한된 권한(600)으로 보호하고 누구에게도 드러내지 말라는 의미다.
여기에 대응하는 공개 키는 다음과 같다.
—–BEGIN PUBLIC KEY—–
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQbKbSSs2ik
6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5
e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+H
fBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTIN
WniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBC
eVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQg
NQIDAQAB
—–END PUBLIC KEY—–
CSRCertificate Signing Request은 다음과 같다.
—–BEGIN CERTIFICATE REQUEST—–
MIICzjCCAbYCAQAwgYgxFDASBgNVBAMMC2V4YW1wbGUuY29tMQswCQYDVQQLDAJJ
VDEPMA0GA1UECAwGTG9uZG9uMRIwEAYDVQQKDAlBQ01FIEluYy4xIDAeBgkqhkiG
9w0BCQEWEWFkbWluQGV4YW1wbGUuY29tMQswCQYDVQQGEwJHQjEPMA0GA1UEBwwG
TG9uZG9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQb
KbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3
OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYO
cfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wm
wZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZ
EUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2
tjtp+LQgNQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAGIQVhXfuWdINNfceNPm
CkAGv4yzpx88L34bhO1Dw4PYWnoS2f7ItuQA5zNk9EJhjkwK8gYspK7mPkvHDbFa
Um7lPSWsm3gjd3pU7dIaHxQ+0AW9lOw5ukiBlO4t3qgt+jTVZ3EhMbR0jDSyjTrY
kTgfuqQrGOQSmLb5XviEtCcN0rseWib3fKIl8DM69JiA2AALxyk7DCkS1BqLNChT
pnbgvtlUhc4yFXNCtwPGskXIvLsCn2LRy+qdsPM776kDLgD36hK0Wu14Lpsoa/p+
ZRuwKqTjdaV23o2aUMULyCRuITlghEEkRdJsaXadHXtNd5I5vDJOAAt46PIXcyEZ
aQY=
—–END CERTIFICATE REQUEST—–
이 특정 CSR은 서버의 공개 키와 영국 런던을 기반으로 하는 기업 ACME에 관한 자세한 정보, 도메인 이름 example.com를 포함한다.
마지막으로 서명된 HTTPS 인증서는 다음과 같다.
—–BEGIN CERTIFICATE—–
MIIDjjCCAnYCCQCJdR6v1+W5RzANBgkqhkiG9w0BAQUFADCBiDEUMBIGA1UEAwwL
ZXhhbXBsZS5jb20xCzAJBgNVBAsMAklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNV
BAoMCUFDTUUgSW5jLjEgMB4GCSqGSIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20x
CzAJBgNVBAYTAkdCMQ8wDQYDVQQHDAZMb25kb24wHhcNMTYwNDE5MTAzMjI1WhcN
MTcwNDE5MTAzMjI1WjCBiDEUMBIGA1UEAwwLZXhhbXBsZS5jb20xCzAJBgNVBAsM
AklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNVBAoMCUFDTUUgSW5jLjEgMB4GCSqG
SIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20xCzAJBgNVBAYTAkdCMQ8wDQYDVQQH
DAZMb25kb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCb7Tfo7Y+V
RBsptJKzaKTo7pNjLr5mxqzmgCTcaKgYuXVFb02LyRqCp2cPr0S3b2bW+Xk4g+wG
hbc5ZvVoFbl7cnTH2mtcjVb9+m+4/02ascFQ3gRLXtWWJGl9Ufdod88Lysqm/ca8
dg5x86Yw34d8FmVR4okqzpzlaZJV2dkHRHhQBa5DfRocQFWq2uGAepgMGiRV7T8f
jCbBkQhBMg1aeII4VHlSmEl/mc/yWMZuY/E1Od9v+IdL9yGNyMXtMYwbfp7sQGhC
KNkRRCzkgEJ5V586cUsrmMvH4EL/9f4U3MHIOKVO36Xbwj/dk3W6OFqTvdgVtaOM
tHa2O2n4tCA1AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBABwwkE7wX5gmZMRYugSS
7peSx83Oac1ikLnUDMMOU8WmqxaLTTZQeuoq5W23xWQWgcTtfjP9vfV50jFzXwat
5Ch3OQUS53d06hX5EiVrmTyDgybPVlfbq5147MBEC0ePGxG6uV+Ed+oUYX4OM/bB
XiFa4z7eamG+Md2d/A1cB54R3LH6vECLuyJrF0+sCGJJAGumJGhjcOdpvUVt5gvD
FIgT9B04VJnaBatEgWbn9x50EP4j41PNFGx/A0CCLgbTs8kZCdhE4QFMxU9T+T9t
rXgaspIi7RA4xkSE7x7B8NbvSlgP79/qUe80Z7d8Oolva6dTZduByr0CejdfhLhi
mNU=
—–END CERTIFICATE—–
모든 부분은 연결되어 있으며 서로 일치해야 한다. 마지막 인증서는 설명 목적으로만 생성한 것이다. 공인된 인증 기관에서 서명하지 않았기 때문에 자체 서명 인증서라고 한다.
다음은 cPanel과 리눅스, FreeBSD, 윈도우에서 설정 단계를 설명한다. 이는 모든 종류의 인증서에 유효한 범용 절차다. 무료 DV 인증서를 얻고 싶다면 아래 나오는 Let’s Encrypt와 Cloudflare 부분에서 따라야 하는 절차에 대해 설명할 것이다.
1단계: 개인 키와 CSR 만들기
다음 예제에서 호환성을 위해 2048비트 RSA 인증서를 사용한다. 서버 공급 업체에서 이를 지원한다면(예: 헤로쿠나 AWS를 사용하지 않는 경우) ECC를 사용하는 편이 좋다.
CPANEL
1. 호스트의 cPanel에 로그인한다.
2. 아래로 스크롤해서 ‘Security’을 찾고 ‘SSL/TLS’를 클릭한다.

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

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

cPanel ‘Private Key’ 관리 (이미지 확대)  
5. 새 개인 키가 생성되고 확인 화면이 나타난다.

cPanel 개인 키 확인 (이미지 확대)  
6. ‘Private Keys’ 홈으로 다시 돌아가면 새로운 키 목록을 보게 된다.

새로 생성된 키가 있는 cPanel ‘Private Keys’ (이미지 확대)  
7. ‘SSL/TLS Manager’ 홈으로 다시 돌아간다. ‘Certificate Signing Requests(CSR)’를 클릭해 새로운 인증서 요청을 만든다.

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

cPanel ‘Generate New Certificate Signing Request’ 양식 (이미지 확대)  
9. 새로운 CSR이 생성되고 확인 화면이 표시된다.

cPanel CSR 확인 (이미지 확대)  
10. ‘Certificate Signing Request’ 홈으로 돌아가면 새로운 CSR 목록이 보인다.

생성된 새로운 CSR이 있는 cPanel ‘Certificate Signing Request’ (이미지 확대)  
리눅스, FREEBSD
OpenSSL이 설치되었는지 다음 명령을 사용해 확인한다.
openssl version
아직 설치되지 않았다면 명령줄을 열고 해당 플랫폼에 대한 OpenSSL을 설치한다.
• 데비안, 우분투 및 클론 sudo apt-get install openssl
•  레드햇, CentOS 및 클론 sudo yum install openssl
• FreeBSD make -C /usr/ports/security/openssl install clean
그 다음 다음 명령으로 개인 키와 CSR을 생성한다.
openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr
개인 키가 생성되고 CSR에 대한 몇 가지 질문을 요청받는다.
Generating a 2048 bit RSA private key
……………………+++
……………………………………………………….+++
writing new private key to ‘example.com.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
모든 질문에 알맞은 답을 제공하고(서명된 인증서에 공개), HTTPS 인증서를 요청하는 도메인 이름과 정확히 일치해야 하는 ‘Common Name’ 섹션에 특별히 주의한다. 최상위 수준 도메인만(example.com) 포함한다. CA는 보통 www 하위 도메인(예: http://www.example.com) 역시 추가한다.
Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:London
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:ACME Inc.
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:admin@example.com
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
 
윈도우의 IIS(INTERNET INFORMATION SERVER)
1. 시작 → 관리 도구 → IIS(인터넷 정보 서비스) 관리자를 실행하고 서버 이름을 클릭한다. 가운데 열에서 ‘Server Certificates’를 더블 클릭한다.

IIS 관리자에서 ‘Server Certificates’ 더블클릭 (이미지 확대)
2. 오른쪽 열에서 ‘Create Certificate Request’를 클릭한다.

오른쪽 열에서 ‘Create Certificate Request’ 클릭 (이미지 확대)
3. 도메인 이름과 일치해야 하는 ‘Common Name’에 주의하면서 조직의 세부 내용을 입력하고 ‘Next’를 클릭한다.

조직의 세부 내용 입력 창 (이미지 확대)
4. ‘Cryptographic Service Provider’에서는 기본값을 사용하고, ‘Bit length’를 2048로 설정한다.

‘Bit length’를 2048로 설정 (이미지 확대)
5. 생성된 CSR을 저장할 위치를 지정하고 ‘Finish’를 클릭한다.

생성된 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을 사용할 수 있는 모든 플랫폼에서 자체 서명 인증서를 만들 수 있다.
openssl x509 -signkey example.com.key -in example.com.csr -req -days 365 -out example.com.crt
자체 서명 인증서를 사용할 수 있다면 서버에 이 인증서를 설치해야 한다. 같은 공급 업체의 호스팅과 HTTPS 등록 서비스를 사용하고 있다면(많은 호스팅 공급 업체가 HTTPS 인증서를 판매한다), 웹사이트용으로 새로 구매한 HTTPS 인증서를 설치하고 활성화하는 자동화된 절차가 있을 것이다. 다른 곳에서 호스팅 중 이라면 인증서를 다운로드하고 인증서를 사용할 수 있도록 서버를 구성해야 한다.
3단계: 웹사이트에 HTTPS 인증서 설치하기
CPANEL
1. ‘SSL/TLS Manager’ 홈으로 다시 돌아간다. ‘Certificates(CRT)’를 클릭해서 새로운 인증서를 가져온다.

cPanel ‘SSL/TLS Manager’ (이미지 확대)
2. HTTPS 등록 기관에서 받은 인증서 파일의 내용을 붙여 넣기 하거나 ‘Browse’ 버튼을 사용해 인증서를 업로드한다.

cPanel의 새로운 HTTPS 인증서 가져오기 (이미지 확대)
3. HTTPS 인증서 내용을 붙여 넣을 때 내용이 분석되며, 확인을 위한 평문 값이 표시된다. 내용을 검토하고 ‘Save Certificate’ 버튼을 클릭한다.

cPanel의 HTTPS 인증서 검토와 확인 (이미지 확대)
4. 새로운 HTTPS 인증서를 저장하면 다음과 같은 확인 화면이 나타난다.

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

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

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

cPanel ‘Install an SSL Website’ (이미지 확대)
https://www.example.com으로 액세스할 수 있는지 확인한다. 웹사이트가 잘 동작하면 영구적으로 HTTP 트래픽을 HTTPS로 리디렉션하고 싶을 것이다. 그렇게 하려면 웹사이트 루트 폴더의 .htaccess 파일(아파치 웹 서버의 경우)에 몇 줄의 코드를 넣어야 한다.
RewriteEngine On
 
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
.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을 확인하는 것으로 시작한다. 운영체제에 따라 다음 구문 중 하나가 동작해야 한다.
apache2 -M | grep ssl
or
httpd -M | grep ssl
mod_ssl이 설치됐으면 다음과 같은 결과가 표시된다.
ssl_module (shared)
Syntax OK
약간 다른 유사한 결과가 나올 수도 있다.
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
Listen          80
Listen          443
 
<VirtualHost *:80>
ServerName example.com
ServerAlias http://www.example.com
Redirect 301 / https://www.example.com/
</VirtualHost>
 
<VirtualHost *:443>
ServerName example.com
Redirect 301 / https://www.example.com/
</VirtualHost>
 
<VirtualHost *:443>
ServerName http://www.example.com
…
SSLEngine on
SSLCertificateFile/path/to/signed_certificate_followed_by_intermediate_certs
SSLCertificateKeyFile /path/to/private/key