신기한 Lets Encrypt/Certbot 및 nginx 구성 설계도 없음

LetsEncrypt는 인증서 발급 기구로 모든 사람에게 무료 ssl 인증서를 제공한다.나는 이미 그것을 사용한 지 여러 해가 되었지만, 처음에 나는 그들의 도구에 만족하지 않았기 때문에, 지금까지 나는 내가 작성한 클라이언트 (python의 또 다른 자작 클라이언트를 모방한 것) 를 사용해 왔다.
여러 해 동안, 그들의 공식 고객 (현재) 이름은 certbot 이고, 그 디자인은 분명히 나보다 더 좋다.나는 여전히 설정 옵션을 매개 변수로 실시간 명령에 전달함으로써 설정 옵션을 바꾸는 것을 좋아하지 않는다. 이것은 본문 뒤에서 볼 수 있지만, 이것은 생활 방식의 하나이다.
그럼에도 불구하고, 나는 그것으로 하여금 나의nginx 웹 서버를 제어하게 하고 싶지 않다. 특히nginx 플러그인이 무엇을 해야 한다고 주장하는 세부 사항이 매우 적기 때문이다.본고에서, 나는certbot와nginx를 어떻게 설정하여certbot의 '키' 를nginx에 넘기지 않고 서로 협력할 수 있는지 보여 드리겠습니다.

nginx certbot 사이펀과https 리디렉션
이 시스템의 첫 번째 부분은nginx 가상 호스트를 설치하여 포트 80의 모든 데이터를 처리하고 다음 두 가지를 완성하는 것이다.만약 요청이certbot 질문이라면, 이 요청을 포트8000에서 실행되는 상위 서버로 전송합니다.이 상위 서버 포트는 현재 존재하지 않지만, 잠시 후 이 포트에서certbot의 도전 응답 서버를 시작할 것입니다.그렇지 않으면, 모든 남은 유량을 포트 443의https로 다시 지정합니다.

