이 페이지에서는 다음 단계를 포함하여 서버에서 HTTPS를 설정하는 방법을 안내합니다.
- 2048비트 RSA 공개 키/비공개 키 쌍을 만듭니다.
- 공개 키를 포함하는 CSR (인증서 서명 요청)을 생성합니다.
- 생성한 CSR을 CA (인증 기관)와 공유하여 최종 인증서 또는 인증서 체인을 받습니다.
/etc/ssl등 웹 액세스가 불가능한 곳 (Linux 및 Unix)이나 IIS가 인증서를 필요로 하는 곳 (Windows)에 최종 인증서를 설치합니다.
키 및 CSR(인증서 서명 요청) 생성
이 섹션에서는 대부분의 Linux, BSD, Mac OS X 시스템과 함께 제공되는 openssl 명령줄 프로그램을 사용하여 비공개 키와 공개 키, CSR를 생성합니다.
공개 키/비공개 키 쌍 생성
먼저 2,048비트 RSA 키 쌍을 생성합니다. 키가 짧으면 무차별 암호 대입 공격으로 해킹될 수 있고, 키가 길면 불필요한 리소스가 사용됩니다.
다음 명령어를 사용하여 RSA 키 쌍을 생성합니다.
openssl genrsa -out www.example.com.key 2048
그러면 다음과 같이 출력됩니다.
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
인증서 서명 요청 생성
이 단계에서는 공개 키와 조직 및 웹사이트에 대한 정보를 인증서 서명 요청(CSR)에 삽입합니다. openssl 명령어는 필요한 메타데이터를 묻습니다.
다음 명령을 실행하여
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
다음과 같이 출력됩니다.
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.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
CSR의 유효성을 확인하려면 다음 명령어를 실행하세요.
openssl req -text -in www.example.com.csr -noout
다음과 같은 응답이 나타나야 합니다.
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
...
CSR을 인증 기관에 제출
인증 기관 (CA)마다 CSR을 제출하는 방법이 다릅니다. 여기에는 웹사이트의 양식을 사용하거나 이메일로 CSR을 보내는 것이 포함될 수 있습니다. 일부 CA 또는 해당 재판매업체는 이 프로세스의 일부 또는 전체(경우에 따라 키 쌍 및 CSR 생성 포함)를 자동화할 수도 있습니다.
CSR을 CA로 전송하고 지시에 따라 최종 인증서 또는 인증서 체인을 받습니다.
공개 키 보증 서비스 수수료는 CA마다 다릅니다.
복수의 고유한 DNS 이름 (예: example.com, www.example.com, example.net 및 www.example.net 모두)에 매핑하거나 *.example.com과 같은 '와일드 카드' 이름 등 둘 이상의 DNS 이름에 키를 매핑하는 옵션도 있습니다.
/etc/ssl 등 웹 액세스가 불가능한 곳 (Linux 및 Unix)이나 IIS가 인증서를 필요로 하는 곳 (Windows)의 모든 프런트 엔드 서버에 인증서를 복사합니다.
서버에서 HTTPS 사용 설정
서버에서 HTTPS 활성화는 웹페이지에 보안을 제공하는 중요한 단계입니다.
- Mozilla의 Server Configuration 도구를 사용하여 HTTPS를 지원하도록 서버를 설정합니다.
- Qualys의 SSL Server Test를 통해 사이트를 정기적으로 테스트하여 A 또는 A+ 이상의 등급을 유지합니다.
이 시점에서 중대한 작업 결정을 내려야 합니다. 다음 중 하나를 선택합니다.
- 웹 서버에서 콘텐츠를 제공하는 각 호스트 이름에 고유한 IP 주소를 지정합니다.
- 이름 기반 가상 호스팅을 사용합니다.
각 호스트 이름에 고유한 IP 주소를 사용해 왔다면 모든 클라이언트에서 HTTP와 HTTPS를 모두 지원할 수 있습니다. 하지만, 이름 기반 가상 호스팅이 일반적으로 더 편리하므로 대부분의 사이트 운영자는 이를 사용하여 IP 주소를 유지합니다.
서버에서 HTTPS 서비스를 사용할 수 있도록 설정하지 않은 경우 지금 사용하도록 설정합니다(HTTP에서 HTTPS로 리디렉션하지 않음). 자세한 내용은 HTTP를 HTTPS로 리디렉션을 참고하세요. 구입하고 설치한 인증서를 사용하도록 웹 서버를 구성합니다. Mozilla의 구성 생성기가 유용할 수 있습니다.
호스트 이름 또는 하위 도메인이 많은 경우 각각 올바른 인증서를 사용해야 합니다.
지금뿐만 아니라 사이트 수명 전체에 걸쳐 Qualys의 SSL Server Test를 사용하여 HTTPS 구성을 정기적으로 확인하세요. 사이트는 A 또는 A+ 등급을 받아야 합니다. 이보다 낮은 등급을 초래하는 모든 원인은 버그로 처리하고 항상 주의해야 합니다. 알고리즘과 프로토콜을 상대로 한 새로운 공격이 항상 개발되고 있기 때문입니다.
사이트 내 URL을 상대 URL로 만들기
HTTP뿐만 아니라 HTTPS로도 사이트를 제공하므로 프로토콜에 상관없이 사이트가 가능한 한 원활하게 작동해야 합니다. 중요한 요소는 사이트 내 링크에 대한 상대적 URL을 사용하는 것입니다.
사이트 내 URL과 외부 URL이 특정 프로토콜에 종속되지 않도록 합니다.
상대 경로를 사용하거나 //example.com/something.js와 같이 프로토콜을 제외합니다.
HTTPS를 사용하여 HTTP 리소스가 포함된 페이지를 제공하면 문제가 발생할 수 있습니다. 브라우저가 안전하지 않은 리소스를 사용하는 안전한 페이지를 발견하면 사용자에게 페이지가 완전히 안전하지 않다고 경고하고 일부 브라우저는 HTTP 리소스를 로드하거나 실행하지 않아 페이지가 손상됩니다. 하지만 HTTP 페이지에 HTTPS 리소스를 안전하게 포함할 수 있습니다. 이러한 문제를 해결하는 방법에 관한 자세한 내용은 혼합 콘텐츠 수정을 참고하세요.
사이트의 다른 페이지로 연결되는 HTTP 기반 링크를 따라가면 사용자 환경이 HTTPS에서 HTTP로 다운그레이드될 수도 있습니다. 이 문제를 해결하려면 사이트 내 URL을 프로토콜 상대 (프로토콜 없음, //example.com으로 시작) 또는 호스트 상대 (/jquery.js와 같이 경로만으로 시작)로 만들어 최대한 상대적으로 만드세요.
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p>
<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="//img.example.com/logo.png"/>; <p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p> <p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
실수를 방지하려면 직접 하지 말고 스크립트를 사용하여 링크를 업데이트하세요. 사이트 콘텐츠가 데이터베이스에 있는 경우 데이터베이스의 개발 복사본에서 스크립트를 테스트합니다. 사이트 콘텐츠가 단순한 파일로만 구성된 경우 파일의 개발 사본에서 스크립트를 테스트합니다. 변경사항이 QA를 통과한 후에만 평상시와 같이 운영 환경에 적용하세요. Bram van Damme의 스크립트 또는 유사한 스크립트를 사용하여 사이트의 혼합 콘텐츠를 검색할 수 있습니다.
다른 사이트의 리소스를 포함하는 것과 달리 다른 사이트에 연결하는 경우에는 프로토콜을 변경하지 마세요. 이러한 사이트의 작동 방식을 제어할 수 없습니다.
대규모 사이트에 대한 마이그레이션 작업이 더 원활하게 진행되도록 하려면 프로토콜에 상대적인 URL을 사용하는 것이 좋습니다. 아직 HTTPS를 완전히 배포할 수 있을지 확실치 않은 경우에 사이트의 모든 하위 리소스에 대해 HTTPS를 강제로 사용하게 하면 역효과가 날 수 있습니다. 일정 기간 HTTPS가 새롭고 이상할 가능성이 크므로 HTTP 사이트도 계속해서 작동되어야 합니다. 시간이 지남에 따라 마이그레이션을 완료하고 HTTPS를 락인(lock in)할 것입니다(아래 두 섹션 참조).
사이트가 서드 파티(예: CDN 또는 jquery.com)에서 제공하는 스크립트, 이미지 또는 기타 리소스를 사용하는 경우 두 가지 옵션이 있습니다.
- 이러한 리소스에 대해 프로토콜에 상대적인 URL을 사용합니다. 서드 파티에서 HTTPS를 제공하지 않는 경우 이를 지원하도록 요청합니다. jquery.com을 포함하여 대부분의 업체에서 이미 HTTPS를 지원하고 있습니다.
- HTTP와 HTTPS를 모두 제공하는 개발자가 제어하는 서버에서 리소스를 제공합니다. 이 경우 사이트의 모양, 성능, 보안을 더 효과적으로 제어할 수 있고 사이트 보안을 위해 서드 파티를 신뢰할 필요가 없다는 장점이 있습니다.
HTTP를 HTTPS로 리디렉션
검색엔진에 HTTPS를 사용하여 사이트에 액세스하도록 알리려면 <link rel="canonical" href="https://…"/> 태그를 사용하여 각 페이지의 헤드에 기본 링크를 추가합니다.
STS(Strict Transport Security) 및 보안 쿠키 설정
이제 HTTPS 사용을 '락인(lock in)'할 준비가 되었습니다.
- 301 리디렉션 비용을 방지하려면 HSTS (HTTP Strict Transport Security)를 사용하세요.
- 항상 쿠키에 보안 플래그를 설정하세요.
먼저 Strict Transport Security를 사용하여 http:// 참조를 따르는 경우에도 항상 HTTPS를 사용하여 서버에 연결해야 함을 클라이언트에 지시합니다. 이를 통해 SSL 스트리핑과 같은 공격이 차단되고 HTTP를 HTTPS로 리디렉션에서 사용 설정한 301 redirect의 왕복 이동 비용도 방지됩니다.
HSTS를 사용 설정하려면 Strict-Transport-Security 헤더를 설정합니다. OWASP의 HSTS 페이지에 다양한 서버 소프트웨어에 대한 지침 링크가 나와 있습니다.
대부분의 웹 서버는 사용자설정 헤더를 추가하기 위한 유사한 기능을 제공합니다.
또한 클라이언트가 HTTP를 통해 쿠키 (예: 인증 또는 사이트 기본 설정용 쿠키)를 전송하지 않도록 하는 것도 중요합니다. 예를 들어 사용자의 인증 쿠키가 일반 텍스트 형식으로 노출되면 다른 모든 것이 올바르더라도 전체 세션의 보안이 보장되지 않게 됩니다.
이를 방지하려면 웹 앱을 변경하여 항상 웹 앱에서 설정하는 쿠키에 보안 플래그를 설정하도록 하세요. 이 OWASP 페이지에서는 여러 앱 프레임워크에서 보안 플래그를 설정하는 방법을 설명합니다. 모든 애플리케이션 프레임워크에는 플래그를 설정하는 방법이 있습니다.
대부분의 웹 서버는 단순한 리디렉션 기능을 제공합니다. 301 (Moved Permanently)를 사용하여 검색엔진과 브라우저에 HTTPS 버전이 표준 버전임을 알리고 사용자를 사이트의 HTTP 버전에서 HTTPS 버전으로 리디렉션합니다.
검색 순위
Google은 HTTPS를 긍정적인 검색 품질 지표로 사용합니다. 또한 이 검색 순위를 유지하면서 사이트를 이전, 이동 또는 마이그레이션하는 방법에 관한 가이드를 게시하고 있습니다. Bing은 웹마스터 가이드라인도 게시합니다.
성능
콘텐츠 및 애플리케이션 레이어가 잘 조율된 경우 (Steve Souders의 서적 참고) 나머지 TLS 성능 우려 사항은 일반적으로 애플리케이션의 전반적인 비용에 비해 작습니다. 이러한 비용은 절감하고 상각할 수도 있습니다. TLS 최적화에 관한 도움말은 Ilya Grigorik의 High Performance Browser Networking, Ivan Ristic의 OpenSSL Cookbook, Bulletproof SSL And TLS를 참고하세요.
경우에 따라 TLS는 성능을 향상시킬 수 있습니다. 이는 주로 HTTP/2가 실현되었기 때문입니다. 자세한 내용은 Chrome Dev Summit 2014에서 HTTPS 및 HTTP/2 성능에 관한 Chris Palmer의 강연을 참고하세요.
리퍼러 헤더
사용자 에이전트는 사용자가 HTTPS 사이트의 링크를 따라 다른 HTTP 사이트에 접속할 때 참조자 헤더를 전송하지 않습니다. 이 문제가 발생하는 경우 다음과 같은 방법으로 해결할 수 있습니다.
- 다른 사이트를 HTTPS로 마이그레이션해야 합니다. 피참조자 사이트가 이 가이드의 서버에서 HTTPS 사용 섹션을 완료한 경우 사이트의 링크를
http://에서https://로 변경하거나 프로토콜에 상대적인 링크를 사용할 수 있습니다. - 참조자 헤더와 관련된 다양한 문제를 해결하려면 새 참조자 정책 표준을 사용하세요.
광고 수익
광고를 표시함으로써 사이트의 수익을 내는 사이트 운영자는 HTTPS로 마이그레이션해도 광고 노출이 감소하지 않도록 하기를 원합니다. 그러나 혼합 콘텐츠 보안 문제로 인해 HTTP <iframe>은 HTTPS 페이지에서 작동하지 않습니다.
광고주가 HTTPS를 통해 게시할 때까지 사이트 운영자는 광고 수익 손실 없이 HTTPS로 마이그레이션할 수 없습니다. 하지만 사이트 운영자가 HTTPS로 마이그레이션할 때까지 광고주는 HTTPS를 통해 게시할 생각을 거의 갖지 않습니다.
HTTPS를 통해 광고 서비스를 제공하는 광고주를 사용하고 HTTPS를 전혀 지원하지 않는 광고주에게는 적어도 HTTPS를 옵션으로 제공하도록 요청하여 이 교착 상태를 타파할 수 있습니다. 많은 광고주가 제대로 상호 운용할 때까지 사이트 내 URL을 상대 URL로 만들기를 완료하는 것을 연기해야 할 수도 있습니다.