Certbot challenge failed 해결

Problem

Certbot가 거의 끝까지 가서 챌린지에 관한 뭔가를 출력하더니 Some challenges have failed 또는 Failed authorization procedure로 멈췄습니다. 인증서는 없습니다. 답답한 건 이 한 줄이 완전히 다른 두 검증 방식을 덮고 있고, 그 둘은 완전히 다른 이유로 실패하며, 한쪽의 해법이 다른 쪽엔 무용하다는 점입니다. 뭘 바꾸기 전에 어느 챌린지를 돌렸는지부터 알아내세요. http-01과 dns-01은 정반대 지점에서 깨집니다.

두 챌린지는 소유를 서로 다르게 증명한다

Certbot는 CA에게 도메인을 실제로 통제한다는 것을 증명해야 합니다. 방법은 둘이고, 받은 오류는 어느 쪽이냐에 달려 있습니다:

• http-01 — CA가 클라이언트에 토큰을 건네고, Certbot가 그걸 파일로 써서 CA가 평문 HTTP로 http://도메인/.well-known/acme-challenge/<TOKEN>에서 가져갑니다. CA가 올바른 토큰을 읽어내면 통과. 그 호스트명의 80포트에서 응답하는 것을 통제함을 증명합니다.
• dns-01 — Certbot가 값을 계산하고 당신이 그것을 _acme-challenge.도메인에 TXT 레코드로 게시합니다. CA가 그 레코드를 DNS로 조회합니다. DNS 존을 통제함을 증명하며, 와일드카드 인증서를 발급할 수 있는 유일한 방법입니다. 웹서버에 도달할 필요가 전혀 없습니다.

같은 “challenge failed”지만 하나는 웹서버의 도달성 문제이고 다른 하나는 DNS의 레코드 문제입니다. 그것부터 가리세요.

http-01이 실패할 때

http-01은 HTTP로 파일을 가져오는 것이라, 실패는 거의 항상 그 가져오기가 있어야 할 곳에 안 닿는 문제입니다:

• Timeout during connect (likely firewall problem) — 검증 서버가 80포트로 연결조차 못 열었습니다. vhost가 아니라 네트워크 차단이나 잘못된 DNS 대상입니다. A/AAAA 레코드가 맞는 서버를 가리키는지, 80포트가 세계에 열려 있는지 확인하세요. 443만 허용하는 클라우드 방화벽이 전형적 원인입니다 — 사이트 자체가 HTTPS-only여도 CA는 80이 필요하다는 걸 잊습니다.
• 챌린지 경로에서 404 — 연결은 됐는데 토큰 파일이 CA가 본 곳에 없었습니다. 엉뚱한 문서 루트, .well-known을 서빙하는 것과 다른 vhost, 또는 경로를 삼킨 rewrite/redirect 규칙에 걸린 것입니다. Certbot의 리다이렉트 처리는 여기서 관대합니다 — Let’s Encrypt는 최대 10번 리다이렉트를 따라가지만 http:/https:로만, 80이나 443 포트로만 갑니다 — 그래서 다른 포트로의 리다이렉트는 브라우저는 따라가도 검증은 깨집니다.
• 브라우저에선 되는데 그래도 실패 — 2025년 9월부터 Let’s Encrypt는 모든 검증을 여러 네트워크 관점에서 확증하며(MPIC), 요구 관점 수는 2026년 말까지 다섯으로 늘어납니다. 일부 지역 트래픽을 막는 방화벽이나 GeoIP 규칙은, 당신 경로가 멀쩡해도 막힌 관점에서 실패합니다. 검증이 간헐적이거나 지역 의존적이면 깨진 설정이 아니라 지오블록을 의심하세요.

경험칙: http-01 문제는 인터넷과 웹서버 사이에 있습니다 — DNS 대상, 80포트, 방화벽, 정확한 경로 — 대개 애플리케이션 안이 아닙니다.

dns-01이 실패할 때

dns-01은 서버를 건드리지 않으므로, 실패는 전부 TXT 레코드에 관한 것입니다 — 존재하는지, 올바른지, 전파됐는지:

• DNS problem: NXDOMAIN looking up TXT for _acme-challenge... — 레코드가 아직 CA에 안 보입니다. 그걸 만들었어야 할 API 호출이 안 됐거나(엉뚱한 존, 잘못된 자격증명, 그 이름에 권위가 없는 제공자에 쓰는 플러그인), 만들어졌지만 검증이 돌 때까지 권위 네임서버에 전파가 안 됐습니다. 게시와 검증 사이를 충분히 안 기다리는 dns-01 자동화가 이걸 끊임없이 만납니다.
• 틀리거나 오래된 TXT 값 — 레코드는 있는데 안 맞습니다. 이전 실패 실행이 남긴 옛 챌린지 값, 또는 교체가 아니라 추가한 제공자 탓에 TXT 레코드가 여러 개라 검사가 혼란스러운 것. 레코드는 정확히 _acme-challenge.<검증되는 이름>에 있어야 하고, 와일드카드는 서브도메인별이 아니라 기본 도메인의 _acme-challenge입니다.
• 레코드는 맞는데 CAA로 발급이 실패 — 챌린지와 별개로 CA는 CAA 레코드를 확인하고, 그게 있는데 해당 CA를 안 나열하면 발급을 거부합니다. 한 CA만 허용하는 CAA 레코드는 dns-01 챌린지가 완벽히 통과해도 Let’s Encrypt를 막습니다. 챌린지 자체는 통과했기에 놓치기 쉽습니다.

DechoNet으로 진단

• DNS 조회(DNS Lookup)는 _acme-challenge TXT 레코드가 실제로 보이는지와 어떤 값인지 확인합니다 — dns-01 레코드가 올바로 게시됐는지 확인하고 남은 중복 TXT를 잡는 가장 빠른 길입니다. A/AAAA 레코드도 보여줘 http-01이 맞는 서버를 가리키는지, CAA 레코드도 보여줘 CAA 차단을 배제할 수 있습니다.
• HTTP 점검(HTTP Check)은 CA가 하는 방식대로 URL을 가져와, /.well-known/acme-challenge/가 80포트 평문 HTTP로 도달 가능한지, 리다이렉트가 검증이 안 따라갈 곳으로 경로를 보내는지 보여줍니다.
• SSL 점검(SSL Check)은 발급 성공 후 새 인증서가 실제로 443에 서빙되는지 확인하고, 반복된 실패로 발급 한도에 가까워졌는지 의심될 때 CT 뷰가 도움이 됩니다.

해결 체크리스트

• 오류에서 챌린지 종류를 식별. .well-known/acme-challenge 또는 80포트 타임아웃 = http-01; _acme-challenge TXT / NXDOMAIN 메시지 = dns-01.
• http-01: A/AAAA가 맞는 서버를 가리키는지, 80포트가 밖에서 열려 있는지, 토큰 경로가 404 나거나 80/443 아닌 포트로 리다이렉트되지 않는지 확인.
• dns-01: _acme-challenge TXT 레코드가 존재하고, 현재 값을 담고, 오래된 중복이 없고, 검증 전에 전파됐는지 확인.
• CAA 배제: CAA 레코드가 있다면 당신의 CA(Let’s Encrypt는 letsencrypt.org)를 허용해야 하며, 아니면 챌린지와 무관하게 발급이 실패합니다.
• 로컬에선 되는데 CA에서 실패하면 다중 관점 검증을 의심 — 지오블록이나 지역 기반 방화벽 규칙을 확인.
• 와일드카드가 필요하거나 80포트를 못 여나요? dns-01을 쓰세요. http-01은 둘 다 못 합니다.

이럴 땐 확대 대응

• 80포트를 정말 노출할 수 없으면(일부 관리형 플랫폼, 내부 전용 호스트), http-01과 싸우지 말고 API 구동 플러그인으로 dns-01로 옮기세요.
• 레코드가 분명히 있는데 dns-01이 계속 NXDOMAIN이면, 플러그인이 권위 없는 존에 쓰고 있을 수 있습니다 — 전파를 탓하기 전에 그 이름이 실제로 어디에 위임됐는지 확인하세요.
• 반복 실패로 발급 한도에 튕기고 있다면 재시도를 멈추고 too many certificates already issued를 먼저 읽으세요.