NGINX giới thiệu hỗ trợ gốc cho giao thức ACME

• NGINX đã công bố bản preview hỗ trợ gốc giao thức ACME để tự động hóa việc cấp và gia hạn chứng chỉ SSL/TLS
• Thông qua mô-đun mới ngx_http_acme_module dựa trên Rust, giờ đây có thể yêu cầu, cài đặt và gia hạn chứng chỉ chỉ bằng cấu hình NGINX mà không cần công cụ bên ngoài
• Nhờ đó, giảm phụ thuộc vào các công cụ bên ngoài như Certbot, đồng thời tăng cường bảo mật và tính độc lập nền tảng
• Phiên bản đầu tiên hỗ trợ HTTP-01 challenge; hỗ trợ TLS-ALPN và DNS-01 được lên kế hoạch cho tương lai
• Hỗ trợ ACME được kỳ vọng sẽ đóng vai trò quan trọng trong việc tự động hóa bảo mật không chỉ trên web mà còn trong môi trường IoT và edge computing

---

Tổng quan và các thay đổi chính

• NGINX đã công bố bản preview của tính năng hỗ trợ giao thức ACME
• Thông qua mô-đun mới ngx_http_acme_module, NGINX được thiết kế để xử lý trực tiếp việc yêu cầu, cài đặt và gia hạn chứng chỉ ngay trong cấu hình
• Hỗ trợ ACME này sử dụng nội bộ NGINX-Rust SDK và được cung cấp dưới dạng mô-đun động dựa trên Rust
• Không chỉ người dùng mã nguồn mở mà cả khách hàng doanh nghiệp NGINX Plus đều có thể sử dụng tính năng này
• Bằng cách giảm phụ thuộc vào các công cụ bên ngoài như Certbot, tính bảo mật và hiệu quả của việc quản lý chứng chỉ được nâng cao

Giới thiệu về giao thức ACME

• Giao thức ACME (Automated Certificate Management Environment) là giao thức truyền thông tự động hóa việc cấp, xác minh, gia hạn và thu hồi chứng chỉ SSL/TLS
• Client có thể trực tiếp quản lý vòng đời chứng chỉ thông qua giao tiếp tự động với CA (Certificate Authority) mà không cần thao tác thủ công của bên trung gian
• Internet Security Research Group (ISRG) đã phát triển và công bố giao thức này vào năm 2015 thông qua dự án Let’s Encrypt
• Trước khi ACME xuất hiện, quá trình cấp chứng chỉ mang tính thủ công, tốn kém và dễ phát sinh lỗi
• ACMEv2 mới nhất bổ sung nhiều tính năng như phương thức xác thực và hỗ trợ wildcard, giúp tăng tính linh hoạt và bảo mật

Quy trình tự động hóa chứng chỉ dựa trên ACME của NGINX

• Việc tự động hóa vòng đời chứng chỉ bằng giao thức ACME trong NGINX diễn ra qua 4 bước sau

• 1. Cấu hình máy chủ ACME

  • Để kích hoạt tính năng ACME, bắt buộc phải chỉ định directory URL của máy chủ ACME bằng acme_issuer
  • Khi có sự cố phát hành chứng chỉ, cũng có thể tùy chọn chỉ định thông tin liên hệ client, đường dẫn lưu dữ liệu trạng thái, v.v.

• 2. Cấp phát bộ nhớ dùng chung (zone)

  • Có thể cấu hình thêm shared memory zone để lưu chứng chỉ, khóa riêng và dữ liệu challenge bằng acme_shared_zone
  • Kích thước mặc định là 256K và có thể mở rộng khi cần

• 3. Cấu hình challenge

  • Bản preview hiện tại chỉ hỗ trợ HTTP-01 challenge, được dùng để xác minh quyền sở hữu tên miền
  • Vì vậy, cần định nghĩa listener cổng 80 và cấu hình phản hồi 404 mặc định trong cấu hình NGINX
  • Trong tương lai sẽ hỗ trợ thêm TLS-ALPN, DNS-01 challenge

