웹사이트 검색

일반적인 LetsEncrypt 오류를 수정하는 방법

소개

도메인 이름 또는 HTTPS 지원을 구성할 때 발생할 수 있는 일반적인 오류가 많이 있습니다. 도메인 이름 시스템인 DNS는 문제를 해결하기 어려울 수 있으며 오류가 스택의 다른 부분으로 인해 발생할 수 있는 경우 오류가 DNS에 있다고 결정적으로 귀속시키기는 어렵습니다.

악명 높은 "시스템 관리자의 하이쿠\는 다음과 같습니다.

It's not DNS
There's no way it's DNS
It was DNS

DNS 문제가 발생하는 가장 일반적인 경우는 서버에 대한 SSL/HTTPS 지원을 구성하려고 할 때입니다. 예를 들어 DigitalOcean DNS 또는 다른 공급자를 사용하는 경우입니다.

DNS 레코드

DNS는 어디서나 IP 주소를 사용하도록 요구하지 않고 your_domain.com과 같은 도메인 이름을 사용하여 웹 서버에 트래픽을 할당하고 전달하는 시스템입니다. 모든 도메인 등록 기관(DigitalOcean 포함)은 전반적으로 유사한 구문과 규칙을 사용하지만 DNS 레코드 관리를 위한 자체 인터페이스를 제공합니다.

DNS 레코드 유형에 대한 전체 개요는 An Introduction to DNS Terminology, Components, and Concepts를 참조하십시오.

가장 일반적인 DNS 레코드는 도메인 이름에서 서버 주소로의 기본 링크인 A 레코드입니다. 이 자습서에서는 서버 IP 주소에 정식 도메인 이름을 할당하기 위해 주로 A 레코드에 관심을 갖게 됩니다.

DigitalOcean의 DNS를 사용하는 경우 구성된 A 레코드는 다음과 같습니다.

DNS 레코드 업데이트 또는 마이그레이션

DNS를 업데이트하면 적용되는 데 약간의 시간이 걸릴 수 있습니다. 일반적으로 30분 미만이 소요되지만 변경 후 즉시 DNS를 테스트할 수 없기 때문에 오류가 오해의 소지가 있을 수 있습니다. DNS 변경 사항이 대부분 또는 모든 글로벌 이름 서버에 전파될 때까지 도메인에 대해 LetsEncrypt를 구성할 수 없습니다.

또한 whatsmydns.net과 같은 웹 사이트를 사용하여 DNS 조회에 사용되는 대부분의 글로벌 이름 서버 또는 전체에 DNS 변경 사항이 전파되었는지 여부를 테스트할 수 있습니다. DNS가 로컬에서 확인되지 않으면 대부분의 위치에서 작동하는지 확인할 수 있습니다. ISP는 이러한 서버 중 일부보다 업데이트 속도가 느릴 수 있지만 대부분의 경우 몇 분이면 됩니다.

DNS 변경 사항이 일부 서버에는 전파되었지만 다른 서버에는 전파되지 않았을 때 짧은 시간 내에 테스트하는 경우 원격 서버와 로컬 웹 브라우저에서 다른 결과를 받을 수 있어 더욱 혼란스러울 수 있습니다. ISP가 업데이트하기 전에 원격 서버 또는 물방울의 DNS가 업데이트되는 경우 이런 일이 발생할 수 있습니다. 이러한 오류를 배제하기 위해 nslookup 명령을 사용하여 특정 도메인 이름이 확인되는 IP 주소를 테스트할 수도 있습니다.

  1. nslookup linux-console.net



Output
…
Name:    linux-console.net
Addresses:  2606:4700::6810:b50f
          2606:4700::6810:b60f
          104.16.181.15
          104.16.182.15

이렇게 하면 로컬 결과가 전역 DNS 확인자와 일치하는지 확인할 수 있습니다.

더 긴 TTL 또는 Time-To-Live 값으로 DNS를 구성하면 업데이트하는 데 시간이 더 오래 걸립니다. 대부분의 도메인 이름 등록 기관에서 구성한 기본 TTL 값은 3600초 또는 1시간입니다. 일반적으로 A 레코드 바로 옆에 나열됩니다. TTL 값이 길수록 캐시 요청을 보다 효율적으로 수행할 수 있지만 DNS 변경 사항을 전파하는 데 시간이 더 오래 걸릴 수 있습니다. DNS를 변경하거나 테스트하려는 경우 TTL을 일시적으로 더 낮게 설정할 수 있습니다.

