วิธีแก้ไขปัญหาข้อความแสดงข้อผิดพลาด “ไม่สามารถเริ่มต้น TLS ได้: การเชื่อมต่อ SSL ล้มเหลว” ใน Zimbra

ข้อความนี้Unable to start TLS: SSL handshake failedหมายความว่าไคลเอนต์และเซิร์ฟเวอร์ไม่สามารถทำการเจรจาเพื่อเริ่มต้นการเชื่อมต่อแบบเข้ารหัสได้สำเร็จ ใน Zimbra ข้อความนี้อาจมาจากหลายแหล่ง รูปแบบที่พบบ่อยคือข้อความzmcontrol statusแจ้งว่าการเชื่อมต่อกับ LDAP master ล้มเหลวในการตรวจสอบใบรับรอง นอกจากนี้ ไคลเอนต์อีเมลหรือรีเลย์ SMTP ก็อาจรายงานปัญหาการเชื่อมต่อบนพอร์ตอีเมลสาธารณะได้เช่นกัน

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

สิ่งที่ควรรู้ก่อนเปลี่ยนแปลงอะไรก็ตาม

TLSคือโปรโตคอลที่ใช้เข้ารหัสการเชื่อมต่อเครือข่ายการจับมือ TLSคือการแลกเปลี่ยนข้อมูลเบื้องต้นที่ระบบทั้งสองตกลงกันเกี่ยวกับพารามิเตอร์การเข้ารหัสและตรวจสอบความถูกต้องของใบรับรองเซิร์ฟเวอร์STARTTLSเริ่มต้นด้วยการเชื่อมต่อโปรโตคอลแบบธรรมดา จากนั้นจะเปลี่ยนไปใช้ TLS เมื่อทั้งสองฝ่ายร้องขอ LDAP และ SMTP สามารถใช้ STARTTLS ได้ ดังนั้นข้อผิดพลาดนี้เพียงอย่างเดียวจึงไม่สามารถระบุบริการที่ล้มเหลวได้

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

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

ขั้นตอนที่ 1: ระบุการเชื่อมต่อ TLS ที่ล้มเหลว

ขั้นแรก ให้ลองทำซ้ำปัญหาและอ่านข้อความทั้งหมด หากข้อความปรากฏขึ้นเมื่อ Zimbra ตรวจสอบสถานะบริการและมีข้อความเช่นนั้นwhen connecting to ldap masterให้ตรวจสอบ TLS ภายในของ LDAP หากมีเพียงไคลเอนต์อีเมลเท่านั้นที่ล้มเหลวในการส่งอีเมลผ่าน SMTP ให้ตรวจสอบปลายทาง SMTP สาธารณะ รวมถึงชื่อโฮสต์ พอร์ต และโหมดการเข้ารหัสของไคลเอนต์

su - zimbra
zmcontrol status

ตรวจสอบบันทึก Zimbra ล่าสุดที่มีเวลาประทับเดียวกัน ในการติดตั้งหลายๆ ครั้ง บันทึกหลักจะอยู่ที่/var/log/zimbra.log; ใช้ตำแหน่งบันทึกที่กำหนดค่าไว้บนเซิร์ฟเวอร์ของคุณ

grep -Ei 'Unable to start TLS|SSL handshake|certificate|ldap|STARTTLS' /var/log/zimbra.log | tail -n 80

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

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

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url
zmlocalconfig ldap_starttls_supported
zmlocalconfig ldap_starttls_required

ความพร้อมใช้งานและผลลัพธ์ที่สำคัญอาจแตกต่างกันไปตามเวอร์ชันของ Zimbra และบทบาทของโหนด ข้อมูลเหล่านี้ใช้สำหรับการวินิจฉัยเท่านั้น อย่าเปลี่ยนแปลงค่าใดๆ เพียงเพราะมันปรากฏในผลลัพธ์ เอกสารของ Zimbra อธิบายถึงบทบาทของการตั้งค่า LDAP STARTTLS และแนะนำให้เปิดใช้งาน TLS ภายในไว้: ค่าการกำหนดค่าภายในของ Zimbra TLS และ STARTTLS

ขั้นตอนที่ 2: ตรวจสอบนาฬิการะบบ, DNS และการเชื่อมต่อ

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

date -u
getent hosts ldap.example.com

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

