SSL 인증서 완전 이해 가이드 — 만료·갱신 책임·DNS-01·CNAME 자동화

"인증서가 6일 뒤 만료됩니다. 직접 갱신하시겠어요, 아니면 DNS에 CNAME 하나를 추가해 자동 갱신으로 전환하시겠어요?"

이 안내를 처음 받으면 질문이 한꺼번에 생깁니다. 인증서는 왜 멀쩡히 쓰다가 만료되는지, 서비스 제공자는 만료일을 어떻게 알았는지, 갱신 책임은 누구에게 있는지, CNAME의 HOST와 VALUE는 왜 서로 다른지부터 막힙니다. 특히 "CNAME 하나면 앞으로 영원히 아무것도 안 해도 된다"는 설명은 이해하기 쉽지만 기술적으로는 정확하지 않습니다.

이 글은 라이브 서비스용 커스텀 도메인 live.frank.example을 사용하는 가상 사례로 SSL/TLS 인증서의 전체 수명주기를 정리합니다. frank.example은 문서용 예약 도메인이므로 실제 고객 주소가 아닙니다. 실제 작업에서는 반드시 서비스 제공자가 전달한 HOST와 VALUE를 그대로 사용해야 합니다.

먼저, 30초짜리 전체 지도부터 보자

긴 설명에 들어가기 전에 오늘 해결할 문제를 한 장으로 펼쳐보겠습니다.

┌─────────────────────── 인증서가 살아 있는 동안 ───────────────────────┐
│                                                                       │
│   사용자 브라우저  ─────── HTTPS 연결 ───────▶  live.frank.example   │
│                              인증서 확인                 서비스       │
│                                                                       │
└───────────────────────────────────────────────────────────────────────┘
                                  │
                           만료일이 다가오면?
                                  ▼
┌─────────────────────── 자동 갱신의 숨은 통로 ────────────────────────┐
│                                                                       │
│  고객 DNS          CNAME 위임         Agora DNS           인증기관   │
│                                                                       │
│  _acme-challenge.live.frank.example                                  │
│          └────────▶ live.frank.example.acme-challenge.agoramdn.com   │
│                              └──── TXT 토큰 ────▶ 도메인 확인 완료    │
│                                                                       │
└───────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
                    새 인증서 발급 → 배포 → TLS 보호 유지

등장인물은 넷뿐입니다.

이제 각 상자가 왜 필요한지 하나씩 열어보겠습니다.

0. 핵심 명제 — 인증서 갱신은 파일 교체가 아니라 신뢰를 다시 증명하는 과정이다

TLS 인증서는 "이 공개키가 이 도메인의 것"이라는 사실을 인증기관(CA)이 일정 기간 보증하는 전자 신분증이다. 만료는 장애가 아니라 보안 설계다. 문제는 만료 자체가 아니라, 만료 전에 새 인증서를 발급하고 실제 서비스에 배포하는 절차가 자동화되어 있지 않은 것이다. DNS-01과 CNAME 위임은 이 절차 중 '도메인 통제권 증명'을 서비스 제공자에게 안전하게 맡기는 방법이다.

먼저 용어부터 정확히 맞추겠습니다.

1. SSL/TLS 인증서는 정확히 무엇을 보증하나

브라우저가 https://live.frank.example에 연결할 때 서버는 TLS 인증서를 내밉니다. 인증서에는 대략 다음 정보가 들어 있습니다.

• 인증서가 보호하는 도메인: subjectAltName(SAN)
• 서버 공개키
• 발급한 인증기관과 인증서 체인
• 유효 시작 시각: Not Before
• 유효 종료 시각: Not After
• 인증서 일련번호와 서명 알고리즘

브라우저는 이 정보를 이용해 세 가지를 확인합니다.

1. 지금 접속한 호스트명이 인증서의 SAN에 포함되어 있는가?
2. 인증서가 신뢰하는 CA 체인으로 서명되어 있는가?
3. 현재 시각이 Not Before와 Not After 사이인가?

셋 중 하나라도 실패하면 브라우저는 연결을 안전하다고 보지 않습니다. 따라서 인증서는 단순히 주소창에 자물쇠를 그리는 파일이 아니라, 도메인·공개키·유효기간을 하나로 묶어 신뢰를 만드는 서명된 데이터입니다.

인증서와 개인키는 같은 것이 아니다

