▲

NGINX, ACME 프로토콜 기본 지원 도입

 (blog.nginx.org)
3P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • NGINX가 SSL/TLS 인증서 발급·갱신을 자동화하는 ACME 프로토콜을 네이티브로 지원하는 프리뷰 버전을 공개함
  • Rust 기반의 신규 모듈 ngx_http_acme_module 을 통해 외부 툴 없이 NGINX 설정만으로 인증서 요청·설치·갱신이 가능해짐
  • 이를 통해 Certbot 같은 외부 툴 의존을 줄이고, 보안성과 플랫폼 독립성이 높아짐
  • 초기 버전은 HTTP-01 챌린지를 지원하며, TLS-ALPN·DNS-01 지원은 향후 계획됨
  • ACME 지원은 웹뿐만 아니라 IoT·에지 컴퓨팅 환경의 보안 자동화에도 중요한 역할을 할 것으로 기대됨

개요 및 주요 변화

  • NGINX가 ACME 프로토콜 지원 기능의 프리뷰 버전을 공개함
  • 새로운 모듈인 ngx_http_acme_module을 통해 NGINX 설정에서 인증서 요청, 설치, 갱신을 직접 처리할 수 있게 설계됨
  • 이 ACME 지원은 내부적으로 NGINX-Rust SDK를 활용하며, Rust 기반의 동적 모듈 형태로 제공됨
  • 오픈소스 사용자 뿐만 아니라 NGINX Plus 엔터프라이즈 고객 모두 이 기능을 사용할 수 있음
  • 기존 Certbot과 같은 외부 툴에 대한 의존도를 줄임으로써, 인증서 관리의 보안성과 효율성을 높임

ACME 프로토콜 소개

  • ACME(Automated Certificate Management Environment) 프로토콜은 SSL/TLS 인증서의 발급, 검증, 갱신, 폐기를 자동화하는 통신 프로토콜임
  • 클라이언트가 CA(Certificate Authority)와의 자동화 통신을 통해 직접 중간자의 수작업 없이 인증서 라이프사이클을 관리할 수 있음
  • Internet Security Research Group(ISRG) 이 2015년 Let’s Encrypt 프로젝트로 개발 및 공개함
  • ACME의 등장 전에는 인증서 발급 과정이 수동적이고 비용과 오류 가능성이 높았음
  • 최신 ACMEv2는 인증 방식, 와일드카드 지원 등 다양한 기능이 추가되어 유연성과 보안성이 증가함

NGINX의 ACME 기반 인증서 자동화 흐름

  • NGINX에서 ACME 프로토콜을 활용한 인증서 라이프사이클 자동화는 아래 4단계로 이루어짐

  • 1. ACME 서버 설정

    • ACME 기능 활성화를 위해서는acme_issuer로 ACME 서버의 디렉터리 URL을 반드시 지정해야 함
    • 인증서 이슈 발생 시 클라이언트 연락 정보, 상태 데이터 저장 경로 등도 옵션으로 지정 가능

  • 2. 공유 메모리(zone) 할당

    • acme_shared_zone으로 인증서와 개인키, 챌린지 데이터 저장을 위한 공유 메모리 zone을 추가로 설정 가능
    • 기본 사이즈는 256K이며 필요에 따라 증설 가능

  • 3. 챌린지(Challenge) 구성

    • 현재 프리뷰 버전은 HTTP-01 챌린지만 지원하며, 도메인 소유권 검증에 사용됨
    • 이를 위해 NGINX 설정에서 포트 80 리스너와 기본 404 응답 설정을 정의해야 함
    • 추후 TLS-ALPN, DNS-01 챌린지 지원 예정

  • 4. 인증서 발급 및 갱신

    • acme_certificate 디렉티브를 서버 블록에 추가하면, 해당 도메인에 대해 TLS 인증서 발급/갱신 자동화 가능
    • 인증서 발급 대상 도메인은 일반적으로 server_name으로 명시함
    • server_name에서 정규표현식, 와일드카드는 프리뷰 버전에서 지원되지 않음
    • 모듈 내 변수 $acme_certificate, $acme_certificate_key를 통해 자동으로 인증서와 키가 연결됨

주요 장점

  • 전 세계 HTTPS 사용 급증의 중심에는 ACME 프로토콜이 있음
  • 자동화된 인증서 관리로 인증서 라이프사이클 관리 비용 및 수작업에 의한 오류가 현격하게 줄어듦
  • 외부 툴 제거로 공격 표면 축소 및 이식성 확보
  • 다양한 환경에서의 보안 표준화 촉진

