웹사이트 검색

CentOS 7에서 Nginx용 자체 서명 SSL 인증서를 생성하는 방법


소개

TLS(Transport Layer Security)와 이전 SSL(Secure Sockets Layer)은 일반 트래픽을 보호되고 암호화된 래퍼로 래핑하는 데 사용되는 웹 프로토콜입니다.

이 기술을 사용하여 서버는 외부 당사자가 메시지를 가로챌 가능성 없이 서버와 클라이언트 간에 안전하게 트래픽을 보낼 수 있습니다. 인증서 시스템은 또한 사용자가 연결 중인 사이트의 신원을 확인하는 데 도움을 줍니다.

이 가이드에서는 CentOS 7 서버에서 Nginx 웹 서버와 함께 사용할 자체 서명 SSL 인증서를 설정합니다.

참고: 자체 서명된 인증서는 서버와 모든 클라이언트 간의 통신을 암호화합니다. 그러나 웹 브라우저에 포함된 신뢰할 수 있는 인증 기관에서 서명하지 않았기 때문에 사용자는 인증서를 사용하여 서버의 ID를 자동으로 확인할 수 없습니다. 결과적으로 사용자는 사이트를 방문할 때 보안 오류를 보게 됩니다.

이러한 제한으로 인해 자체 서명된 인증서는 대중에게 서비스를 제공하는 프로덕션 환경에 적합하지 않습니다. 일반적으로 대체 통신 채널을 통해 인증서의 유효성에 대한 신뢰를 설정할 수 있는 단일 사용자 또는 소규모 사용자 그룹이 사용하는 중요하지 않은 서비스를 보안하거나 테스트하는 데 사용됩니다.

프로덕션 준비가 된 인증서 솔루션에 대해서는 CentOS 7 자습서에서 Let’s Encrypt 인증서로 Nginx 설정을 확인하세요.

전제 조건

이 자습서를 완료하려면 다음이 있어야 합니다.

  • CentOS 7 자습서의 초기 서버 설정에 설명된 대로 sudo 권한으로 구성된 루트가 아닌 사용자가 있는 CentOS 서버.
  • Nginx를 CentOS 7에 설치하는 방법에 설명된 대로 서버에 설치된 Nginx.

시작할 준비가 되면 sudo 사용자로 서버에 로그인하십시오.

1단계 - SSL 인증서 생성

TLS/SSL은 공개 인증서와 개인 키의 조합을 사용하여 작동합니다. SSL 키는 서버에서 비밀로 유지됩니다. 클라이언트로 전송되는 콘텐츠를 암호화하는 데 사용됩니다. SSL 인증서는 콘텐츠를 요청하는 모든 사람과 공개적으로 공유됩니다. 연결된 SSL 키로 서명된 콘텐츠를 해독하는 데 사용할 수 있습니다.

공개 인증서를 보유하는 데 사용할 수 있는 /etc/ssl/certs 디렉토리는 서버에 이미 존재해야 합니다. 개인 키 파일을 보관하려면 /etc/ssl/private 디렉토리도 만들어야 합니다. 이 키의 비밀성은 보안에 필수적이므로 무단 액세스를 방지하기 위해 권한을 잠그는 것이 중요합니다.

  1. sudo mkdir /etc/ssl/private
  2. sudo chmod 700 /etc/ssl/private

이제 다음을 입력하여 단일 명령으로 OpenSSL을 사용하여 자체 서명된 키 및 인증서 쌍을 생성할 수 있습니다.

  1. sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

