소개
이 튜토리얼에서는 신뢰할 수 있는 상업용 인증 기관(CA)으로부터 SSL 인증서를 획득하고 설치하는 방법을 안내합니다. SSL 인증서를 사용하면 웹 서버가 트래픽을 암호화할 수 있으며, 방문자에게 서버 신원을 검증할 수 있는 메커니즘도 제공합니다. SSL을 사용하는 웹 사이트는 https://
프로토콜을 통해 액세스됩니다.
2010년대 중반 이전에는 많은 소규모 웹 사이트가 항상 SSL 또는 HTTPS를 사용하지 않았습니다. 그 이후로 보안 기대치가 증가하면서, Let’s Encrypt 프로젝트가 규모에 맞는 무료 신뢰할 수 있는 SSL 인증서를 제공하여 거의 모든 사람이 필요에 따라 HTTPS를 사용할 수 있게 했습니다.
그러나 Let’s Encrypt의 인증서에는 일부 제한 사항이 있습니다. 이 인증서는 매 3개월마다 만료되며, 일반적으로 작동하는 자동 갱신 스크립트를 사용해야 하며, 이를 할 수 없는 환경에서는 사용하기 어려울 수 있습니다. Let’s Encrypt는 또한 웹 존재의 법적 소유권을 확인하는 확장 검증 인증서나 웹 사이트의 각 가능한 하위 도메인(예: shop.example.com)마다 수동으로 등록하지 않아도 자동으로 일치하는 와일드카드 인증서를 제공하지 않습니다.
대부분의 사용자에게는 이러한 것들이 중요한 제한 사항이 아닐 것입니다. Let’s Encrypt는 많은 개인 및 상업 웹 사이트에 대한 인기 있는 옵션입니다. 그러나 특정 기업 소프트웨어 요구 사항이 있거나 매우 큰 상업적 운영이 있는 경우 상업용 CA에서 인증서를 구매하는 것을 고려해야 합니다.
이 자습서에서는 신뢰할 수 있는 인증 기관에서 SSL 인증서를 선택하고 배포하는 방법에 대해 다룹니다. SSL 인증서를 획득한 후, 이 자습서에서는 Nginx 및 Apache 웹 서버에 설치하는 방법을 다룰 것입니다.
필수 조건
상업용 CA에서 SSL 인증서를 획득하기 위한 몇 가지 필수 조건이 있습니다:
-
등록된 도메인 이름. 이 자습서에서는
example.com
을 사용합니다. Namecheap에서 도메인 이름을 구입하거나 Freenom으로 무료로 얻을 수 있거나 원하는 도메인 등록기를 사용할 수 있습니다. -
도메인의 WHOIS 레코드 중 하나의 이메일 주소에 액세스하거나 도메인 자체의 “관리자 유형” 이메일 주소에 액세스합니다. SSL 인증서를 발급하는 인증 기관은 일반적으로 도메인의 WHOIS 레코드 중 하나의 주소 또는 도메인 자체의 일반적인 관리자 이메일 주소로 확인 이메일을 보내서 도메인 제어를 확인합니다. 확장 유효성 인증서를 발급받으려면 웹 사이트 소유자의 법적 신원을 확인하는 문서를 포함하여 기타 사항을 인증 기관에 제공해야 합니다.
-
서버를 위해 DNS 레코드를 설정합니다. DigitalOcean을 사용하는 경우, 추가 방법에 대한 자세한 내용은 DNS 문서를 참조하십시오.
이 자습서는 Ubuntu 22.04 서버의 구성 지침을 제공합니다. 이 자습서에 따라 Ubuntu 22.04용 초기 서버 설정을 완료하여 sudo가 활성화된 non-root 사용자와 방화벽을 설정할 수 있습니다. 대부분의 최신 Linux 버전은 비슷하게 작동합니다.
또한, Nginx나 Apache와 같은 웹 서버를 설치해야 합니다. Ubuntu 22.04에 Nginx 설치하는 방법 또는 Ubuntu 22.04에 Apache 웹 서버 설치하는 방법을 따라 설치해야 합니다. 도메인에 대한 서버 블록(또는 Apache 가상 호스트)이 있는지 확인하십시오.
단계 1 – 인증 기관 선택
인증 기관을 선택할 때 고려해야 할 몇 가지 요소가 있습니다.
루트 인증서 프로그램 멤버십
가장 중요한 점은 선택한 CA가 가장 일반적으로 사용되는 운영 체제 및 웹 브라우저의 루트 인증서 프로그램의 회원인 것이며, 즉 “신뢰할 수 있는” CA이며, 그 루트 인증서가 일반적인 브라우저 및 기타 소프트웨어에서 신뢰받는다는 것입니다. 웹사이트의 SSL 인증서가 신뢰할 수 있는 CA에 의해 서명되면, 해당 CA를 신뢰하는 소프트웨어에서 신원이 유효하다고 간주됩니다.
대부분의 상용 CA는 일반적인 루트 CA 프로그램의 회원일 것이지만, 인증서 구매 전에 확인하는 것이 좋습니다. 예를 들어, Apple은 신뢰할 수 있는 SSL 루트 인증서 목록을 공개하고 있습니다.
인증서 유형
요구하는 인증서 유형을 제공하는 CA를 선택하십시오. 많은 CA가 이러한 인증서 유형의 변형을 다양한 이름과 가격 구조로 제공합니다. 각 유형의 간단한 설명은 다음과 같습니다:
- 단일 도메인: 단일 도메인에 사용되는 인증서, 예:
example.com
. 추가 서브도메인(예:www.example.com
)은 포함되지 않습니다. - 와일드카드: 도메인 및 해당 서브도메인에 사용되는 인증서입니다. 예를 들어,
*.example.com
에 대한 와일드카드 인증서는www.example.com
및store.example.com
에도 사용할 수 있습니다. - 다중 도메인: SAN 또는 UC 인증서로 알려져 있으며, 여러 도메인 및 하위 도메인을 Subject Alternative Name 필드에 추가하여 사용할 수 있습니다. 예를 들어, 단일 다중 도메인 인증서는
example.com
,www.example.com
, 및example.net
과(와) 같이 사용할 수 있습니다.
앞서 언급한 인증서 유형 외에도, CA가 제공하는 다양한 유효성 검사 수준이 있습니다:
- 도메인 유효성 검사 (DV): DV 인증서는 CA가 요청자가 해당 도메인을 소유하거나 제어하는지를 확인한 후 발급됩니다
- 조직 유효성 검사 (OV): OV 인증서는 발급 CA가 요청자의 법적 신원을 확인한 후에만 발급될 수 있습니다
- 확장 유효성 검사 (EV): EV 인증서는 발급 CA가 요청자의 법적 신원 및 기타 사항을 엄격한 지침에 따라 확인한 후에만 발급될 수 있습니다. 이 유형의 인증서의 목적은 사이트 방문자에게 귀하의 조직 신원의 정당성에 대한 추가적인 보증을 제공하는 것입니다. EV 인증서는 단일 또는 다중 도메인일 수 있지만 와일드카드는 아닙니다
추가 기능
많은 CA는 SSL 인증서 발급 업체와 구분하기 위해 다양한 “보너스” 기능을 제공합니다. 이러한 기능 중 일부는 비용을 절약할 수 있으므로 구매 전에 귀하의 요구 사항을 고려하는 것이 중요합니다. 찾아볼 기능 예시로는 무료 인증서 재발급이나 단일 도메인 가격의 인증서 등이 있습니다. www.
와 도메인 기본 이름을 포함한 인증서의 SAN이 example.com
일 경우를 들 수 있습니다.
단계 2 – CSR 및 개인 키 생성
사전 준비 사항을 정리했고 필요한 인증서 유형을 알게 되었다면, 이제 인증서 서명 요청(CSR)과 개인 키를 생성할 시간입니다.
웹 서버로 Apache HTTP 또는 Nginx를 사용할 계획이라면, 웹 서버에서 개인 키 및 CSR을 생성하기 위해 openssl
명령을 사용할 수 있습니다. 이 튜토리얼에서는 관련 파일을 홈 디렉토리에 모두 저장할 수 있지만, 서버의 안전한 위치에 저장하십시오:
개인 키인 example.com.key
와 CSR인 example.com.csr
을 생성하려면 다음 명령을 실행하십시오 (도메인 이름을 example.com
으로 바꿉니다):
- openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr
이 시점에서 여러 줄의 정보를 입력해야 하며 이는 인증서 요청에 포함될 것입니다. 가장 중요한 부분은 Common Name
필드이며, 이는 인증서에 사용할 이름과 일치해야 합니다. 예를 들어, example.com
, www.example.com
, 또는 (와일드카드 인증서 요청의 경우) *.example.com
과 같이 사용하고자 하는 이름과 일치해야 합니다. OV 또는 EV 인증서를 획득할 계획이라면 다른 모든 필드가 귀하의 조직 또는 비즈니스 세부 정보를 정확하게 반영하도록 해야 합니다. “도전 암호”를 제공하는 것은 필요하지 않습니다.
예를 들면:
OutputCountry Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:[email protected]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
이렇게 하면 .key
및 .csr
파일이 생성됩니다. .key
파일은 개인 키이며 안전하게 보관되어야 합니다. .csr
파일은 SSL 인증서를 요청하기 위해 CA에 보낼 파일입니다.
- ls example.com*
Outputexample.com.csr example.com.key
CA에 인증서 요청을 제출할 때 CSR을 복사하여 붙여넣어야 합니다. CSR의 내용을 출력하려면 cat
을 사용하십시오:
cat example.com.csr
이제 CA에서 인증서를 구매할 준비가 되었습니다.
단계 3 – 인증서 구매 및 획득
다양한 상업용 CA 공급업체가 있으며, 귀하의 설정에 가장 적합한 옵션을 비교하고 대조할 수 있습니다. 예를 들어, Namecheap은 SSL 인증서 재판매업체로 작동하며, 지난 과거에는 최적의 가치를 제공하기 위해 상위 CA 공급업체를 변경한 적이 있습니다. 현재로서는 Comodo CA에서 인증서를 제공하고 있습니다. 2022년 12월 기준으로 다음은 그들의 제공 사항 중 일부입니다:
선택을 마친 후에는 이전 단계에서 생성한 CSR을 업로드해야 합니다. CA 공급업체는 또한 “승인자” 단계를 갖게 될 것이며, 이는 인증서를 얻고자 하는 도메인의 WHOIS 레코드에 있는 주소 또는 관리자 유형 주소로 검증 요청 이메일을 보낼 것입니다.
인증서를 승인한 후, 해당 인증서는 명명된 관리자에게 이메일로 발송됩니다. 이를 개인 키 및 CSR을 생성한 위치와 동일한 위치에 서버에 복사하고 저장해야 합니다. 인증서는 도메인 이름 및 .crt
확장자로 명명하고 중간 인증서는 intermediate.crt
로 명명하십시오.
인증서는 이제 웹 서버에 설치할 준비가 되었지만, 먼저 방화벽에 몇 가지 변경을 가해야 할 수 있습니다.
단계 4 – 방화벽 업데이트로 HTTPS 허용
ufw
방화벽이 우분투 22.04 설정 가이드에서 권장하는 대로 활성화되어 있는 경우 HTTPS 트래픽을 허용하도록 설정을 조정해야 합니다. Nginx와 Apache는 설치 시 ufw
에 몇 가지 프로필을 등록합니다.
다음을 입력하여 현재 설정을 볼 수 있습니다:
- sudo ufw status
출력에 Nginx HTTP
또는 Apache
만 포함된 경우 웹 서버로의 HTTP 트래픽만 허용됩니다:
OutputStatus: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)
HTTPS 트래픽을 추가로 허용하려면 Nginx Full
또는 Apache
Full 프로필을 허용하고 중복된 HTTP 프로필을 삭제하십시오:
- sudo ufw allow 'Nginx Full'
- sudo ufw delete allow 'Nginx HTTP'
이렇게하면 다음과 같은 결과가 나올 것입니다:
- sudo ufw status
OutputStatus: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx Full ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx Full (v6) ALLOW Anywhere (v6)
마지막 단계에서 인증서를 설치해야 합니다.
서버에 인증서 설치 단계
원하는 CA로부터 인증서를 획득한 후 웹 서버에 설치해야 합니다. 이는 웹 서버 소프트웨어 구성에 몇 가지 SSL 관련 라인을 추가하는 것을 포함합니다.
이 튜토리얼은 우분투 22.04에서 Nginx와 Apache를 구성하는 방법을 다루지만, 대부분의 최신 리눅스 버전에서 비슷하게 작동합니다. 이 튜토리얼은 또한 다음을 가정합니다:
- 개인 키, SSL 인증서 및 해당하는 경우 CA의 중간 인증서가 홈 디렉토리인
/home/sammy
에 있습니다. - 개인 키의 이름은
example.com.key
입니다. - SSL 인증서는
example.com.crt
- 귀하의 제공 업체에서 반환한 CA 중간 인증서는
intermediate.crt
참고: 실제 환경에서는 이러한 파일을 웹 서버 프로세스(일반적으로 root
)만 액세스 할 수 있는 위치에 저장하고 개인 키는 안전한 곳에 보관해야 합니다. 예를 들어, Let’s Encrypt는 생성된 인증서를 /etc/letsencrypt
에 저장합니다. 프로덕션 예제는 다중 서버 구성의 복잡성 때문에 다를 수 있습니다.
Nginx
이것은 Nginx에 SSL 인증서를 수동으로 배포하는 단계입니다.
CA가 중간 인증서만 반환한 경우, 인증서 및 CA 중간 인증서를 포함하는 단일 “체인” 인증서 파일을 작성해야 합니다.
인증서 파일이 example.com.crt
인 경우, cat
명령을 사용하여 파일을 연결하여 example.com.chained.crt
라는 결합 파일을 만들 수 있습니다:
- cat example.com.crt intermediate.crt > example.com.chained.crt
nano
또는 기호에 따라 기본 Nginx 서버 블록 파일을 열어 편집합니다:
- sudo nano /etc/nginx/sites-enabled/default
listen
지시문을 찾아 수정하여 listen 443 ssl
로 변경하세요:
…
server {
listen 443 ssl;
…
다음으로, 동일한 서버 블록 내에서 server_name
지시문을 찾고 해당 값이 인증서의 공통 이름과 일치하는지 확인하십시오. 또한 인증서 및 개인 키 파일의 경로를 지정하기 위해 ssl_certificate
및 ssl_certificate_key
지시문을 추가하십시오:
…
server_name example.com;
ssl_certificate /home/sammy/example.com.chained.crt;
ssl_certificate_key /home/sammy/example.com.key;
…
가장 안전한 SSL 프로토콜과 암호만 허용하려면 다음 줄을 파일에 추가하십시오:
…
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
…
마지막으로, HTTP 요청을 기본적으로 HTTPS로 리디렉션하려면 파일 맨 위에 추가적인 서버 블록을 추가할 수 있습니다:
server {
listen 80;
server_name example.com;
rewrite ^/(.*) https://example.com/$1 permanent;
}
…
파일을 저장하고 닫으십시오. 만약 nano
를 사용 중이라면, Ctrl+X
를 누르고 프롬프트가 나타나면 Y
를 누르고 Enter를 누르십시오.
Nginx를 다시 시작하기 전에 nginx -t
를 사용하여 구성을 유효성 검사할 수 있습니다:
- sudo nginx -t
문제가 없다면, SSL을 HTTPS로 활성화하기 위해 Nginx를 다시 시작하십시오:
- sudo systemctl restart nginx
HTTPS를 통해 사이트에 액세스하여 작동 여부를 확인하십시오. 예: https://example.com
. 또한 리디렉션이 올바르게 작동하는지 확인하기 위해 HTTP를 통해 연결해 보려고 할 것입니다. 예: http://example.com
.
아파치
아파치에서 SSL 인증서를 수동으로 배포하는 단계입니다.
nano
또는 선호하는 텍스트 편집기를 사용하여 기본 아파치 가상 호스트 파일을 엽니 다:
- sudo nano /etc/apache2/sites-available/000-default.conf
<VirtualHost *:80>
항목을 찾고 웹 서버가 포트 443
에서 청취하도록 수정하십시오:
…
<VirtualHost *:443>
…
다음으로, ServerName
지시문을 추가하십시오. 이미 존재하지 않는 경우:
…
ServerName example.com
…
그런 다음 다음 줄을 추가하여 인증서 및 키 경로를 지정하십시오:
…
SSLEngine on
SSLCertificateFile /home/sammy/example.com.crt
SSLCertificateKeyFile /home/sammy/example.com.key
SSLCACertificateFile /home/sammy/intermediate.crt
…
이 시점에서 서버가 HTTPS(포트 443)에서만 수신 대기하도록 구성되어 있으므로 HTTP(포트 80)로의 요청은 처리되지 않습니다. HTTP 요청을 HTTPS로 리디렉션하려면 파일 상단에 다음을 추가하십시오(두 곳 모두 이름을 대체하십시오):
<VirtualHost *:80>
ServerName example.com
Redirect permanent / https://example.com/
</VirtualHost>
…
파일을 저장하고 닫으십시오. nano
를 사용하는 경우 Ctrl+X
를 누르고, 그런 다음 프롬프트가 표시되면 Y
를 입력하고 Enter 키를 누릅니다.
다음 명령을 실행하여 Apache SSL 모듈을 활성화하십시오:
- sudo a2enmod ssl
이제 새 구성을 로드하고 HTTPS를 통한 TLS/SSL을 활성화하려면 Apache를 다시 시작하십시오.
- sudo systemctl restart apache2
HTTPS를 통해 사이트에 액세스하여 테스트하십시오. 예: https://example.com
. 리디렉션이 올바르게 작동하는지 확인하려면 HTTP를 통해 연결도 시도하십시오. 예: http://example.com
.
결론
이 튜토리얼에서는 상업용 CA에서 SSL 인증서를 구매해야 하는 경우를 판단하는 방법과 사용 가능한 옵션을 비교하는 방법을 배웠습니다. 또한 Nginx 또는 Apache를 HTTPS 지원으로 구성하는 방법과 그 구성을 프로덕션 환경에 맞게 조정하는 방법도 배웠습니다.
다음으로 로드 밸런서와 작업할 때와 같은 다른 SSL 사용 사례에 대해 읽어 보는 것이 좋습니다.