แก้ไขปัญหาใบรับรอง Zimbra หมดอายุ: ต่ออายุใบรับรองแบบลงนามด้วยตนเองอย่างปลอดภัย

เซิร์ฟเวอร์ Zimbra อาจดูเหมือนทำงานได้ปกติ จนกระทั่งผู้ใช้พบคำเตือนในเบราว์เซอร์ เช่น “ใบรับรองหมดอายุ” โปรแกรมอีเมลปฏิเสธการเชื่อมต่อ SSL/TLS หรือผู้ดูแลระบบพบว่าใบรับรองหมดอายุแล้ว วิธีแก้ไขที่ปลอดภัยและรวดเร็วที่สุดคือ อย่าเปลี่ยนส่วนประกอบทั้งหมดของใบรับรองในทันที ให้ตรวจสอบก่อนว่าส่วนใดหมดอายุ จากนั้นจึงต่ออายุส่วนที่จำเป็นที่สุด

ขั้นตอนปัจจุบันของ Zimbra Tech Center สำหรับการใช้งานใบรับรองแบบลงนามเองบนเซิร์ฟเวอร์เดียว ใช้zmcertmgrในการสร้างและใช้งานใบรับรอง ที่สำคัญ Zimbra ระบุว่า การสร้างหน่วยงานออกใบรับรอง (CA) ใหม่นั้นเป็นทางเลือกสำหรับต่ออายุใบรับรองแบบลงนามเองทั่วไป คุณไม่จำเป็นต้องเปลี่ยน CA ทุกครั้งที่ใบรับรองเซิร์ฟเวอร์หมดอายุ เอกสารอ้างอิงอย่างเป็นทางการที่ใช้สำหรับคู่มือนี้ได้รับการตรวจสอบเมื่อวันที่ 6 ตุลาคม 2026: สร้างใบรับรอง SSL แบบลงนามเองใหม่ — เซิร์ฟเวอร์เดียวและคอนโซลการดูแลระบบ และเครื่องมือใบรับรอง CLI

เหตุใดใบรับรอง Zimbra ที่หมดอายุจึงก่อให้เกิดปัญหาในการให้บริการอย่างแท้จริง

Zimbra ใช้ใบรับรอง TLS ในบริการต่างๆ เช่น เว็บอินเทอร์เฟซ พร็อกซี LDAP และโปรโตคอลอีเมล เมื่อใบรับรองหมดอายุ ลูกค้าสามารถปฏิเสธการเชื่อมต่อได้ แม้ว่ากระบวนการของ Zimbra ที่อยู่เบื้องหลังจะยังคงทำงานอยู่ก็ตาม ดังนั้นคำเตือนในเบราว์เซอร์จึงเป็นเพียงอาการหนึ่งเท่านั้น ขึ้นอยู่กับโครงสร้างเครือข่ายและนโยบายของลูกค้า คุณอาจพบการเชื่อมต่อ IMAP/POP/SMTP ที่ปลอดภัยล้มเหลว ข้อผิดพลาดของพร็อกซี หรือปัญหา LDAP/TLS ด้วย

มีกรณีการหมดอายุที่แตกต่างกันสองกรณีที่ต้องแยกแยะ:

• เฉพาะใบรับรองเซิร์ฟเวอร์เท่านั้นที่หมดอายุกรณีนี้แก้ไขได้ง่ายกว่า หากใบรับรอง CA ของ Zimbra ยังใช้งานได้อยู่ ให้ใช้ใบรับรองเซิร์ฟเวอร์ใหม่ ติดตั้ง และรีสตาร์ทบริการ
• ใบรับรอง CA ของ Zimbra หมดอายุแล้ว โปรดสร้างและติดตั้ง CA ใหม่ จากนั้นสร้างและติดตั้งใบรับรองเซิร์ฟเวอร์ใหม่ที่ลงนามโดย CA นั้น ในการใช้งานแบบหลายเซิร์ฟเวอร์ ความสอดคล้องของ CA ระหว่างโหนดมีความสำคัญ ดังนั้นอย่ามองสภาพแวดล้อมแบบหลายโหนดเหมือนกับเซิร์ฟเวอร์เดียว

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

ขั้นตอนที่ 1: ตรวจสอบว่าใบรับรองที่ใช้งานอยู่นั้นหมดอายุแล้วจริงหรือไม่

สลับไปที่บัญชี Zimbra และตรวจสอบใบรับรองที่ใช้งานอยู่สำหรับบริการภายในเครื่อง:

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

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

คุณยังสามารถตรวจสอบใบรับรองที่ไคลเอ็นต์ระยะไกลได้รับจริงบน HTTPS ได้อีกด้วย แทนที่mail.example.comด้วยชื่อโฮสต์ที่ผู้ใช้เชื่อมต่อ:

openssl s_client -connect mail.example.com:443 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

การตรวจสอบระยะไกลนี้มีประโยชน์เมื่อviewdeployedcrtดูเหมือนถูกต้องแล้ว แต่เบราว์เซอร์ยังคงเห็นใบรับรองเก่าอยู่ เพราะเป็นการทดสอบใบรับรองที่แสดงผ่านเครือข่าย แทนที่จะทดสอบเฉพาะไฟล์ที่อยู่บนดิสก์เท่านั้น