인증서는 공개해도 되는 정보입니다. 실제로 TLS 연결을 맺는 모든 클라이언트에게 전달됩니다. 반면 개인키는 서버만 보관해야 합니다.

인증서:  공개키 + 도메인 + 유효기간 + CA 서명  → 외부 공개 가능
개인키:  서버가 해당 공개키의 주인임을 증명       → 절대 외부 공유 금지

수동 갱신에서 인증서 파일과 함께 개인키까지 이메일이나 메신저로 전달하는 방식은 피해야 합니다. 제공자가 CSR(Certificate Signing Request)을 만들고 고객은 서명된 인증서 체인만 전달하는 구조인지, 암호화된 비밀 채널을 사용하는지 먼저 확인해야 합니다.

2. 왜 인증서는 일부러 만료되게 만들었나

인증서는 여권과 비슷합니다. 어제까지 멀쩡했던 여권도 유효기간이 지나면 출국 심사를 통과할 수 없죠. 발급 당시에는 신뢰할 수 있었더라도 그 상태를 무기한 보증할 수는 없습니다.

발급                  안전하게 사용                    만료
 │                         │                             │
 ▼                         ▼                             ▼
   Not Before ━━━━━━━━━━━ 유효 구간 ━━━━━━━━━━━━━━━ Not After
                           │
                           └── 이 구간 안에서 새 인증서를 준비해야 한다

              “만료일에 갱신” 위험     “충분히 일찍 재발급” 안전

이유 1 — 개인키 유출의 피해 시간을 제한한다

공격자가 개인키를 탈취하면 인증서가 유효한 동안 서버를 사칭할 가능성이 생깁니다. 인증서 폐기(Revocation) 체계가 존재하지만 모든 클라이언트가 항상 즉시 폐기 상태를 확인한다고 가정할 수는 없습니다. 짧은 유효기간은 최악의 경우에도 오래된 자격 증명이 자연스럽게 사라지도록 만드는 마지막 안전장치입니다.

이유 2 — 오래된 암호 정책을 주기적으로 걷어낸다

허용 키 길이, 서명 알고리즘, 인증서 체인 정책은 계속 바뀝니다. 유효기간이 짧으면 다음 재발급 때 새로운 정책을 적용할 수 있습니다. 한 번 발급한 인증서가 수년간 남아 있으면 취약한 설정도 함께 오래 남습니다.

이유 3 — 도메인 통제권을 다시 확인한다

도메인은 양도되거나 DNS 운영 주체가 바뀔 수 있습니다. 과거에 도메인을 통제했다는 사실이 현재도 유효하다고 볼 수 없습니다. 재발급 과정에서 도메인 통제권을 다시 증명하는 이유입니다.

2026년 기준 유효기간은 더 짧아지는 추세다

2026년 3월 15일 이후 발급되는 공개 TLS 인증서의 최대 유효기간은 CA/Browser Forum 기준 200일입니다. 2027년에는 100일, 2029년에는 47일로 더 짧아질 예정입니다. Let's Encrypt의 기본 프로필은 현재 90일이며, 2027년부터 64일, 2028년부터 45일로 단계적으로 단축될 계획입니다. 6일짜리 단기 인증서 프로필도 이미 선택할 수 있습니다.

즉 "보통 90일에서 1년"이라는 설명은 빠르게 낡고 있습니다. 앞으로의 운영 원칙은 명확합니다.

인증서를 사람이 달력에 적어두고 교체하는 운영은 더 이상 지속 가능하지 않다. 짧은 인증서 수명은 자동 갱신을 선택 기능이 아니라 기본 전제로 만든다.

3. 만료되면 실제로 어디가 깨지나

인증서의 Not After를 지나면 서버 프로세스가 반드시 멈추는 것은 아닙니다. 서버는 계속 인증서를 제시할 수 있지만 클라이언트가 “이 신분증은 기한이 끝났는데요?”라며 신뢰를 거부합니다.

사용자 입장에서는 애플리케이션 서버가 살아 있어도 접속할 수 없으므로 서비스 장애와 동일한 결과입니다. 더 까다로운 점은 일부 클라이언트가 기존 TLS 세션을 잠시 재사용해 모든 사용자가 동시에 실패하지 않을 수 있다는 것입니다. "나는 아직 접속된다"는 말이 인증서가 정상이라는 증거가 되지는 않습니다.