일련의 질문을 받게 됩니다. 계속 진행하기 전에 명령에서 어떤 일이 발생하는지 살펴보겠습니다.

  • openssl: OpenSSL 인증서, 키 및 기타 파일을 만들고 관리하기 위한 기본 명령줄 도구입니다.
  • req: 이 하위 명령은 X.509 인증서 서명 요청(CSR) 관리를 사용하도록 지정합니다. "X.509\는 SSL 및 TLS가 키 및 인증서 관리를 위해 준수하는 공개 키 인프라 표준입니다. 새 X.509 인증서를 생성하려고 하므로 이 하위 명령을 사용합니다.
  • -x509: 일반적으로 발생하는 인증서 서명 요청을 생성하는 대신 자체 서명된 인증서를 만들고 싶다고 유틸리티에 알려 이전 하위 명령을 추가로 수정합니다.
  • -nodes: 이것은 OpenSSL이 암호로 인증서를 보호하는 옵션을 건너뛰도록 지시합니다. 서버가 시작될 때 사용자 개입 없이 파일을 읽을 수 있으려면 Nginx가 필요합니다. 다시 시작할 때마다 암호를 입력해야 하므로 암호를 사용하면 이러한 일이 발생하지 않습니다.
  • -days 365: 이 옵션은 인증서가 유효한 것으로 간주되는 기간을 설정합니다. 여기에서 1년으로 설정했습니다.
  • -newkey rsa:2048: 새 인증서와 새 키를 동시에 생성하도록 지정합니다. 이전 단계에서 인증서 서명에 필요한 키를 생성하지 않았으므로 인증서와 함께 생성해야 합니다. rsa:2048 부분은 2048비트 길이의 RSA 키를 만들도록 지시합니다.
  • -keyout: 이 줄은 OpenSSL에 생성 중인 개인 키 파일을 저장할 위치를 알려줍니다.
  • -out: 생성 중인 인증서를 어디에 둘지 OpenSSL에 알려줍니다.

위에서 설명한 대로 이러한 옵션은 키 파일과 인증서를 모두 생성합니다. 인증서에 정보를 올바르게 삽입하기 위해 서버에 대한 몇 가지 질문을 받게 됩니다.

프롬프트를 적절하게 작성하십시오. 가장 중요한 줄은 일반 이름(예: 서버 FQDN 또는 귀하의 이름)을 요청하는 줄입니다. 서버와 연결된 도메인 이름 또는 서버의 공용 IP 주소를 입력해야 합니다.

전체 프롬프트는 다음과 같습니다.

Output
Country Name (2 letter code) [XX]:US State or Province Name (full name) []:Example Locality Name (eg, city) [Default City]:Example Organization Name (eg, company) [Default Company Ltd]:Example Inc Organizational Unit Name (eg, section) []:Example Dept Common Name (eg, your name or your server's hostname) []:your_domain_or_ip Email Address []:webmaster@example.com

생성한 두 파일 모두 /etc/ssl 디렉토리의 적절한 하위 디렉토리에 배치됩니다.

OpenSSL을 사용할 때 클라이언트와 완전 순방향 보안 협상에 사용되는 강력한 Diffie-Hellman 그룹도 만들어야 합니다.

다음을 입력하면 됩니다.

  1. sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

이 작업은 몇 분 정도 걸릴 수 있지만 완료되면 구성에서 사용할 수 있는 /etc/ssl/certs/dhparam.pem에 강력한 DH 그룹이 생성됩니다.

2단계 - SSL을 사용하도록 Nginx 구성

CentOS의 기본 Nginx 구성은 상당히 구조화되어 있지 않으며 기본 구성 파일 내에 기본 HTTP 서버 블록이 있습니다. Nginx는 추가 구성을 위해 /etc/nginx/conf.d 디렉토리에서 .conf로 끝나는 파일을 확인합니다.

생성한 인증서 파일을 사용하여 콘텐츠를 제공하는 서버 블록을 구성하기 위해 이 디렉터리에 새 파일을 만듭니다. 그런 다음 HTTP 요청을 HTTPS로 리디렉션하도록 기본 서버 블록을 선택적으로 구성할 수 있습니다.

TLS/SSL 서버 블록 생성

/etc/nginx/conf.d 디렉터리에 ssl.conf라는 파일을 만들고 엽니다.

  1. sudo vi /etc/nginx/conf.d/ssl.conf

내부에서 server 블록을 열어 시작합니다. 기본적으로 TLS/SSL 연결은 포트 443을 사용하므로 수신 포트여야 합니다. server_name은 인증서를 생성할 때 일반 이름으로 사용한 서버의 도메인 이름 또는 IP 주소로 설정해야 합니다. 다음으로 ssl_certificate, ssl_certificate_keyssl_dhparam 지시문을 사용하여 생성한 SSL 파일의 위치를 설정합니다.

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name your_server_ip;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
}

