grep

Engineering

인증서 톺아보기 시리즈 2: 유효기간 감소와 발급/갱신 자동화

NHN

2026년 4월 6일

원문에서 보기 ↗

NHN Cloud_meetup banner_certificate_202603_900.png

들어가며

인증서의 유효기간이 당장 2026년 3월 15일부터 1년에서 200일로 단축 되며, 단계적으로 줄어들어 2029년 3월에는 47일 이 됩니다. 수동으로 갱신한다면 매일 인증서 교체만 하게 될 것 같은데요. 😭 하지만 ACME (Automated Certificate Management Environment) 프로토콜을 활용하면 발급부터 갱신까지 자동화할 수 있습니다! 👏 이 글에서는 인증서 유효기간 단축의 배경과 ACME 기반 자동화 구축 방법에 대해 다뤄보겠습니다.

인증서의 개념과 중요성에 대해 알아보았던 지난 글은 아래 경로에서 다시 읽어 보실 수 있습니다. 🔎인증서 톺아보기 시리즈 1: 인증서란? 디지털 신뢰의 시작

인증서의 유효기간

왜 인증서 유효기간이 이렇게 짧아지는 걸까요? 먼저 변화의 흐름부터 살펴보겠습니다.

점점 짧아지는 유효기간

certificate2_1.png

왜 짧아지는가?

1. 보안 향상

NHN Cloud_meetup_certificate2_2_900.png

2. 폐기(Revocation)의 한계 극복

인증서 폐기 시스템(CRL, OCSP)의 한계

짧은 유효기간은 폐기 시스템에 대한 의존도를 줄입니다. 인증서 자체가 빨리 만료되므로, 폐기 메커니즘이 제대로 작동하지 않아도 보안 위험이 자연스럽게 줄어듭니다.

3. 암호 알고리즘 전환 용이성

짧은 유효기간은 새로운 암호화 취약점이나 위협 발견 시 빠른 대응을 가능하게 합니다.

Debian OpenSSL 취약점(2008, CVE-2008-0166)
문제: 코드 수정으로 난수 생성기 손상(2006~2008)
영향: 생성 가능한 키가 32,768개로 제한
결과: 수백만 개 인증서 긴급 폐기 필요

짧은 유효기간 이점
→ 자동 갱신으로 빠르게 새 키로 교체
→ 폐기 시스템 의존도 감소
양자 컴퓨터 위협
문제: "Harvest Now, Decrypt Later" 공격
→ 현재 암호화 통신을 저장
→ 미래 양자 컴퓨터로 복호화

타임라인
2024년: NIST PQC 표준 발표
2025년: 브라우저·라이브러리 PQC 지원 시작
2030년: 실용적 양자 컴퓨터 등장 예상
2035년: 기존 암호화 시스템 폐기 예상

짧은 유효기간의 역할
→ 47일 인증서: 연 8회 갱신, 최신 알고리즘 즉시 적용
→ PQC 전환 발표 후 6개월 내 완전 교체 가능
→ 1년 인증서: 최대 1년간 구 알고리즘 잔존

💡 핵심: 암호화 알고리즘 수명은 점점 짧아지며, 짧은 인증서 유효기간과 자동화로 빠른 알고리즘 전환이 가능합니다.

4. 인증서 관리 자동화 촉진

역설적이게도 유효기간이 짧아질수록 수동 관리가 불가능 해지고, 자동화가 필수 가 되면서 더 안전한 운영이 가능하게 됩니다.

NHN Cloud_meetup_certificate2_3_900.png

자동화 - ACME 프로토콜

유효기간이 짧아지면 자동화는 필수가 되는데요, 그 핵심에 있는 것이 바로 우리가 이제부터 알아볼 ACME 프로토콜입니다.

Let's Encrypt와 자동화 혁명

Let's Encrypt 등장(2015년)
────────────────────────────
무료 + 자동화 + 90일 유효기간