향후 계획

  • TLS-ALPN, DNS-01 챌린지 지원 추가 예정
  • 사용자 피드백 기반으로 기능 확장
  • IoT, API, 엣지 컴퓨팅 도입 확대에 따라, ACME는 향후 더욱 넓은 범위의 자동화 보안 인프라에서 핵심 역할을 담당할 것으로 예상됨
  • NGINX의 네이티브 ACME 지원은 웹 보안과 자동화, 확장성을 미래 표준으로 만들어가는 기반 역할을 할 것

시작하기

  • 오픈소스 사용자는 NGINX Linux 패키지에서 프리빌트 모듈 사용 가능
  • NGINX Plus 엔터프라이즈 고객은 F5 지원 동적 모듈 형태로 제공
  • 모듈 문서는 NGINX Docs 참고
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • 현재 프리뷰 버전에서는 HTTP-01 챌린지만 지원하여 클라이언트 도메인 소유권을 검증함
    DNS-01 방식이 퍼블릭하게 열리지 않은 nginx 사용자에게는 훨씬 의미 있는 기능임(예: Nginx Proxy Manager 사용 시). DNS-01은 단순히 레코드만 업데이트하는 방식이라 항상 제일 깔끔하다고 생각해왔음. 이 기능이 도입되길 정말 기다림
    • 하지만 dns api key를 반드시 보유해야 하며, 많은 dns 제공업체는 zone별로 별도의 api key를 제공하지 않음. 개인적으로 DNS-01을 좋아하지만 현실적으로 아쉬운 타협이 필요할 수 있음
    • 기다릴 필요 없음: angie에서도 지원함 (angie는 원래 nginx 개발자들이 f5에서 나와서 만든 nginx 포크임)
    • Traefik의 ACME 관련 아쉬운 점은 DNS 제공업체당 하나의 api key만 사용할 수 있다는 점임. 이 때문에 도메인별로 api key를 제한하거나, 여러 계정의 도메인을 쓰는 경우 제약이 많음. Nginx는 이런 제한 없이 나오길 기대함
    • 개인적으로 homelab에서는 step-ca와 caddy 조합으로 dns01을 사용 중임. 매우 만족스러운 경험임
    • DNS-01을 아주 잘 지원하니 Angie로 넘어가는 것도 추천함
  • 이건 꽤 큰 변화임. Caddy는 예전부터 지원해왔지만, 모두가 caddy를 선호하는 것은 아님. 이번 업그레이드는 Traefik 같은 소프트웨어의 점유율을 뺏어올 가능성이 있음
    • Caddy의 깔끔한 문법이 특히 마음에 듦. 현재 nginx(nginx proxy manager를 통해)와 Traefik을 쓰지만 최근에는 Caddy로 프로젝트를 해봤는데 아주 쾌적했음. 앞으로 시간 나면 selfhosted 환경을 Caddy로 전환하고 싶음. 혹은 pangolin 같은 걸 쓸 수도 있을 듯. pangolin은 cloudflare tunnels의 대안까지 제공함
    • 최근에 caddy로 아예 넘어옴. nginx의 http 1 desync 문제 관련 소극적 대응이 결정적 계기였음. 문제 생길 때까지 기다리거나, auditor가 물어봐도 nginx가 확실히 답변해주지 않는 상황은 싫음.
      Caddy는 nginx보다 확실히 쉬움. 각종 서비스와 테스트, 교육기관용 특별 서비스까지 커버하는 템플릿과 더 나은 로깅, 본인에게는 완벽한 인증서 처리, 더 좋은 메트릭스 기능을 제공함.
      다만 아직 플러그인 쪽은 공부 중인데, caddy는 rate limiting이 없고, powerbi의 버그로 인해 특정 사용자가 이미지를 하루에 30만 번 요청하는 상황 때문에 불편함도 있음
    • 확실히 그렇다고 생각함. 집에서는 traefik을 일부 사용 중인데, 이제는 바로 대체할 것 같음
  • 환영할 만한 변화임. Dokku(내가 메인테이너임)는 letsencrypt 플러그인으로 임시방편을 쓰고 있는데, 사용자들이 랜덤한 이슈를 겪는 경우가 많았음.nginx가 reload 도중 종종 "멈춰서" 엔드포인트를 못 찾는 현상도 있음.이런 복잡한 변수가 적을수록 좋은 방향임
    하지만 이 기능이 Ubuntu나 Debian의 stable repository에 들어가기까지는 시간이 꽤 걸릴 것임.
    게다가 아직 DNS 챌린지(와일드카드 인증서)가 지원되지 않아 단기적으로는 Dokku엔 큰 도움이 되지 않을 듯함
    • 안녕하세요! 이렇게 여기서 뵙게 돼서 반가움
      dokku를 시도(지금도 시도 중)해보고 있는데, 진입장벽이 꽤 높게 느껴졌음
      예를 들어, Coolify는 github app을 만들면 바로 배포를 연동할 수 있었고, GH actions로 컨테이너를 빌드/배포 하는 경험도 있음.
      dokku 공식 문서는 참고서 느낌이라 백과사전 읽는 기분임: dokku git 초기화 공식문서
      Coolify처럼 바로 배포를 도와주는 즉각적인 안내(definitive getting started)가 더 유용하다고 느낌: coolify github 연동 도움말
      Dokku에 인기 OSS앱 설치, 단계별 목표/완료 방식의 입문 가이드, baremetal 환경에서 리버스 프록시와 여러 인기앱까지 한번에 다루는 튜토리얼이 있었으면 좋겠음
      결국 Dokku를 쓰는 목적은 Dokku 자체가 아니라, Dokku로 쉽고 빠르게 "내가 원하는 상태"까지 도달하는 것임
      최종적으로는 "마음에 드는 레포를 클릭하면 바로 내 머신에 배포" 가능한 painless 프로세스를 원함. 그 후에 뒷단 세부를 파고들고 싶음
  • 좋은 소식임. 혹시 모르는 사람들을 위해 소개하자면 dehydrated라는 손쉬운 솔루션이 있었음. vhost 설정에 몇 줄만 추가하면 됨: 
      location ^~ /.well-known/acme-challenge/ {  
    alias ;  
  }
    dehydrated는 오래전부터 HTTP-01 갱신 자동화에 쓰이는 가벼운 툴임
    • 기능 자체는 정말 멋진데, 수천 명이 의존하는 프로젝트가 안정(Stable) 릴리스를 계속 내놓지 않는 상황은 아쉬움
      v1.0.0 정식 릴리스 없는 소프트웨어는 인터페이스가 언제든 예고 없이 바뀔 수 있음. 메이저 버전 0은 언젠간 함정이 됨.
      유지보수자들에게 안정적 버전 릴리스를 요구하길 권장함.
      dehydrated는 7년 째 major version 0 상태임
      0ver.org도 참고할 만함:
      "프로덕션에서 쓰고 있다면 이미 1.0.0이 되어야 한다"는 식의 버저닝 철학임
      더 자세한 내용은 여기 참고
  • 이번 릴리스에 작은 실수가 있었음: ngx_http_acme_module는 여러 리눅스 배포판 패키지로 포함됐지만, Debian stable만 빠져 있음
    nginx 공식 패키지 목록에 따르면 oldstable/oldoldstable은 있는데 4일 전에 출시된 Debian 13 Trixie는 없음
    • 지금 Trixie 패키지 업로드 작업 중임. 이번 주 내에 올라갈 예정임. Debian 13이 출시된 지 4일밖에 안 됐으니 새 OS용 인프라 세팅에 시간이 필요했음. (본인은 F5 근무자임)
    • 아마 그건 Debian 측 실수라고 생각함
  • Caddy를 알게 된 이후로 nginx를 더 이상 쓰지 않음. 개발 경험이 훨씬 나아짐
  • 오픈소스 대기업의 문제는 ‘기본적인 혁신’을 제대로 이해하고 구현하는 데 항상 늦는다는 것임
    Caddy와 Traefik이 5년 전에 이미 했던 것을 이제서야 nginx가 지원하게 됨.
    물론 좋은 변화라고 생각함. 이제 더 이상 certbot을 직접 실행하지 않아도 되니까 편해짐
    • 실제로 Caddy는 거의 10년 전인 2016년에 Let’s Encrypt의 자동 HTTPS를 어느 정도 지원했었음.
      Nginx는 거의 9~10년 늦게 해당 기능을 도입하는 셈임
  • 개인적으로는 nginx가 웹 콘텐츠 서빙만 하고 certbot이 갱신을 처리하는 방식이 오히려 문제라고 느낀 적이 없음
    원래 한 가지 일을 잘하고 조합할 수 있는 유닉스 철학이 더 낫다고 생각함
    온갖 기능을 다 붙이는 ‘툴’은 필연적으로 어느 한 부분에서 부족해질 수밖에 없음
    • certbot으로 세팅하는 게 꽤 번거로운 경험임
      certbot이 자동 설정을 시도해도 대부분의 기본 환경이 아니면 잘 동작하지 않음
      nginx 안에서 전부 직접 처리하는 게 오히려 더 나은 솔루션으로 느껴짐
  • 즉, 이 기능 도입으로 nginx 설정 파일에 몇 줄만 추가하면 certbot을 설치/운영할 필요가 없어졌다는 의미로 이해함
    또한 Let's Encrypt 외의 대안도 쉽게 사용할 수 있는 길이 열렸는지 궁금함
  • 기대되는 변화임
    Caddy는 바로 쓸 수 있는 편의 기능들이 많아서 정말 유용함
    개인적으로 Caddy로 완전히 전환하지 못한 이유는 nginx의 rate limiting 및 geo 모듈에 대한 필요 때문임
답변달기