다음으로 사이트의 보안을 강화할 몇 가지 추가 SSL 옵션을 추가합니다. 사용할 옵션은 Cipherlist.eu의 권장 사항입니다. 이 사이트는 널리 사용되는 소프트웨어에 사용하기 쉬운 암호화 설정을 제공하도록 설계되었습니다.

참고: Cipherlist.eu의 기본 권장 설정은 강력한 보안을 제공합니다. 경우에 따라 클라이언트 호환성을 희생해야 합니다. 이전 클라이언트를 지원해야 하는 경우 "예, 레거시/오래된 소프트웨어에서 작동하는 암호화 제품군을 제공합니다.\라는 레이블이 붙은 링크를 클릭하여 액세스할 수 있는 대체 목록이 있습니다.

두 주석 블록 사이의 위 구성에서 기본 제안 대신 호환성 목록을 사용할 수 있습니다. 사용하는 구성의 선택은 지원해야 하는 항목에 따라 크게 달라집니다.

수정할 구성이 몇 가지 있습니다. 먼저 resolver 지시문에 대한 업스트림 요청에 대해 선호하는 DNS 확인자를 추가할 수 있습니다. 이 가이드에 Google을 사용했지만 다른 기본 설정이 있는 경우 이를 변경할 수 있습니다.

마지막으로 잠시 시간을 내어 "사전 로드\ 기능에 대해 읽어보십시오. HSTS를 사전 로드하면 보안이 강화되지만 실수로 활성화하거나 잘못 활성화하면 광범위한 결과를 초래할 수 있습니다. 이 가이드에서는 설정을 사전 로드하지 않지만 다음을 수행할 수 있습니다. 의미를 이해했다고 확신하는 경우 수정하십시오.

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name your_server_ip;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    ########################################################################
    # from https://cipherlist.eu/                                            #
    ########################################################################
    
    ssl_protocols TLSv1.3;# Requires nginx >= 1.13.0 else use TLSv1.2
    ssl_prefer_server_ciphers on;
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
    ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
    ssl_session_timeout  10m;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off; # Requires nginx >= 1.5.9
    ssl_stapling on; # Requires nginx >= 1.3.7
    ssl_stapling_verify on; # Requires nginx => 1.3.7
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
    # Disable preloading HSTS for now.  You can use the commented out header line that includes
    # the "preload" directive if you understand the implications.
    #add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    ##################################
    # END https://cipherlist.eu/ BLOCK #
    ##################################
}

자체 서명된 인증서를 사용하고 있기 때문에 SSL 스테이플링이 사용되지 않습니다. Nginx는 단순히 경고를 출력하고 자체 서명된 인증서에 대한 스테이플링을 비활성화하며 계속해서 올바르게 작동합니다.

마지막으로 사이트에 대한 나머지 Nginx 구성을 추가합니다. 이것은 귀하의 필요에 따라 다를 것입니다. 예제의 기본 위치 블록에 사용된 지시어 중 일부를 복사하면 문서 루트와 일부 오류 페이지가 설정됩니다.

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name your_server_ip;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    ########################################################################
    # from https://cipherlist.eu/                                            #
    ########################################################################
    
    . . .
    
    ##################################
    # END https://cipherlist.eu/ BLOCK #
    ##################################

    root /usr/share/nginx/html;

    location / {
    }

    error_page 404 /404.html;
    location = /404.html {
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    }
}

완료되면 저장하고 종료합니다. 이렇게 하면 생성된 SSL 인증서를 사용하여 트래픽을 암호화하도록 Nginx가 구성됩니다. 지정된 SSL 옵션은 가장 안전한 프로토콜과 암호만 사용되도록 합니다. 이 예제 구성은 단순히 기본 Nginx 페이지를 제공하므로 필요에 맞게 수정할 수 있습니다.

