NGINX akhirnya telah memperkenalkan sokongan asli untuk protokol ACME , membolehkan pengurusan sijil SSL/TLS automatik secara langsung melalui arahan konfigurasi. Ciri yang telah lama dinanti-nantikan ini menghapuskan keperluan untuk alat luaran seperti Certbot , tetapi respons komuniti mendedahkan kedua-dua keseronokan dan kebimbangan yang ketara mengenai batasan pelaksanaan tersebut.
Langkah-langkah Konfigurasi Modul ACME NGINX:
- Sediakan pelayan ACME dengan URL direktori
- Peruntukkan zon memori berkongsi (lalai 256K, boleh dikembangkan)
- Konfigurasikan cabaran HTTP-01 pada port 80
- Gunakan arahan
acme_certificate
dalam blok pelayan - Rujuk sijil dengan pembolehubah
$acme_certificate
dan$acme_certificate_key
![]() |
---|
NGINX memperkenalkan sokongan asli untuk protokol ACME, meningkatkan pengurusan sijil SSL/TLS |
Sokongan Cabaran DNS-01 Menjadi Isu Utama
Perbincangan yang paling hangat tertumpu pada keputusan NGINX untuk melancarkan dengan hanya sokongan cabaran HTTP-01 , meninggalkan cabaran DNS-01 yang lebih serba boleh. Ahli komuniti amat kecewa kerana DNS-01 membolehkan sijil wildcard dan berfungsi untuk perkhidmatan dalaman yang tidak boleh diakses secara umum. Ramai pengguna bergantung pada DNS-01 untuk persediaan homelab, rangkaian peribadi, dan konfigurasi domain yang kompleks di mana HTTP-01 tidak akan berfungsi.
Cabaran teknikal terletak pada kepelbagaian penyedia DNS . Setiap perkhidmatan DNS mempunyai API sendiri untuk mencipta rekod TXT yang diperlukan untuk pengesahan DNS-01 . Menyokong ini memerlukan NGINX mengekalkan integrasi dengan berpuluh-puluh penyedia yang berbeza, daripada pemain utama seperti Cloudflare dan AWS kepada perkhidmatan serantau yang lebih kecil. Sesetengah ahli komuniti mencadangkan menggunakan protokol piawai seperti RFC 2136 sebagai ganti API tersuai, tetapi penggunaan masih terhad di kalangan penyedia.
Batasan Semasa:
- Cabaran HTTP-01 sahaja (tiada sokongan DNS-01 atau TLS-ALPN)
- Tiada sokongan sijil wildcard dalam keluaran awal
- Memerlukan pendengar port 80 untuk pemprosesan cabaran
- Ungkapan nalar tidak disokong dalam arahan server_name
Pengaruh Caddy terhadap Evolusi Pelayan Web
Pengumuman ini telah mencetuskan semula perbincangan mengenai Caddy , pelayan web berasaskan Go yang mempelopori HTTPS automatik dengan sokongan ACME terbina dalam. Ramai pengguna memuji kesederhanaan Caddy dan pengurusan sijil yang komprehensif, dengan sesetengahnya mempersoalkan mengapa mereka perlu kembali kepada NGINX apabila Caddy sudah menyelesaikan masalah ini dengan elegan. Perbandingan ini menyerlahkan bagaimana pendekatan batteries included Caddy berbeza dengan falsafah modular tradisional NGINX .
Walau bagaimanapun, pembela NGINX menegaskan bahawa persekitaran perusahaan sering memerlukan ciri lanjutan NGINX , ciri prestasi, dan ekosistem yang luas. Perdebatan ini mencerminkan peralihan yang lebih luas dalam infrastruktur web, di mana kemudahan penggunaan semakin bersaing dengan kuasa mentah dan fleksibiliti.
Penyelesaian Pesaing yang Disebutkan:
- Caddy: ACME terbina dalam dengan sokongan DNS-01, HTTPS automatik
- Angie: Fork NGINX dengan ACME komprehensif termasuk DNS-01
- Traefik: Berfokuskan Docker dengan konfigurasi berasaskan label
- Apache mod_md: Sokongan ACME terbina dalam untuk Apache HTTP Server
Kebimbangan Pelaksanaan dan Kesediaan Produksi
Maklum balas komuniti mendedahkan kebimbangan praktikal mengenai modul ACME baharu. Persoalan masih wujud mengenai mekanisme pembaharuan, keupayaan penyahpepijatan, dan penggunaan berbilang pelayan. Sesetengah pengguna bimbang tentang had kadar apabila berbilang contoh NGINX cuba membaharui sijil secara serentak, manakala yang lain mempersoalkan bagaimana sistem mengendalikan kes tepi seperti sijil tamat tempoh atau kegagalan rangkaian.
Pergantungan modul pada Rust SDK baharu NGINX juga menimbulkan keraguan, kerana ia memperkenalkan satu lagi kebergantungan dan kerumitan yang berpotensi. Pengguna yang biasa dengan seni bina berasaskan C NGINX yang secara tradisinya mudah tertanya-tanya tentang implikasi jangka panjang peralihan seni bina ini.
DNS adalah satu-satunya pilihan untuk perkhidmatan dalaman yang tidak boleh dicapai dari internet luaran, dan anda boleh mendapat wildcard dengan cabaran DNS .
Penyelesaian Alternatif Mendapat Perhatian
Pengumuman ini juga telah meningkatkan minat terhadap alternatif dan fork NGINX . Angie , yang dibangunkan oleh bekas pembangun teras NGINX , sudah merangkumi sokongan ACME yang lebih komprehensif dengan cabaran DNS-01 . Kelebihan masa ini menyerlahkan tekanan persaingan yang dihadapi NGINX daripada kedua-dua alternatif yang mantap seperti Caddy dan fork yang muncul yang menangani titik kesakitan pengguna dengan lebih cepat.
Perbincangan ini juga mendedahkan ekosistem alat yang pelbagai yang telah muncul di sekitar pengurusan sijil, daripada penyelesaian ringan seperti dehydrated kepada sistem gred perusahaan. Ramai pengguna telah melabur dalam alur kerja ini dan mempersoalkan sama ada beralih kepada sokongan asli NGINX memberikan faedah yang mencukupi untuk mewajarkan kos migrasi.
Respons komuniti menunjukkan bahawa walaupun sokongan ACME NGINX mewakili kemajuan, pelaksanaan awal HTTP-01 sahaja mungkin tidak mencukupi untuk banyak kes penggunaan dunia sebenar. Tekanan untuk sokongan DNS-01 dan dokumentasi yang diperbaiki berkemungkinan akan membentuk evolusi ciri dalam keluaran akan datang.