5.6 KiB
kind, slug, title, topic, topicName, project, status, questionStatus, sourceRevision, evidence, source
| kind | slug | title | topic | topicName | project | status | questionStatus | sourceRevision | evidence | source | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| QUESTION | is-this-lab-issuing-certificates-with-http-01-or-dns-01 | 이 실험대의 certbot 은 HTTP-01 로 받고 있는가 DNS-01 로 받고 있는가 | lab-environment-build | 실험대 환경 구성 | virtualization | 게시 전 | RESOLVED | import-head 9465582b5d1630eb4ae7c4e078021486919bf6b6 · uncommitted-working-tree snapshot |
|
|
이 실험대의 certbot 은 HTTP-01 로 받고 있는가 DNS-01 로 받고 있는가
2026-09-17 renewal 설정을 직접 읽으면서 답이 나왔다. authenticator = dns-cloudflare 였다. 따라서 이 실험대의 certbot은 DNS-01로 등록되어 있다(observed). 이전에 HTTP-01과 DNS-01 중 어느 쪽인지 열어 둔 상태는 닫는다.
관계
- 인증서는 DNS-01 로 받는다 — 실험대 주소가 공개 인터넷에 없어 HTTP-01 이 성립하지 않는다 이 결정이 설계 의도만 적은 것이 아니라 현재 실험대의 등록 상태와도 일치한다는 것이 확인됐다.
- DNS-01 으로 와일드카드 인증서를 받고 갱신이 서빙까지 닿게 한다
renewal 설정의
authenticator와 자격증명 경로를 실제 출력으로 확인한 Setup이다. - 실험대를 철거하고 무엇이 남는지 확인한다 검증 방식은 닫혔지만 현재 Cloudflare 자격증명이 재발급에 쓸 수 있는지는 별도 확인이 필요해 인증서 보존 판단에는 그 조건이 남는다.
- 갱신은 매번 SUCCESS 였고 옛 인증서가 계속 나갔다 — 2305초와 1~2초 이 질문은 발급·갱신 방식만 닫는다. 갱신된 파일을 nginx가 다시 읽는 문제는 그 Case의 범위다.
- 공개 터널을 쓰지 않고 tailnet 직결로 둔다 — 홉이 하나 늘면 재려던 계약이 오염된다 공개 인터넷에서 HTTP-01이 성립하지 않는 조건은 그대로다.
- 가이드대로 다시 쳐서 이 실험대가 같은 상태로 서는가 7단계 중 04의 인증 방식 판정은 닫혔다. 재발급 자격증명과 dry-run 성공 여부는 별도 검증으로 남긴다.
사실
2026-09-17 sudo sh -c 안에서 /etc/letsencrypt/renewal/*.conf를 읽었다. 후속 원문에는 다음 세 줄이 남아 있다.
authenticator = dns-cloudflaredns_cloudflare_credentials = /etc/letsencrypt/cloudflare.iniserver = https://acme-v02.api.letsencrypt.org/directory
일반 셸에서 sudo grep ... /etc/letsencrypt/renewal/*.conf로 친 첫 시도는 zsh가 글로브를 sudo보다 먼저 펼치면서 no matches found로 실패했다. 그래서 sudo sh -c 안에서 글로브를 펼쳤다.
같은 후속 원문에서 Cloudflare 자격증명 파일의 토큰 길이는 0자로 측정됐고 토큰 검증은 Invalid request headers로 실패했다. 따라서 DNS-01 등록 여부는 확인됐지만 현재 자격증명이 유효하다고 확인된 것은 아니다.
auth.hyeonworks.com은 tailnet 주소 100.83.212.4로 풀리고, 이 주소는 공개 인터넷에서 라우팅되지 않는 100.64.0.0/10 안이다. 이 조건 때문에 HTTP-01을 현재 진입 경로에 그대로 적용할 수 없다는 판단도 바뀌지 않는다.
2026-09-17 현재 lineage는 /etc/letsencrypt/live/auth.hyeonworks.com/이었다. /etc/letsencrypt/live/hyeonworks.com/은 원본 가이드에 남은 known-wrong 경로였고, 그대로 nginx -t를 실행하면 certificate file not found로 실패했다.
가정
renewal 설정이 2026-09-17 관측 뒤에 수동으로 변경되지 않았다고 전제한다. 이후 설정을 바꾸면 이 기록의 “현재” 범위도 그 시점까지만 유효하다.
미지수
이 질문의 핵심 미지수였던 authenticator는 해소됐다.
남은 미지수는 다른 판단에 속한다.
/etc/letsencrypt/cloudflare.ini에 유효한 토큰을 다시 넣었는가.- 그 토큰의 권한이 필요한 zone과 DNS 편집 범위로 좁혀져 있는가.
- 현재
certbot renew --dry-run이 성공하는가.
이 셋은 DNS-01인지 HTTP-01인지를 다시 여는 근거가 아니다. 재발급·갱신 가능성을 확인하는 후속 조건이다.
제약
비밀 값은 증거에 남기지 않는다. 자격증명은 길이·존재 여부와 API 검증 결과까지만 기록한다.
sudo가 필요한 디렉터리의 글로브는 일반 사용자 셸에서 먼저 펼치지 않는다. 이 실험대에서는 그 방식이 실제로 실패했다.
선택지
1. DNS-01 — 현재 관측과 일치
renewal 설정이 dns-cloudflare를 직접 가리킨다. 이 질문의 답이다.
2. HTTP-01 — 현재 관측과 불일치
원본 가이드 04에는 --webroot 경로가 남아 있었지만, 현재 renewal 설정이 그것을 사용한다는 증거는 없다. historical document branch로만 남긴다.
다음 검증
이 Question은 RESOLVED다. authenticator를 다시 읽는 것은 질문을 닫기 위한 검증이 아니라 설정 변경 감시다.
재발급 가능성을 확인하려면 유효한 Cloudflare 자격증명을 준비한 뒤 sudo certbot renew --dry-run을 별도 검증한다. 그 결과가 실패하더라도 이 Question을 다시 OPEN으로 돌리지 않는다. 실패 원인은 자격증명·DNS 권한·ACME 경로 쪽의 새 문제로 분리한다.
닫는 조건 : 2026-09-17 raw evidence에서 authenticator = dns-cloudflare가 직접 관측되어 충족됐다.