• 4. Cấp và gia hạn chứng chỉ

  • Nếu thêm directive acme_certificate vào server block, có thể tự động hóa việc cấp/gia hạn chứng chỉ TLS cho tên miền tương ứng
  • Tên miền mục tiêu cấp chứng chỉ thường được chỉ định bằng server_name
  • Biểu thức chính quy và wildcard trong server_name chưa được hỗ trợ ở bản preview
  • Thông qua các biến trong mô-đun $acme_certificate, $acme_certificate_key, chứng chỉ và khóa sẽ được liên kết tự động

Các ưu điểm chính

• Giao thức ACME là trung tâm của sự bùng nổ sử dụng HTTPS trên toàn cầu
• Tự động hóa quản lý chứng chỉ giúp giảm mạnh chi phí quản lý vòng đời chứng chỉ và lỗi do thao tác thủ công
• Loại bỏ công cụ bên ngoài giúp thu hẹp bề mặt tấn công và đảm bảo tính di động
• Thúc đẩy chuẩn hóa bảo mật trong nhiều môi trường khác nhau

Kế hoạch tiếp theo

• Dự kiến bổ sung hỗ trợ TLS-ALPN và DNS-01 challenge
• Mở rộng tính năng dựa trên phản hồi của người dùng
• Khi việc áp dụng IoT, API, edge computing tiếp tục mở rộng, ACME được kỳ vọng sẽ giữ vai trò then chốt trong hạ tầng bảo mật tự động hóa trên phạm vi rộng hơn trong tương lai
• Hỗ trợ ACME gốc của NGINX sẽ đóng vai trò nền tảng trong việc biến bảo mật web, tự động hóa và khả năng mở rộng thành tiêu chuẩn tương lai

Bắt đầu

• Người dùng mã nguồn mở có thể dùng mô-đun dựng sẵn tại NGINX Linux packages
• Khách hàng doanh nghiệp NGINX Plus được cung cấp dưới dạng mô-đun động có hỗ trợ từ F5
• Xem tài liệu mô-đun tại NGINX Docs

[GN⁺]

Ý kiến trên Hacker News

• Ở bản preview hiện tại chỉ hỗ trợ thử thách HTTP-01 để xác minh quyền sở hữu tên miền của client.
  Phương thức DNS-01 có ý nghĩa hơn nhiều với những người dùng nginx không public mở ra ngoài (ví dụ: khi dùng Nginx Proxy Manager). DNS-01 chỉ đơn giản là cập nhật bản ghi nên tôi luôn thấy đó là cách gọn gàng nhất. Tôi thực sự đã chờ tính năng này được đưa vào.
  • Nhưng bắt buộc phải có dns api key, và nhiều nhà cung cấp dns không cấp api key riêng theo từng zone. Cá nhân tôi thích DNS-01, nhưng trên thực tế có thể cần một sự thỏa hiệp chưa thật sự lý tưởng.
  • Không cần phải chờ: angie cũng hỗ trợ (angie là một bản fork của nginx do các nhà phát triển nginx gốc rời f5 để tạo ra)
  • Điểm tôi chưa hài lòng ở ACME của Traefik là chỉ có thể dùng một api key cho mỗi nhà cung cấp DNS. Vì vậy sẽ bị hạn chế khá nhiều nếu muốn giới hạn api key theo từng tên miền, hoặc khi dùng tên miền thuộc nhiều tài khoản khác nhau. Tôi hy vọng Nginx sẽ không có giới hạn như vậy.
  • Cá nhân tôi đang dùng dns01 với bộ đôi step-ca và caddy trong homelab. Trải nghiệm rất hài lòng.
  • Angie hỗ trợ DNS-01 rất tốt nên tôi cũng khuyên nên chuyển sang Angie.
