NGINX เปิดตัวการรองรับโปรโตคอล ACME แบบเนทีฟ

 (blog.nginx.org)
5 คะแนน โดย GN⁺ 2025-08-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • NGINX เปิดตัวพรีวิวที่รองรับ โปรโตคอล ACME แบบเนทีฟสำหรับทำงานอัตโนมัติในการออกและต่ออายุใบรับรอง SSL/TLS
  • ผ่านโมดูลใหม่แบบ Rust ชื่อ ngx_http_acme_module ทำให้สามารถขอ ติดตั้ง และต่ออายุใบรับรองได้จากการตั้งค่า NGINX โดยตรงโดยไม่ต้องใช้เครื่องมือภายนอก
  • สิ่งนี้ช่วยลดการพึ่งพาเครื่องมือภายนอกอย่าง Certbot พร้อมเพิ่มความปลอดภัยและความเป็นอิสระจากแพลตฟอร์ม
  • เวอร์ชันเริ่มต้นรองรับ HTTP-01 challenge และมีแผนจะรองรับ TLS-ALPN และ DNS-01 ในอนาคต
  • คาดว่าการรองรับ ACME จะมีบทบาทสำคัญต่อการทำงานอัตโนมัติด้านความปลอดภัย ไม่ใช่แค่บนเว็บ แต่รวมถึง IoT และสภาพแวดล้อม edge computing ด้วย

ภาพรวมและการเปลี่ยนแปลงสำคัญ

  • 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 รุ่นปัจจุบันเพิ่มความสามารถหลากหลาย เช่น วิธีการยืนยันตัวตนและการรองรับไวลด์การ์ด ทำให้มีความยืดหยุ่นและปลอดภัยมากขึ้น

ขั้นตอนการทำงานอัตโนมัติของใบรับรองด้วย ACME ใน NGINX

  • การทำงานอัตโนมัติของวงจรชีวิตใบรับรองด้วยโปรโตคอล ACME ใน NGINX ประกอบด้วย 4 ขั้นตอนดังนี้

  • 1. ตั้งค่าเซิร์ฟเวอร์ ACME

    • ในการเปิดใช้ฟีเจอร์ ACME ต้องระบุ directory URL ของเซิร์ฟเวอร์ ACME ด้วย acme_issuer
    • เมื่อมีการออกใบรับรอง ยังสามารถกำหนดตัวเลือกเพิ่มเติม เช่น ข้อมูลติดต่อไคลเอนต์ และพาธสำหรับเก็บข้อมูลสถานะได้

  • 2. จัดสรรหน่วยความจำที่ใช้ร่วมกัน (zone)

    • สามารถตั้งค่า shared memory zone เพิ่มเติมผ่าน acme_shared_zone เพื่อเก็บใบรับรอง คีย์ส่วนตัว และข้อมูล challenge
    • ขนาดเริ่มต้นคือ 256K และขยายได้ตามต้องการ

  • 3. ตั้งค่า challenge

    • เวอร์ชันพรีวิวปัจจุบันรองรับเฉพาะ HTTP-01 challenge ซึ่งใช้สำหรับยืนยันความเป็นเจ้าของโดเมน
    • เพื่อให้ทำงานได้ ต้องกำหนด listener บนพอร์ต 80 และ การตอบกลับ 404 แบบค่าเริ่มต้น ในการตั้งค่า NGINX
    • มีแผนจะรองรับ TLS-ALPN และ DNS-01 challenge ในภายหลัง

  • 4. ออกและต่ออายุใบรับรอง

    • หากเพิ่ม directive acme_certificate ลงใน server block ก็จะสามารถทำงานอัตโนมัติในการออก/ต่ออายุใบรับรอง TLS สำหรับโดเมนนั้นได้
    • โดยทั่วไปโดเมนเป้าหมายของการออกใบรับรองจะระบุด้วย server_name
    • ในเวอร์ชันพรีวิว server_name ที่เป็น regular expression และ wildcard ยังไม่รองรับ
    • ตัวแปร $acme_certificate และ $acme_certificate_key ภายในโมดูลจะเชื่อมใบรับรองและคีย์ให้โดยอัตโนมัติ

