▲

6일짜리 및 IP 주소 인증서 일반 제공 개시

 (letsencrypt.org)
2P by GN⁺ 14시간전 | ★ favorite | 댓글 1개
  • 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년 연례 보고서에서 비영리 활동 전반을 확인 가능
▲
GN⁺ 14시간전  [-]
Hacker News 의견들

  • 오늘 기준으로 certbot으로는 IP 주소 인증서를 받을 수 없었음
    대신 lego를 사용했는데, 정확한 명령어를 찾는 데 꽤 시간이 걸렸음
    어제 성공한 명령은 다음과 같음
    lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived

    • 혹시 Caddy에서도 이 기능이 지원되는지 궁금했음
      아직 진행 중인 듯함 (GitHub 이슈)

  • 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보다 더 신뢰할 수 있음

  • IP 인증서를 원한다면 certbot은 아직 지원하지 않음
    관련 PR이 열려 있음 (#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 플러그인이 여러 제공자를 지원함
    • 이런 경우엔 사설 CA를 사용하는 것도 방법임
    • 내부망 주소는 외부에서 소유 증명을 할 수 없으니, 그냥 도메인을 쓰는 게 낫다고 생각함

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

  • IP 주소 인증서는 짧게 존재하는 서비스(ephemeral service) 가 TLS 통신을 할 때 유용함
    DNS 레코드를 따로 만들 필요가 없어서 수백 개의 임시 인스턴스를 띄울 때 편리함

    • Encrypted Client Hello(ECH) 에도 활용 가능함
      평문으로 노출되는 SNI 대신 IP 인증서를 사용하면, 외부에서 실제 호스트명을 볼 수 없음
      대형 클라우드가 아닌 소규모 사이트도 프록시 없이 ECH를 쓸 수 있게 됨
    • Let's Encrypt의 공식 발표에 다양한 사용 사례가 정리되어 있음
    • 등록기관 의존성이 없다는 점이 매력적임
      더 익명성이 높아짐
    • 사람을 대상으로 하지 않는 서비스라면 네임서버 의존성 제거가 특히 유용함
    • DNS over TLS나 DNS over HTTPS 같은 프로토콜에도 적용 가능함
답변달기