웹사이트 검색

상용 인증 기관에서 SSL 인증서를 설치하는 방법


소개

이 자습서에서는 신뢰할 수 있는 상용 인증 기관(CA)에서 SSL 인증서를 획득하고 설치하는 방법을 보여줍니다. SSL 인증서를 사용하면 웹 서버가 트래픽을 암호화하고 방문자에게 서버 ID를 검증하는 메커니즘을 제공할 수도 있습니다. 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 웹 서버에 SSL 인증서를 설치하는 방법을 다룹니다.

전제 조건

상용 CA에서 SSL 인증서를 얻으려면 몇 가지 전제 조건이 있습니다.

  • 등록된 도메인 이름입니다. 이 자습서에서는 전체적으로 example.com을 사용합니다. Freenom에서 도메인 이름을 구입하거나 선택한 도메인 등록 기관을 사용할 수 있습니다.\n
  • 도메인의 WHOIS 레코드에 있는 이메일 주소 중 하나 또는 도메인 자체의 "관리 유형\ 이메일 주소에 대한 액세스. SSL 인증서를 발급하는 인증 기관은 일반적으로 도메인에 있는 주소 중 하나로 확인 이메일을 보내 도메인 제어를 확인합니다. 도메인의 WHOIS 레코드 또는 도메인 자체의 일반 관리자 이메일 주소 확장 유효성 검사 인증서를 발급받으려면 무엇보다도 웹 사이트 소유자의 법적 신원을 확인하기 위한 서류를 CA에 제공해야 합니다.\n
  • 서버에 대해 설정된 DNS 레코드. DigitalOcean을 사용하는 경우 추가 방법에 대한 자세한 내용은 DNS 설명서를 참조하십시오.\n

이 튜토리얼에서는 Ubuntu 22.04 튜토리얼에 대한 이 초기 서버 설정에 따라 Ubuntu 22.04 서버 설정에 대한 구성 지침을 제공하며, 여기에는 sudo가 활성화된 루트가 아닌 사용자 및 방화벽이 포함됩니다. 대부분의 최신 Linux 버전은 유사하게 작동합니다.

또한 도메인에 대한 서버 블록(또는 Apache 가상 호스트) 다음에 Nginx 또는 Apache와 같은 웹 서버가 설치되어 있어야 합니다.

1단계 – 인증 기관 선택

사용할 인증 기관이 확실하지 않은 경우 고려해야 할 몇 가지 요소가 있습니다.

루트 인증서 프로그램 멤버십

가장 중요한 점은 선택한 CA가 가장 일반적으로 사용되는 운영 체제 및 웹 브라우저의 루트 인증서 프로그램의 구성원이라는 것입니다. 즉, "신뢰할 수 있는\ CA이며 루트 인증서는 일반 브라우저 및 기타 소프트웨어 웹 사이트의 SSL 인증서가 신뢰할 수 있는 CA에 의해 서명된 경우 해당 ID는 CA를 신뢰하는 소프트웨어에서 유효한 것으로 간주됩니다.

접하게 될 대부분의 상용 CA는 공통 루트 CA 프로그램의 구성원이지만 인증서를 구입하기 전에 확인하는 것이 나쁠 것은 없습니다. 예를 들어 Apple은 신뢰할 수 있는 SSL 루트 인증서 목록을 게시합니다.

인증서 유형

필요한 인증서 유형을 제공하는 CA를 선택했는지 확인하십시오. 많은 CA는 다양한 이름과 가격 구조로 이러한 인증서 유형의 변형을 제공합니다. 다음은 각 유형에 대한 간단한 설명입니다.

  • 단일 도메인: 단일 도메인에 사용됩니다. example.com. www.example.com과 같은 추가 하위 도메인은 포함되지 않습니다.
  • 와일드카드: 도메인 및 하위 도메인에 사용됩니다. 예를 들어 *.example.com에 대한 와일드카드 인증서는 www.example.comstore.example.com<에도 사용할 수 있습니다. /리>
  • 다중 도메인: SAN 또는 UC 인증서로 알려져 있으며 주체 대체 이름 필드에 추가된 여러 도메인 및 하위 도메인과 함께 사용할 수 있습니다. 예를 들어 단일 다중 도메인 인증서는 example.com, www.example.comexample.net

