Let’s Encrypt 인증서 갱신 실패 해결: Certbot·DNS·포트 80·Nginx 점검

그림: 인증서 만료 확인부터 도메인 검증, 시험 갱신, 웹 서버 재적용까지의 점검 순서입니다.

Let’s Encrypt 인증서 갱신에 실패했다면 곧바로 재설치를 반복하지 마세요. 실패 원인은 만료 시각, 도메인 검증 방식, DNS·포트 80 접근, Certbot 설정, Nginx 재적용 중 어디에 있는지 순서대로 확인해야 합니다. 이 글은 운영 서버에서 장애 범위를 좁히는 절차를 다룹니다.

1. 만료와 실제 제공 인증서를 구분한다

서버에 저장된 인증서 만료일과 사용자에게 보이는 인증서 만료일이 다를 수 있습니다. sudo certbot certificates로 Certbot 관리 인증서를 확인하고, 브라우저 또는 openssl s_client -connect example.com:443 -servername example.com로 서비스가 제공하는 인증서를 확인하세요. 실제 도메인으로 example.com을 바꿉니다. 프록시나 로드 밸런서가 앞에 있다면 인증서 종료 지점이 어디인지 먼저 파악해야 합니다.

2. 실패 로그로 검증 방식을 확인한다

sudo certbot renew --dry-run으로 시험 갱신을 실행하고 표시된 인증서 이름·인증 플러그인·오류 메시지를 읽습니다. 자동 갱신용 systemd 타이머나 cron이 실행되는지도 확인하세요. 시험 갱신이 성공해도 실제 웹 서버가 새 인증서를 읽는 단계는 별도로 검증해야 합니다. 운영 중에는 변경 전 현재 설정과 인증서 경로를 기록해 두세요.

3. HTTP-01과 DNS-01의 장애 지점을 나눈다

검증 방식	먼저 볼 것	흔한 문제
HTTP-01	도메인 A/AAAA, 외부 포트 80, 리다이렉트·프록시	접속 차단, 잘못된 원본, 다중 서버 불일치
DNS-01	TXT 레코드, DNS API 권한, 전파·위임	오래된 값, 자격 증명 만료, 권한 부족

Let’s Encrypt의 HTTP-01 검증은 포트 80을 사용합니다. 포트 443만 열려 있다고 해결되지 않습니다. 와일드카드 인증서는 DNS-01 방식이 필요합니다. 방화벽과 DNS를 변경하기 전 영향 도메인을 확인하세요.

4. Nginx가 새 인증서를 읽는지 확인한다

갱신 파일이 존재하더라도 Nginx가 다른 경로를 가리키거나 설정 재적용이 누락될 수 있습니다. sudo nginx -t로 문법을 검사한 다음, 필요할 때 안전한 운영 절차에 따라 Nginx를 reload합니다. 인증서 경로는 보통 /etc/letsencrypt/live/도메인/ 아래이지만 실제 설정을 기준으로 확인하세요. 여러 서버 또는 CDN 앞단에서 TLS가 종료된다면 각 지점의 인증서를 별도로 확인합니다. Nginx 자체 장애는 Nginx 502 점검 가이드와 구분해 처리하세요.

5. 재발 방지 체크리스트

1. 갱신 타이머의 실행 기록과 실패 알림을 확인합니다.
2. 도메인 A·AAAA·CNAME과 서비스 원본을 문서화합니다.
3. DNS-01 사용 시 최소 권한의 API 자격 증명 만료를 감시합니다.
4. 갱신 후 서비스 도메인의 실제 인증서를 검사합니다.
5. 만료 며칠 전 알림과 정기 dry-run을 운영 절차에 넣습니다.

예를 들어 새 인증서는 발급됐는데 사이트가 이전 인증서를 보인다면, 재발급을 반복하기보다 Nginx·로드 밸런서·CDN 중 어느 계층이 인증서를 제공하는지 확인하는 편이 빠릅니다.

6. 자주 묻는 질문

Q. 포트 80을 항상 열어야 하나요?
HTTP-01 검증에는 외부에서 포트 80으로 접근할 수 있어야 합니다. DNS-01은 DNS TXT 레코드를 이용하는 별도 방식입니다.

Q. dry-run 성공이면 끝인가요?
아닙니다. 실제 갱신 일정과 Nginx 재적용, 외부에서 보이는 인증서를 확인하세요.

Q. 와일드카드 인증서를 HTTP-01로 갱신할 수 있나요?
Let’s Encrypt의 와일드카드 인증에는 DNS-01 검증이 필요합니다.

공식 자료: Let’s Encrypt 검증 방식 · Certbot 명령 매뉴얼 · Certbot 사용자 안내 (확인일: 2026-09-26)