ข้อดีสำคัญ

  • โปรโตคอล ACME เป็นหัวใจสำคัญของการเติบโตอย่างรวดเร็วของการใช้งาน HTTPS ทั่วโลก
  • การจัดการใบรับรองแบบอัตโนมัติช่วยลดอย่างมากทั้ง ต้นทุนในการจัดการวงจรชีวิตใบรับรอง และ ข้อผิดพลาดจากงานแมนนวล
  • การตัดเครื่องมือภายนอกออกช่วย ลดพื้นผิวการโจมตี และ เพิ่มความสามารถในการพกพา
  • ช่วยผลักดัน การทำมาตรฐานด้านความปลอดภัย ในหลากหลายสภาพแวดล้อม

แผนในอนาคต

  • มีแผนเพิ่มการรองรับ TLS-ALPN และ DNS-01 challenge
  • ขยายความสามารถตามฟีดแบ็กของผู้ใช้
  • เมื่อการนำ IoT, API และ edge computing ไปใช้งานเพิ่มขึ้น คาดว่า ACME จะมีบทบาทสำคัญในโครงสร้างพื้นฐานด้านความปลอดภัยแบบอัตโนมัติที่ครอบคลุมยิ่งขึ้นในอนาคต
  • การรองรับ ACME แบบเนทีฟของ NGINX จะเป็นรากฐานสำคัญในการผลักดันให้ความปลอดภัยบนเว็บ การทำงานอัตโนมัติ และความสามารถในการขยายระบบ กลายเป็นมาตรฐานแห่งอนาคต

