셀프 호스팅 인증서는 왜 로컬에서는 갱신되지만 인터넷에서는 실패할까요?

ACME 인증 기관이 인터넷에 노출된 경로를 통해 챌린지에 접근하거나 이를 검증할 수 없으면 인증서가 로컬에서는 갱신되더라도 외부에서는 실패할 수 있습니다.

자체 호스팅 NAS나 홈 서버에서는 로컬 시험 실행으로 Certbot, acme.sh 또는 리버스 프록시가 챌린지 파일을 만들고 자체 구성에 접근할 수 있음을 확인할 수 있습니다. 하지만 외부 발급에는 다른 요구 사항이 추가됩니다. 권한 있는 DNS가 올바른 주소를 가리켜야 하고, 선택한 IPv4 또는 IPv6 경로에 접근할 수 있어야 하며, 라우터와 방화벽이 검증 요청을 전달해야 합니다. 또한 리버스 프록시는 리디렉션이나 애플리케이션 라우트가 방해하기 전에 정확한 챌린지 토큰을 제공해야 합니다.

로컬 클라이언트 성공과 공개 도메인 검증을 구분하기

갱신 로그를 읽고 실제로 무엇이 성공했는지 확인하세요. 로컬 구성 확인, 인증서 파싱 테스트, 웹 루트 쓰기 또는 스테이징 요청이 외부 인증 기관이 홈 서버에 도달했다는 뜻은 아닙니다.

일반적인 Nginx Proxy Manager 사례에서는 로컬 프록시 인터페이스가 정상적으로 작동하더라도 HTTP 챌린지가 실패할 때 먼저 확인해야 할 요구 사항으로 공개 포트 80 접근 가능 여부를 제시합니다.

챌린지 유형, 호스트 이름, 검증 URL, 확인된 주소 및 정확한 CA 오류를 기록하세요. 새로운 증거 없이 갱신을 반복해서 강제하지 말고 DNS 조회, TCP 연결, HTTP 상태, 토큰 불일치 또는 2차 검증 중 최초 외부 실패 지점부터 진행하세요.

권한 있는 A 및 AAAA 레코드와 실제 서버 경로 비교하기

모든 인증서 호스트 이름을 권한 있는 DNS를 통해 조회하고 A 및 AAAA 응답을 기록하세요. 이를 라우터의 현재 공인 IPv4, 서버의 접근 가능한 IPv6 주소 및 실제로 챌린지를 제공하는 프록시와 비교하세요.

Virtualmin 갱신 사례에서는 검증 요청을 고장 난 IPv6 경로로 보내던 공개 AAAA 레코드를 제거한 뒤에야 성공했습니다. 이는 정상적인 IPv4 설정이 있어도 고장 난 AAAA 검증 경로가 우선 사용될 수 있음을 보여 줍니다.

어떤 주소 체계에 완전히 접근할 수 없다면 해당 레코드를 일시적으로 제거하거나 방화벽, 라우팅, 리스너 및 프록시 경로를 수정하세요. 발급을 다시 시도하기 전에 모든 권한 있는 네임서버가 동일한 최신 레코드를 반환하는지도 확인하세요.

외부에서 정확한 HTTP 챌린지 URL 테스트하기

HTTP-01의 경우 구성된 /.well-known/acme-challenge/ 경로 아래에 무해한 테스트 파일을 배치한 뒤, 모바일 데이터나 다른 외부 네트워크에서 인증서 호스트 이름을 사용해 HTTP로 요청하세요.

Home Assistant 자체 호스팅 보고서는 서비스 자체가 로컬에서 작동하더라도 ISP가 차단한 HTTP 챌린지가 HTTP 검증을 방해하는 방식을 보여 줍니다.

외부 요청은 인증, 캡티브 페이지, 라우터 로그인 페이지, 애플리케이션 404 또는 접근할 수 없는 대상으로의 리디렉션 없이 올바른 토큰에 도달해야 합니다. TCP 포트 80이 전혀 열리지 않는다면 ACME 클라이언트를 변경하기 전에 ISP, CGNAT, 라우터 포트 포워딩, 호스트 방화벽 및 프록시 리스너를 점검하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

리버스 프록시와 웹 루트가 동일한 토큰을 제공하는지 확인하기

ACME 클라이언트가 기록한 토큰 경로와 공개 가상 호스트가 사용하는 파일 시스템 또는 임시 응답기를 비교하세요. 컨테이너, 바인드 마운트 및 별도의 프록시 네트워크로 인해 클라이언트가 한 디렉터리에 쓰고 NGINX 또는 Caddy가 다른 디렉터리에서 제공할 수 있습니다.

외부 챌린지 요청 한 건이 진행되는 동안 프록시 액세스 로그를 확인하세요. 요청이 도착했지만 404를 반환한다면 라우트 또는 웹 루트 불일치가 원인입니다. 401 또는 403은 인증이나 필터링을 가리키며, 502는 챌린지 경로에 불필요한 업스트림 의존성이 있음을 의미합니다.

챌린지 위치가 일반 애플리케이션 라우팅보다 우선하도록 설정하고 호스트 이름을 유지하세요. 리디렉션은 단순하게 유지하고 외부에서 확인하세요. 갱신 중 오프라인일 수 있는 백엔드 애플리케이션을 통해 토큰을 전달하지 마세요.

CGNAT, 방화벽 및 여러 위치에서의 접근 가능성 확인하기

라우터의 WAN 주소를 공인 IPv4 주소와 비교하고, 둘 이상의 외부 네트워크에서 검증 포트에 접근할 수 있는지 확인하세요. 로컬 NAT 루프백 테스트가 성공하더라도 원치 않는 인터넷 트래픽이 라우터에 전혀 도달하지 않을 수 있습니다.

인증 기관은 라우팅 공격을 줄이기 위해 점점 더 여러 네트워크 위치에서 검증을 수행합니다. 여러 검증 관점에 관한 연구는 한 국가, ISP 또는 테스트 서비스에서 접근 가능한 경로가 더 광범위한 검증에서는 여전히 실패할 수 있는 이유를 설명합니다.

검증 중에는 제한된 챌린지 경로에서 지역 차단, 국가 필터, 임시 차단 규칙 및 속도 제한을 제거하세요. 홈 연결이 CGNAT 뒤에 있거나 ISP가 필요한 포트를 차단한다면 관련 없는 방화벽 규칙을 약화하는 대신 DNS-01 또는 아웃바운드 검증 방식을 사용하세요.

네트워크 경계에 맞는 챌린지 유형 선택하기

공개 DNS가 올바르고 포트 80이 챌린지 응답기에 안정적으로 도달할 수 있다면 HTTP-01을 유지하세요. 인바운드 접근이 불가능하거나 와일드카드 인증서가 필요하거나 서비스를 비공개로 유지해야 한다면 DNS-01을 사용하세요.

CGNAT가 인바운드 검증을 차단하는 방식을 다룬 ZimaSpace 문서는 로컬 프록시를 수정하는 것보다 ACME 방식을 변경하는 편이 적절한 상황을 파악하는 데 도움이 됩니다.

프로덕션 CA를 통한 강제 갱신이 성공하고, 새 인증서가 활성 프록시에 배포되며, 외부 클라이언트가 새 일련번호와 만료일을 수신하고, 수동으로 포트나 DNS를 변경하지 않아도 무인 갱신 테스트가 작동할 때 비로소 문제가 해결된 것입니다.