처음엔 정말 간단한 작업이었다.

DB 스펙 문서(db-specification.html)를 팀원들이 볼 수 있게 어딘가에 올리면 되는 일. GitHub Pages 시도 → private 레포라 불가. htmlpreview.github.io → private 레포라 404. 결국 "그냥 프로덕션 서버에 올리자"는 결론에 도달했다.

nginx 컨테이너 하나 띄우고, 80 포트로 /econipass/db-specification.html 서비스. 30분이면 끝날 줄 알았다.

브라우저가 갑자기 반란을 일으키다

파일 올리고 URL 열었더니 blocked:origin. 크롬이 접속을 막아버린 것이다.

원인을 파고들어 보니 HSTS(HTTP Strict Transport Security) 문제였다. 이 도메인(elon.tpm.querypie.io)에 예전에 HTTPS로 접속한 적이 있고, 크롬이 "이 도메인은 무조건 HTTPS로만 접속해야 해"라고 캐시에 박아놓은 것이다. 그러니까 HTTP:80으로 서비스해도, 브라우저가 자동으로 HTTPS로 리다이렉트한 뒤, 인증서가 만료됐으니 에러를 뱉는 구조.

"HTTPS가 안 열리는데 HTTP로 서비스하면 되는 거 아니야?"

이 질문이 얼마나 순진한 생각이었는지 깨닫는 데는 그리 오래 걸리지 않았다.

SSL 인증서가 2025년 12월에 만료되어 있었다. 인프라가 살아있으니 도메인은 잘 찾아가는데, HTTPS 연결 자체가 실패하는 상황. 브라우저 캐시에서 HSTS를 지우면 임시로 볼 수 있지만, 팀원 모두에게 "크롬 캐시 지우세요"라고 할 순 없는 노릇이다.

결론: 인증서를 갱신해야 한다.

인프라 구조 파악부터

인증서를 갱신하려면 인프라 구조를 먼저 파악해야 했다. 이 도메인의 트래픽 흐름을 따라가 보면:

사용자 브라우저
    ↓ HTTPS:443
Tencent STGW (43.166.63.91)   ← 보안 게이트웨이, SSL 처리
    ↓
Tencent CLB (lb-jr4kimtz)     ← 로드 밸런서, 여기에 인증서 등록
    ↓
VM (10.99.0.9)                ← Docker 컨테이너들

핵심 발견: SSL 인증서는 VM이 아니라 CLB 리스너에 등록되어 있다. 인증서를 갱신하려면 CLB에 새 인증서를 교체해야 한다.

Tencent Cloud 무료 DV 인증서 (TrustAsia, 90일짜리)를 사용 중이었다. 이걸 갱신하면 된다.

도메인 소유권 증명의 함정

인증서를 발급받으려면 "이 도메인 내 거 맞아요"를 CA(인증 기관)에 증명해야 한다. 방법은 두 가지:

방법 A: 파일 검증
http://elon.tpm.querypie.io/.well-known/pki-validation/fileauth.txt
CA가 이 URL에 접근해서 파일을 확인하면 끝.

방법 B: DNS TXT 검증
_dnsauth.elon.tpm.querypie.io TXT 레코드를 DNS에 추가하면 끝.

당연히 쉬워 보이는 A를 먼저 시도했다. nginx 컨테이너에 파일 올리고, CA 검증 요청. 결과는 LocalCheck: -11. CA가 파일에 접근을 못 한다는 뜻이다.

왜? STGW가 HTTP:80을 받지 않기 때문이다. 도메인으로 들어오는 모든 트래픽은 STGW를 먼저 거치는데, STGW는 HTTPS:443만 받고 HTTP:80은 504로 뱉어버린다. CA가 HTTP로 파일을 확인하러 왔다가 504를 보고 포기한 것이다.

CLB에 HTTP:80 리스너를 추가하고, VM 보안 그룹에 포트를 열어보는 등 여러 시도를 해봤지만 STGW 레이어에서 막히는 구조라 근본적으로 해결이 안 됐다.

PDF 한 장이 해결책을 알려주다