สำหรับการเชื่อมต่อ SMTP STARTTLS ที่เชื่อมต่อกับไคลเอ็นต์ คู่มือการแก้ไขปัญหา SMTP ของ Zimbra สาธิตการทดสอบพอร์ต 25 ด้วย OpenSSL พอร์ต 587 ก็เป็นพอร์ตที่ใช้กันทั่วไปสำหรับการส่งข้อความด้วย STARTTLS เช่นกัน ใช้ชื่อโฮสต์และพอร์ตที่กำหนดค่าไว้ในไคลเอ็นต์อีเมล:

openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -showcerts

สำหรับ SMTP บนพอร์ต 25 ให้แทนที่587ด้วย25พอร์ต 465 ใช้ TLS แบบไม่ระบุชัดเจน ดังนั้นอย่าเพิ่ม เมื่อทดสอบพอร์ตนั้น การเชื่อมต่อ TCP ที่สำเร็จไม่ได้หมายความว่าใบรับรองนั้นเชื่อถือได้หรือว่าไคลเอ็นต์ใช้โหมดความปลอดภัยที่ถูกต้องเสมอไป โปรด-starttls smtpดูคู่มือการแก้ไขปัญหา SMTP และ OpenSSL ของ Zimbra

ขั้นตอนที่ 3: ตรวจสอบใบรับรองที่ Zimbra นำไปใช้งานจริง

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

ในฐานะผู้ดูแลระบบ Zimbra ให้ดูใบรับรองที่ Zimbra รายงานว่าได้ถูกติดตั้งแล้ว:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

ตรวจสอบหัวเรื่องหรือชื่อทางเลือกของหัวเรื่อง (SAN) ผู้ออกใบรับรอง วันหมดอายุ และบริการของใบรับรองแต่ละรายการ SAN ควรมีชื่อโฮสต์ที่ใช้จริงสำหรับการเชื่อมต่อ LDAP หรืออีเมล นอกจากนี้ ตรวจสอบให้แน่ใจว่าโหนดทั้งหมดในการใช้งานแบบหลายเซิร์ฟเวอร์มีใบรับรองและห่วงโซ่ใบรับรองที่คาดหวังไว้ Zimbra ระบุว่าการดูใบรับรองที่ใช้งานอยู่จะทำได้เฉพาะในเซิร์ฟเวอร์ ดังนั้นให้เรียกใช้การตรวจสอบบนแต่ละโหนดที่เกี่ยวข้อง

หากคุณมีไฟล์ใบรับรองต้นฉบับ โปรดตรวจสอบวันที่และชื่อของไฟล์เหล่านั้นก่อนนำไปใช้งาน:

openssl x509 -in /tmp/commercial.crt -noout -dates -subject -issuer -ext subjectAltName

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

ขั้นตอนที่ 4: ตรวจสอบคีย์ส่วนตัวและห่วงโซ่ใบรับรอง

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

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

/opt/zimbra/bin/zmcertmgr verifycrt comm   /opt/zimbra/ssl/zimbra/commercial/commercial.key   /tmp/commercial.crt   /tmp/ca_chain.crt

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

คู่มือใบรับรองของ Zimbra อธิบายลำดับขั้นตอนการตรวจสอบและการใช้งาน รวมถึงห่วงโซ่ CA: การติดตั้งใบรับรอง Zimbra และเครื่องมือ CLIหน้าการแก้ไขปัญหาห่วงโซ่ใบรับรองยังอธิบายถึงข้อผิดพลาดในการตรวจสอบห่วงโซ่ผู้ออกใบรับรองด้วย: คำแนะนำเกี่ยวกับห่วงโซ่ใบรับรองของ Zimbra

ขั้นตอนที่ 5: แก้ไขและใช้งานใบรับรองอย่างปลอดภัย

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

/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt

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

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

su - zimbra
zmcontrol restart
zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

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

ขั้นตอนที่ 6: ตรวจสอบการตั้งค่าความเชื่อถือของ LDAP โดยไม่ต้องปิดใช้งาน TLS

