ต่ออายุ certificate ผ่านแล้ว เว็บใช้ใบใหม่จริงหรือยัง

ระบบต่ออายุ certificate อาจรายงานว่าทำงานสำเร็จ แต่ผู้ใช้ยังเห็นใบเดิมหรือคำเตือนว่าใกล้หมดอายุได้ หากมองเฉพาะงานขอใบ เราอาจมั่นใจเร็วเกินไปว่าทุกจุดที่รับ TLS เปลี่ยนตามแล้ว

ระหว่าง CA ออกใบใหม่กับ client ได้รับใบนั้นมีหลายขั้น ทั้งไฟล์ที่เขียน ตำแหน่งที่ service อ่าน วิธีโหลดค่า และจำนวน endpoint ที่ต้องส่งมอบ หากมี CDN หรือ load balancer อยู่หน้าแอป จุดที่ผู้ใช้เห็นก็อาจไม่ใช่เครื่องที่รันคำสั่งต่ออายุ

เกณฑ์จบงานจึงควรตามไปถึงใบที่ถูกส่งจริงครับ แล้วค่อยแยกย้อนกลับว่าหากไม่ตรง การส่งมอบค้างอยู่ที่ขั้นใด

แยกออกใบ ส่งมอบ และใช้งานจริงออกจากกัน

ขั้นออกใบยืนยันว่า CA ทำกระบวนการออก certificate ให้สำเร็จตามข้อมูลที่ขอ ส่วนขั้นส่งมอบนำไฟล์กับข้อมูลที่จำเป็นไปไว้ในตำแหน่งของบริการ และขั้นใช้งานจริงคือ TLS endpoint โหลดชุดนั้นแล้วส่งให้ client ตามชื่อที่เรียก

ตัวอย่างสมมติคือเครื่องจัดการใบเขียนไฟล์ใหม่สำเร็จ แต่ proxy อยู่ใน container ที่อ่านสำเนาอีก directory หนึ่ง งานออกใบจึงผ่านได้พร้อมกับบริการที่ยังใช้ไฟล์เก่า ปัญหานี้ไม่จำเป็นต้องแก้ด้วยการขอใบซ้ำ เพราะสิ่งที่ขาดคือการเชื่อมขั้นส่งมอบ

ก่อนเพิ่มคำสั่งอัตโนมัติ ควรระบุเจ้าของ certificate แต่ละชุด ชื่อที่ครอบคลุมและจุดที่ใช้ หากผู้ให้บริการจัดการใบที่ edge ให้เอง อาจเป็นอีกวงจรหนึ่งจากใบที่ origin ใช้ และต้องติดตามแยกตามความรับผิดชอบนั้น

งานตรวจรอบต่ออายุผ่านไม่ได้แปลว่าเพิ่งได้ใบใหม่

เครื่องมืออาจตรวจแล้วพบว่ายังไม่ถึงเวลาต้องต่ออายุ จึงจบโดยไม่มีข้อผิดพลาดและไม่ได้เปลี่ยนใบ ตัวอย่าง Certbot มีการใช้ exit status ที่ต้องอ่านภายใต้ความหมายนี้ ไม่ใช้เลขศูนย์เป็นหลักฐานว่า certificate ทุกชุดเพิ่งถูกออกใหม่

หากต้องทำงานหลังต่ออายุสำเร็จ ควรใช้กลไกที่เครื่องมือกำหนดให้สัมพันธ์กับเหตุการณ์นั้น เช่น deploy hook ของ Certbot ซึ่งต่างจาก post hook ที่เกี่ยวข้องกับหลังความพยายามต่ออายุตามกติกาของมัน

แต่การเข้า deploy hook ก็ยังไม่รับรองว่าทุกคำสั่งภายในทำงานถูก เราต้องตรวจผลการส่งไฟล์ การตรวจ config และการนำค่าไปใช้ พร้อมเก็บสถานะเมื่อบางขั้นไม่ผ่าน ไม่ให้คำสั่งสุดท้ายที่ไม่สำคัญกลบความล้มเหลวของขั้นก่อนหน้า

รายละเอียดการติดตั้งและการเรียก hook ต้องตรวจตามรุ่นกับวิธีจัดการบริการที่ใช้ ไม่คัดลอกคำสั่ง reload ของระบบหนึ่งไปเรียกในอีกเครื่องที่ไม่ได้เป็นเจ้าของ TLS endpoint จริง

โหลดไฟล์ให้ถูกชุดก่อนคิดเรื่อง restart

Certificate กับ private key ต้องเป็นคู่ที่สอดคล้องกัน และ chain ต้องมีรูปแบบตามที่บริการรองรับ การอัปเดตไฟล์เพียงส่วนหนึ่งหรือสลับ path อาจทำให้ config ใหม่ใช้ไม่ได้ แม้ไฟล์แต่ละชิ้นเปิดอ่านได้ก็ตาม

ต้องดูด้วยว่าไฟล์ที่ service อ่านเป็น path เดียวกับที่เครื่องมือดูแลหรือเป็นสำเนาซึ่งต้องส่งต่อเอง หากใช้ volume หรือ symlink ควรตรวจความหมายของ path ในบริบทของ process นั้น ไม่ดูเฉพาะไฟล์จาก shell บน host แล้วคิดว่า container เห็นเหมือนกันทั้งหมด

การส่งมอบควรมีวิธีรักษาชุดไฟล์ให้ครบและย้อนกลับได้ตามเครื่องมือที่เลือก ไม่เขียนทับทีละชิ้นโดยเปิดช่วงที่บริการอาจอ่านชุดไม่ตรงกัน และต้องให้สิทธิ์อ่าน private key เฉพาะตัวที่จำเป็น ไม่แก้ด้วยการเปิดอ่านได้ทั้งเครื่องเพื่อให้ reload ผ่าน

