# Let's Encrypt, 6일짜리 및 IP 주소 인증서 일반 제공 개시

> Clean Markdown view of GeekNews topic #25900. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25900](https://news.hada.io/topic?id=25900)
- GeekNews Markdown: [https://news.hada.io/topic/25900.md](https://news.hada.io/topic/25900.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-17T15:32:54+09:00
- Updated: 2026-01-17T15:32:54+09:00
- Original source: [letsencrypt.org](https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability)
- Points: 14
- Comments: 1

## Summary

**Let's Encrypt**가 **6일짜리 단기 인증서**와 **IP 주소 기반 인증서**를 정식으로 제공하기 시작했습니다. 단기 인증서는 160시간만 유효해 자주 갱신하도록 설계되었으며, 이를 통해 폐기 절차의 불안정성에 의존하지 않고 보안을 강화합니다. IP 주소 인증서는 IPv4·IPv6 모두 지원하며, 주소 변동성을 고려해 단기 형태로만 발급됩니다. 이번 변화는 인증서 자동화와 짧은 수명 주기를 표준화하려는 **보안 인프라 전환의 신호탄**으로 평가됩니다.

## Topic Body

- **Let's Encrypt**가 **6일 유효기간의 단기 인증서**와 **IP 주소 기반 인증서**를 정식으로 제공 시작  
- 단기 인증서는 **160시간(약 6일 16시간)** 동안 유효하며, ACME 클라이언트에서 ‘shortlived’ 프로필을 선택해 발급 가능  
- 이 인증서는 **자주 갱신하도록 유도해 보안성을 강화**하고, **신뢰성 낮은 폐기(revocation) 절차 의존도를 줄이는 목적**  
- IP 주소 인증서는 **IPv4와 IPv6 모두 지원**하며, IP 주소의 변동성이 높아 **단기 인증서 형태로만 발급**  
- 이번 조치는 **자동화된 인증서 갱신 체계 확산과 보안 강화를 위한 단계적 변화**로 평가됨  

---

### 단기(6일) 인증서 제공
- **단기 인증서(short-lived certificate)** 는 160시간 동안 유효하며, 기존 90일 인증서보다 훨씬 짧은 수명  
  - ACME 클라이언트에서 **‘shortlived’ 인증서 프로필**을 선택하면 발급 가능  
- 이 인증서는 **더 자주 검증을 요구**함으로써 보안을 강화하고, **폐기 시스템의 불안정성 문제를 완화**  
  - 기존에는 개인키 유출 시 인증서 폐기가 필요했으나, 폐기 절차가 신뢰할 수 없어 만료 전까지 취약 상태가 지속될 수 있었음  
  - 단기 인증서 사용 시 이러한 **취약 기간이 크게 단축**됨  
- 단기 인증서는 **선택적(opt-in)** 방식이며, 기본값으로 전환할 계획은 없음  
  - **자동 갱신 프로세스를 완전히 구축한 사용자**는 손쉽게 전환 가능  
  - 하지만 모든 사용자가 짧은 수명에 익숙하지 않음을 고려해 **기본값은 유지**  
- 향후 몇 년 내에 **기본 인증서 유효기간을 90일에서 45일로 단축**할 예정  

### IP 주소 인증서
- **IP 주소 인증서(IP address certificate)** 는 **도메인 이름 대신 IP 주소로 TLS 연결을 인증**할 수 있게 함  
  - **IPv4와 IPv6 모두 지원**  
- IP 주소 인증서는 반드시 **단기 인증서 형태로만 발급**  
  - IP 주소는 도메인보다 **더 자주 변경되므로**, **빈번한 검증이 필요**하다는 이유  
- 관련 세부 정보와 사용 사례는 **2025년 7월 발표된 첫 IP 인증서 게시물**에서 확인 가능  

### 지원 및 후원
- 이번 개발은 **Open Technology Fund**, **Sovereign Tech Agency**, 그리고 **후원자 및 기부자**들의 지원으로 이루어짐  
- **Let's Encrypt**는 비영리 단체 **Internet Security Research Group (ISRG)** 이 운영하는 **무료·자동화·공개 인증기관(CA)**  
- ISRG의 2025년 연례 보고서에서 **비영리 활동 전반**을 확인 가능

## Comments



### Comment 49385

- Author: neo
- Created: 2026-01-17T15:32:54+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46647491) 
- 오늘 기준으로 **certbot**으로는 IP 주소 인증서를 받을 수 없었음  
  대신 [lego](https://go-acme.github.io/lego/)를 사용했는데, 정확한 명령어를 찾는 데 꽤 시간이 걸렸음  
  어제 성공한 명령은 다음과 같음  
  `lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived`
  - 혹시 **Caddy**에서도 이 기능이 지원되는지 궁금했음  
    아직 진행 중인 듯함 ([GitHub 이슈](https://github.com/caddyserver/caddy/issues/7399))

- IP 주소 인증서는 **iOS 사용자**가 직접 DoH 서버를 운영할 때 특히 흥미로운 주제임  
  iOS에서는 FQDN과 IP 모두에 올바른 인증서가 있어야 작동했음  
  그래서 dns4eu나 nextdns 같은 대형 서비스의 프로필은 잘 작동하지만, 개인이 만든 DoH 서버는 실패했음
  - **OpenSSL**이 TLS 연결 시 인증서의 SAN 필드에 IP 주소가 포함되어야 한다고 엄격히 요구함  
    아마 iOS 엔지니어가 명시적으로 추가한 게 아니라, 사용하는 **암호화 라이브러리의 부작용**일 가능성이 있음
  - 나는 개인 도메인을 리버스 프록시 뒤에서 DoH로 매일 사용 중인데 아무 문제 없음

- 왜 6일짜리 인증서인지 궁금했음  
  8일이면 주 단위로 갱신하기 좋고, 8은 **2의 거듭제곱**이자 행운의 숫자라 생각했음  
  하지만 6은 그냥 마음에 들지 않음
  - 6일 주기로 하면 장기적으로 부하가 주중에 **균등하게 분산**됨  
    8일이면 특정 요일에 트래픽이 몰릴 수 있음
  - 실제로는 6일이 아니라 약 **160시간(6.6일)** 임  
    160은 첫 11개의 소수의 합이자, 첫 세 소수의 세제곱 합이기도 함
  - 6일은 **신이 6일 일하고 7일째 쉬었다**는 상징도 있음
  - 6은 가장 작은 **완전수(perfect number)** 라서 완벽함의 상징임

- 다음으로는 **.onion 주소용 인증서** 발급에 집중하길 바람  
  .onion은 이미 키 쌍을 가지고 있어서 소유 증명이 DNS보다 더 신뢰할 수 있음
  - 관련 표준 문서와 사이트들  
    * [RFC 9799](https://datatracker.ietf.org/doc/html/rfc9799)  
    * [acmeforonions.org](https://acmeforonions.org)  
    * [Tor Project 연구 문서](https://onionservices.torproject.org/research/appendixes/acme/)
  - 하지만 Tor 자체가 이미 **암호화와 신원 검증**을 제공하므로 HTTPS가 꼭 필요하진 않다고 생각함

- IP 인증서를 원한다면 certbot은 아직 지원하지 않음  
  관련 PR이 열려 있음 ([#10495](https://github.com/certbot/certbot/pull/10495))  
  대신 **acme.sh**는 이미 지원하는 듯함
  - 현재 IP 주소를 지원하는 ACME 클라이언트로는 **acme.sh, lego, traefik, acmez, caddy, cert-manager**가 있음  
    certbot도 곧 지원될 것으로 기대함

- 나는 2주 갱신 주기로 테스트 중이었는데, 이제 인증서가 **6일짜리**로 나와서 당황했음  
  파이프라인이 실패하면 디버깅할 시간이 너무 짧음  
  IP가 도메인보다 더 **변동성이 크다**는 이유는 납득하기 어려움  
  VPS의 고정 IP는 그렇게 자주 바뀌지 않음
  - 하지만 AWS 같은 곳에서는 **Elastic IP**를 즉시 해제할 수 있음  
    만약 45일짜리 인증서를 발급받고 바로 IP를 반납하면, 다른 사용자가 그 IP를 쓰게 됨  
    그럼 남의 IP에 대한 유효한 인증서를 갖게 되는 셈이라 위험함
  - 클라우드 환경에서는 IP가 빠르게 재할당되므로 **6일도 긴 편**이라 생각함
  - 너무 짧은 인증서 수명은 현실적인 운영 방식과 맞지 않음  
    이런 정책은 현장의 실무를 잘 모르는 접근 같음
  - IP의 **소유 통제권**이 문제임  
    대부분의 서비스 운영자는 IP 자체를 직접 통제하지 않으므로, CA의 리스크를 줄이기 위한 조치임
  - EC2 인스턴스에 EIP를 연결하지 않으면 재시작 시 거의 항상 다른 IP를 받게 됨  
    악용은 어렵지만, 여전히 보안상 고려할 부분임

- IP 주소 인증서가 생기면 **IPsec 전송 모드**가 다시 주목받을 수 있을지 궁금했음  
  내가 작성한 RFC 5660도 관련 있음
  - 하지만 현실적으로는 이미 **SDN이나 site-to-site VPN**이 충분히 보급되어 있음  
    IPsec 터널에 인증서를 쓰게 하는 것도 여전히 번거로움  
    일부 방화벽 장비는 인증서 체인이 길면 인증 실패를 일으키는 이상한 버그도 있음
  - **IPSec 표준**은 너무 크고 복잡하며, 만든 회사조차 수십 년간 CVE를 계속 받았음

- IP 인증서는 인터넷에서 접근 가능한 주소만 가능하므로, **LAN 기기용 TLS**는 여전히 어려움
  - **IPv6**를 쓰면 외부 노출 없이도 가능함  
    엣지에서 DNAT로 트래픽을 받아 인증서 갱신용 VM으로 전달하고, 내부 기기로 분배하면 됨
  - 나는 집 네트워크용으로 **와일드카드 인증서**(`*.home.example.com`)를 사용 중임  
    TXT 레코드를 API로 설정할 수 있는 공개 DNS가 필요하지만, [lego의 DNS 플러그인](https://go-acme.github.io/lego/dns/)이 여러 제공자를 지원함
  - 이런 경우엔 **사설 CA**를 사용하는 것도 방법임
  - 내부망 주소는 외부에서 소유 증명을 할 수 없으니, 그냥 도메인을 쓰는 게 낫다고 생각함

- 이번 발표가 정말 반가움  
  IP 인증서는 **self-hosted 소프트웨어의 초기 부트스트랩 문제**를 해결해줌  
  예를 들어 TakingNames의 [instant subdomains 기능](https://takingnames.io/blog/instant-subdomains)을 더 이상 필요로 하지 않을 수도 있음

- IP 주소 인증서는 **짧게 존재하는 서비스(ephemeral service)** 가 TLS 통신을 할 때 유용함  
  DNS 레코드를 따로 만들 필요가 없어서 수백 개의 임시 인스턴스를 띄울 때 편리함
  - **Encrypted Client Hello(ECH)** 에도 활용 가능함  
    평문으로 노출되는 SNI 대신 IP 인증서를 사용하면, 외부에서 실제 호스트명을 볼 수 없음  
    대형 클라우드가 아닌 **소규모 사이트**도 프록시 없이 ECH를 쓸 수 있게 됨
  - [Let's Encrypt의 공식 발표](https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate#how-let-s-encrypt-subscribers-may-use-ip-address-certs)에 다양한 사용 사례가 정리되어 있음
  - **등록기관 의존성**이 없다는 점이 매력적임  
    더 **익명성**이 높아짐
  - 사람을 대상으로 하지 않는 서비스라면 **네임서버 의존성 제거**가 특히 유용함
  - DNS over TLS나 DNS over HTTPS 같은 프로토콜에도 적용 가능함
