NGINX memperkenalkan dukungan bawaan untuk protokol ACME

• NGINX merilis versi pratinjau yang secara native mendukung protokol ACME untuk mengotomatisasi penerbitan dan pembaruan sertifikat SSL/TLS
• Melalui modul baru berbasis Rust ngx_http_acme_module, permintaan, pemasangan, dan pembaruan sertifikat kini dapat dilakukan hanya dengan konfigurasi NGINX tanpa alat eksternal
• Dengan ini, ketergantungan pada alat eksternal seperti Certbot berkurang, sekaligus meningkatkan keamanan dan kemandirian platform
• Versi awal mendukung HTTP-01 challenge, sementara dukungan TLS-ALPN dan DNS-01 direncanakan untuk tahap berikutnya
• Dukungan ACME diharapkan memainkan peran penting dalam otomatisasi keamanan tidak hanya untuk web, tetapi juga di lingkungan IoT dan edge computing

---

Ikhtisar dan perubahan utama

• NGINX merilis versi pratinjau fitur dukungan protokol ACME
• Melalui modul baru ngx_http_acme_module, NGINX dirancang agar dapat menangani permintaan, pemasangan, dan pembaruan sertifikat langsung dari konfigurasi NGINX
• Dukungan ACME ini secara internal memanfaatkan NGINX-Rust SDK dan disediakan dalam bentuk modul dinamis berbasis Rust
• Fitur ini dapat digunakan baik oleh pengguna open source maupun pelanggan enterprise NGINX Plus
• Dengan mengurangi ketergantungan pada alat eksternal seperti Certbot, keamanan dan efisiensi pengelolaan sertifikat meningkat

Pengenalan protokol ACME

• Protokol ACME (Automated Certificate Management Environment) adalah protokol komunikasi yang mengotomatisasi penerbitan, verifikasi, pembaruan, dan pencabutan sertifikat SSL/TLS
• Klien dapat mengelola siklus hidup sertifikat secara langsung melalui komunikasi otomatis dengan CA (Certificate Authority) tanpa pekerjaan manual dari perantara
• Dikembangkan dan dipublikasikan pada 2015 oleh Internet Security Research Group (ISRG) melalui proyek Let’s Encrypt
• Sebelum ACME hadir, proses penerbitan sertifikat bersifat manual dengan biaya dan kemungkinan kesalahan yang tinggi
• ACMEv2 terbaru menambahkan berbagai kemampuan seperti metode autentikasi dan dukungan wildcard, sehingga meningkatkan fleksibilitas dan keamanan

Alur otomatisasi sertifikat berbasis ACME di NGINX

• Di NGINX, otomatisasi siklus hidup sertifikat menggunakan protokol ACME berlangsung dalam 4 tahap berikut

• 1. Konfigurasi server ACME

  • Untuk mengaktifkan fitur ACME, URL direktori server ACME harus ditentukan melalui acme_issuer
  • Saat terjadi proses penerbitan sertifikat, informasi kontak klien, jalur penyimpanan data status, dan opsi lain juga dapat ditentukan

• 2. Alokasi memori bersama (zone)

  • Melalui acme_shared_zone, dapat ditambahkan pengaturan shared memory zone untuk menyimpan sertifikat, private key, dan data challenge
  • Ukuran default adalah 256K dan dapat diperbesar sesuai kebutuhan

• 3. Konfigurasi challenge

  • Saat ini versi pratinjau hanya mendukung HTTP-01 challenge, yang digunakan untuk verifikasi kepemilikan domain
  • Untuk itu, konfigurasi NGINX harus mendefinisikan listener port 80 dan pengaturan respons 404 default
  • Dukungan TLS-ALPN dan DNS-01 challenge direncanakan di masa mendatang

• 4. Penerbitan dan pembaruan sertifikat

  • Jika direktif acme_certificate ditambahkan ke server block, otomatisasi penerbitan/pembaruan sertifikat TLS untuk domain terkait dapat dilakukan
  • Domain target penerbitan sertifikat umumnya dinyatakan dengan server_name
  • Regular expression dan wildcard pada server_name belum didukung pada versi pratinjau
  • Variabel modul $acme_certificate dan $acme_certificate_key secara otomatis menghubungkan sertifikat dan key

Keunggulan utama

• Protokol ACME menjadi pusat dari lonjakan penggunaan HTTPS di seluruh dunia
• Pengelolaan sertifikat yang terotomatisasi secara signifikan mengurangi biaya manajemen siklus hidup sertifikat dan kesalahan akibat pekerjaan manual
• Penghapusan alat eksternal membantu mengurangi attack surface dan meningkatkan portabilitas
• Mendorong standardisasi keamanan di berbagai lingkungan

Rencana ke depan