ขั้นตอนที่ 2: ตรวจสอบสถานะการให้บริการและตัดสินใจว่า CA จำเป็นต้องต่ออายุด้วยหรือไม่

ก่อนทำการเปลี่ยนใบรับรอง โปรดตรวจสอบสถานะการให้บริการของ Zimbra ในปัจจุบัน เพื่อให้คุณมีข้อมูลอ้างอิง:

zmcontrol status

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

หาก CA หมดอายุแล้ว หรือคุณมีเหตุผลที่ได้รับการบันทึกไว้ว่าต้องเปลี่ยน CA ใหม่ ให้สร้าง CA ใหม่:

/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr deployca

ขั้นตอนที่ 3: สร้างและใช้งานใบรับรองเซิร์ฟเวอร์แบบลงนามด้วยตนเองใหม่

สำหรับการต่ออายุใบรับรองแบบเซิร์ฟเวอร์เดียวที่ไม่ซับซ้อน Zimbra ได้ระบุลำดับขั้นตอนดังต่อไปนี้ ตัวอย่างนี้จะสร้างใบรับรองที่มีอายุการใช้งาน 365 วัน:

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365
/opt/zimbra/bin/zmcertmgr deploycrt self

หากไคลเอ็นต์เชื่อมต่อผ่านชื่อ DNS มากกว่าหนึ่งชื่อ ให้สร้างใบรับรองโดยใช้ Subject Alternative Names ที่จำเป็น แทนที่จะถือว่าชื่อโฮสต์เริ่มต้นนั้นเพียงพอ เครื่องมือสร้างใบรับรองของ Zimbra รองรับสิ่งนี้-subjectAltNamesตัวอย่างเช่น:

/opt/zimbra/bin/zmcertmgr createcrt -new -days 365 -subjectAltNames "mail.example.com,webmail.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt self

ใช้ชื่อที่ชี้ไปยังบริการ Zimbra นี้จริงๆ และเป็นชื่อที่ผู้ใช้หรือระบบผสานรวมของคุณใช้งานจริง ใบรับรองอาจยังไม่หมดอายุ แต่ก็ยังอาจตรวจสอบไม่ผ่านหากชื่อโฮสต์ที่ร้องขอไม่ตรงกับค่า subject/SAN ของใบรับรองนั้น

อย่าใช้ขั้นตอนการลงนามด้วยตนเองนี้เพื่อเขียนทับใบรับรองเชิงพาณิชย์/ที่ได้รับการยอมรับจากสาธารณะโดยไม่ตั้งใจ หากเซิร์ฟเวอร์ของคุณควรใช้ใบรับรองเชิงพาณิชย์ ให้หยุดที่นี่และทำตามขั้นตอนการติดตั้งใบรับรองเชิงพาณิชย์ของ Zimbra แทน

ขั้นตอนที่ 4: ตรวจสอบการติดตั้ง รีสตาร์ท Zimbra และทดสอบจากฝั่งไคลเอ็นต์

ตรวจสอบว่า Zimbra ได้ติดตั้งใบรับรองใหม่เรียบร้อยแล้ว:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

จากนั้นให้รีสตาร์ท Zimbra เพื่อให้บริการโหลดใบรับรองใหม่:

zmcontrol restart

หลังจากรีสตาร์ทเสร็จสมบูรณ์แล้ว ให้เรียกใช้คำสั่งต่อไปนี้:

zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

ผลลัพธ์ที่คุณต้องการนั้นง่ายมาก: บริการที่คาดหวังทำงานอยู่ และใบรับรองที่ใช้งานอยู่มีวันหมดอายุในอนาคต สุดท้าย ให้ทำการทดสอบ OpenSSL ระยะไกลซ้ำอีกครั้งกับชื่อโฮสต์ที่ผู้ใช้เข้าถึงจริง นั่นเป็นการพิสูจน์ว่ามีอะไรให้บริการบนเครือข่ายหลังจากรีสตาร์ทแล้ว

หากเบราว์เซอร์ยังคงแสดงใบรับรองเก่าหรือหมดอายุอยู่

อย่าสร้างใบรับรองใหม่ทันที ให้ดำเนินการตามขั้นตอนที่เหลือตามลำดับ:

