วิธีการติดตั้งใบรับรอง SSL เชิงพาณิชย์บนเซิร์ฟเวอร์ Zimbra

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

วิธีที่ปลอดภัยที่สุดในการจัดการงานนี้คือการทำเป็นลำดับของการตรวจสอบแทนที่จะเป็นคำสั่ง "ติดตั้งใบรับรอง" เพียงครั้งเดียว เครื่องมือใบรับรองของ Zimbra ที่มีเอกสารกำกับไว้zmcertmgrสามารถสร้างคำขอลงนามใบรับรอง (CSR) ตรวจสอบคีย์ส่วนตัวและห่วงโซ่ CA ปรับใช้ใบรับรองกับบริการของ Zimbra และแสดงใบรับรองที่ใช้งานอยู่ในปัจจุบัน ศูนย์เทคนิคอย่างเป็นทางการของ Zimbra ได้บันทึกคำสั่งเหล่านี้ไว้ในคู่มือคอนโซลการดูแลระบบและเครื่องมือใบรับรอง CLI

ตัวอย่างการติดตั้ง Zimbra SSL ที่ประสบความสำเร็จควรมีลักษณะอย่างไร

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

• รายการ SAN ของใบรับรองประกอบด้วยชื่อโฮสต์สาธารณะทั้งหมดที่ไคลเอ็นต์ใช้งานจริง เช่นmail.example.com.
• ใบรับรองที่ออกให้ตรงกับรหัสส่วนตัวที่จัดเก็บไว้สำหรับใบรับรองเชิงพาณิชย์
• Zimbra สามารถตรวจสอบความถูกต้องของห่วงโซ่ใบรับรองทั้งหมด ตั้งแต่ใบรับรองเซิร์ฟเวอร์ ผ่านใบรับรอง CA ระดับกลาง ไปจนถึง CA ระดับราก
• zmcertmgr deploycrt commดำเนินการเสร็จสมบูรณ์โดยไม่มีข้อผิดพลาดเรื่องคีย์ไม่ตรงกันหรือการตรวจสอบความต่อเนื่องของข้อมูล
• บริการของ Zimbra กลับมาทำงานได้อย่างราบรื่น
• zmcertmgr viewdeployedcrtแสดงใบรับรองที่คาดหวังไว้
• เบราว์เซอร์หรือไคลเอ็นต์ TLS ที่เชื่อมต่อกับชื่อโฮสต์สาธารณะจะเห็นใบรับรองใหม่และจะไม่เห็นคำเตือนเรื่องความน่าเชื่อถือ

หากการตรวจสอบใดๆ เหล่านี้ล้มเหลว ให้แก้ไขเลเยอร์นั้นๆ ก่อนดำเนินการต่อ การปรับใช้ไฟล์เดิมซ้ำๆ มักไม่สามารถแก้ปัญหาคีย์, SAN หรือห่วงโซ่ได้

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

หน้า Tech Center ปัจจุบันของ Zimbra ระบุว่า ใน Zimbra เวอร์ชัน 8.7 และเวอร์ชันที่ใหม่กว่าzmcertmgrจะทำงานในฐานะzimbraผู้ใช้ นอกจากนี้ยังระบุว่าคีย์ส่วนตัวเชิงพาณิชย์จะต้องตั้งชื่อไว้commercial.keyใน/opt/zimbra/ssl/zimbra/commercialและไฟล์ใบรับรองเซิร์ฟเวอร์พร้อมไฟล์ CA-chain ควรถูกจัดเตรียมไว้ในไดเร็กทอรีชั่วคราวก่อนการใช้งานจริง

ขั้นตอนที่ 1: สำรองข้อมูลใบรับรองปัจจุบัน

อย่าเริ่มด้วยการลบไดเร็กทอรี SSL ที่มีอยู่ก่อน ให้สร้างข้อมูลสำรองก่อนเพื่อที่คุณสามารถกู้คืนได้หากการติดตั้งใหม่ล้มเหลว ตัวอย่างที่ปลอดภัยสำหรับผู้ใช้ root คือ:

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.backup-$(date +%Y%m%d-%H%M%S)

โปรดจดบันทึกใบรับรองที่ใช้งานอยู่ปัจจุบันก่อนที่จะทำการเปลี่ยนแปลง:

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

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

ขั้นตอนที่ 2: สร้าง CSR ด้วยชื่อโฮสต์ที่คุณต้องการใช้งานจริง

สำหรับการสร้างใบรับรองเชิงพาณิชย์ใหม่ ให้สร้าง CSR โดยใช้ชื่อโฮสต์สำหรับการใช้งานจริงและ SAN เพิ่มเติมใดๆ เอกสารของ Zimbra ระบุไวยากรณ์ดังต่อไปนี้:

/opt/zimbra/bin/zmcertmgr createcsr comm -new \
-subject "/C=US/ST=CA/L=Sunnyvale/O=Example/OU=IT/CN=mail.example.com" \
-subjectAltNames "mail.example.com"

หากผู้ใช้เชื่อมต่อผ่านชื่ออื่น เช่นwebmail.example.comให้รวมชื่อนั้นไว้ในรายการ SAN เมื่อขอใบรับรอง ไคลเอนต์ TLS สมัยใหม่จะตรวจสอบชื่อโฮสต์กับ SAN ดังนั้นใบรับรองที่ดูถูกต้องตามชื่อทั่วไปเพียงอย่างเดียว อาจยังคงแสดงคำเตือนในเบราว์เซอร์หากไม่มีชื่อโฮสต์

ตรวจสอบ CSR ก่อนส่งไปยังหน่วยงานออกใบรับรองของคุณ:

/opt/zimbra/bin/zmcertmgr viewcsr comm /opt/zimbra/ssl/zimbra/commercial/commercial.csr

จุดตรวจสอบ:หยุดที่นี่หากชื่อ DNS ที่ร้องขอไม่ถูกต้อง การออกใบรับรองก่อนแล้วพบว่า SAN หายไปในภายหลัง หมายความว่าโดยปกติแล้วคุณจะต้องให้ CA ออกใบรับรองใหม่ให้

ขั้นตอนที่ 3: รวบรวมใบรับรองเซิร์ฟเวอร์และห่วงโซ่ CA ที่สมบูรณ์

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

รูปแบบการจัดเวทีโดยทั่วไปมีดังนี้:

/tmp/commercial.crt
/tmp/ca_intermediary.crt
/tmp/ca.crt

จากนั้นสร้างห่วงโซ่ตามลำดับที่ Zimbra ได้ระบุไว้:

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

ใช้ไฟล์ที่หน่วยงานออกใบรับรอง (CA) จัดหาให้สำหรับผลิตภัณฑ์ใบรับรองของคุณโดยเฉพาะ อย่าคัดลอกใบรับรองระดับกลางจากบทเรียนที่ไม่เกี่ยวข้องเพียงเพราะชื่อแบรนด์ของ CA ดูคล้ายกัน ลำดับชั้นของ CA เปลี่ยนแปลงไปตามเวลา และใบรับรองระดับกลางที่ไม่ถูกต้องเป็นสาเหตุทั่วไปของunable to get local issuer certificateปัญหา

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

นี่คือด่านตรวจสอบความปลอดภัยที่สำคัญที่สุด เรียกใช้คำสั่งตรวจสอบที่ระบุไว้ในเอกสารโดยใช้ผู้ใช้ Zimbra ในเวอร์ชัน Zimbra ปัจจุบัน:

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

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

หากการตรวจสอบล้มเหลว ให้เลือกวิธีแก้ไขตามข้อผิดพลาด

• ใบรับรองและคีย์ส่วนตัวไม่ตรงกัน:ใบรับรอง CA ไม่ได้ออกโดย CSR ที่เชื่อมโยงกับปัจจุบันcommercial.keyโปรดกู้คืนคีย์ที่ถูกต้องหรือออกใบรับรองใหม่จาก CSR ใหม่
• ไม่สามารถตรวจสอบความถูกต้องของห่วงโซ่ใบรับรองได้:ชุดใบรับรองระดับกลาง/รากไม่สมบูรณ์ เรียงลำดับไม่ถูกต้อง หมดอายุ หรือไม่ใช่ห่วงโซ่สำหรับใบรับรองเซิร์ฟเวอร์นี้ โปรดขอรับห่วงโซ่ที่ถูกต้องจากหน่วยงานออกใบรับรอง (CA)
• ใบรับรองหมดอายุ:ห้ามใช้งาน ขอใบรับรองใหม่และตรวจสอบด้วยว่าใบรับรองระดับกลางหรือใบรับรองรากในห่วงโซ่หมดอายุหรือไม่ Zimbra ได้ระบุถึงข้อผิดพลาดนี้ไว้ใน คำแนะนำการแก้ไข ปัญหาใบรับรองรากที่หมดอายุแล้ว
• ชื่อโฮสต์หายไป:การตรวจสอบอาจไม่แสดงชื่อโฮสต์เดียวกันกับที่เบราว์เซอร์ตรวจสอบ โปรดตรวจสอบ SAN ที่ออกให้และออกใหม่หากไม่พบชื่อสาธารณะ

ขั้นตอนที่ 5: ใช้งานใบรับรองเชิงพาณิชย์

ควรดำเนินการติดตั้งใช้งานหลังจากตรวจสอบความถูกต้องเรียบร้อยแล้วเท่านั้น:

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

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

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