삽질을 한참 하던 중, 팀의 Tencent Cloud 구축 가이드 PDF가 있다는 걸 떠올렸다. "Guide to Building on Tencent Cloud (with AWS Domain Integration)"

PDF를 열어보니 lucas.tpm.querypie.io로 동일한 인증서 발급 작업을 한 기록이 있었다. 그리고 결정적인 한 줄:

Domain validation method: Manual DNS validation

파일 검증이 아니라 DNS TXT 검증을 쓰고 있었던 것이다. 그리고 DNS 설정 화면은 Tencent DNS가 아니라 AWS Route53이었다.

이 도메인(tpm.querypie.io)의 DNS가 AWS Route53에서 관리되고 있었다. 파일 검증은 HTTP 접근이 필요하지만, DNS 검증은 HTTP와 전혀 무관하다. CA가 DNS 서버에 직접 TXT 레코드를 조회하는 방식이라, STGW가 막든 말든 상관없다.

DNS TXT 레코드가 하는 일

잠깐, 여기서 개념 하나를 짚고 가자.

우리가 도메인으로 서버를 찾을 수 있는 건 A 레코드 덕분이다:

elon.tpm.querypie.io  A  43.166.63.91

이건 "이 도메인은 이 IP야"라고 알려주는 주소록 같은 것.

TXT 레코드는 다르다. 기계가 읽는 메모장이다. SSL 인증서 발급 시에는 CA가 무작위 토큰을 생성하고, "이 값을 DNS TXT에 넣을 수 있으면 이 도메인 주인으로 인정하겠다"고 한다. DNS 관리 권한이 있어야만 TXT를 추가할 수 있으니, 이게 곧 소유권 증명이 된다.

_dnsauth.elon.tpm.querypie.io  TXT  "202603150953..."
                                      ↑ Tencent CA가 발급한 일회용 토큰

현재 상황

지금은 이 단계에 와 있다:

  1. ✅ 기존 FILE 방식 인증서 신청 취소
  2. ✅ DNS 방식으로 새 인증서 신청 (W71snIR5)
  3. ⏳ Route53에 TXT 레코드 추가 — Route53 관리자에게 요청 중
  4. ⬜ CA 검증 완료 → 인증서 발급
  5. ⬜ CLB 리스너에 새 인증서 교체
  6. ⬜ https://elon.tpm.querypie.io/econipass/db-specification.html 정상 접근

Route53 관리자에게 보낸 메시지는 이렇다:

Route53 tpm.querypie.io zone에 TXT 레코드 하나만 추가해주실 수 있나요?

  • Record name: _dnsauth.elon.tpm
  • Type: TXT
  • Value: 202603150953...

elon.tpm.querypie.io SSL 인증서 발급용이에요. Lucas님이 예전에 동일하게 하셨던 작업입니다!

배운 것들

1. HTTP와 HTTPS는 브라우저 캐시 앞에서 별개가 아니다
HSTS가 캐시된 도메인은 HTTP로 서비스해도 HTTPS로 강제된다. 인증서 만료 = 서비스 불가.

2. 인프라 계층을 파악하지 않으면 삽질한다
파일 검증이 실패한 이유는 STGW 레이어 때문이었다. CLB, 보안그룹만 보다가 STGW를 놓쳤다. 트래픽이 어떤 경로로 흐르는지 먼저 그려야 한다.

3. 이미 누군가 한 적 있는 작업은 문서에 있다
PDF 한 장이 몇 시간의 삽질을 끝냈다. 팀의 가이드 문서는 무조건 먼저 읽어야 한다.

4. DNS TXT 검증은 생각보다 강력하다
HTTP 접근 불가 환경에서도 사용 가능하고, 서버 설정 변경 없이 DNS만으로 처리된다. 앞으로 인증서 발급할 때 기본값으로 고려할 것.

30분 작업이 반나절 삽질로 바뀌었지만, 덕분에 인프라 구조를 제대로 이해하게 됐다. TXT 레코드 추가 후 인증서가 발급되면 진짜 끝이다. 아마도.