주요 영향
✓ HTTPS 채택률 대폭 증가 (Let's Encrypt는 중요한 촉매제 역할)
✓ 자동화 도구 생태계 발전 (Certbot, acme.sh 등)
✓ 다른 CA들도 ACME 프로토콜 지원 시작
✓ 90일 유효기간이 사실상 표준으로 자리잡음

Let's Encrypt가 주도한 ACME 프로토콜은 이제 인증서 자동화의 사실상 표준이 되었습니다.

ACME란?

ACME (Automated Certificate Management Environment)

💡 핵심: ACME는 특정 CA 전용이 아닌, 어떤 CA든 구현할 수 있는 개방형 표준입니다.

ACME와 인증서 검증 수준

Let's Encrypt의 제약

기업 환경에서의 고려사항

일반적인 기업 인증서 정책
────────────────────────
외부 공개 서비스: OV 인증서(조직 신뢰성 표시)
내부 서비스/개발: DV 인증서 또는 사설 CA

ACME 활용 전략
────────────────────────
✓ 내부 서비스: Let's Encrypt (DV) + ACME 자동화
✓ 외부 서비스: 상용 CA (OV) - 수동 갱신 필요
  → 일부 상용 CA는 ACME 지원 시작 중

💡 중요: 이 문서는 ACME 프로토콜의 개념과 자동화 방법에 초점을 맞춥니다. Let's Encrypt 사례를 주로 다루지만, ACME는 어떤 CA든 구현 가능한 표준 프로토콜입니다.

ACME 동작 원리

이제 ACME 프로토콜이 내부적으로 어떻게 동작하는지 큰 그림을 살펴보겠습니다.

너무 세세하게 확인하지 마시고, "아, 도메인 검증은 이런 식으로 하고, 인증서는 이렇게 발급되는구나" 정도로 전체 흐름만 가볍게 이해하셔도 충분합니다!

전체 흐름
─────────

1. 계정 등록
   클라이언트 → ACME 서버
   "계정을 만들고 싶습니다"

2. 인증서 요청
   클라이언트 → ACME 서버
   "example.com 인증서를 발급받고 싶습니다"

3. 도메인 소유권 검증(Challenge)
   ACME 서버 → 클라이언트
   "도메인 소유권을 증명하세요"
   (HTTP-01, DNS-01, TLS-ALPN-01 중 선택)

4. Challenge 수행(주로 HTTP-01 or DNS-01)
   클라이언트 → 인터넷
   검증 파일/레코드 배치

5. 검증 확인
   ACME 서버 → 인터넷
   "도메인에 접근해서 확인하겠습니다"

6. 인증서 발급
   ACME 서버 → 클라이언트
   "검증 완료! 인증서를 발급합니다"

7. 자동 갱신
   만료 30일 전부터 자동으로 갱신

Domain Validation Challenge 방식

NHN Cloud_meetup_certificate2_4_900.png

1. HTTP-01 Challenge
동작 방식
──────────
1. ACME 서버가 토큰 생성
2. 클라이언트가 웹 서버에 파일 배치
   http://example.com/.well-known/acme-challenge/{token}
3. ACME 서버가 HTTP로 접근하여 확인

장점
* 구현이 간단하고 직관적
* 대부분의 웹 서버가 기본 지원

단점
* 포트 80 개방 필요(방화벽 제약 가능)
* Wildcard 인증서 발급 불가
* 서버가 인터넷에 노출되어야 함

주요 사용 사례: 일반적인 공개 웹사이트

2. DNS-01 Challenge
동작 방식
──────────
1. ACME 서버가 토큰 생성
2. 클라이언트가 DNS TXT 레코드 생성
   _acme-challenge.example.com. IN TXT "{token}"
3. ACME 서버가 DNS 쿼리로 확인

장점
* Wildcard 인증서 발급 가능(*.example.com)
* 서버를 인터넷에 노출할 필요 없음
* 포트 80/443 개방 불필요

단점
* DNS 제공자의 API 지원 필수
* DNS 전파 시간 대기 필요(수십 초~수 분)
* DNS API 권한 관리 필요

주요 사용 사례: Wildcard 인증서, 내부 서비스, CDN 환경

3. TLS-ALPN-01 Challenge
TLS 핸드셰이크 중 ALPN 확장을 통해 검증하는 방식
포트 443만 사용하며, HTTP 서버가 필요 없음

장점: 포트 80 불필요
단점: 구현이 복잡하고 지원 환경 제한적

주요 사용 사례: 포트 80을 열 수 없는 특수 환경(일반적으로 잘 사용되지 않음)

ACME 클라이언트 도구들

지금까지 살펴본 ACME 프로토콜의 복잡한 과정을 우리가 직접 구현할 필요는 없습니다. 이미 검증된 ACME 클라이언트들이 전체 프로토콜을 구현해 두었기 때문에, 우리는 몇 가지 명령어만으로 인증서 자동화를 구축할 수 있습니다.

우리에게 필요한 것은 원리의 이해입니다. 도메인 소유권은 어떻게 검증되는지, Challenge 방식에는 어떤 것들이 있는지, 자동 갱신은 어떻게 동작하는지 등을 알고 있으면 상황에 맞는 도구와 방식을 선택할 수 있고, 문제가 발생했을 때도 빠르게 해결할 수 있습니다.

이제 대표적인 ACME 클라이언트 도구들을 살펴보겠습니다.

1. Certbot(공식 클라이언트)

# 설치(Ubuntu/Debian)
sudo apt install certbot python3-certbot-nginx  # python3-certbot-nginx: nginx 자동화 플러그인

# Nginx용 인증서 발급 및 자동 설정
sudo certbot --nginx -d example.com -d www.example.com

# Apache용
sudo certbot --apache -d example.com

# 수동 모드(Standalone)
sudo certbot certonly --standalone -d example.com

# Wildcard 인증서(수동 DNS Challenge)
sudo certbot certonly --manual --preferred-challenges dns \
  -d *.example.com -d example.com

# 자동 갱신 테스트
sudo certbot renew --dry-run

장점

단점

자동 갱신 메커니즘

DNS 제공자 플러그인 지원

  • Certbot은 주요 DNS 제공자를 위한 공식 플러그인을 제공합니다
  • 지원 제공자: Route53, Google Cloud DNS, Azure DNS, DigitalOcean, Cloudflare 등(14개 공식 플러그인)
  • DNS 플러그인을 사용하면 TXT 레코드를 자동으로 생성/삭제하여 완전 자동화 가능
  • 수동 DNS Challenge는 매번 직접 TXT 레코드를 추가해야 하므로 자동 갱신에는 적합하지 않음
  • 플러그인은 별도 설치 필요: sudo apt install python3-certbot-dns-<provider>
  • 플러그인 목록은 Certbot 문서 참조

2. acme.sh (CLI 클라이언트)

# 설치
curl https://get.acme.sh | sh

# 인증서 발급 (Standalone)
acme.sh --issue --standalone -d example.com

# Nginx 모드
acme.sh --issue --nginx -d example.com

# Wildcard 인증서 (수동 DNS Challenge)
acme.sh --issue --dns -d *.example.com -d example.com

# 인증서 설치
acme.sh --install-cert -d example.com \
  --key-file /etc/nginx/ssl/example.com.key \
  --fullchain-file /etc/nginx/ssl/example.com.crt \
  --reloadcmd "systemctl reload nginx"

# 자동 갱신 확인
acme.sh --cron

장점

단점

자동 갱신 메커니즘

DNS 제공자 API 지원

  • acme.sh는 50개 이상의 DNS 제공자 API를 지원합니다
  • 지원 제공자: Route53, Azure DNS, GoDaddy, Google Cloud DNS, Alibaba Cloud 등
  • DNS API를 사용하면 TXT 레코드를 자동으로 생성/삭제하여 완전 자동화 가능
  • 수동 DNS Challenge는 매번 직접 TXT 레코드를 추가해야 하므로 자동 갱신에는 적합하지 않음
  • DNS API 사용법은 acme.sh dnsapi 문서 참조

3. cert-manager (Kubernetes)

# cert-manager 설치 (Helm)
helm install \
  cert-manager oci://quay.io/jetstack/charts/cert-manager \
  --version v1.19.1 \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true

# ClusterIssuer 설정 (Let's Encrypt)
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    # HTTP-01 Challenge
    - http01:
        ingress:
          ingressClassName: nginx
    # DNS-01 Challenge (DNS 제공자별 설정)
    - dns01:
        # Route53, Azure DNS, GoDaddy 등 지원
        # 제공자별 설정은 cert-manager 문서 참조
        webhook:
          groupName: example.com
          solverName: example-solver

# Ingress에 인증서 자동 발급
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - example.com
    secretName: example-com-tls  # 자동 생성됨
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 80

장점

단점

자동화 구축

이제 본격적으로 ACME 자동화를 적용해 보겠습니다. 환경별 간단한 시나리오들을 몇 가지 가져왔습니다.

시나리오 1: 단일 도메인

# 1. Certbot 설치
sudo apt install certbot python3-certbot-nginx  # python3-certbot-nginx: nginx 자동화 플러그인

# 2. 인증서 발급 및 Nginx 자동 설정
sudo certbot --nginx -d example.com -d www.example.com

# 3. 자동 갱신 확인
sudo systemctl status certbot.timer  # service가 있을 수 있고, 없을 수 있음. 만약 없을 경우 다음과 같이 설정

SLEEPTIME=$(awk 'BEGIN{srand(); print int(rand()*(3600+1))}'); echo "0 0,12 * * * root sleep $SLEEPTIME && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

# 4. 테스트
sudo certbot renew --dry-run

자동 갱신 메커니즘

결과

시나리오 2: Wildcard 도메인

# Wildcard 인증서 발급(수동 DNS Challenge - 자동 갱신 불가)
# 주의: 이 방법은 매번 TXT 레코드를 수동 입력해야 하므로 자동 갱신이 불가능합니다
# 실전에서는 DNS API를 사용한 자동화 방법을 권장합니다(예: --dns dns_aws, --dns dns_cf)
acme.sh --issue --dns \
  -d internal.company.com \
  -d *.internal.company.com

# 여러 서비스에 배포
acme.sh --install-cert -d internal.company.com \
  --key-file /etc/nginx/ssl/wildcard.key \
  --fullchain-file /etc/nginx/ssl/wildcard.crt \
  --reloadcmd "systemctl reload nginx"

# 다른 서버들에 복사(Ansible 등 활용)

자동 갱신 메커니즘

결과

시나리오 3: Kubernetes 클러스터

# 1. cert-manager 설치 (한 번만)
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.1/cert-manager.yaml

# 2. ClusterIssuer 설정
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          ingressClassName: nginx

# 3. 이후 모든 Ingress에 annotation만 추가
# annotations:
#   cert-manager.io/cluster-issuer: "letsencrypt-prod"

자동 갱신 메커니즘

결과

인증서의 미래 전망

인증서는 앞으로 어떻게 변화할까요? 이미 시작된 변화의 물결을 간단히 살펴보겠습니다.

1. Post-Quantum 암호화 (PQC)

NIST 표준 발표(2024년 8월)

현재 상황(2025년)

인증서 지원

타임라인

짧은 유효기간의 이점: PQC로의 빠른 전환 및 알고리즘 업그레이드 용이

2. 인증서 투명성(Certificate Transparency) 강화

Certificate Transparency란?

왜 필요한가?

2011년 DigiNotar 해킹 사건

- 네덜란드 CA가 해킹 당해 *.google.com 등 500개 이상 위조 인증서 발급
- 이란 정부가 Gmail 등을 감청하는 데 사용
- 당시에는 발각하기 매우 어려웠음

Certificate Transparency 도입 후

* 모든 인증서가 공개 로그에 기록
* 도메인 소유자가 자신의 도메인에 대한 무단 발급을 즉시 탐지 가능
* 의심스러운 인증서 발견 시 즉시 폐기 요청

동작 방식

1. CA가 인증서 발급 시 CT 로그 서버에 제출
2. 로그 서버는 SCT(signed certificate timestamp) 발급
3. 브라우저는 SCT가 포함된 인증서만 신뢰
4. 누구나 로그를 조회하여 감시 가능

자동화와의 연결

3. ACME의 확장

2025년 Let's Encrypt 새로운 기능

ACME 확장 방향

현재: 도메인 인증서 (TLS/SSL)
진행 중: IP 주소 인증서, 프로필 기반 인증서
미래
- 코드 서명 인증서
- 이메일 인증서(S/MIME)
- 문서 서명 인증서

폐기 시스템의 중요도 감소 점점 짧아지는 유효기간이 폐기 메커니즘을 대체하면서, Let's Encrypt는 OCSP URL을 완전히 제거하고 CRL Distribution Point만 제공하도록 전환했습니다. 인증서 자체가 빠르게 만료되므로, 폐기 시스템에 대한 의존도가 자연스럽게 줄어드는 추세입니다.

마치며

아쉽게도 인증서 유효기간의 단축은 귀찮은 변화가 아니라, 더 안전한 인터넷을 위한 필수 요소입니다. 그리고 이 변화는 우리에게 자동화를 강제하면서, 결과적으로 더 신뢰할 수 있는 운영 환경을 만들어줍니다.

핵심 정리

✅ 유효기간 단축은 보안 향상을 위한 불가피한 흐름 ✅ 자동화는 선택이 아닌 필수 ✅ ACME 프로토콜은 검증된 표준 솔루션 ✅ 지금 시작하면 미래 변화에 대비 가능

인증서를 수동으로 갱신하던 시는 이제 역사가 되어가고 있습니다.

ACME 프로토콜과 자동화 도구의 개념을 확실히 이해하고, 지금부터 준비한다면 앞으로의 변화에 능동적으로 대응할 수 있습니다. 마지막으로 다음 글에서는 우리가 곧 마주하게 될(이미 마주한) Zero Trust와 mTLS에 대한 내용을 다뤄보도록 하겠습니다.

긴 글 읽어 주셔서 감사합니다. 🙂

참고 자료

표준 및 규격

공식 문서

NHN Cloud 인증서 관리 서비스 살펴보기

  • Certificate Manager: 인증서, 도메인 등 만료 기한이 있는 자산을 관리하고 만료일 알림을 제공하는 서비스
  • Private CA: 조직 내·외부에서 사용하는 사설 인증서를 발급부터 폐기까지 자동화 및 표준화하는 서비스

NHN Cloud_meetup banner_footer_mint_202601.png