요약
[](https://www.nhncloud.com/kr) ## 들어가며 인증서의 유효기간이 당장 2026년 3월 15일부터 **1년에서 200일로 단축**되며, 단계적으로 줄어들어 **2029년 3월에는 47일**이 됩니다. 수동으로 갱신한다면 매일 인증서 교체만 하게 될 것 같은데요. 하지만 **ACME (Automated Certificate Management Environment)** 프로토콜을 활용하면 발급부터 갱신까지 자동화할 수 있습니다! 이 글에서는 인증서 유효기간 단축의 배경과 ACME 기반 자동화 구축 방법에 대해 다뤄보겠습니다. > 인증서의 개념과 중요성에 대해 알아보았던 지난 글은 아래 경로에서 다시 읽어 보실 수 있습니다. > [인증서 톺아보기 시리즈 1: 인증서란? 디지털 신뢰의 시작](https://meetup.nhncloud.com/posts/409) ## 인증서의 유효기간 왜 인증서 유효기간이 이렇게 짧아지는 걸까요? 먼저 변화의 흐름부터 살펴보겠습니다. ### 점점 짧아지는 유효기간  ### 왜 짧아지는가? #### 1\. 보안 향상  * **1년 인증서**: 키 유출 발견까지 평균 6개월이 걸리므로, 공격자가 최대 6개월 이상 탈취한 인증서를 악용할 수 있음 * **90일 인증서**: 유효기간 자체가 짧아 키가 유출되더라도 악용 가능한 최대 기간이 90일로 제한되며, 피해 범위는 상대적으로 작음 #### 2\. 폐기(Revocation)의 한계 극복 인증서 폐기 시스템(CRL, OCSP)의 한계 * 모든 클라이언트가 폐기 상태를 확인하지 않음 * OCSP 서버 장애 시 보안 vs 가용성 딜레마 * 캐싱으로 인한 지연 짧은 유효기간은 폐기 시스템에 대한 의존도를 줄입니다. 인증서 자체가 빨리 만료되므로, 폐기 메커니즘이 제대로 작동하지 않아도 보안 위험이 자연스럽게 줄어듭니다. #### 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\. 인증서 관리 자동화 촉진 역설적이게도 유효기간이 짧아질수록 **수동 관리가 불가능**해지고, **자동화가 필수**가 되면서 **더 안전한 운영이 가능**하게 됩니다.  ## 자동화 - 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)** * IETF 표준 프로토콜(RFC 8555, 2019년 3월 표준화) * 인증서 발급, 갱신, 폐기를 자동화 * Let's Encrypt가 주도하여 개발했으나, **업계 표준 프로토콜**이 됨 * **주요 지원 CA:** Let's Encrypt, ZeroSSL, Google Trust Services, Buypass 등 * **최신 확장:** RFC 9773 (ACME Renewal Information - ARI, 2025년 6월 발행) > **핵심**: ACME는 특정 CA 전용이 아닌, 어떤 CA든 구현할 수 있는 개방형 표준입니다. ### ACME와 인증서 검증 수준 **Let's Encrypt의 제약** * Let's Encrypt는 **DV (Domain Validated) 인증서만** 발급 * 도메인 소유권만 자동으로 검증 → 완전 자동화 가능 * OV/EV는 조직 실재 확인, 법적 서류 검토 등 **사람의 검증 필요** **기업 환경에서의 고려사항** ``` 일반적인 기업 인증서 정책 ──────────────────────── 외부 공개 서비스: 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 방식  ##### 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(공식 클라이언트) ```bash # 설치(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 제공자 플러그인 포함) * 대부분의 웹 서버 자동 설정 **단점** * Python 의존성 * 비교적 무거움 **자동 갱신 메커니즘** * Certbot 설치 시 **systemd timer** 자동 설정(`certbot.timer` - OS마다 동작이 달라서 확인 필요 "직접 확인 필수") * 하루 2회 실행, 만료 30일 이내 인증서 자동 갱신 > **DNS 제공자 플러그인 지원** > > * Certbot은 주요 DNS 제공자를 위한 공식 플러그인을 제공합니다 > * 지원 제공자: Route53, Google Cloud DNS, Azure DNS, DigitalOcean, Cloudflare 등(14개 공식 플러그인) > * DNS 플러그인을 사용하면 TXT 레코드를 자동으로 생성/삭제하여 완전 자동화 가능 > * 수동 DNS Challenge는 매번 직접 TXT 레코드를 추가해야 하므로 자동 갱신에는 적합하지 않음 > * 플러그인은 별도 설치 필요: `sudo apt install python3-certbot-dns-` > * 플러그인 목록은 [Certbot 문서](https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins) 참조 ### 2\. acme.sh (CLI 클라이언트) ```bash # 설치 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 ``` **장점** * 순수 Shell Script, 의존성 없음 * 50+ DNS 제공자 API 지원 * 빠르고 가벼움 **단점** * 자동 웹 서버 설정 미지원 **자동 갱신 메커니즘** * 설치 시 **cron job** 자동 등록(`crontab -l`로 확인) * 매일 실행, 만료 60일 이내 인증서 자동 갱신 > **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 문서](https://github.com/acmesh-official/acme.sh/wiki/dnsapi) 참조 ### 3\. cert-manager (Kubernetes) ```yaml # 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: [email protected] 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 ``` **장점** * Kubernetes 네이티브 * 완전 자동화 * 여러 Issuer 지원(Let's Encrypt, Vault, Venafi) **단점** * Kubernetes 전용 ## 자동화 구축 이제 본격적으로 ACME 자동화를 적용해 보겠습니다. 환경별 간단한 시나리오들을 몇 가지 가져왔습니다. ### 시나리오 1: 단일 도메인 ```bash # 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 ``` **자동 갱신 메커니즘** * systemd timer가 하루 2회 실행 * 만료 30일 전 자동 갱신 시작 * Nginx 설정 자동 업데이트 및 reload **결과** * 가장 간단한 설정으로 완전 자동화 * 서버별로 독립적으로 관리 * HTTP-01 Challenge 사용(포트 80 필요) ### 시나리오 2: Wildcard 도메인 ```bash # 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 등 활용) ``` **자동 갱신 메커니즘** * cron job이 매일 실행 * 만료 60일 전 자동 갱신 시작 * 갱신 시 reloadcmd로 서비스 자동 재시작 **결과** * 하나의 Wildcard 인증서로 여러 서브도메인 커버 * DNS-01 Challenge 사용(포트 80 불필요) * 중앙 서버에서 발급 후 배포 방식(Ansible 등 활용) ### 시나리오 3: Kubernetes 클러스터 ```yaml # 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: [email protected] privateKeySecretRef: name: letsencrypt-prod solvers: - http01: ingress: ingressClassName: nginx # 3. 이후 모든 Ingress에 annotation만 추가 # annotations: # cert-manager.io/cluster-issuer: "letsencrypt-prod" ``` **자동 갱신 메커니즘** * cert-manager controller가 주기적으로 인증서 상태 모니터링 * 만료 30일 전 자동 갱신 시작(기본값, 설정 가능) * 갱신된 인증서는 Secret에 자동 업데이트 **결과** * 새 도메인 추가 시 자동 인증서 발급 * 완전 자동 갱신(사람 개입 불필요) * Secret으로 저장되어 Pod에 자동 마운트 ## 인증서의 미래 전망 인증서는 앞으로 어떻게 변화할까요? 이미 시작된 변화의 물결을 간단히 살펴보겠습니다. ### 1\. Post-Quantum 암호화 (PQC) **NIST 표준 발표(2024년 8월)** * ML-DSA (디지털 서명, 구 CRYSTALS-Dilithium) - FIPS 204 * ML-KEM (키 캡슐화, 구 CRYSTALS-KYBER) - FIPS 203 * SLH-DSA (서명, 구 SPHINCS+) - FIPS 205 **현재 상황(2025년)** * Cloudflare: TLS 1.3 연결의 약 2%가 PQC 사용 중 * 주요 브라우저 지원 * Chrome 131+(2024년 11월): ML-KEM 하이브리드 지원 * Firefox 135+(2025년 2월): ML-KEM 하이브리드 지원 * OpenSSL 3.5.0+(2025년 4월): ML-KEM 하이브리드 지원 * Go 1.24+(2025년 2월): X25519MLKEM768 지원 **인증서 지원** * 현재: 주로 키 교환(ML-KEM) 단계에서 PQC 적용 중 * 미래: 디지털 서명(ML-DSA)까지 확대 * 전환 방식: 하이브리드 방식(기존 알고리즘 + PQC 조합) **타임라인** * 2030년: 기존 암호화 시스템 deprecated 예상 * 2035년: 기존 암호화 시스템 완전 폐기 예상 **짧은 유효기간의 이점:** PQC로의 빠른 전환 및 알고리즘 업그레이드 용이 ### 2\. 인증서 투명성(Certificate Transparency) 강화 **Certificate Transparency란?** * 모든 인증서 발급을 공개 로그에 기록하는 시스템 * Google이 주도하여 2013년 도입, 현재 업계 표준 * CA가 인증서를 발급하면 공개 로그 서버에 자동 기록 **왜 필요한가?** 2011년 DigiNotar 해킹 사건 ``` - 네덜란드 CA가 해킹 당해 *.google.com 등 500개 이상 위조 인증서 발급 - 이란 정부가 Gmail 등을 감청하는 데 사용 - 당시에는 발각하기 매우 어려웠음 ``` Certificate Transparency 도입 후 ``` * 모든 인증서가 공개 로그에 기록 * 도메인 소유자가 자신의 도메인에 대한 무단 발급을 즉시 탐지 가능 * 의심스러운 인증서 발견 시 즉시 폐기 요청 ``` **동작 방식** ``` 1. CA가 인증서 발급 시 CT 로그 서버에 제출 2. 로그 서버는 SCT(signed certificate timestamp) 발급 3. 브라우저는 SCT가 포함된 인증서만 신뢰 4. 누구나 로그를 조회하여 감시 가능 ``` **자동화와의 연결** * ACME로 발급된 모든 인증서도 CT 로그에 자동 기록 * 짧은 유효기간 + CT = 무단 발급 시도의 피해 최소화 * 모니터링 도구로 자신의 도메인 감시 가능(예: Facebook CT Monitor, crt.sh) ### 3\. ACME의 확장 **2025년 Let's Encrypt 새로운 기능** * **ACME Profiles** (2025년 1월 9일 발표): 클라이언트가 특정 프로필 요청 가능 * **6일 유효기간 인증서** (2025년 2월 첫 발급, 2025년 말부터 일반 제공 예정): 짧은 유효기간으로 폐기 불필요 * **IP 주소 인증서** (2025년 말 출시 예정): IP 주소가 포함된 SAN 인증서 발급(6일 인증서와 함께 제공) * **EKU 변경** (2026년 2월 11일): TLS Client Authentication EKU 제거 예정 **ACME 확장 방향** ``` 현재: 도메인 인증서 (TLS/SSL) 진행 중: IP 주소 인증서, 프로필 기반 인증서 미래 - 코드 서명 인증서 - 이메일 인증서(S/MIME) - 문서 서명 인증서 ``` **폐기 시스템의 중요도 감소** 점점 짧아지는 유효기간이 폐기 메커니즘을 대체하면서, Let's Encrypt는 OCSP URL을 완전히 제거하고 CRL Distribution Point만 제공하도록 전환했습니다. 인증서 자체가 빠르게 만료되므로, 폐기 시스템에 대한 의존도가 자연스럽게 줄어드는 추세입니다. ## 마치며 아쉽게도 인증서 유효기간의 단축은 귀찮은 변화가 아니라, **더 안전한 인터넷을 위한 필수 요소**입니다. 그리고 이 변화는 우리에게 자동화를 강제하면서, 결과적으로 더 신뢰할 수 있는 운영 환경을 만들어줍니다. **핵심 정리** ✅ 유효기간 단축은 보안 향상을 위한 불가피한 흐름 ✅ 자동화는 선택이 아닌 필수 ✅ ACME 프로토콜은 검증된 표준 솔루션 ✅ 지금 시작하면 미래 변화에 대비 가능 **인증서를 수동으로 갱신하던 시**는 이제 역사가 되어가고 있습니다. ACME 프로토콜과 자동화 도구의 개념을 확실히 이해하고, 지금부터 준비한다면 앞으로의 변화에 능동적으로 대응할 수 있습니다. 마지막으로 다음 글에서는 우리가 곧 마주하게 될(이미 마주한) **Zero Trust와 mTLS에 대한 내용**을 다뤄보도록 하겠습니다. 긴 글 읽어 주셔서 감사합니다. ## 참고 자료 ### 표준 및 규격 * [RFC 8555 - ACME Protocol](https://datatracker.ietf.org/doc/html/rfc8555) * [RFC 9773 - ACME Renewal Information (ARI)](https://datatracker.ietf.org/doc/html/rfc9773) * [CA/Browser Forum - Ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/#ballot-contents) ### 공식 문서 * [Let's Encrypt - Getting Started](https://letsencrypt.org/getting-started/) * [Certbot Documentation](https://eff-certbot.readthedocs.io/) * [acme.sh Documentation](https://github.com/acmesh-official/acme.sh) * [cert-manager Documentation](https://cert-manager.io/docs/) ### NHN Cloud 인증서 관리 서비스 살펴보기 > * [Certificate Manager](https://www.nhncloud.com/kr/service/management/certificate-manager): 인증서, 도메인 등 만료 기한이 있는 자산을 관리하고 만료일 알림을 제공하는 서비스 > * [Private CA](https://www.nhncloud.com/kr/service/management/private-ca): 조직 내·외부에서 사용하는 사설 인증서를 발급부터 폐기까지 자동화 및 표준화하는 서비스[](https://www.nhncloud.com/kr)