• Đây là một thay đổi khá lớn. Caddy đã hỗ trợ từ lâu, nhưng không phải ai cũng thích caddy. Bản nâng cấp lần này có thể lấy bớt thị phần của những phần mềm như Traefik.
  • Tôi đặc biệt thích cú pháp gọn gàng của Caddy. Hiện tôi dùng nginx (thông qua nginx proxy manager) và Traefik, nhưng gần đây có thử làm dự án với Caddy và thấy rất dễ chịu. Nếu có thời gian, sau này tôi muốn chuyển môi trường self-hosted sang Caddy. Hoặc có thể dùng thứ gì đó như pangolin. pangolin còn cung cấp cả giải pháp thay thế cho cloudflare tunnels.
  • Gần đây tôi đã chuyển hẳn sang caddy. Yếu tố quyết định là cách phản hồi thiếu tích cực của nginx về vấn đề desync trong http 1. Tôi không thích tình huống phải chờ đến khi sự cố xảy ra, hoặc khi auditor hỏi thì nginx cũng không trả lời rõ ràng.
    Caddy chắc chắn dễ hơn nginx. Nó cung cấp template bao quát nhiều loại dịch vụ, cả test, cả dịch vụ đặc biệt cho tổ chức giáo dục, logging tốt hơn, xử lý chứng chỉ hoàn hảo với tôi, và tính năng metrics tốt hơn.
    Tuy vậy tôi vẫn đang tìm hiểu phần plugin; caddy không có rate limiting, và do bug của powerbi nên có người dùng nào đó đang yêu cầu ảnh tới 300.000 lần mỗi ngày, khiến tôi cũng thấy khá bất tiện.
  • Tôi cũng thực sự nghĩ vậy. Ở nhà tôi đang dùng traefik một phần, nhưng giờ có lẽ sẽ thay thế ngay.
• Đây là thay đổi đáng hoan nghênh. Dokku (tôi là maintainer) hiện đang dùng plugin letsencrypt như một giải pháp tạm, và người dùng thường gặp khá nhiều lỗi ngẫu nhiên. Cũng có hiện tượng nginx đôi khi bị "treo" trong lúc reload nên không tìm được endpoint. Càng ít biến số phức tạp kiểu này thì càng tốt.
  Tuy nhiên sẽ còn khá lâu trước khi tính năng này có mặt trong stable repository của Ubuntu hay Debian.
  Hơn nữa hiện vẫn chưa hỗ trợ thử thách DNS (chứng chỉ wildcard), nên trong ngắn hạn có lẽ chưa giúp được nhiều cho Dokku.
  • Xin chào! Rất vui được gặp anh ở đây như thế này.
    Tôi đã thử Dokku (và vẫn đang thử), nhưng cảm giác rào cản ban đầu khá cao.
    Ví dụ như với Coolify, chỉ cần tạo github app là có thể gắn ngay vào luồng deploy, và tôi cũng từng có trải nghiệm build/deploy container bằng GH actions.
    Tài liệu chính thức của dokku giống kiểu tài liệu tra cứu nên đọc có cảm giác như đang xem bách khoa toàn thư: tài liệu chính thức về khởi tạo git của dokku
    Tôi thấy một hướng dẫn nhập môn rõ ràng, đi thẳng vào việc deploy ngay như Coolify sẽ hữu ích hơn: hướng dẫn tích hợp github của coolify
    Sẽ thật tốt nếu Dokku có hướng dẫn cài các ứng dụng OSS phổ biến, tài liệu nhập môn theo từng bước với mục tiêu/hoàn thành rõ ràng, và tutorial xử lý một lượt từ reverse proxy đến nhiều ứng dụng phổ biến trong môi trường baremetal.
    Cuối cùng, mục tiêu dùng Dokku không phải là bản thân Dokku, mà là đạt đến "trạng thái tôi mong muốn" một cách dễ và nhanh nhờ Dokku.
    Về lâu dài, tôi muốn một quy trình painless kiểu "bấm vào repo mình thích là triển khai ngay lên máy của tôi". Sau đó tôi mới muốn đào sâu các chi tiết phía sau.