• Dukungan untuk challenge TLS-ALPN dan DNS-01 akan ditambahkan
• Fitur akan diperluas berdasarkan masukan pengguna
• Seiring meluasnya adopsi IoT, API, dan edge computing, ACME diperkirakan akan memainkan peran inti dalam infrastruktur keamanan otomatis yang lebih luas di masa depan
• Dukungan native ACME dari NGINX akan menjadi fondasi dalam menjadikan keamanan web, otomasi, dan skalabilitas sebagai standar masa depan

Memulai

• Pengguna open source dapat menggunakan modul prebuilt dari NGINX Linux packages
• Pelanggan enterprise NGINX Plus mendapatkannya dalam bentuk modul dinamis yang didukung F5
• Lihat dokumentasi modul di NGINX Docs

[GN⁺]

Opini Hacker News

• Saat ini pada versi pratinjau hanya mendukung challenge HTTP-01 untuk memverifikasi kepemilikan domain klien
  Metode DNS-01 adalah fitur yang jauh lebih berarti bagi pengguna nginx yang tidak terbuka ke publik (misalnya saat menggunakan Nginx Proxy Manager). DNS-01 hanya perlu memperbarui record, jadi menurut saya ini selalu pendekatan yang paling rapi. Saya benar-benar menunggu fitur ini hadir
  • Tetapi Anda harus memiliki dns api key, dan banyak penyedia dns tidak menyediakan api key terpisah per zone. Saya pribadi menyukai DNS-01, tetapi secara realistis mungkin perlu kompromi yang kurang memuaskan
  • Tidak perlu menunggu: angie juga mendukungnya (angie adalah fork nginx yang dibuat oleh para pengembang asli nginx setelah keluar dari f5)
  • Hal yang disayangkan dari ACME di Traefik adalah hanya bisa memakai satu api key per penyedia DNS. Karena itu, ada banyak keterbatasan saat ingin membatasi api key per domain atau memakai domain dari beberapa akun. Saya berharap Nginx hadir tanpa batasan semacam ini
  • Secara pribadi, di homelab saya memakai kombinasi step-ca dan caddy dengan dns01. Pengalamannya sangat memuaskan
  • Karena dukungan DNS-01-nya sangat baik, saya juga merekomendasikan pindah ke Angie
• Ini perubahan yang cukup besar. Caddy sudah lama mendukung ini, tetapi tidak semua orang menyukai caddy. Upgrade kali ini berpotensi merebut pangsa dari software seperti Traefik
  • Saya sangat menyukai sintaks Caddy yang rapi. Saat ini saya memakai nginx (melalui nginx proxy manager) dan Traefik, tetapi belakangan saya mencoba mengerjakan proyek dengan Caddy dan rasanya sangat nyaman. Kalau nanti ada waktu, saya ingin memigrasikan lingkungan self-hosted saya ke Caddy. Atau mungkin memakai sesuatu seperti pangolin. pangolin bahkan menyediakan alternatif untuk cloudflare tunnels
  • Saya baru-baru ini benar-benar pindah ke caddy. Pemicu utamanya adalah respons nginx yang pasif terhadap masalah desync http 1. Saya tidak suka situasi harus menunggu sampai masalah benar-benar terjadi, atau ketika auditor bertanya tetapi nginx tidak memberi jawaban yang tegas.
    Caddy jelas lebih mudah daripada nginx. Ia menyediakan template yang mencakup berbagai layanan, pengujian, hingga layanan khusus untuk institusi pendidikan, plus logging yang lebih baik, penanganan sertifikat yang sempurna bagi saya, dan fitur metrics yang lebih baik.
    Namun saya masih mempelajari sisi pluginnya; caddy tidak punya rate limiting, dan karena bug di powerbi ada pengguna tertentu yang meminta gambar 300 ribu kali sehari, jadi ada juga ketidaknyamanannya
  • Saya rasa memang begitu. Di rumah saya masih memakai traefik untuk sebagian hal, tetapi sekarang sepertinya akan langsung saya ganti