ขั้นตอนที่ 6: รีสตาร์ทบริการ Zimbra

หลังจากติดตั้งเสร็จแล้ว ให้รีสตาร์ท Zimbra:

su - zimbra
zmcontrol restart

จากนั้นตรวจสอบสถานะการให้บริการ:

zmcontrol status

หากบริการไม่กลับมาทำงานตามปกติRunningให้ตรวจสอบก่อนประกาศว่าการเปลี่ยนแปลงใบรับรองเสร็จสมบูรณ์ ปัญหาเกี่ยวกับใบรับรองอาจส่งผลกระทบต่อ LDAP, พร็อกซี, กล่องจดหมาย หรือการสื่อสารอื่นๆ ที่ขึ้นอยู่กับ TLS โดยเฉพาะอย่างยิ่งในการติดตั้งแบบหลายโหนด

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

ให้ใช้มุมมองใบรับรองของ Zimbra ก่อน:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

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

/opt/zimbra/bin/zmcertmgr checkcrtexpiration all -days 30

สุดท้ายนี้ ให้ทดสอบชื่อโฮสต์สาธารณะที่ผู้ใช้เปิดใช้งานอย่างละเอียด การตรวจสอบ OpenSSL จากเครื่องอื่นที่มีประโยชน์คือ:

openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts

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

เมื่อขั้นตอนมาตรฐานไม่เพียงพอ

เปลี่ยนวิธีการของคุณแทนที่จะบังคับใช้ขั้นตอนแบบโหนดเดียว หากมีเงื่อนไขใดเงื่อนไขหนึ่งต่อไปนี้เกิดขึ้น:

• Zimbra แบบหลายโหนด:การติดตั้งใบรับรองอาจต้องครอบคลุมบทบาทพร็อกซี กล่องจดหมาย LDAP และ MTA บนโฮสต์ที่แตกต่างกัน เครื่องมือใบรับรองของ Zimbra รองรับตัวเลือกหลายเซิร์ฟเวอร์ แต่โปรดตรวจสอบขั้นตอนสำหรับโครงสร้างระบบของคุณก่อนใช้งาน
• รีเวิร์สพร็อกซีหรือโหลดบาลานเซอร์ภายนอกจะยุติการเชื่อมต่อ TLS:อาจจำเป็นต้องติดตั้งใบรับรองสาธารณะบนอุปกรณ์นั้นด้วย ใบรับรอง Zimbra ที่ถูกต้องเพียงอย่างเดียวจะไม่เปลี่ยนแปลงสิ่งที่ไคลเอ็นต์เห็นหาก TLS ยุติการทำงานที่ต้นทาง
• คุณกำลังนำเข้าคีย์ที่มีอยู่แล้ว:โปรดตรวจสอบให้แน่ใจว่าได้วางคีย์นั้นไว้ในตำแหน่งที่ Zimbra คาดหวังว่าจะมีคีย์ส่วนตัวเชิงพาณิชย์ และสิทธิ์การเข้าถึงตรงกับข้อกำหนดของเวอร์ชันก่อนทำการตรวจสอบ
• หน่วยงานออกใบรับรอง (CA) ของคุณจัดหาชุดใบรับรองระดับกลางให้เท่านั้น:โปรดปฏิบัติตามคำแนะนำของ CA ในปัจจุบันสำหรับห่วงโซ่ใบรับรอง แทนที่จะสร้างใบรับรองรากขึ้นมาเอง Zimbra ต้องการห่วงโซ่ใบรับรองที่สามารถตรวจสอบความถูกต้องได้ ซึ่งไฟล์ที่ใช้จะขึ้นอยู่กับผู้ออกใบรับรอง
• ใบรับรองได้รับการต่ออายุโดยใช้ชื่อโฮสต์เดิม แต่ใช้คีย์ที่แตกต่างกัน:โปรดอัปเดตคีย์ส่วนตัวให้ตรงกันก่อนทำการตรวจสอบcommercial.keyใบรับรองที่ออกใหม่สำหรับคู่คีย์ใหม่ไม่สามารถใช้ตรวจสอบความ ถูกต้องได้

การตรวจสอบตนเองครั้งสุดท้าย

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

สำหรับไวยากรณ์คำสั่งและพฤติกรรมเฉพาะเวอร์ชัน โปรดใช้เอกสารเครื่องมือใบรับรองอย่างเป็นทางการ ของ Zimbra เป็นแหล่งอ้างอิงหลัก ตัวอย่างในที่นี้ใช้mail.example.comเป็นเพียงตัวแทน โปรดแทนที่ชื่อ ไฟล์ใบรับรอง และรายละเอียดองค์กรด้วยค่าที่ออกให้สำหรับสภาพแวดล้อมของคุณ