앞서 언급한 인증서 유형 외에도 CA에서 제공하는 다양한 수준의 유효성 검사가 있습니다.

  • 도메인 유효성 검사(DV): DV 인증서는 CA가 요청자가 문제의 도메인을 소유하거나 제어함을 확인한 후에 발급됩니다.
  • 조직 유효성 검사(OV): OV 인증서는 발급 CA가 요청자의 법적 신원을 확인한 후에만 발급될 수 있습니다.
  • 확장 유효성 검사(EV): EV 인증서는 발급 CA가 무엇보다도 엄격한 지침에 따라 요청자의 법적 신원을 확인한 후에만 발급될 수 있습니다. 이 유형의 인증서의 목적은 사이트 방문자에게 조직 ID의 정당성에 대한 추가 보증을 제공하는 것입니다. EV 인증서는 단일 또는 다중 도메인일 수 있지만 와일드카드는 아닙니다.

추가 기능

많은 CA는 다른 SSL 인증서 발급 공급업체와 차별화하기 위해 매우 다양한 "보너스\ 기능을 제공합니다. 이러한 기능 중 일부는 결국 비용을 절감할 수 있으므로 이전에 제공 사항과 요구 사항을 비교하는 것이 중요합니다. 주의해야 할 기능의 예로는 무료 인증서 재발급 또는 www. 및 도메인 기본 이름(예: www.example.com )에 대해 작동하는 단일 도메인 가격 인증서가 있습니다. 와 example.com의 SAN

2단계 – CSR 및 개인 키 생성

전제 조건을 정렬하고 필요한 인증서 유형을 알고 나면 인증서 서명 요청(CSR) 및 개인 키를 생성할 차례입니다.

Apache HTTP 또는 Nginx를 웹 서버로 사용하려는 경우 openssl 명령을 사용하여 웹 서버에서 개인 키와 CSR을 생성할 수 있습니다. 이 자습서에서는 모든 관련 파일을 홈 디렉터리에 보관할 수 있지만 서버의 안전한 위치에 자유롭게 저장할 수 있습니다.

example.com.key라는 개인 키와 example.com.csr라는 CSR을 생성하려면 다음 명령을 실행합니다(example.com 를 도메인 이름으로 변경):

  1. openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr

이 시점에서 인증서 요청에 포함될 여러 줄의 정보를 입력하라는 메시지가 표시됩니다. 가장 중요한 부분은 일반 이름 필드로, 인증서를 사용하려는 이름과 일치해야 합니다(예: example.com, www). example.com 또는 (와일드카드 인증서 요청의 경우) *.example.com. OV 또는 EV 인증서를 받을 계획이라면 다른 모든 필드가 조직 또는 비즈니스 세부 정보를 정확하게 반영하는지 확인하십시오. "챌린지 암호\를 제공할 필요가 없습니다.

예를 들어:

Output
Country 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 []:sammy@example.com 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에 보낼 파일입니다.

  1. ls example.com*
Output
example.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 확장자를 사용하여 인증서 이름을 지정합니다. example.com.crt, 중간 인증서 이름을 intermediate.crt로 지정합니다.

이제 인증서를 웹 서버에 설치할 준비가 되었지만 먼저 방화벽을 일부 변경해야 할 수 있습니다.

4단계 – HTTPS를 허용하도록 방화벽 업데이트

Ubuntu 22.04 설정 가이드에서 권장하는 대로 ufw 방화벽을 활성화한 경우 HTTPS 트래픽을 허용하도록 설정을 조정해야 합니다. Nginx와 Apache는 모두 설치 시 ufw로 몇 개의 프로필을 등록합니다.

다음을 입력하여 현재 설정을 볼 수 있습니다.

  1. sudo ufw status

Nginx HTTP 또는 Apache만 포함된 출력을 수신하는 경우 HTTP 트래픽만 웹 서버에 허용됩니다.

Output
Status: 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 프로필 허용량을 삭제하세요.

  1. sudo ufw allow 'Nginx Full'
  2. sudo ufw delete allow 'Nginx HTTP'

그러면 다음과 같은 결과가 생성됩니다.

  1. sudo ufw status
Output
Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6)

마지막 단계에서 인증서를 설치합니다.

5단계 – 서버에 인증서 설치