4. 서비스 제공자는 만료 6일 전을 어떻게 알았을까

인증서의 만료일은 비밀이 아닙니다. TLS handshake에서 서버가 인증서를 공개하므로 인터넷에서 해당 엔드포인트에 연결할 수 있다면 누구나 Not After를 읽을 수 있습니다.

openssl s_client \
  -connect live.frank.example:443 \
  -servername live.frank.example </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

출력은 다음과 같은 형태입니다.

subject=CN=live.frank.example
issuer=C=US, O=Let's Encrypt, CN=...
notBefore=Jul 01 00:00:00 2026 GMT
notAfter=Sep 29 23:59:59 2026 GMT

일반적인 모니터링 흐름은 이렇습니다.

[주기적 TLS 연결]
        ↓
[서버가 제시한 인증서 수집]
        ↓
[SAN·체인·Not After 검사]
        ↓
[남은 일수 계산]
        ↓
[경고 임계값 도달 시 담당자 알림]

다만 Agora가 어떤 주기로 검사하는지, 30일·14일·7일·3일 같은 어떤 임계값을 쓰는지, 특정 알림이 어떤 내부 경로를 거쳤는지는 공개 근거 없이는 확정할 수 없습니다. [NEEDS VERIFICATION] 확인 가능한 사실은 실제 서비스 인증서의 Not After를 외부에서 읽어 만료일까지 남은 시간을 계산할 수 있다는 점입니다.

인증서 모니터링에서 함께 봐야 할 것

만료일만 확인하면 충분하지 않습니다.

• 실제 클라이언트가 접속하는 호스트와 포트가 맞는가?
• SNI를 넣었을 때 올바른 인증서가 반환되는가?
• SAN에 대상 호스트가 정확히 포함되어 있는가?
• 중간 인증서 체인이 누락되지 않았는가?
• 새 인증서 발급 후 로드밸런서와 모든 엣지에 배포되었는가?
• 자동 갱신 작업의 마지막 성공 시각은 언제인가?

발급은 성공했는데 서버가 여전히 이전 인증서를 내보내는 장애도 흔합니다. 그래서 운영 모니터링은 발급 시스템 상태가 아니라 실제 외부 엔드포인트가 제시하는 인증서를 기준으로 해야 합니다.

5. 갱신 책임은 누구에게 있나 — 도메인 소유자만 보면 반쪽 답이다

"커스텀 도메인이니 무조건 고객 책임 아닌가요?" 가장 많이 나오는 질문입니다. 답은 절반만 맞다입니다. DNS를 통제하는 쪽과 인증서를 실제로 발급·배포하는 쪽이 다를 수 있기 때문입니다. 책임은 인증서 운영 모델과 계약으로 결정됩니다.

              고객이 계속 쥐고 있는 것            Agora가 맡을 수 있는 것
           ┌─────────────────────────┐        ┌─────────────────────────┐
           │ 도메인 소유권            │        │ ACME 발급 요청           │
           │ CNAME·CAA 유지           │   🤝   │ 개인키·인증서 수명주기   │
           │ 위임 철회 권한            │◀──────▶│ 인프라 배포·자동 갱신     │
           └─────────────────────────┘        └─────────────────────────┘

                “권한을 전부 넘김”이 아니라 “인증 전용 구간만 위임”

옵션 1 — 고객이 인증서를 직접 제공하는 경우

고객이 CA와 인증서 수명주기를 관리합니다.

1. 고객이 키와 CSR 생성
2. CA에서 도메인 통제권 검증
3. 인증서와 체인 발급
4. 정해진 보안 채널로 제공자에게 전달
5. 제공자가 서비스 인프라에 배포
6. 외부 엔드포인트에서 새 인증서 확인
7. 다음 만료 전에 전 과정을 반복

장점은 CA, 키 관리, 인증서 정책을 고객이 통제할 수 있다는 것입니다. 금융·공공·대기업처럼 사내 PKI 정책이나 승인 절차가 엄격한 조직에 적합합니다.

대가는 운영 책임입니다. 발급만 자동화하고 제공자 전달이 수동이면 완전한 자동화가 아닙니다. 담당자 휴가, 승인 지연, 잘못된 체인 파일, 개인키 불일치 같은 사람이 만든 실패 지점이 남습니다.