• Tin tốt đấy. Để giới thiệu cho ai chưa biết thì trước đây đã có một giải pháp đơn giản là dehydrated. Chỉ cần thêm vài dòng vào cấu hình vhost:

    location ^~ /.well-known/acme-challenge/ {  
      alias ;  
    }  
  

  dehydrated là một công cụ nhẹ đã được dùng từ lâu để tự động hóa gia hạn HTTP-01.
  • Bản thân tính năng thì rất hay, nhưng hơi đáng tiếc khi một dự án mà hàng nghìn người phụ thuộc vẫn không liên tục phát hành bản Stable.
    Phần mềm chưa có bản phát hành chính thức v1.0.0 thì giao diện có thể thay đổi bất kỳ lúc nào mà không báo trước. Major version 0 sớm muộn cũng thành cái bẫy.
    Tôi khuyên nên yêu cầu các maintainer phát hành bản ổn định.
    dehydrated đã ở major version 0 suốt 7 năm.
    0ver.org cũng đáng xem:
    Đó là một triết lý versioning kiểu "nếu đang dùng trong production thì lẽ ra nó phải là 1.0.0 rồi".
    Xem thêm chi tiết tại đây
• Có một sai sót nhỏ trong đợt phát hành này: ngx_http_acme_module đã được đưa vào package của nhiều bản phân phối Linux, nhưng lại thiếu Debian stable.
  Theo danh sách package chính thức của nginx thì có oldstable/oldoldstable, nhưng lại không có Debian 13 Trixie vừa phát hành cách đây 4 ngày.
  • Hiện chúng tôi đang làm việc để upload package cho Trixie. Dự kiến sẽ có trong tuần này. Debian 13 mới ra được 4 ngày nên cần thời gian để thiết lập hạ tầng cho OS mới. (Tôi làm ở F5)
  • Tôi nghĩ có lẽ đó là do phía Debian làm sai.
• Từ khi biết đến Caddy, tôi không còn dùng nginx nữa. Trải nghiệm phát triển tốt hơn hẳn.
• Vấn đề của các ông lớn mã nguồn mở là họ luôn chậm trong việc hiểu và triển khai đúng kiểu “đổi mới cơ bản”.
  Những gì Caddy và Traefik đã làm từ 5 năm trước thì giờ nginx mới hỗ trợ.
  Dù vậy tôi vẫn thấy đây là thay đổi tích cực. Giờ sẽ tiện hơn vì không còn phải tự chạy certbot nữa.
  • Thực ra Caddy đã hỗ trợ tự động HTTPS của Let’s Encrypt ở một mức độ nào đó từ tận năm 2016, tức gần 10 năm trước.
    Nginx coi như đang đưa tính năng này vào muộn hơn khoảng 9~10 năm.
• Cá nhân tôi chưa từng thấy mô hình để nginx chỉ phục vụ nội dung web còn certbot lo việc gia hạn là một vấn đề.
  Tôi vẫn nghĩ triết lý Unix, mỗi thứ làm tốt một việc và có thể ghép với nhau, là tốt hơn.
  Một “công cụ” ôm đồm đủ mọi chức năng thì sớm muộn cũng sẽ có phần nào đó làm chưa tốt.
  • Việc thiết lập bằng certbot là một trải nghiệm khá phiền.
    Dù certbot có cố tự cấu hình thì hễ lệch khỏi môi trường mặc định là phần lớn sẽ không hoạt động tốt.
    Cảm giác để mọi thứ được xử lý trực tiếp trong nginx lại là một giải pháp tốt hơn.
• Vậy tôi hiểu là với tính năng này, chỉ cần thêm vài dòng vào file cấu hình nginx là không còn phải cài/vận hành certbot nữa đúng không?
  Tôi cũng tò mò liệu việc này có mở ra con đường để dễ dàng dùng các lựa chọn thay thế ngoài Let's Encrypt hay không.
• Đây là thay đổi đáng mong đợi.
  Caddy rất hữu ích vì có nhiều tính năng tiện lợi dùng được ngay.
  Lý do cá nhân tôi vẫn chưa thể chuyển hẳn sang Caddy là vì còn cần rate limiting và module geo của nginx.