สำหรับ NGINX การเปลี่ยน configuration ผ่านการ reload มีขั้นตรวจและนำค่าใหม่ไปใช้ ถ้าไม่ผ่านระบบอาจทำงานต่อด้วย config เก่า การที่ process ยังอยู่จึงไม่ได้ยืนยันว่าใบใหม่ถูกโหลดแล้ว ต้องอ่านผลของขั้น reload ร่วมกับการตรวจจากภายนอก

เปิด connection ใหม่และรักษาชื่อที่ client ใช้จริง

การดู certificate ในไฟล์ช่วยยืนยันสิ่งที่เตรียมไว้ ส่วนการเปิด TLS connection ใหม่ไปยัง endpoint ช่วยดูสิ่งที่มันส่งอยู่ ควรตรวจผ่าน hostname เดิมพร้อม SNI และเปิดการตรวจชื่อกับ chain ให้ตรง client ที่ต้องรองรับ

หากมีหลาย node ต้องเก็บว่าผลมาจากปลายทางใดด้วย การตรวจสุ่มครั้งเดียวอาจเจอ node ที่อัปเดตแล้ว ส่วนอีก node ยังส่งใบเดิมอยู่ การผูกหลักฐานกับที่อยู่และเวลาไว้จึงช่วยตามการกระจายที่ยังไม่ครบ

IPv4 กับ IPv6 ก็อาจถึงคนละจุด ต้องรวมทั้งสองในขอบเขตที่ประกาศให้บริการ และถ้ามีหลายภูมิภาคหรือ edge ให้ตรวจตามสิ่งที่ทีมควบคุมและผู้ให้บริการเปิดให้ยืนยัน ไม่ใช้ผลจาก origin ไปอ้างแทนใบที่ผู้ใช้ได้รับจาก edge

ข้อมูลที่เทียบได้มีชื่อใน SAN ผู้ออก ช่วงเวลาที่ใช้ได้ และตัวระบุใบตามเครื่องมือ ไม่จำเป็นต้องยึดว่าทุก endpoint ต้องได้ serial เดียวกันหากระบบตั้งใจใช้หลายใบที่ถูกต้อง แต่ต้องอธิบายได้ว่าแต่ละจุดใช้ชุดใดและยังผ่านสัญญาความเชื่อถือที่ต้องการ

ตรวจการติดตั้งโดยไม่เอาใบ staging ปะปน

การทดสอบต่ออายุช่วยให้รู้ว่าช่องทางยืนยันชื่อกับ client ทำงานได้ตามสภาพแวดล้อมทดสอบ แต่ไม่ได้พิสูจน์ทุกขั้นส่งมอบโดยอัตโนมัติ ต้องอ่านว่าโหมดทดสอบรัน hook ใด ใช้ไฟล์ใด และมีผลต่อบริการจริงหรือไม่

ควรแยกใบ staging ออกจากใบใช้งานจริงอย่างชัดเจน เพราะมันช่วยทดสอบกระบวนการแต่ไม่ใช่สิ่งที่ client ทั่วไปเชื่อถือตามปกติ การทดสอบที่ดีต้องตรวจการกระจายโดยไม่เผลอทำให้ endpoint จริงส่งใบของระบบทดสอบแทน

เมื่อจำลองความล้มเหลว ให้ใช้สภาพแวดล้อมที่แยกและเก็บชุดเดิมไว้ เช่น ขั้นตรวจ config ไม่ผ่านหรือปลายทางหนึ่งรับไฟล์ไม่ได้ แล้วดูว่าระบบรายงานสถานะค้างให้ตามแก้ได้จริงหรือไม่ ไม่ทดสอบด้วยการทำให้ใบ production หมดอายุเพื่อรอดูว่ามีใครแจ้ง

ติดตามอายุจากจุดใช้งาน ควบคู่กับสุขภาพของงานต่ออายุ

การติดตามควรมีทั้งผลรอบต่ออายุและอายุใบที่ endpoint ส่ง เพื่อให้เห็นกรณีงาน scheduler ไม่ทำงานกับกรณีออกใบแล้วแต่ส่งไม่ครบแยกกัน การมีข้อมูลเพียงฝั่งใดฝั่งหนึ่งยังเหลือช่องว่างให้หมดอายุโดยไม่มีหลักฐานตรงเหตุ

กำหนดเวลาที่ต้องแก้ก่อนหมดอายุจากระยะดำเนินการจริงของทีมและระบบ ไม่เลือก threshold จากตัวเลขในบทความทั่วไป แล้วเตรียมข้อมูลที่ใช้ส่งต่อ เช่น ชื่อบริการ จุด TLS และขั้นสุดท้ายที่ตรวจผ่าน โดยไม่แนบ private key หรือ credential ของ CA

ใบรับรองที่ต่ออายุแล้วต้องเดินทางจากการออกใบไปถึง endpoint ที่ผู้ใช้เชื่อมจริง การแยกสถานะแต่ละขั้น พร้อมตรวจ connection ใหม่และอายุใบที่ถูกส่ง ช่วยให้รู้ว่าปัญหาอยู่ที่การขอ การส่งมอบหรือการโหลดค่า เราจึงติดตาม HTTPS จากสิ่งที่ผู้ใช้ได้รับ แทนการพึ่งข้อความว่างานต่ออายุผ่านเพียงอย่างเดียว