옵션 2 — CNAME을 추가해 제공자 관리형으로 전환하는 경우

고객은 DNS에 위임 레코드를 한 번 추가하고, 제공자는 ACME 클라이언트와 자신이 관리하는 DNS 영역을 이용해 발급·갱신·배포를 자동화합니다.

고객: CNAME 위임을 생성하고 유지
  ↓
제공자: ACME 주문 생성
  ↓
CA: DNS-01 토큰 전달
  ↓
제공자: 위임받은 DNS 영역에 TXT 토큰 게시
  ↓
CA: TXT 값 검증 후 인증서 발급
  ↓
제공자: 서비스 인프라에 배포하고 주기적으로 재발급

장점은 짧아지는 인증서 수명에 대응하기 쉽고, 고객 DNS 계정의 API 키를 제공자에게 넘기지 않아도 된다는 것입니다. 단점은 인증서 발급과 개인키 운영을 제공자에게 위탁한다는 점입니다. 보안 정책상 가능한지 먼저 확인해야 합니다.

6. DNS-01 챌린지는 무엇을 증명하나

CA는 인증서를 요청한 주체가 live.frank.example을 통제하는지 확인해야 합니다. DNS-01에서는 다음 위치에 CA가 지정한 일회성 값을 TXT 레코드로 게시하게 합니다.

_acme-challenge.live.frank.example

예를 들어 CA가 기대하는 값이 token-abc123이라면 최종적으로 DNS 질의 결과가 다음처럼 보여야 합니다.

_acme-challenge.live.frank.example.  TXT  "token-abc123"

왜 이것이 소유권 증명이 될까요? 아무나 live.frank.example의 권한 있는 DNS 영역에 레코드를 만들 수는 없기 때문입니다. CA는 "이 웹서버에 로그인할 수 있는가"가 아니라 이 도메인의 DNS를 통제할 수 있는가를 검증합니다.

DNS-01은 웹서버의 80번 포트를 열 필요가 없고 와일드카드 인증서에도 사용할 수 있습니다. 대신 매 발급마다 토큰이 바뀌므로 자동화하려면 DNS API 권한이 필요합니다. CNAME 위임은 고객 DNS 전체 권한을 제공자에게 주지 않고 _acme-challenge 한 지점만 맡기는 해법입니다.

7. CNAME의 HOST와 VALUE는 왜 서로 다른가

설명용 가상 도메인에 다음 레코드를 추가한다고 가정하겠습니다.

Type:   CNAME
Host:   _acme-challenge.live.frank.example
Value:  live.frank.example.acme-challenge.agoramdn.com
TTL:    300 또는 Auto

위 VALUE는 원리를 설명하기 위한 형식 예시입니다. 실제 운영에서는 Agora 알림이나 콘솔이 제공한 값을 한 글자도 바꾸지 말고 사용해야 합니다. 제품별 실제 CA, 발급 프로필, Target 규칙은 [NEEDS VERIFICATION] 입니다.

HOST는 대표번호, VALUE는 실제 콜센터 번호

HOST를 회사 대표번호, VALUE를 외부 콜센터 번호에 비유해봅시다. 고객은 대표번호를 한 번 안내해두고, 실제 상담 인력과 운영은 콜센터가 맡습니다. 다만 DNS가 웹 요청을 콜센터로 전달하는 것은 아닙니다. DNS resolver가 "이 이름의 정식 이름은 저쪽이다"라는 답을 받고 VALUE 쪽에 다시 DNS 질의합니다.

CA가 TXT 질의
_acme-challenge.live.frank.example
                │
                │ CNAME 응답
                ▼
live.frank.example.acme-challenge.agoramdn.com
                │
                │ TXT 재질의
                ▼
"token-abc123"  ← 제공자가 자동으로 게시한 값

따라서 CNAME은 인증서 트래픽이나 사용자의 HTTPS/RTMP 트래픽을 Agora로 보내는 설정이 아닙니다. _acme-challenge라는 인증 전용 DNS 이름의 질의만 위임합니다. 실제 서비스 호스트의 A/AAAA/CNAME 레코드에는 영향을 주지 않습니다.

8. CNAME 하나로 갱신이 자동화되는 전체 흐름

최초 1회 — 고객이 위임을 설정한다

