letsencrypt 인증서 발급 한도 초과

문제

배포가 나갔는데 인증서 단계가 too many certificates already issued for exact set of domains로 실패합니다. 도메인은 아무것도 안 바뀌었습니다. 인증서 100개를 달라고 한 적도 없습니다. 그런데 딱 필요한 순간에 Let’s Encrypt가 하나 더 주기를 거부합니다.

본능은 이걸 우연히 부딪힌 자의적 할당량으로 취급하고 우회로를 찾는 것입니다. 그게 함정입니다. 이 오류는 당신이 일부러 인증서를 너무 많이 요청해서 나는 경우가 거의 없습니다 — 설정 안의 무언가가 재시작마다, 배포마다 같은 인증서를 조용히 몇 번이고 요청해서, 정상 서버라면 연 여섯 번쯤 건드릴 한도를 소진시킨 것입니다. 오류는 증상이고, 버그는 루프입니다.

어느 한도에 걸린 건가

Let’s Encrypt에는 여러 발급 한도가 있고, 사람들을 넘어뜨리는 둘은 헷갈리기 쉽습니다:

• 등록 도메인당 인증서 — 주 50개. example.com과 모든 서브도메인에 발급된 인증서를 합쳐 셉니다. 등록 도메인(Public Suffix List의 eTLD+1)에서 측정되기 때문입니다. 서브도메인 많은 대형 배포가 이걸 칩니다.
• 중복 인증서 — 주 5개. 완전히 동일한 호스트명 집합의 인증서를 셉니다. example.com, www.example.com을 덮는 인증서를 한 주에 여섯 번 요청하면 여섯 번째가 거부됩니다.

문구가 어느 쪽인지 알려줍니다. too many certificates already issued for exact set of domains는 중복 인증서 한도 — 동일한 인증서를 너무 여러 번 요청한 것입니다. 등록 도메인을 언급하는 메시지는 주 50개 한도입니다. 원인도 해법도 다르니, 무엇을 하기 전에 오류부터 읽으세요.

갱신이 범인인 경우는 거의 없다

전부를 다시 보게 만드는 숫자: 실제 인증서는 대략 60일에 한 번 갱신됩니다. Let’s Encrypt가 향하고 있는 더 짧은 수명 — 47일 인증서, 3분의 2 지점쯤 갱신 — 을 감안해도 한 이름당 연 열두 번 남짓입니다. 정당한 일정 중 무엇도 한 주에 5회 근처에 못 갑니다.

그래서 중복 한도에 걸렸다면 그 인증서는 갱신되는 게 아닙니다. 재발급되는 것이고, 무언가가 촘촘한 루프로 그러고 있습니다. 흔한 용의자:

• 재시작마다 새 인증서를 요청하는 컨테이너/파드 — /etc/letsencrypt(또는 ACME 상태)를 볼륨에 보존하지 않는 경우. 크래시 루프나 몇 번의 스케일 업다운이면 점심 전에 동일 인증서 5개를 발급합니다.
• 모든 배포마다 certbot을 도는 CI/CD 파이프라인 — “인증서 받기”를 멱등한 빌드 단계로 취급하지만 실제로는 발급 한도가 걸린 네트워크 호출입니다.
• 여러 서버 또는 잘못 구성된 클러스터 — 저장소를 공유하지 않은 채 각자 같은 인증서를 독립적으로 요청하며 저마다 자기 사본이 필요하다고 믿습니다.
• 백오프 없는 자동화 재시도 — 무관한 이유로 요청이 실패하고 스크립트가 즉시 재시도하며, 발급까지 도달한 시도마다 토큰을 씁니다.

공통점은 인증서가 저장·재사용되는 게 아니라 버려지고 재요청된다는 것입니다. 저장을 고치면 발급 한도는 다시는 볼 일 없는 문제가 됩니다.

토큰 버킷: 일주일을 통째로 기다리지 않는다

많은 조언이 아직도 “한도 초기화까지 7일 기다려라”라고 합니다. 2025년 초 Let’s Encrypt가 고정 주간 창을 토큰 버킷 방식으로 교체하면서 그건 더 이상 사실이 아닙니다. 이제 용량은 한 번에 리셋되지 않고 연속으로 리필됩니다: 중복 인증서 버킷은 대략 34시간마다 인증서 1개를 회복하므로, 벽에 부딪힌 뒤 보통 하루 남짓이면 다시 발급할 수 있습니다.