เริ่มต้นใช้งาน

  • ผู้ใช้โอเพนซอร์สสามารถใช้โมดูลแบบ prebuilt ได้จาก NGINX Linux packages
  • ลูกค้าองค์กร NGINX Plus จะได้รับในรูปแบบโมดูลไดนามิกที่รองรับโดย F5
  • ดูเอกสารของโมดูลได้ที่ NGINX Docs

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-08-14
ความคิดเห็นบน Hacker News
  • ในเวอร์ชันพรีวิวตอนนี้รองรับเฉพาะ challenge แบบ HTTP-01 เพื่อยืนยันความเป็นเจ้าของโดเมนของไคลเอนต์
    สำหรับผู้ใช้ nginx ที่ไม่ได้เปิดสู่สาธารณะ วิธี DNS-01 มีความหมายกว่ามาก (เช่น ตอนใช้ Nginx Proxy Manager) ผมคิดมาตลอดว่า DNS-01 สะอาดที่สุดเพราะแค่อัปเดตเรคอร์ดเท่านั้น รอฟีเจอร์นี้มานานมาก
    • แต่ก็ต้องมี dns api key แน่นอน และผู้ให้บริการ dns หลายเจ้าก็ไม่ได้ให้ api key แยกตามแต่ละ zone ส่วนตัวชอบ DNS-01 แต่ในโลกจริงอาจต้องยอมประนีประนอมที่น่าเสียดายอยู่บ้าง
    • ไม่ต้องรอ: angie ก็รองรับ อยู่แล้ว (angie เป็น nginx fork ที่สร้างโดยอดีตนักพัฒนา nginx ซึ่งออกมาจาก f5)
    • จุดที่น่าเสียดายของ ACME ใน Traefik คือใช้ api key ได้เพียงหนึ่งชุดต่อผู้ให้บริการ DNS ทำให้มีข้อจำกัดเยอะมากถ้าจะจำกัด api key ตามโดเมน หรือถ้าใช้โดเมนจากหลายบัญชี หวังว่า Nginx จะออกมาโดยไม่มีข้อจำกัดแบบนี้
    • ส่วนตัวใน homelab ใช้ dns01 คู่กับ step-ca และ caddy อยู่ ประสบการณ์ดีมาก
    • Angie รองรับ 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 อย่างชัดเจน มีทั้งเทมเพลตที่ครอบคลุมบริการต่าง ๆ การทดสอบ และบริการพิเศษสำหรับสถาบันการศึกษา รวมถึง logging ที่ดีกว่า การจัดการใบรับรองที่สำหรับผมถือว่าสมบูรณ์แบบ และความสามารถด้าน metrics ที่ดีกว่า
      แต่ตอนนี้ยังเรียนรู้ฝั่งปลั๊กอินอยู่ เพราะ caddy ไม่มี rate limiting และมีบั๊กของ powerbi ที่ทำให้ผู้ใช้บางคนร้องขอรูปภาพวันละ 300,000 ครั้ง เลยมีจุดที่ไม่สะดวกเหมือนกัน
    • เห็นด้วยอย่างยิ่ง ที่บ้านผมใช้ traefik อยู่บางส่วน แต่ตอนนี้น่าจะเปลี่ยนแทนได้ทันที
  • เป็นการเปลี่ยนแปลงที่น่ายินดี Dokku (ผมเป็นเมนเทนเนอร์) ตอนนี้ใช้ letsencrypt plugin เป็นทางแก้ชั่วคราว และผู้ใช้มักเจอปัญหาแปลก ๆ แบบสุ่มอยู่บ่อย อีกทั้ง nginx ยังมีอาการ "ค้าง" ระหว่าง reload เป็นบางครั้งจนหา endpoint ไม่เจอด้วย ยิ่งมีตัวแปรซับซ้อนน้อยเท่าไรก็ยิ่งดี
    แต่กว่าฟีเจอร์นี้จะเข้า stable repository ของ Ubuntu หรือ Debian ก็คงต้องใช้เวลาอีกพอสมควร
    แถมตอนนี้ยังไม่รองรับ DNS challenge (wildcard certificate) ดังนั้นในระยะสั้นอาจไม่ได้ช่วย Dokku มากนัก
    • สวัสดีครับ! ดีใจที่ได้เจอคุณที่นี่แบบนี้
      ผมเคยลอง dokku (และตอนนี้ก็ยังลองอยู่) แต่รู้สึกว่าจุดเริ่มต้นค่อนข้างยาก
      เช่น Coolify สามารถสร้าง github app แล้วเชื่อมการ deploy ได้ทันที และผมก็เคยมีประสบการณ์ build/deploy container ด้วย GH actions มาก่อน
      เอกสารทางการของ dokku ให้ความรู้สึกเหมือนเอกสารอ้างอิง เลยเหมือนกำลังอ่านสารานุกรม: เอกสารทางการเรื่องการเริ่มต้น git ของ dokku
      ผมรู้สึกว่าคู่มือเริ่มต้นแบบชัดเจนที่พาไป deploy ได้ทันทีเหมือนของ Coolify จะมีประโยชน์กว่า: คู่มือการเชื่อม github ของ coolify
      อยากให้ Dokku มีคู่มือสำหรับติดตั้งแอป OSS ยอดนิยม, คู่มือเริ่มต้นแบบมีเป้าหมาย/จบเป็นขั้นตอน, และบทสอนที่ครอบคลุมตั้งแต่ reverse proxy บน baremetal ไปจนถึงหลายแอปยอดนิยมในที่เดียว
      สุดท้ายแล้ว เป้าหมายของการใช้ Dokku ไม่ใช่ตัว Dokku เอง แต่คือการไปให้ถึง "สภาพที่ฉันต้องการ" ได้อย่างง่ายและรวดเร็วด้วย Dokku
      ท้ายที่สุดผมอยากได้กระบวนการที่ painless แบบ "คลิกเรโปที่ชอบแล้ว deploy ลงเครื่องตัวเองได้ทันที" แล้วค่อยไปเจาะรายละเอียดฝั่ง backend ต่อ
  • เป็นข่าวดี สำหรับคนที่ยังไม่รู้ ก่อนหน้านี้มีโซลูชันใช้งานง่ายชื่อ dehydrated อยู่แล้ว แค่เพิ่มไม่กี่บรรทัดใน vhost config: 
      location ^~ /.well-known/acme-challenge/ {  
    alias ;  
  }
    dehydrated เป็นเครื่องมือเบา ๆ ที่ใช้ทำ renewal แบบอัตโนมัติด้วย HTTP-01 มานานมากแล้ว
    • ฟีเจอร์มันเจ๋งมากจริง ๆ แต่ก็น่าเสียดายที่โปรเจ็กต์ที่มีคนหลายพันคนพึ่งพา ยังไม่ออก Stable release อย่างต่อเนื่อง
      ซอฟต์แวร์ที่ยังไม่มี v1.0.0 อย่างเป็นทางการ อาจเปลี่ยนอินเทอร์เฟซได้ทุกเมื่อโดยไม่แจ้งล่วงหน้า major version 0 สักวันหนึ่งจะกลายเป็นกับดัก
      ผมแนะนำให้กดดันเมนเทนเนอร์ให้ออกเวอร์ชันเสถียร
      dehydrated อยู่ในสถานะ major version 0 มา 7 ปีแล้ว
      0ver.org ก็น่าอ่านเช่นกัน:
      เป็นแนวคิดเรื่องการทำเวอร์ชันที่ประมาณว่า "ถ้าใช้งานในโปรดักชันอยู่แล้ว ก็ควรเป็น 1.0.0 ได้แล้ว"
      รายละเอียดเพิ่มเติมดู ที่นี่
  • รีลีสครั้งนี้มีพลาดเล็กน้อย: ngx_http_acme_module ถูกบรรจุในแพ็กเกจของหลายดิสโทรลินุกซ์ แต่ Debian stable กลับยังไม่มี
    ตาม รายการแพ็กเกจทางการของ nginx มี oldstable/oldoldstable แต่ไม่มี Debian 13 Trixie ที่เพิ่งออกเมื่อ 4 วันก่อน
    • ตอนนี้กำลังทำงานอัปโหลดแพ็กเกจสำหรับ Trixie อยู่ น่าจะขึ้นภายในสัปดาห์นี้ Debian 13 เพิ่งออกมาได้แค่ 4 วัน จึงต้องใช้เวลาตั้งค่าอินฟราสำหรับ OS ใหม่อยู่บ้าง (ผมทำงานที่ F5)
    • ผมคิดว่านั่นน่าจะเป็นความผิดพลาดฝั่ง Debian
  • ตั้งแต่รู้จัก Caddy ผมก็เลิกใช้ nginx ไปเลย ประสบการณ์ฝั่งนักพัฒนาดีกว่ามาก
  • ปัญหาของยักษ์ใหญ่โอเพนซอร์สคือมักช้าเสมอในการเข้าใจและทำ "นวัตกรรมพื้นฐาน" ให้ถูกต้อง
    สิ่งที่ Caddy และ Traefik ทำไปแล้วตั้งแต่ 5 ปีก่อน nginx เพิ่งจะมารองรับตอนนี้
    แน่นอนว่าผมคิดว่านี่เป็นการเปลี่ยนแปลงที่ดี อย่างน้อยตอนนี้ก็ไม่ต้องรัน certbot เองอีกแล้ว สะดวกขึ้นมาก
    • ที่จริง Caddy รองรับ automatic HTTPS ของ Let’s Encrypt ได้ในระดับหนึ่งตั้งแต่ปี 2016 ซึ่งก็เกือบ 10 ปีแล้ว
      เท่ากับว่า Nginx ใส่ฟีเจอร์นี้ช้ากว่าอยู่เกือบ 9-10 ปี
  • ส่วนตัวไม่เคยรู้สึกว่าวิธีที่ nginx ทำหน้าที่เสิร์ฟเว็บคอนเทนต์ แล้วให้ certbot จัดการ renewal เป็นปัญหาอะไร
    ผมยังคิดว่าปรัชญาแบบยูนิกซ์ที่ให้แต่ละอย่างทำหน้าที่ของตัวเองให้ดีและประกอบกันได้ดีกว่า
    "เครื่องมือ" ที่พยายามยัดทุกอย่างเข้ามา สุดท้ายก็เลี่ยงไม่ได้ที่จะมีบางส่วนที่ทำได้ไม่ดีพอ
    • การตั้งค่าด้วย certbot เป็นประสบการณ์ที่ค่อนข้างยุ่งยาก
      ถึง certbot จะพยายามตั้งค่าอัตโนมัติให้ แต่ถ้าไม่ใช่สภาพแวดล้อมมาตรฐานทั่วไปก็มักทำงานได้ไม่ดี
      การให้ nginx จัดการทุกอย่างเองภายในน่าจะเป็นทางออกที่ดีกว่า
  • ถ้าอย่างนั้นผมเข้าใจว่าการเพิ่มฟีเจอร์นี้หมายความว่า แค่เพิ่มอีกไม่กี่บรรทัดในไฟล์ config ของ nginx ก็ไม่จำเป็นต้องติดตั้ง/ดูแล certbot แล้ว
    และก็สงสัยด้วยว่านี่เปิดทางให้ใช้ตัวเลือกอื่นนอกจาก Let's Encrypt ได้ง่ายขึ้นหรือไม่
  • เป็นการเปลี่ยนแปลงที่น่าตื่นเต้น
    Caddy มีความสะดวกแบบพร้อมใช้หลายอย่าง เลยมีประโยชน์มากจริง ๆ
    ส่วนตัวเหตุผลที่ยังย้ายไป Caddy ไม่ได้ทั้งหมด คือยังต้องพึ่ง rate limiting และโมดูล geo ของ nginx