HTTP에서 HTTPS로 리디렉션 만들기(선택 사항)

현재 구성에서 Nginx는 포트 443의 요청에 대해 암호화된 콘텐츠로 응답하지만 포트 80의 요청에 대해 암호화되지 않은 콘텐츠로 응답합니다. 즉, 사이트에서 암호화를 제공하지만 사용을 강요하지는 않습니다. 일부 사용 사례에서는 괜찮을 수 있지만 일반적으로 암호화를 요구하는 것이 좋습니다. 이는 암호와 같은 기밀 데이터가 브라우저와 서버 간에 전송될 수 있는 경우에 특히 중요합니다.

고맙게도 기본 Nginx 구성 파일을 사용하면 기본 포트 80 서버 블록에 지시문을 쉽게 추가할 수 있습니다. ssl.conf 시작 부분에 다음을 삽입하면 됩니다.

server {
    listen 80;
    listen [::]:80;
    server_name your_server_ip;
    return 301 https://$host$request_uri;
}

. . .

완료되면 파일을 저장하고 닫습니다. 이렇게 하면 들어오는 요청을 구성한 HTTPS 서버 블록으로 리디렉션하도록 포트 80(기본) 서버 블록의 HTTP를 구성합니다.

3단계 - Nginx에서 변경 사항 활성화

이제 변경을 완료했으므로 Nginx를 다시 시작하여 새 구성을 구현할 수 있습니다.

먼저 구성 파일에 구문 오류가 없는지 확인해야 합니다. 다음을 입력하면 됩니다.

  1. sudo nginx -t

모든 것이 성공하면 다음과 같은 결과가 나타납니다.

Output
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

처음에 경고를 확인하십시오. 앞서 언급했듯이 이 특정 설정은 자체 서명된 인증서가 SSL 스테이플링을 사용할 수 없기 때문에 경고를 표시합니다. 이것은 예상된 것이며 서버는 여전히 연결을 올바르게 암호화할 수 있습니다.

출력이 위와 일치하면 구성 파일에 구문 오류가 없습니다. Nginx를 안전하게 다시 시작하여 변경 사항을 구현할 수 있습니다.

  1. sudo systemctl restart nginx

구성한 SSL 설정을 구현하면서 Nginx 프로세스가 다시 시작됩니다.

4단계 - 암호화 테스트

이제 SSL 서버를 테스트할 준비가 되었습니다.

웹 브라우저를 열고 주소 표시줄에 https:// 다음에 서버의 도메인 이름 또는 IP를 입력합니다.

https://server_domain_or_IP

생성한 인증서는 브라우저의 신뢰할 수 있는 인증 기관 중 하나에서 서명하지 않았기 때문에 아래와 같은 무섭게 보이는 경고가 표시될 수 있습니다.

이는 정상적인 현상입니다. 귀하는 인증서의 암호화 측면에만 관심이 있으며 호스트 인증에 대한 제3자 검증에는 관심이 없습니다. "고급\을 클릭하면 호스트로 계속 진행할 수 있는 링크가 제공됩니다.

귀하의 사이트로 이동해야 합니다. 브라우저 주소 표시줄을 보면 부분 보안 표시가 표시됩니다. 이것은 그 위에 "x\가 있는 자물쇠이거나 느낌표가 있는 삼각형일 수 있습니다. 이 경우 이는 인증서를 확인할 수 없음을 의미합니다. 여전히 연결을 암호화하고 있습니다.

HTTP 요청을 HTTPS로 리디렉션하도록 Nginx를 구성한 경우 리디렉션이 올바르게 작동하는지 확인할 수도 있습니다.

http://server_domain_or_IP

동일한 아이콘이 표시되면 리디렉션이 올바르게 작동했음을 의미합니다.

결론

클라이언트 연결에 강력한 암호화를 사용하도록 Nginx 서버를 구성했습니다. 이렇게 하면 요청을 안전하게 처리할 수 있으며 외부인이 트래픽을 읽을 수 없습니다.