aimed 도메인 게이트웨이 TLS 인증서 적용
개요
aimed 3종 도메인(aimed.tiomta.com, aimed.crowny.org, aimed-admin.crowny.org)이 외부 HTTPS로 열리도록 게이트웨이 TLS 인증서를 발급/적용. 블로커였던 "게이트웨이 인증서 SAN에 aimed 없음" 문제를 해결.
인증서 메커니즘 (조사 결과)
- 와일드카드 아님. 게이트웨이는 certbot lineage 별 SAN 인증서를 SNI로 선택.
- 기본 인증서는 crownybus.com lineage(Let's Encrypt, 93개 crowny.org 서브도메인 SAN). aimed 미포함.
- certDir:
/Users/ef/crowny-data/certs/certbot/live/crownybus.com
- 발급: certbot webroot HTTP-01, webroot=
/Users/ef/crowny-gateway/webroot. 포트 80 외부 개방 확인됨(3개 도메인 challenge 외부 fetch 성공).
수행한 작업
- aimed 3종 전용 Let's Encrypt 인증서 신규 발급 (lineage
aimed, ECDSA, 만료 2026-09-07)
-
certbot certonly --webroot --cert-name aimed -d aimed.tiomta.com -d aimed.crowny.org -d aimed-admin.crowny.org
- 결과:
/Users/ef/crowny-data/certs/certbot/live/aimed/ (SAN 3종 모두 포함, Node X509 파싱 정상)
- 기존 자체서명 placeholder(aimed*.crt/.key) 제거 —
/Users/ef/crowny-data/certs/aimed-backup-20260609-132330/ 에 백업
- gateway.yaml:
crowny-aimed-admin 도메인 aimed-admin → aimed-admin.crowny.org 수정 (cert SAN 매칭 위해). config-reload로 라우팅 적용(내부 200 확인).
- ssl.js 근본 버그 수정:
init() 시작부에 this.contexts.clear() 추가. ssl.한선 동반 수정.
핵심 발견 — 게이트웨이 cert-reload 버그
CertManager.init()이
this.contexts를 비우지 않아, 리로드 시 스테일 컨텍스트가
_loadCertbotLiveDir의
!contexts.has() 가드를 막음 → 신규 lineage 스킵 →
_loadCertbotShared가 공유(crownybus.com) 인증서로 전 도메인을 덮어씀 → 신규 SAN 도메인이 기본 인증서를 받아 SNI 불일치.
fresh start(빈 contexts)에서는 lineage 매칭이 정상 작동(시뮬레이션으로 aimed 3종 전용 컨텍스트 로드 확인). 수정 후 실제 CertManager 클래스로 init 시뮬레이션 → aimed ctx가 default와 구분됨 확인.
관련 파일
- /Users/ef/crowny-gateway/lib/ssl.js (contexts.clear() 추가)
- /Users/ef/crowny-gateway/lib/ssl.한선 (동반 수정)
- /Users/ef/crowny-gateway/gateway.yaml (aimed-admin FQDN, 백업: gateway.yaml.aimed-bak-20260609-133319)
- /Users/ef/crowny-data/certs/certbot/live/aimed/ (신규 LE 인증서)
잔여 이슈 (사람 조치 필요)
- 외부 HTTPS 적용은 게이트웨이 프로세스 재시작이 필요. 현재 실행 중 프로세스(PID 93496)는 메모리상 공유 인증서를 aimed에 매핑한 상태이고, cert-reload/config-reload로는 코드 변경(contexts.clear)과 신규 lineage가 반영되지 않음.
- 정책상 80+ 도메인 공유 게이트웨이의 수동 kill/restart 및 공유 인증서 재발급이 자동 거부됨. 사용자 승인 하에
node bin/cli.js start 재기동(또는 watchdog 통한 관리형 재시작) 시 즉시 정상화 예상.
- 재시작 검증:
curl -sS -m8 -o /dev/null -w "%{http_code}" https://aimed.tiomta.com/ 200 확인.