NGINX ได้เปิดตัวการสนับสนุน ACME protocol แบบ native ในที่สุด ซึ่งช่วยให้สามารถจัดการใบรับรอง SSL/TLS แบบอัตโนมัติได้โดยตรงผ่าน configuration directives ฟีเจอร์ที่รอคอยมานานนี้ช่วยขจัดความจำเป็นในการใช้เครื่องมือภายนอกอย่าง Certbot แต่การตอบสนองจากชุมชนเผยให้เห็นทั้งความตื่นเต้นและความกังวลอย่างมากเกี่ยวกับข้อจำกัดในการใช้งาน
ขั้นตอนการกำหนดค่า NGINX ACME Module:
- ตั้งค่าเซิร์ฟเวอร์ ACME ด้วย directory URL
- จัดสรรพื้นที่หน่วยความจำแบบแชร์ (ค่าเริ่มต้น 256K สามารถขยายได้)
- กำหนดค่า HTTP-01 challenges บนพอร์ต 80
- ใช้คำสั่ง
acme_certificateในบล็อกเซิร์ฟเวอร์ - อ้างอิงใบรับรองด้วยตัวแปร
$acme_certificateและ$acme_certificate_key
 |
|---|
| NGINX แนะนำการสนับสนุน ACME protocol แบบ native เพื่อปรับปรุงการจัดการใบรับรอง SSL/TLS |
การสนับสนุน DNS-01 Challenge กลายเป็นจุดขัดแย้งหลัก
การอภิปรายที่ร้อนแรงที่สุดมุ่งเน้นไปที่การตัดสินใจของ NGINX ที่เปิดตัวด้วยการสนับสนุน HTTP-01 challenge เท่านั้น โดยไม่รวม DNS-01 challenges ที่มีความยืดหยุ่นมากกว่า สมาชิกชุมชนรู้สึกผิดหวังเป็นพิเศษเพราะ DNS-01 ช่วยให้สามารถใช้ wildcard certificates และทำงานกับบริการภายในที่ไม่สามารถเข้าถึงได้จากสาธารณะ ผู้ใช้หลายคนพึ่งพา DNS-01 สำหรับการตั้งค่า homelab เครือข่ายส่วนตัว และการกำหนดค่าโดเมนที่ซับซ้อนที่ HTTP-01 ไม่สามารถทำงานได้
ความท้าทายทางเทคนิคอยู่ที่ความหลากหลายของผู้ให้บริการ DNS บริการ DNS แต่ละรายมี API ของตัวเองสำหรับการสร้าง TXT records ที่จำเป็นสำหรับการตรวจสอบ DNS-01 การสนับสนุนสิ่งนี้จะต้องให้ NGINX รักษาการเชื่อมต่อกับผู้ให้บริการที่แตกต่างกันหลายสิบราย ตั้งแต่ผู้เล่นรายใหญ่อย่าง Cloudflare และ AWS ไปจนถึงบริการระดับภูมิภาคขนาดเล็ก สมาชิกชุมชนบางคนแนะนำให้ใช้โปรโตคอลมาตรฐานอย่าง RFC 2136 แทนการใช้ APIs แบบกำหนดเอง แต่การยอมรับยังคงมีจำกัดในหมู่ผู้ให้บริการ
ข้อจำกัดปัจจุบัน:
- รองรับเฉพาะ HTTP-01 challenges (ไม่รองรับ DNS-01 หรือ TLS-ALPN)
- ไม่รองรับใบรับรอง wildcard ในรุ่นเริ่มต้น
- ต้องการ port 80 listener สำหรับการประมวลผล challenge
- ไม่รองรับ regular expressions ใน server_name directive
อิทธิพลของ Caddy ต่อการพัฒนา Web Server
การประกาศนี้ได้จุดประกายการอภิปรายเกี่ยวกับ Caddy ซึ่งเป็น web server ที่พัฒนาด้วย Go และเป็นผู้บุกเบิก automatic HTTPS ด้วยการสนับสนุน ACME แบบ built-in ผู้ใช้หลายคนชื่นชมความเรียบง่ายและการจัดการใบรับรองที่ครอบคลุมของ Caddy โดยบางคนตั้งคำถามว่าทำไมพวกเขาจึงต้องกลับไปใช้ NGINX เมื่อ Caddy แก้ปัญหาเหล่านี้ได้อย่างสง่างามแล้ว การเปรียบเทียบนี้เน้นให้เห็นว่าแนวทาง batteries included ของ Caddy ตัดกันกับปรัชญาแบบ modular แบบดั้งเดิมของ NGINX อย่างไร
อย่างไรก็ตาม ผู้สนับสนุน NGINX ชี้ให้เห็นว่าสภาพแวดล้อมระดับองค์กรมักต้องการฟีเจอร์ขั้นสูง ลักษณะประสิทธิภาพ และระบบนิเวศที่กว้างขวางของ NGINX การถกเถียงนี้สะท้อนการเปลี่ยนแปลงที่กว้างขึ้นในโครงสร้างพื้นฐานเว็บ ที่ความง่ายในการใช้งานแข่งขันกับพลังและความยืดหยุ่นแบบดิบมากขึ้น
โซลูชันคู่แข่งที่กล่าวถึง:
- Caddy: มี ACME ในตัวพร้อมรองรับ DNS-01 และ HTTPS อัตโนมัติ
- Angie: Fork ของ NGINX ที่มี ACME ครบครันรวมถึง DNS-01
- Traefik: เน้น Docker พร้อมการกำหนดค่าแบบ label-based
- Apache mod_md: รองรับ ACME ในตัวสำหรับ Apache HTTP Server
ข้อกังวลในการใช้งานและความพร้อมสำหรับการใช้งานจริง
ความคิดเห็นจากชุมชนเผยให้เห็นความกังวลในทางปฏิบัติเกี่ยวกับ ACME module ใหม่ คำถามยังคงอยู่เกี่ยวกับกลไกการต่ออายุ ความสามารถในการแก้ไขข้อผิดพลาด และการติดตั้งแบบหลายเซิร์ฟเวอร์ ผู้ใช้บางคนกังวลเกี่ยวกับ rate limiting เมื่อ NGINX instances หลายตัวพยายามต่ออายุใบรับรองพร้อมกัน ในขณะที่คนอื่นๆ ตั้งคำถามว่าระบบจัดการกับกรณีพิเศษอย่างใบรับรองที่หมดอายุหรือความล้มเหลวของเครือข่ายอย่างไร
การพึ่งพา NGINX's ใหม่ Rust SDK ของ module นี้ยังทำให้เกิดความสงสัย เนื่องจากมันแนะนำ dependency และความซับซ้อนที่อาจเกิดขึ้นอีกอย่างหนึ่ง ผู้ใช้ที่คุ้นเคยกับสถาปัตยกรรมแบบ C-based ที่ตรงไปตรงมาแบบดั้งเดิมของ NGINX สงสัยเกี่ยวกับผลกระทบระยะยาวของการเปลี่ยนแปลงสถาปัตยกรรมนี้
DNS เป็นตัวเลือกเดียวสำหรับบริการภายในที่ไม่สามารถเข้าถึงได้จากอินเทอร์เน็ตภายนอก และคุณสามารถได้ wildcards ด้วย DNS challenges
โซลูชันทางเลือกได้รับความสนใจ
การประกาศนี้ยังช่วยเพิ่มความสนใจใน NGINX alternatives และ forks Angie ที่พัฒนาโดยนักพัฒนาหลักของ NGINX เดิม รวมการสนับสนุน ACME ที่ครอบคลุมมากขึ้นด้วย DNS-01 challenges อยู่แล้ว ข้อได้เปรียบด้านเวลานี้เน้นให้เห็นแรงกดดันในการแข่งขันที่ NGINX เผชิญจากทั้งทางเลือกที่มีอยู่อย่าง Caddy และ forks ใหม่ๆ ที่แก้ไขจุดเจ็บปวดของผู้ใช้ได้เร็วกว่า
การอภิปรายยังเผยให้เห็นระบบนิเวศเครื่องมือที่หลากหลายที่เกิดขึ้นรอบการจัดการใบรับรอง ตั้งแต่โซลูชันน้ำหนักเบาอย่าง dehydrated ไปจนถึงระบบระดับองค์กร ผู้ใช้หลายคนได้ลงทุนใน workflows เหล่านี้แล้วและตั้งคำถามว่าการเปลี่ยนไปใช้การสนับสนุน NGINX แบบ native ให้ประโยชน์เพียงพอที่จะปรับเปลี่ยนต้นทุนการย้ายข้อมูลหรือไม่
การตอบสนองของชุมชนแสดงให้เห็นว่าแม้การสนับสนุน ACME ของ NGINX จะเป็นความก้าวหน้า แต่การใช้งาน HTTP-01-only เริ่มต้นอาจไม่เพียงพอสำหรับกรณีการใช้งานจริงหลายๆ กรณี แรงกดดันสำหรับการสนับสนุน DNS-01 และเอกสารที่ปรับปรุงแล้วน่าจะเป็นตัวกำหนดการพัฒนาของฟีเจอร์ในรุ่นที่จะออกมา