고객은 자신의 DNS 관리 권한으로 _acme-challenge.live.frank.example CNAME을 추가합니다. 이 행동 자체가 "이 이름의 ACME 검증 응답은 Target 측에 맡기겠다"는 위임입니다.

발급 시마다 — 제공자가 새로운 토큰에 응답한다

1. 제공자의 ACME 클라이언트가 live.frank.example 인증서를 주문합니다.
2. CA가 DNS-01 토큰을 발급합니다.
3. 제공자가 agoramdn.com 아래 자신이 관리하는 Target에 해당 TXT 값을 게시합니다.
4. CA가 고객 쪽 _acme-challenge를 조회합니다.
5. DNS resolver가 CNAME을 따라 제공자 영역의 TXT를 조회합니다.
6. CA가 토큰 일치를 확인하고 새 인증서를 발급합니다.
7. 제공자가 새 인증서와 개인키를 서비스 인프라에 배포합니다.
8. 다음 갱신 시에는 새 토큰으로 2~7을 반복합니다.

고객이 추가한 CNAME 값은 그대로지만 Target에 게시되는 TXT 토큰은 발급 때마다 달라질 수 있습니다. 이것이 고객은 한 번 설정하고, 제공자는 계속 자동 갱신할 수 있는 이유입니다.

9. 실제 DNS 관리 화면에는 어떻게 입력하나

DNS 제공자마다 전체 도메인을 입력하는지, 현재 Zone 기준의 상대 이름만 입력하는지가 다릅니다.

일반 DNS 패널

Type:   CNAME
Name:   _acme-challenge.live.frank.example
Target: live.frank.example.acme-challenge.agoramdn.com
TTL:    300 또는 Auto

Cloudflare

Type:         CNAME
Name:         _acme-challenge.live
Target:       live.frank.example.acme-challenge.agoramdn.com
Proxy status: DNS only
TTL:          Auto

Zone이 frank.example일 때 Cloudflare의 Name 필드에는 _acme-challenge.live처럼 상대 이름을 넣어도 전체 FQDN으로 저장됩니다. 화면에 최종 이름이 _acme-challenge.live.frank.example로 보이는지 확인합니다. ACME 검증용 레코드는 HTTP 프록시 대상이 아니므로 DNS only로 둡니다.

AWS Route 53

Record name:  _acme-challenge.live
Record type:  CNAME
Value:        live.frank.example.acme-challenge.agoramdn.com
TTL:          300

Route 53 Hosted Zone이 frank.example인지 먼저 확인해야 합니다. 다른 Zone에 같은 문자열을 추가하면 화면상 레코드는 있어 보여도 실제 권한 있는 DNS에서는 조회되지 않습니다.

가장 흔한 입력 실수 — 도메인 중복

일부 패널은 Name 뒤에 Zone 이름을 자동으로 붙입니다. 여기에 전체 FQDN을 넣으면 다음처럼 중복될 수 있습니다.

의도: _acme-challenge.live.frank.example
실제: _acme-challenge.live.frank.example.frank.example

저장 후 관리 화면만 보지 말고 외부 DNS 질의로 최종 결과를 확인해야 합니다.

10. 추가 후 어떻게 검증하나

1단계 — CNAME이 보이는지 확인

dig CNAME _acme-challenge.live.frank.example +short

예상 결과:

live.frank.example.acme-challenge.agoramdn.com.

2단계 — 전체 질의 경로 확인

dig _acme-challenge.live.frank.example TXT

발급 작업이 진행 중이라면 CNAME을 따라간 최종 TXT 값이 보일 수 있습니다. 발급 중이 아닐 때 TXT가 비어 있다고 해서 CNAME 설정이 반드시 잘못된 것은 아닙니다. 토큰은 필요할 때만 게시하고 검증 후 제거할 수 있기 때문입니다.

3단계 — 권한 있는 DNS에서 직접 확인

재귀 DNS 캐시 때문에 결과가 엇갈리면 먼저 NS를 찾고 권한 있는 서버에 직접 질의합니다.

dig NS frank.example +short
dig @<authoritative-nameserver> \
  CNAME _acme-challenge.live.frank.example +short

4단계 — 발급 후 실제 서비스 인증서 확인

openssl s_client \
  -connect live.frank.example:443 \
  -servername live.frank.example </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -serial -dates