upstream certbot {
  server 127.0.0.1:8000;
}
server {
  listen [::]:80;
  listen 80;
  server_name _;

  location /.well-known/acme-challenge {
    proxy_pass http://certbot;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }

  location / {
    return 301 https://$host$request_uri;
  }
}

일반적인 설정을 사용하는 경우 파일이 /etc/nginx/sites-available/에 있어야 합니다.nginx는 asciibetical에 프로필을 불러오기 때문에 마인01-http이라고 부릅니다.그런 다음 해당 위치 기호에서 /etc/nginx/sites-enabled/로 파일을 연결하여 활성화합니다.
업스트림 포트는 중요하지 않습니다. 사용하지 않은 포트일 수도 있습니다.또 주의해야 할 것은 완벽한 세계에서 방향을 바꾸는 것은 308(which redirects without changing method일 수 있지만, 모든 클라이언트가 그것을 정확하게 처리할 수 있을지 확실하지 않기 때문에 우리는 현재 301을 사용할 것이다.API를 위탁 관리하고 있지 않으면 그다지 중요하지 않다.
새 구성을 로드하려면 먼저

$ sudo nginx -t

그리고 시스템의 init 시스템을 사용하여 다시 불러옵니다.하면, 만약, 만약...

$ sudo systemctl reload nginx

증서를 발급하다
certbot이 설치되어 있지 않으면 설치하십시오.너도 계좌를 등록할 수 있지만, 만약 네가 등록하지 않는다면, 그것은 증서의 발급에 따라 발생할 것이라고 나는 믿는다.
실제 인증서를 발급하기 위해서 다음 내용을 포함하는 작은 셸 스크립트를 만드십시오.이전에 지정한 바와 같이 포트 8000에서 질문 응답 서비스를 시작합니다.

#!/bin/bash

sudo certbot certonly\
  --standalone\
  --http-01-port 8000\
  --deploy-hook 'systemctl reload nginx'\
  --cert-name MYDOMAIN.TLD\
  -d MYDOMAIN.TLD,www.MYDOMAIN.TLD,...

명령일 뿐이기 때문에, 이론적으로, 스크립트로 저장할 필요가 없이 직접 실행할 수 있습니다.불행하게도, 앞에서 언급한 바와 같이, 이 명령을 실행하는 것도 클라이언트 자체를 설정하고 있다.모든 설정, 특히 필드를 변경하려면 모든 설정을 완전히 다시 실행하고 변경할 매개 변수만 변경해야 한다(일반적으로 필드를 추가한다).만약 전체 명령을 통과하지 않았다면, 설정한 설정이 취소될 것이라고 생각했을 것입니다.따라서 스크립트로 저장하면 설정을 변경할 수 있고, 설정이 변하지 않도록 합니다.근데 설정이 뭘까요?
이론적으로, 인증서 이름은 당신이 원하는 모든 것일 수 있지만, 나는 당신의 메인 도메인을 사용하는 것을 권장합니다.-d는 등록할 이름 목록으로 쉼표로 구분됩니다.간단한 도메인과 www. 도메인을 등록하는 것을 잊지 마세요. 물론 당신이 필요로 하는 다른 호스트 이름도 있습니다.도메인에 어떤 내용이 있는지 여부는 중요하지 않습니다. 서버에 요청해야 합니다. 즉, DNS 공급자가 설정되어 있습니다.중요한 것은 설정된 포트가nginx 설정에서 사이펀에 사용되는 포트와 같은지 확인하는 것입니다.
당혹스러운 것은'배치 연결'도 재계약 연결을 설치하는 방식이다.우리의 첫 번째 문제에서, 우리는nginx를 다시 불러올 필요가 없다. 새 인증서를 사용할 수 있도록 설정된 것이 없기 때문에, 인증서를 다시 불러올 필요가 없다.단, 인증서를 자동으로 갱신할 때 원하는 방식으로 실행할 수 있도록 클라이언트를 설정하고 있다는 것을 다시 한 번 기억하십시오. 이 동작이 필요합니다.만약 당신이 그것을 설정하고 싶지 않다면, 괜찮습니다. 나중에 이 줄을 추가해서 인증서를 다시 사용하거나, 제가 잠시 후에 지적할 프로필을 통해 완성할 수 있습니다.
지금 스크립트를 실행합니다.완료되면 새 인증서의 경로를 출력해야 합니다.만약 당신이 그들을 다시 볼 필요가 있다면, 당신은 달리기를 할 수 있습니다 sudo certbot certificates.이 파일들은 /etc/letsencrypt/live/MYDOMAIN.TLD/에 있습니다.나중에 이 경로가 필요합니다.

DH 매개변수 생성하기
SSL을 구성하기 전에 서버에 Diffie-Hellman 매개 변수를 생성해야 합니다.이렇게 하면 다른 파일이 생성되므로 배치할 위치가 필요합니다.나는 보통 /etc/nginx/ssl/의nginx 설정에 새 디렉터리를 만든다.이렇게 하면 이 명령을 실행하여 매개변수 파일을 생성할 수 있습니다.

$ sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096

엄밀히 말하면 루트 사용자는 이 명령을 실행할 필요가 없지만, 필요하지 않으면 파일의 소유권을 변경해야 합니다.

nginx SSL 설정 구성
이 파일을 만든 후 새 파일을 추가합니다. 이번에는 /etc/nginx/conf.d/ssl.conf 입니다.안에 있는 물건을 넣다

ssl_certificate     /etc/letsencrypt/live/MYDOMAIN.TLD/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/MYDOMAIN.TLD/privkey.pem;
ssl_protocols       TLSv1.2 TLSv1.3;
ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_dhparam         /etc/nginx/ssl/dhparam.pem;
ssl_session_cache   shared:SSL:10m;
ssl_prefer_server_ciphers off;

나는 이러한 단독 파일에서 ssl 설정을 수집하는 것이 나중에 찾거나 편집할 수 있도록 매우 편리하다고 믿는다.즉, 기본nginx 설정이 ssl 설정을 설정했을 수도 있습니다.최고급nginx 설정 (보통 /etc/nginx/nginx.conf 을 편집하고 충돌하는 ssl 줄을 삭제해야 할 수도 있습니다.참고로, 제 최고급nginx 설정은 매우 간단합니다. 기본 설정만 설정하고 conf.d와 사이트를 사용하는 폴더에 파일을 불러옵니다.
세부 사항에 관해서는 Mozilla's suggestions를 기점으로 하고 SSL Labs를 사용하여 검사하고 보완합니다.nginx의 고민 중 하나는 ssl 파라미터가 (가상) 서버 블록에 계승되지만 헤더는 계승되지 않기 때문에 여기에 보안 헤더를 설정할 수 없다는 것이다.nginx 설정을 다시 테스트하고 다시 불러옵니다.

가상 호스트에서 SSL 사용
이 때 서버에 다른 가상 호스트를 설정했다면 포트 443에서 ssl을 사용할 수 있도록 조정하십시오.ssl 설정에서 제시한 ssl 상세한 정보를 포함할 필요가 없습니다.일반적인 사이트의 서버 블록은 일반적으로 다음과 같이 시작합니다.

server {
  listen [::]:443 ssl;
  listen 443 ssl;
  server_name MYHOST.MYDOMAIN.TLD;

Mojolicious application의 역방향 대리에 대한 우리의 건의the Cookbook에서 약간 수정)는

upstream myapp {
  server 127.0.0.1:8080;
}
server {
  listen [::]:443 ssl;
  listen 443 ssl;
  server_name MYHOST.MYDOMAIN.TLD;
  location / {
    proxy_pass http://myapp;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

8080 포트 (hypnotoad의 기본 포트) 에서 프로그램을 시작했고 reverse proxy mode 에 있는지 확인하십시오.내용을 바꾸면,nginx를 다시 테스트하고 불러오십시오.
새 인증서가 사용 중인지 확인하려면 사이트를 방문하십시오.크롬에서 녹색 자물쇠를 누르고, 밑에 있는 목록에서 인증서를 누르십시오.그것은 너에게 90일의 잉여 수명을 가진 증서를 제시해야 한다.

설정 검사
certbot에cron이나 시스템 작업이 설치되어 있습니다. 이 작업은 인증서 만료 30일 전이나 60일 후에 인증서 갱신을 시도합니다./etc/crontab 또는 /etc/cron.*/*의cron 파일을 확보하거나 systemctl list-timers의cron 파일check을 보기 위해서입니다.인증서를 업데이트하려고 시도하는 것을 알고 있습니다.
또한 배포/갱신 연결이 설치되어 있는지 확인해야 합니다.연장 설정에서 보실 수 있습니다. 제 연장 설정은 /etc/letsencrypt/renewal/MYDOMAIN.TLD.conf 입니다.회선을 검사하다

renew_hook = systemctl reload nginx

[renewalparams] 블록 아래에 있습니다.이 목록을 다시 필요로 한다면, 이 파일에는 관련 인증서의 경로도 포함되어 있습니다.설정 취소를 피하기 위해 끊임없이 다시 지정할 필요가 없기를 바랍니다.Grrr.

cron/timer 확인
cron이나 타이머는 매일 두 번 실행되도록 설정되어 있습니다.그래서 하루 정도 기다린 후에 letsencrypt 로그 (내 전화번호 /var/log/letsencrypt/letsencrypt.log 를 검사하면 갱신을 시도하지만 인증서가 낡지 않았다는 소식을 들을 수 있다.

INFO:certbot.renewal:Cert not yet due for renewal

60일 후에 새 인증서가 발급되었는지,nginx가 이 인증서를 사용하고 있는지 확인하는 달력을 설정해야 할 수도 있습니다.만약 문제가 발생한다면, 너는 30일의 시간을 가지고 그것을 복구할 것이다. 이 정도면 충분할 것이다.설령 네가 이렇게 하더라도, 오래된 인증서가 10일 남았을 때, 새 인증서로 바뀌었다 하더라도, letsencrypt의 전자메일을 받을 것이다. 이것은 네가 마지막으로 유용한 알림 검사이다. 왜냐하면, 남은 전자메일은 복구할 시간이 거의 없기 때문이다.

SSL 랩을 위한 테스트
모든 준비가 다 되었을 때, 당신은 SSL Labs 모든 정상을 확보하기 위해 마지막 검사를 할 수 있습니다.현재 내가 여기에 표시한 설정은 "A"등급을 받았다.

결론
나는 이 방법이 유용하고 비마법적인 방법이길 바란다. letsencypt를 당신의nginx 서버에 통합시켜 당신이 서버에 대한 제어를 포기하고 제어할 수 없는 블랙박스 스크립트로 변하게 하지 않기를 바란다.01http 가상 호스트가 이러한 도전을 해결했습니다. 갈고리를 배치하여nginx를 다시 불러옵니다. 단지 이것뿐입니다.간단하면서도 마법이 없다.
표지 사진은 CC BY 2.0가 권한을 부여한다EpicTop10.com