브라우저 오류 및 HTTPS 구성 문제

때때로 HTTPS와 DNS를 적절하게 구성했다고 생각할 수 있지만 귀하 또는 귀하의 사용자가 귀하의 웹사이트를 사용하려고 할 때 여전히 브라우저에서 오류를 수신하게 됩니다.

HTTP 오류 코드에 대한 일반 가이드는 Nginx Reverse Proxy를 참조하여 서버에서 실행 중인 다른 애플리케이션에 HTTPS 게이트웨이를 제공하고 게이트웨이가 잘못 구성되면 502 오류가 발생할 수 있습니다.

발생할 수 있는 또 다른 오류는 만료된 인증서입니다. 상업용 HTTPS 인증서와 달리 LetsEncrypt 인증서는 3개월 동안만 유효하며 만료 날짜 전에 인증서를 갱신하지 않으면 웹 사이트에 액세스하려는 모든 사람에게 오류가 발생합니다.

일반적으로 이렇게 하면 ERR_CERT_DATE_INVALID 오류가 발생합니다. Chrome에서는 다음과 같이 표시될 수 있습니다.

LetsEncrypt를 처음 구성할 때 인증서를 자동으로 갱신하는 백그라운드 프로세스를 설정해야 합니다. LetsEncrypt는 일반적으로 인증서가 만료될 때 이메일을 보냅니다.

그러나 이 프로세스가 잘못 구성되었거나 트리거에 실패한 경우 renew 인수를 사용하여 certbot을 다시 실행하여 수동으로 인증서를 언제든지 갱신할 수 있습니다.

  1. sudo certbot renew --nginx -d example.com -d www.example.com

인증서를 갱신한 후 웹 서버를 다시 시작해야 할 수도 있습니다. 웹 서버 구성을 변경하지 않은 경우 인증서를 갱신한 후 systemctl restart nginx를 실행하여 이를 안전하게 자동화할 수 있습니다(예: 예약된 cron에 추가).

혼합 콘텐츠

복잡한 스택을 HTTP에서 HTTPS로 마이그레이션하는 경우 일부 이미지 또는 기타 사이트 자산이 표시되지 않을 수 있습니다. 브라우저의 개발자 콘솔을 열면 다음 오류가 "혼합 콘텐츠\로 인한 것임을 알 수 있습니다.

이는 HTTPS를 통해 제공되는 웹사이트에 HTTP 콘텐츠를 포함해서는 안 된다는 기본 웹 정책 때문입니다. 이는 한 사이트가 두 개의 서로 다른 웹 서버에서 콘텐츠를 로드하거나 웹 애플리케이션이 Nginx 게이트웨이 뒤에서 제공되지만 SSL 전달이 제대로 작동하지 않는 경우에 발생할 수 있습니다.

Nginx를 사용 중이고 웹 서버 뒤에서 실행되는 다른 애플리케이션으로 트래픽을 전달하고 혼합 콘텐츠 경고가 발생하는 경우 location 블록에 몇 가지 추가 SSL 전달 구성을 추가할 수 있습니다.

…
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }

그 외에도 제공하는 모든 사이트가 HTTPS로 구성되어 있는지 확인하십시오. 혼합 콘텐츠 오류에 대한 MDN 설명서를 참조할 수도 있습니다.

LetsEncrypt의 Certbot 스크립트 실행 오류

Let’sEncrypt의 certbot 스크립트 자체를 실행하는 중에 오류가 발생할 수도 있습니다. 경우에 따라 이러한 오류에는 직접 따를 수 있는 설명 출력이 있습니다. 다른 것들은 덜 명확할 수 있습니다. 스크립트가 "시간 초과\이면 방화벽 문제일 가능성이 높으며 다음과 같이 표시됩니다.

  1. certbot --nginx -d example.com -d www.example.com



Output
Press Enter to Continue
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. example.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://example.com/.well-known/acme-challenge/EWbLNaAWwRZGM1UCqSvbIIxFFaoH09wPUEwVuYucCb0: 93 Timeout during connect (likely firewall problem)