• ตรวจสอบ DNS และชื่อโฮสต์ตรวจสอบให้แน่ใจว่าคุณกำลังทดสอบชื่อโฮสต์เดียวกันกับที่ระบุไว้ในใบรับรองใหม่ และสามารถเข้าถึงเซิร์ฟเวอร์ Zimbra ที่ต้องการได้
• ตรวจสอบเส้นทางพร็อกซีเอกสารการแก้ไขปัญหาใบรับรองของ Zimbra ระบุว่าพร็อกซีอาจยังคงแสดงใบรับรองเก่าในบางกรณี ตรวจสอบใบรับรองที่แสดงจากระยะไกล ไม่ใช่แค่ไฟล์ใบรับรองในเครื่องเท่านั้น ดู ข้อ ผิดพลาดของใบรับรอง Zimbra
• ตรวจสอบความน่าเชื่อถือของไคลเอ็นต์ใบรับรองที่ลงนามด้วยตนเองที่ต่ออายุแล้วอาจยังคงมีผลใช้ได้ตามวันหมดอายุ แต่เบราว์เซอร์หรือไคลเอ็นต์อีเมลอาจยังไม่เชื่อถือ การหมดอายุและความน่าเชื่อถือเป็นคนละเรื่องกัน
• ตรวจสอบเวลาของระบบนาฬิกาบนเซิร์ฟเวอร์หรือไคลเอ็นต์ที่ผิดพลาดอย่างร้ายแรงอาจทำให้ใบรับรองที่ถูกต้องดูเหมือนไม่ถูกต้องหรือหมดอายุแล้ว
• ตรวจสอบ CA ( Certificate Authority) หากใบรับรองปลายทางเป็นใบใหม่ แต่ CA ของ Zimbra ที่ออกใบรับรองหมดอายุแล้ว ให้เปลี่ยน CA และสร้างใบรับรองเซิร์ฟเวอร์ใหม่จาก CA ใหม่

ระบบ Zimbra แบบหลายเซิร์ฟเวอร์ต้องการการดูแลที่แตกต่างออกไป

สำหรับการติดตั้งแบบหลายโหนด ให้ใช้ขั้นตอนสำหรับหลายเซิร์ฟเวอร์แทนที่จะทำซ้ำคำสั่งสำหรับเซิร์ฟเวอร์เดียวบนทุกโฮสต์โดยไม่รู้ข้อมูล Zimbra ได้จัดทำเอกสารเกี่ยวกับการสร้าง/ปรับใช้ CA แล้วปรับใช้ใบรับรองแบบลงนามด้วยตนเองไปยังโหนดต่างๆ ด้วยคำสั่งดังกล่าวdeploycrt self -allserverนอกจากนี้ยังเตือนว่าviewdeployedcrtคำสั่งนี้จะรายงานเฉพาะเซิร์ฟเวอร์ภายในเครื่องเท่านั้น เอกสารอ้างอิงอย่างเป็นทางการคือRegenerate Self-Signed SSL Certificate — Multi- Server

ความไม่ตรงกันของ CA ระหว่างมาสเตอร์ LDAP และรีพลิเคชันอาจทำให้เกิดปัญหาเกี่ยวกับ TLS และการจำลองข้อมูล หากคุณใช้งานโครงสร้างแบบหลายเซิร์ฟเวอร์ โปรดตรวจสอบห่วงโซ่ CA บนโหนดที่ได้รับผลกระทบทุกโหนด และปฏิบัติตามลำดับการติดตั้งที่ระบุไว้ในเอกสาร

การตรวจสอบด้วยตนเอง: วิธีตรวจสอบว่าการแก้ไขเสร็จสมบูรณ์แล้ว

ก่อนปิดเคส โปรดตรวจสอบสิ่งต่อไปนี้ทั้งหมด:

• zmcontrol statusแสดงให้เห็นว่าบริการ Zimbra ที่คาดหวังไว้กำลังทำงานอยู่
• zmcertmgr viewdeployedcrtแสดงใบรับรองที่มีวันหมดอายุในอนาคต
• การตรวจสอบระยะไกลopenssl s_clientจะส่งคืนวันที่ของใบรับรองใหม่ตรงกับวันที่ที่ผู้ใช้ชื่อโฮสต์สาธารณะ/ภายในใช้งานจริง
• หัวข้อของใบรับรองหรือ SAN ครอบคลุมชื่อโฮสต์นั้น
• เว็บเมลและโปรโตคอลอีเมลที่สภาพแวดล้อมของคุณใช้สามารถสร้างการเชื่อมต่อ TLS ได้
• หากคุณได้ทำการเปลี่ยน CA ของ Zimbra โดยเจตนา ระบบไคลเอ็นต์หรือระบบภายในที่เชื่อมต่อหรือเชื่อถือ CA เก่าจะได้รับการอัปเดตตามที่จำเป็นแล้ว

สำหรับการหมดอายุของใบรับรอง CA บนเซิร์ฟเวอร์เดี่ยวตามปกติ วิธีที่ก่อให้เกิดผลกระทบน้อยที่สุดมักจะเป็นการเก็บใบรับรอง Zimbra CA ที่ยังคงใช้งานได้ไว้ สร้างใบรับรองเซิร์ฟเวอร์แบบลงนามเองใหม่ ติดตั้งใช้งาน รีสตาร์ทบริการ และตรวจสอบใบรับรองจากภายนอกเซิร์ฟเวอร์ เปลี่ยน CA ก็ต่อเมื่อหมดอายุหรือมีเหตุผลที่ชัดเจนอื่น ๆ ในการเปลี่ยน CA วิธีการนี้ช่วยแก้ไขปัญหาการหยุดชะงักในทันทีพร้อมทั้งหลีกเลี่ยงการเปลี่ยนแปลงห่วงโซ่ความเชื่อถือที่ไม่จำเป็น