หากใบรับรองผ่านการตรวจสอบแล้ว แต่ไคลเอ็นต์ LDAP ของ Zimbra ยังคงปฏิเสธ ให้ตรวจสอบข้อมูลความเชื่อถือของ LDAP และโหนดที่ล้มเหลว เอกสารการแก้ไขปัญหา MTA ที่เก็บถาวรของ Zimbra ระบุว่าห่วงโซ่ CA ที่ไม่ถูกต้อง ใบรับรอง CA ที่หมดอายุ และไฟล์ที่ไม่คาดคิด เป็น/opt/zimbra/conf/caสาเหตุที่เป็นไปได้ของความล้มเหลวของ LDAP STARTTLS ให้ใช้สิ่งนี้เป็นแนวทางในการวินิจฉัย ไม่ใช่เหตุผลในการลบไฟล์: เปรียบเทียบไดเร็กทอรีกับข้อมูลสำรองที่ใช้งานได้ดี หรือคำแนะนำเฉพาะเวอร์ชัน และเก็บรักษาเนื้อหาไว้ก่อนทำการเปลี่ยนแปลงใดๆ

สำหรับการตรวจสอบ LDAP STARTTLS แบบง่ายๆ ไคลเอนต์ OpenLDAP สามารถกำหนดให้ต้องมี StartTLS และสอบถาม Root DSE โดยไม่ต้องระบุข้อมูลประจำตัวบัญชี:

ldapsearch -x -ZZ -H ldap://ldap.example.com:389 -b "" -s base namingContexts

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

ขั้นตอนที่ 7: พิจารณาความเข้ากันได้ของโปรโตคอลหลังจากตรวจสอบใบรับรองแล้วเท่านั้น

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

อย่า "แก้ไข" ข้อผิดพลาดด้วยการเปิดใช้งาน SSLv3 ลดความเข้มงวดในการตรวจสอบ หรือปิดใช้งาน LDAP STARTTLS ทั่วโลก กระทู้ในฟอรัมของ Zimbra มีวิธีแก้ปัญหาชั่วคราวที่ปิดใช้งาน LDAP STARTTLS แต่ผู้ตอบอีกท่านหนึ่งได้เตือนอย่างถูกต้องแล้วว่าการปิดใช้งานคุณสมบัติความปลอดภัยไม่ใช่วิธีแก้ไขใบรับรองที่ถูกต้อง บันทึกการกำหนดค่าภายในของ Zimbra เองแนะนำให้เปิดใช้งาน interprocess TLS และ LDAP STARTTLS ไว้ ใช้การเปลี่ยนแปลงดังกล่าวเฉพาะในกรณีการวินิจฉัยชั่วคราวที่ควบคุมอย่างเข้มงวดหากฝ่ายสนับสนุนของ Zimbra แนะนำให้คุณทำเช่นนั้น และคืนค่าการตั้งค่าที่ปลอดภัยทันที

วิธีการยืนยันการซ่อมแซม

• zmcontrol statusการดำเนินการจะเสร็จสมบูรณ์โดยไม่มีข้อผิดพลาด LDAP TLS หากนั่นคือสาเหตุที่ทำให้การดำเนินการล้มเหลว
• ปลายทาง LDAP หรือ SMTP ที่ได้รับผลกระทบแสดงใบรับรองที่คาดหวังซึ่งยังไม่หมดอายุและมีห่วงโซ่ผู้ออกใบรับรองที่สมบูรณ์
• การทดสอบจากโฮสต์และเส้นทางเครือข่ายเดียวกันนั้นประสบความสำเร็จด้วยโหมด TLS ที่ต้องการ
• บันทึกของ Zimbra ไม่แสดงข้อผิดพลาดในการตรวจสอบใบรับรองหรือการเชื่อมต่อระหว่างการทดสอบอีกต่อไป
• สำหรับโปรโตคอล SMTP ให้ส่งข้อความทดสอบทั้งสองทิศทาง และยืนยันการส่งในคิวหรือบันทึกที่เกี่ยวข้อง

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

หมายเหตุประกอบเอกสาร:หน้าเว็บเกี่ยวกับใบรับรองสาธารณะและ TLS ของ Zimbra มีเนื้อหาสำหรับหลายเวอร์ชัน และบางหน้าเกี่ยวกับการแก้ไขปัญหาถูกเก็บถาวรไว้อย่างชัดเจน คำสั่งในที่นี้สะท้อนถึงรูปแบบ CLI ที่ระบุไว้ในเอกสาร แต่ควรตรวจสอบเส้นทางใบรับรอง สิทธิ์ และข้อกำหนดในการรีสตาร์ทกับเอกสารสำหรับเวอร์ชัน Zimbra ที่ติดตั้งไว้ ตรวจสอบเมื่อวันที่ 6 ตุลาคม 2026