일반적으로 시간 초과는 방화벽이 의도적으로 모든 트래픽을 삭제하기 때문에 전혀 응답을 받을 수 없지만 이에 대한 확인을 받지 못하는 연결로 인해 발생합니다. certbot을 실행하기 전에 방화벽이 포트 80 또는 443을 차단하지 않는지 확인하십시오. 일부 문서에서는 포트 80 또는 443 중 하나만 열면 된다고 제안하지만 오류를 배제하려면 둘 다 열어봐야 합니다. Nginx와 함께 UFW를 사용하는 경우 Nginx Full 구성을 활성화하여 이를 수행할 수 있습니다.

  1. sudo ufw allow 'Nginx Full'

방화벽 설정을 변경한 후 certbot을 다시 실행해 보십시오. 오류를 배제하기 위해 certbot을 연속해서 여러 번 재실행하면 다음과 같은 "실패한 유효성 검사 제한\ 메시지가 표시될 수 있습니다.

Output
too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/

이 경우 계정이 더 이상 속도 제한이 해제될 때까지 최대 1시간을 기다려야 합니다. 유효성 검사 제한 및 기타 certbot 오류에 대한 자세한 내용은 Certbot 설명서를 참조하십시오.

DNS, 시간 초과 또는 연결 문제와 관련되지 않은 다른 certbot 오류를 수신하는 경우 다음을 위해 certbot이 구성한 서버의 Python 환경 문제일 수 있습니다. 우선 실행합니다.

certbot을 제거하고 처음부터 다시 설치하면 거의 항상 해결할 수 있습니다. 이렇게 하려면 Ubuntu 22.04에서 Let's Encrypt로 Nginx를 보호하는 방법의 1단계를 따르십시오. 이는 기존 HTTPS 구성에 영향을 미치지 않으며 이를 유지 관리하고 갱신하는 데 사용되는 도구에만 영향을 미칩니다.

보이는 오류 없이 HTTPS가 작동하지 않음

Certbot과 DNS가 모두 올바르게 작동하는지 확인했지만 사이트가 HTTP 사용에서 HTTPS 사용으로 전환되지 않은 것 같으면 일반적으로 웹 서버 구성에 문제가 있는 것입니다. Certbot은 처음 실행될 때 웹 서버 구성 파일을 자동으로 업데이트하려고 시도합니다. 그렇기 때문에 일반적으로 Certbot 명령에 nginx를 지정하여 인증서를 검색한 후 업데이트할 웹 서버 구성의 종류를 알 수 있습니다. 그러나 기존 웹 서버 구성이 매우 복잡한 경우 Certbot이 HTTPS를 반영하도록 업데이트하지 못할 수 있으므로 직접 변경해야 합니다.

먼저 독립 실행형 모드의 2단계에서와 같이 웹 서버 구성 파일에 server_name 블록을 포함하여 인증서만 검색한 다음 나중에 HTTPS를 사용하도록 웹 서버를 수동으로 구성합니다.

기본 Nginx HTTPS 구성에는 다음과 같이 listen 443 ssl과 SSL 인증서 및 키에 대한 경로가 포함됩니다.

…
    listen 443 ssl;
    # RSA certificate
    ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;

    # Redirect non-https traffic to https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
…

Nginx를 구성하는 경우 웹 서버를 다시 시작하기 전에 유효성 검사를 위해 nginx -t를 실행하여 Nginx 구성에 대한 모든 변경 사항을 확인할 수 있음을 기억하십시오. 변경을 마치면 systemctl restart nginx를 실행하여 새 구성으로 Nginx를 다시 시작할 수 있습니다.

  1. sudo systemctl restart nginx

결론

LetsEncrypt의 목표는 모든 사람에게 어디서나 무료로 HTTPS를 제공하는 것입니다. 이것이 자동으로 작동하면 매우 유용하지만 그렇지 않으면 혼란스러울 수 있습니다. 특히 SSL 또는 DNS 구성 경험이 부족한 경우 더욱 그렇습니다. 이 자습서에서는 LetsEncrypt에 대한 몇 가지 일반적인 오류 시나리오와 문제 해결 단계를 검토했습니다.

다음으로 SSL 인증 기관에 대해 자세히 알아볼 수 있습니다.