여기서 새 Not After가 보일 때 작업이 끝난 것입니다. "DNS 레코드를 추가했다"나 "인증서가 발급됐다"만으로는 충분하지 않습니다. 실제 엣지가 새 인증서를 제공해야 합니다.

11. 자동 갱신이 실패하는 대표 원인

① CNAME과 다른 레코드가 같은 이름에 공존한다

DNS 표준상 CNAME이 있는 이름에는 일반적으로 TXT 같은 다른 데이터가 함께 존재할 수 없습니다. 기존 _acme-challenge TXT가 남아 있다면 DNS 제공자가 CNAME 생성을 거부하거나 예상과 다른 응답을 만들 수 있습니다. 기존 인증 자동화가 이 TXT를 사용 중인지 먼저 확인하고 전환 순서를 정해야 합니다.

② 인증 대상 호스트와 HOST가 다르다

인증서 대상이 edge.live.frank.example이면 DNS-01 이름은 원칙적으로 다음과 같습니다.

_acme-challenge.edge.live.frank.example

_acme-challenge.live.frank.example과는 다른 이름입니다. 서브도메인 한 단계가 빠진 레코드는 다른 인증 대상을 증명합니다. 서비스 제공자가 준 HOST가 예상과 다르면 임의로 고치지 말고, 어떤 SAN의 인증서를 발급하는지 확인해야 합니다.

③ CAA가 CA 발급을 막는다

CAA 레코드는 어떤 CA가 해당 도메인의 인증서를 발급할 수 있는지 제한합니다. 조직 정책이 특정 CA만 허용하는데 관리형 서비스가 다른 CA를 쓰면 DNS-01 검증이 성공해도 발급이 거부될 수 있습니다.

dig CAA frank.example +short
dig CAA live.frank.example +short

실제 사용 CA가 Let's Encrypt라고 확인된 경우에만 letsencrypt.org 허용 여부를 검토합니다. CA를 추정해 CAA를 수정하면 안 됩니다. Agora 관리형 인증서의 실제 CA는 제품 안내에서 확인해야 합니다. [NEEDS VERIFICATION]

④ Target을 보기 좋게 임의 수정한다

Target은 단순한 규칙 기반 문자열이 아니라 고객·프로젝트·제품별 식별자를 포함할 수 있습니다. 대소문자, 점, 접두사를 임의로 제거하거나 예시를 복사하면 다른 DNS 영역을 가리킬 수 있습니다. 안내받은 FQDN을 원문 그대로 사용합니다.

⑤ DNS 변경과 인증서 배포를 같은 시점으로 생각한다

DNS 위임 확인, CA 검증, 인증서 발급, 인프라 배포는 서로 다른 단계입니다. CNAME이 즉시 조회되어도 인증서 교체에는 추가 시간이 걸릴 수 있습니다. 반대로 발급 시스템이 실패하면 DNS가 정상이어도 새 인증서는 나오지 않습니다.

⑥ 자동화가 있으니 모니터링을 없앤다

자동 갱신은 실패 가능성을 줄이지, 실패를 불가능하게 만들지는 않습니다. CNAME 삭제, CAA 변경, ACME 계정 문제, CA 장애, 배포 실패, 잘못된 SNI 매핑이 남습니다. 최소한 다음 경보는 유지해야 합니다.

• 실제 인증서 잔여 유효기간
• 마지막 갱신 성공 시각
• 마지막 배포 성공 시각
• 외부 엔드포인트의 serial 또는 fingerprint 변경 여부
• SAN·체인·SNI 일치 여부

12. 옵션 1과 옵션 2, 무엇을 선택해야 하나

대부분의 일반적인 커스텀 도메인 운영에는 관리형 자동 갱신이 더 안전합니다. 다만 "편하다"와 "책임이 사라진다"는 같은 말이 아닙니다. 고객은 CNAME과 CAA를 유지하고, 제공자는 발급·키·배포 자동화를 운영하며, 양측은 실제 엔드포인트를 모니터링해야 합니다.

13. 운영자가 바로 쓸 수 있는 체크리스트

설정 전

• 인증서 SAN에 들어갈 정확한 FQDN을 확인했다.
• 현재 인증서의 Not After와 남은 시간을 확인했다.
• 직접 제공과 관리형 중 책임 모델을 합의했다.
• 기존 _acme-challenge TXT/CNAME과 다른 자동화의 사용 여부를 확인했다.
• CAA 정책과 실제 사용 CA의 호환성을 확인했다.
• 제공자가 전달한 HOST와 VALUE를 원문 그대로 보관했다.