하지만 버킷은 당신이 그만 빨아들여야만 리필됩니다. 기다리는 동안 고장 난 루프가 계속 발사되면 토큰이 나타나는 즉시 낚아채 무기한 막힙니다. 순서가 중요합니다: 자동화를 멈추고, 그다음 기다린다. 루프가 도는 채 시계만 보는 것이 사람들이 한도가 “먹통”이라고 착각하는 경로입니다.

이미 발급된 것을 확인하라

무엇이든 재발급하기 전에 Let’s Encrypt가 이미 준 것을 보세요 — 발급되는 모든 인증서가 공개 Certificate Transparency 로그에 게시되고, 그 로그는 조회 가능하기 때문입니다. 루프를 눈으로 보는 가장 빠른 방법입니다: CT에 지난 사흘간 같은 이름의 인증서가 열다섯 개 보이면 버그를 찾은 것이고 열여섯 번째는 필요 없습니다. 아주 흔하게, 발급하려는 인증서가 이미 존재하고 완벽히 유효한데 자동화가 그걸 안 불러오는 것뿐입니다.

루프를 고치는 동안엔 클라이언트를 Let’s Encrypt 스테이징 환경으로 돌리세요. 프로덕션을 그대로 흉내 내되 한도가 훨씬 넉넉합니다. 재발급이 멈출 때까지 거기서 갱신 흐름을 테스트하고, 그다음 프로덕션으로 한 번 전환하세요.

DechoNet으로 진단

• SSL 점검은 호스트가 실제로 서빙 중인 인증서 — 발급자, 유효 기간, Certificate Transparency 이력 — 를 읽어, 또 한 번 발급을 쓰기 전에 그 이름의 유효한 인증서가 이미 존재하는지 확인하게 해줍니다. 서빙 중인 인증서가 최신이면 문제는 발급이 아니라 배포입니다.
• DNS 조회는 인증서를 요청 중인 호스트명이 예상한 곳으로 해석되는지 확인해, 중복 요청이 사실은 오타 나거나 낡은 호스트명이 조용히 자기 인증서를 만드는 경우를 잡아줍니다.

해결 체크리스트

• 정확한 오류를 읽으세요. exact set of domains = 중복 인증서 한도(주 5개), 등록 도메인 메시지 = 주 50개 한도.
• 재발급하는 자동화를 멈추세요. 이걸 먼저 — 루프가 빨아들이는 동안엔 토큰 버킷이 리필 안 됩니다.
• Certificate Transparency(SSL 점검 또는 CT 검색)에서 최근 이 이름들에 몇 개가 발급됐는지 확인. 중복 더미면 루프 확정입니다.
• ACME/certbot 상태를 지속 저장소에 보존해 재시작·배포가 새로 요청하지 않고 기존 인증서를 재사용하게 하세요.
• 흐름이 재발급을 멈출 때까지 테스트를 스테이징 환경으로 옮기세요.
• 버킷을 기다리세요 — 중복 토큰 하나에 대략 34시간 — 그다음 프로덕션에서 한 번 발급하고 저장됐는지 확인하세요.

에스컬레이션 시점

• 한 등록 도메인에 진짜로 주 50개 넘는 인증서가 필요하다면(예: 대형 멀티테넌트 플랫폼) 그건 버그가 아니라 실제 용량 수요입니다 — Let’s Encrypt에 바로 이걸 위한 한도 조정 요청 양식이 있습니다.
• 완전히 통제하지 못하는 관리형 플랫폼(PaaS·로드밸런서·호스팅 관리 패널)에서 인증서가 재발급되고 있다면 루프는 그들의 자동화 안에 있습니다. 해법은 당신의 추가 요청이 아니라 그들에게 보내는 지원 티켓입니다.
• 모든 자동화를 멈추고 34시간을 훌쩍 넘겨 기다렸는데도 발급이 안 되면, 한도가 틀렸다고 단정하기 전에 같은 기저 도메인의 다른 팀·테넌트와 등록 도메인 한도를 공유하고 있지 않은지 확인하세요.