선택한 CA에서 인증서를 획득한 후 웹 서버에 설치해야 합니다. 여기에는 웹 서버 소프트웨어 구성에 SSL 관련 몇 줄을 추가하는 작업이 포함됩니다.

이 튜토리얼에서는 Ubuntu 22.04에서 Nginx 및 Apache 구성을 다루지만 대부분의 최신 Linux 버전도 유사하게 작동합니다. 이 자습서에서는 다음과 같은 가정도 합니다.

  • 개인 키, SSL 인증서 및 해당되는 경우 CA의 중간 인증서는 /home/sammy의 홈 디렉토리에 있습니다.
  • 비공개 키는 example.com.key입니다
  • SSL 인증서 이름은 example.com.crt
  • 입니다.
  • 공급자가 반환한 CA 중간 인증서는 intermediate.crt라는 파일에 있습니다.

참고: 프로덕션 환경에서 이러한 파일은 웹 서버 프로세스(일반적으로 루트)만 액세스할 수 있는 위치에 저장해야 하며 개인 키는 안전하게 보관해야 합니다. 예를 들어 Let’s Encrypt는 생성한 인증서를 /etc/letsencrypt에 저장합니다. 프로덕션 예제는 다중 서버 구성의 복잡성으로 인해 다양합니다.

엔진엑스

다음은 Nginx에서 SSL 인증서를 수동으로 배포하는 단계입니다.

CA가 중간 인증서만 반환한 경우 인증서와 CA의 중간 인증서가 포함된 단일 "연결된\ 인증서 파일을 생성해야 합니다.

인증서 파일이 example.com.crt라고 가정하면 cat 명령을 사용하여 파일을 함께 추가하여 example.com.chained라는 결합된 파일을 만들 수 있습니다. .crt:

  1. cat example.com.crt intermediate.crt > example.com.chained.crt

nano 또는 즐겨 사용하는 텍스트 편집기를 사용하여 편집을 위해 기본 Nginx 서버 블록 파일을 엽니다.

  1. sudo nano /etc/nginx/sites-enabled/default

listen 지시문을 찾아 listen 443 ssl로 수정합니다.

…
server {
    listen 443 ssl;
…

그런 다음 동일한 서버 블록 내에서 server_name 지시문을 찾고 해당 값이 인증서의 일반 이름과 일치하는지 확인하십시오. 또한 ssl_certificatessl_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를 사용하여 구성을 확인할 수 있습니다.

  1. sudo nginx -t

문제가 없으면 Nginx를 다시 시작하여 HTTPS를 통한 SSL을 활성화합니다.

  1. sudo systemctl restart nginx

HTTPS를 통해 사이트에 액세스하여 테스트해 보세요. https://example.com. 또한 HTTP를 통해 연결을 시도하고 싶을 것입니다. http://example.com은 리디렉션이 제대로 작동하는지 확인합니다.

아파치

다음은 Apache에서 SSL 인증서를 수동으로 배포하는 단계입니다.

nano 또는 선호하는 텍스트 편집기를 사용하여 기본 Apache 가상 호스트 파일을 열어 편집합니다.

  1. sudo nano /etc/apache2/sites-available/000-default.conf

항목을 찾아 웹 서버가 포트 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 모듈을 활성화합니다.

  1. sudo a2enmod ssl

이제 Apache를 다시 시작하여 새 구성을 로드하고 HTTPS를 통해 TLS/SSL을 활성화합니다.

  1. sudo systemctl restart apache2

HTTPS를 통해 사이트에 액세스하여 테스트해 보세요. https://example.com. 또한 HTTP를 통해 연결을 시도하고 싶을 것입니다. http://example.com은 리디렉션이 제대로 작동하는지 확인합니다.

결론

이 자습서에서는 상용 CA에서 SSL 인증서를 구매해야 하는 시기를 결정하는 방법과 사용 가능한 옵션을 비교 및 대조하는 방법을 배웠습니다. 또한 HTTPS 지원을 위해 Nginx 또는 Apache를 구성하는 방법과 해당 구성을 프로덕션에 맞게 조정하는 방법도 배웠습니다.

다음으로 로드 밸런서로 작업할 때와 같은 다른 SSL 사용 사례에 대해 읽을 수 있습니다.