DNS 설정 후

• 최종 FQDN에 Zone 이름이 중복되지 않았다.
• CNAME은 DNS only로 설정했다.
• dig CNAME으로 권한 있는 DNS의 응답을 확인했다.
• 발급 요청이 시작되었는지 제공자 상태를 확인했다.

발급·배포 후

• 외부에서 새 serial과 Not After를 확인했다.
• SAN에 서비스 호스트가 포함되어 있다.
• 중간 인증서 체인이 정상이다.
• 실제 RTMP/HTTPS 클라이언트로 연결했다.
• 다음 자동 갱신을 감시할 만료 경보가 유지되어 있다.

14. 고객에게 30초 안에 설명하는 답변

"왜 인증서가 만료되나요?"

인증서는 도메인과 공개키를 일정 기간만 보증하는 전자 신분증입니다. 키 유출 피해를 제한하고 최신 보안 정책을 다시 적용하기 위해 의도적으로 만료됩니다. 따라서 만료는 오류가 아니라 설계이고, 갱신 자동화가 운영의 일부입니다.

"6일 남은 걸 어떻게 알았나요?"

서비스가 TLS 연결 때 공개하는 인증서에는 Not After가 들어 있습니다. 모니터링 시스템은 실제 도메인에 접속해 이 날짜를 읽고 남은 기간을 계산할 수 있습니다. 다만 Agora 내부의 구체적인 검사 주기와 경고 임계값은 별도 확인이 필요합니다.

"CNAME 하나가 왜 필요한가요?"

CA가 _acme-challenge의 TXT 값을 확인할 때, 그 질의를 서비스 제공자가 관리하는 DNS 영역으로 넘기기 위해서입니다. 고객 DNS 전체 권한을 넘기지 않고 인증서 검증용 이름 하나만 위임하는 방식입니다.

"HOST와 VALUE는 각각 뭔가요?"

HOST는 CA가 검증을 시작하는 고객 측 DNS 이름이고, VALUE는 서비스 제공자가 실제 검증 토큰을 게시하는 DNS 이름입니다. CNAME은 HOST가 VALUE의 별칭이라고 알려줍니다.

"한 번 추가하면 정말 끝인가요?"

반복적인 인증서 발급과 배포는 자동화됩니다. 하지만 CNAME과 CAA, 서비스 설정이 유지되어야 하고 자동화 실패를 잡는 모니터링도 필요합니다. 정확한 표현은 "한 번 위임하면 전제조건이 유지되는 동안 갱신이 자동화된다"입니다.

15. 한 장 요약

왜 만료되는가?
└─ 키 유출 피해 제한 + 보안 정책 갱신 + 도메인 통제권 재확인

누가 책임지는가?
├─ BYOC: 고객이 발급·갱신, 제공자가 배포
└─ 관리형: 고객이 DNS 위임 유지, 제공자가 발급·갱신·배포

CNAME은 무엇인가?
└─ 인증 전용 DNS 질의를 제공자 관리 영역으로 넘기는 별칭

실제 자동 갱신은?
ACME 주문 → DNS-01 토큰 → 제공자 TXT 게시 → CA 검증
→ 새 인증서 발급 → 인프라 배포 → 외부 엔드포인트 확인

완료 기준은?
└─ DNS 등록이 아니라 실제 서비스가 새 인증서를 제시하는 것

핵심은 CNAME 한 줄 자체가 아닙니다. 고객의 DNS 통제권과 제공자의 인증서 자동화 사이에 작고 명확한 위임 경계를 만드는 것이 핵심입니다. 이 경계가 올바르게 설정되고 모니터링까지 이어질 때, 짧아지는 인증서 수명은 더 이상 달력에 의존하는 장애 요인이 아니라 반복 가능한 운영 절차가 됩니다.

참고 자료

• Let's Encrypt — Challenge Types
• Let's Encrypt — Decreasing Certificate Lifetimes to 45 Days
• Let's Encrypt — Shorter Certificate Lifetimes and Rate Limits
• CA/Browser Forum — Baseline Requirements for TLS Server Certificates
• Let's Encrypt — Certificate Authority Authorization (CAA)