• Ini perubahan yang patut disambut. Dokku (saya adalah maintainer-nya) saat ini memakai solusi sementara lewat plugin letsencrypt, dan pengguna sering mengalami issue acak. Ada juga kasus nginx kadang "macet" saat reload sehingga tidak bisa menemukan endpoint. Semakin sedikit variabel kompleks seperti ini, semakin baik arahnya
  Namun butuh waktu cukup lama sampai fitur ini masuk ke stable repository Ubuntu atau Debian.
  Selain itu, karena challenge DNS (sertifikat wildcard) masih belum didukung, dalam jangka pendek ini tampaknya belum banyak membantu Dokku
  • Halo! Senang bertemu Anda di sini
    Saya sudah mencoba (dan masih mencoba) dokku, tetapi terasa ada hambatan masuk yang cukup tinggi
    Misalnya, di Coolify saya bisa langsung menghubungkan deployment hanya dengan membuat github app, dan saya juga punya pengalaman membangun/mendeploy container lewat GH actions.
    Dokumentasi resmi dokku terasa seperti buku referensi, jadi rasanya seperti membaca ensiklopedia: dokumentasi resmi inisialisasi git di dokku
    Saya merasa panduan langsung yang segera membantu deployment seperti di Coolify akan lebih berguna: panduan integrasi github di coolify
    Akan bagus kalau ada panduan pemula untuk memasang aplikasi OSS populer di Dokku, panduan berbasis tujuan/langkah demi langkah, serta tutorial yang sekaligus membahas reverse proxy dan beberapa aplikasi populer di lingkungan baremetal
    Pada akhirnya tujuan memakai Dokku bukanlah Dokku itu sendiri, tetapi mencapai "keadaan yang saya inginkan" dengan mudah dan cepat melalui Dokku
    Pada akhirnya saya menginginkan proses yang painless, di mana saya bisa "mengklik repo yang saya suka lalu langsung mendeploy ke mesin saya". Setelah itu barulah saya ingin mendalami detail di belakangnya
• Kabar baik. Bagi yang belum tahu, dulu ada solusi mudah bernama dehydrated. Cukup tambahkan beberapa baris ke konfigurasi vhost:

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

  dehydrated sudah lama menjadi tool ringan untuk mengotomatisasi pembaruan HTTP-01
  • Fiturnya sendiri memang sangat keren, tetapi cukup disayangkan proyek yang diandalkan ribuan orang terus tidak merilis versi Stable
    Software tanpa rilisan resmi v1.0.0 bisa mengubah interface kapan saja tanpa pemberitahuan. Major version 0 pada akhirnya menjadi jebakan.
    Saya menyarankan agar maintainer didorong untuk merilis versi stabil.
    dehydrated sudah 7 tahun berada di major version 0
    0ver.org juga layak dilihat:
    Filosofi versioning-nya adalah semacam, "kalau sudah dipakai di production, seharusnya sudah menjadi 1.0.0"
    Untuk detail lebih lanjut lihat di sini
• Ada kesalahan kecil dalam rilis kali ini: ngx_http_acme_module sudah dimasukkan ke paket beberapa distro Linux, tetapi Debian stable tidak termasuk
  Menurut daftar paket resmi nginx, ada oldstable/oldoldstable, tetapi Debian 13 Trixie yang dirilis 4 hari lalu tidak ada
  • Saat ini kami sedang mengerjakan upload paket Trixie. Seharusnya akan naik minggu ini. Karena Debian 13 baru dirilis 4 hari yang lalu, butuh waktu untuk menyiapkan infrastruktur untuk OS baru. (Saya bekerja di F5)
  • Mungkin itu kesalahan di pihak Debian
• Sejak mengenal Caddy, saya tidak lagi memakai nginx. Pengalaman pengembangannya jauh lebih baik
• Masalah perusahaan besar open source adalah mereka selalu terlambat memahami dan menerapkan ‘inovasi dasar’ dengan benar
  Caddy dan Traefik sudah melakukan ini 5 tahun lalu, dan baru sekarang nginx mendukungnya.
  Tentu saya rasa ini perubahan yang baik. Sekarang jadi lebih nyaman karena tidak perlu lagi menjalankan certbot sendiri
  • Sebenarnya Caddy sudah mendukung automatic HTTPS Let’s Encrypt sampai tingkat tertentu sejak 2016, hampir 10 tahun yang lalu.
    Artinya Nginx terlambat sekitar 9~10 tahun dalam menghadirkan fitur ini
• Secara pribadi, saya tidak pernah merasa model nginx hanya menyajikan konten web sementara certbot menangani renewal itu sebagai masalah
  Saya tetap merasa filosofi Unix, di mana setiap hal melakukan satu tugas dengan baik lalu bisa dikombinasikan, lebih baik
  Tool yang menempelkan segala macam fitur pada akhirnya pasti akan kurang di salah satu bagiannya
  • Menyiapkannya dengan certbot adalah pengalaman yang cukup merepotkan
    Bahkan saat certbot mencoba melakukan konfigurasi otomatis, biasanya itu tidak berjalan baik kecuali pada lingkungan yang sangat default
    Menangani semuanya langsung di dalam nginx justru terasa seperti solusi yang lebih baik
• Jadi, saya memahaminya sebagai: dengan masuknya fitur ini, kita tidak lagi perlu memasang/menjalankan certbot jika cukup menambahkan beberapa baris ke file konfigurasi nginx
  Saya juga penasaran apakah ini membuka jalan untuk lebih mudah memakai alternatif selain Let's Encrypt
• Ini perubahan yang menarik
  Caddy sangat berguna karena punya banyak fitur praktis yang siap dipakai
  Secara pribadi alasan saya belum bisa sepenuhnya beralih ke Caddy adalah kebutuhan saya akan rate limiting dan modul geo di nginx