แก้ไขข้อผิดพลาดการเชื่อมต่อ SSL ของ Kopano บนพอร์ตที่กำหนดเอง

กำหนดความหมายของ "การแก้ไขที่ประสบความสำเร็จ"

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

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

ขั้นแรก ให้แยกการตั้งค่าพอร์ตทั่วไปทั้งสองแบบออกจากกัน

ตรวจสอบแล้วสำหรับ Kopano Core:คู่มือผู้ดูแลระบบ Kopano Core เวอร์ชัน 8.0 อธิบายถึงตัวรับฟัง TLS ดั้งเดิมที่ควบคุมโดยserver_listen_tlsตัวอย่างในคู่มือใช้พอร์ต 237 ระบุว่าสามารถเปลี่ยนพอร์ตได้ และกำหนดค่าไฟล์ใบรับรองและ CA ใน/etc/kopano/server.cfgคู่มือยังแสดงให้เห็นถึงไคลเอ็นต์ที่ใช้https://ซ็อกเก็ตเซิร์ฟเวอร์ที่มีพอร์ตและใบรับรองไคลเอ็นต์ที่ตรงกัน ดูKopano Core: การเชื่อมต่อ SSL และใบรับรองและการกำหนดค่าพิเศษของ Kopano Core

สำหรับการเข้าถึง WebApp นั้นโดยปกติผู้ใช้จะเปิด URL ในเบราว์เซอร์ซึ่งให้บริการโดย Apache, Nginx หรือ Kopano Web TLS สามารถยุติการทำงานที่เซิร์ฟเวอร์ส่วนหน้าได้ในขณะที่ส่งต่อคำขอไปยังบริการของ Kopano คู่มือของ Kopano อธิบายเกี่ยวกับการทำ HTTP proxy ไปยัง Core listener บนพอร์ต 236 ในขณะที่คู่มือ Kopano Web อธิบายเกี่ยวกับการตั้งค่าใบรับรอง TLS /etc/kopano/kwebd.cfgพอร์ต HTTPS ของส่วนหน้านั้นไม่จำเป็นต้องเหมือนกับพอร์ต TLS ของ Core เสมอไป โปรดตรวจสอบตัวอย่าง reverse-proxy ของ Coreและคู่มือการติดตั้ง Kopano Web

ขั้นตอนการปฏิบัติ:จดบันทึก URL ของไคลเอ็นต์ พอร์ตที่กำหนดเอง กระบวนการที่คาดว่าจะรับฟังที่พอร์ตนั้น และระบุว่า TLS สิ้นสุดที่พร็อกซีหรือที่ Kopano Core อย่าเปลี่ยนตัวรับฟังทั้งสองพร้อมกัน

1. ตรวจสอบว่ามีอะไรกำลังรับฟังอยู่บนพอร์ตที่กำหนดเองบ้าง

บนเครื่อง Kopano ให้แทนที่ข้อมูล8443ด้านล่างด้วยหมายเลขพอร์ตที่มีปัญหา:

sudo ss -ltnp | grep ':8443'

แถวที่ตรงกันควรแสดงซ็อกเก็ตที่กำลังรอรับการเชื่อมต่อ หากไม่มีแถวใดแสดงว่าบริการไม่ได้ผูกกับพอร์ตนั้น หรือผูกกับที่อยู่พอร์ตอื่น หากพอร์ตนั้นเป็นของพร็อกซีแบบย้อนกลับในเครื่อง ให้ตรวจสอบโฮสต์เสมือนของพร็อกซี หากควรเป็นพอร์ต TLS ดั้งเดิมของ Kopano Core ให้ตรวจสอบserver_listen_tlsในไฟล์/etc/kopano/server.cfg. กระบวนการที่กำลังรอรับการเชื่อมต่อเฉพาะบนพอร์ตนั้น127.0.0.1จะไม่สามารถรับการเชื่อมต่อจากระยะไกลได้โดยตรง ซึ่งอาจเป็นเจตนาเมื่อมีพร็อกซีอยู่ด้านหน้า

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

2. ตรวจสอบ TLS บนชื่อโฮสต์และพอร์ตที่แน่นอน

จากเครื่องไคลเอ็นต์ ทดสอบเอนด์พอยต์สาธารณะด้วย OpenSSL ใช้ชื่อ DNS ที่ปรากฏในใบรับรอง ไม่ใช่ที่อยู่ IP ที่ไม่เกี่ยวข้อง:

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

ตรวจสอบหาใบรับรองที่แสดง โปรโตคอลและรหัสลับที่เจรจาต่อรอง และข้อผิดพลาดในการตรวจสอบใดๆ-servernameตัวเลือกนี้จะส่งชื่อโฮสต์ TLS SNI ซึ่งมีความสำคัญเมื่อเซิร์ฟเวอร์โฮสต์ไซต์ TLS มากกว่าหนึ่งไซต์ OpenSSL อธิบายตัวเลือกเหล่านี้ไว้ในคู่มือ s_clientกด Ctrl+C เพื่อออกจากโหมดตรวจสอบแบบโต้ตอบ

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

สำหรับเอนด์พอยต์ที่เข้าถึงได้จากเบราว์เซอร์ ให้ทำตามขั้นตอนต่อไปนี้:

curl -v https://mail.example.com:8443/webapp/

รายละเอียดที่แสดงออกมาช่วยให้แยกแยะการตรวจสอบ TLS ออกจากการตอบสนอง HTTP เช่น การเปลี่ยนเส้นทาง ข้อผิดพลาด 404 หรือ 502 ได้ ข้อผิดพลาด 404 หลังจากการเชื่อมต่อเสร็จสมบูรณ์แล้ว แสดงว่ามีปัญหาเกี่ยวกับเส้นทางหรือการกำหนดเส้นทาง ไม่ใช่ความล้มเหลวในการเจรจา TLS สำหรับการวินิจฉัยเพียงครั้งเดียวcurl -vkสามารถแสดงได้ว่าการข้ามการตรวจสอบใบรับรองจะเปลี่ยนผลลัพธ์หรือไม่ อย่าปิดใช้งานการตรวจสอบใบรับรองในเบราว์เซอร์ ไคลเอ็นต์ หรือพร็อกซี

ข้อจำกัดที่สำคัญ: TLS ดั้งเดิมของ Kopano Core สามารถใช้ใบรับรองไคลเอ็นต์ได้s_clientการทดสอบพื้นฐานโดยไม่มีใบรับรองไคลเอ็นต์อาจถูกปฏิเสธแม้ว่าตัวรับฟัง TLS จะทำงานได้อย่างถูกต้องก็ตาม หากเซิร์ฟเวอร์ร้องขอการตรวจสอบสิทธิ์ไคลเอ็นต์ ให้ทำการทดสอบซ้ำโดยใช้ใบรับรองไคลเอ็นต์และคีย์ที่ได้รับอนุญาต หรือทดสอบโดยใช้ไคลเอ็นต์บริการ Kopano ที่กำหนดค่าไว้ ห้ามเปิดเผยคีย์ส่วนตัวในบันทึกคำสั่งหรือตั๋วสนับสนุนเด็ดขาด

3. จับคู่โปรโตคอลกับผู้รับฟัง

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

• https://mail.example.com:8443/webapp/หมายความว่าเบราว์เซอร์คาดหวังให้มีการใช้งาน TLS บนพอร์ต 8443
• ตัวอย่างที่ระบุไว้ในเอกสารของ Kopano Core จะส่ง HTTP ผ่านพร็อกซีไปยัง127.0.0.1:236หากการใช้งานของคุณใช้รูปแบบนั้น พร็อกซีต้นทางจะต้องใช้http://แม้ว่าการเชื่อมต่อเบราว์เซอร์สาธารณะจะใช้ HTTPS ก็ตาม
• สำหรับ Kopano Core TLS ดั้งเดิม ตัวอย่างในคู่มือจะใช้server_listen_tls = *:237และ URL ไคลเอ็นต์ที่ขึ้นต้นด้วยhttps://หากคุณเปลี่ยน 237 เป็นพอร์ตที่กำหนดเอง โปรดอัปเดตไคลเอ็นต์หรือพร็อกซีที่เกี่ยวข้องทั้งหมดให้เป็นค่าเดียวกันด้วย

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

4. ซ่อมแซมการตั้งค่า Listener และใบรับรอง

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

server_listen_tls = *:1237
server_ssl_ca_file = /etc/kopano/ssl/ca.pem
server_ssl_key_file = /etc/kopano/ssl/server.pem
server_ssl_key_pass = your-key-passphrase

คู่มือของ Kopano ระบุการตั้งค่า Listener, CA, Server-key และ Key-pass และกำหนดให้รีสตาร์ทkopano-serverหลังจากเปลี่ยน Listener ดั้งเดิมนี้ ตรวจสอบให้แน่ใจว่าเวอร์ชันที่ติดตั้งรองรับตัวเลือกที่แสดงไว้ โครงสร้างแพ็กเกจและคำสั่งอาจแตกต่างกัน ป้องกันไดเร็กทอรีคีย์และตรวจสอบให้แน่ใจว่าบัญชีบริการของ Kopano สามารถอ่านไฟล์ที่จำเป็นได้

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

หาก TLS สิ้นสุดที่ Apache, Nginx หรือ Kopano Web ให้กำหนดค่าใบรับรองและlistenพอร์ตที่กำหนดเองที่ฝั่ง front-end นั้นแทน จากนั้นตั้งค่ารูปแบบและพอร์ต upstream ตาม listener จริงของ backend อย่าเปิดใช้งาน TLS upstream เพียงเพราะฝั่งสาธารณะใช้ HTTPS ก่อนอื่นให้ตรวจสอบว่าพอร์ต backend ก็รองรับ TLS ด้วยหรือไม่

5. ตรวจสอบและโหลดบริการที่ถูกต้องอีกครั้ง

ก่อนที่จะรีโหลดเว็บเซิร์ฟเวอร์ ให้ทำการตรวจสอบการตั้งค่าก่อน เช่นsudo nginx -tสำหรับ Nginx หรือsudo apachectl configtestApache หากการทดสอบรายงานข้อผิดพลาด ให้แก้ไขก่อนที่จะรีโหลด ใช้ชื่อบริการที่ติดตั้งอยู่ในระบบปฏิบัติการของคุณ ตัวอย่างเช่น:

sudo systemctl restart kopano-server
sudo systemctl status kopano-server --no-pager

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

อ่านผลลัพธ์ก่อนทำการเปลี่ยนแปลงเพิ่มเติม

• ไม่มีซ็อกเก็ตสำหรับการรับฟัง:โปรดตรวจสอบตัวรับฟังที่กำหนดค่าไว้ สถานะบริการ และที่อยู่การเชื่อมต่อ
• การเชื่อมต่อถูกปฏิเสธหรือหมดเวลา:ตรวจสอบไฟร์วอลล์, NAT, โหลดบาลานเซอร์ และตรวจสอบว่าพอร์ตเป้าหมายสามารถเข้าถึงได้หรือไม่
• ใบรับรองไม่ถูกต้อง:ตรวจสอบใบรับรองที่กำหนดค่าไว้บนอุปกรณ์ปลายทางที่รับพอร์ตนั้น รวมถึงการเลือก SNI และห่วงโซ่ใบรับรอง
• TLS ใช้งานได้ในเครือข่ายภายใน แต่ใช้งานไม่ได้ในเครือข่ายระยะไกล:เปรียบเทียบเส้นทางของพร็อกซีสาธารณะหรือโหลดบาลานเซอร์กับตัวรับฟังในเครือข่ายภายใน และตรวจสอบค่าโฮสต์และพอร์ตที่ส่งต่อ
• การเชื่อมต่อสำเร็จ แต่เว็บแอปพลิเคชันล้มเหลว:ตรวจสอบสถานะ HTTP, เส้นทางพร็อกซี, บันทึก PHP/เว็บแอปพลิเคชัน และการเชื่อมต่อกับ Kopano Core ดำเนินการต่อที่ระดับแอปพลิเคชัน
• เฉพาะไคลเอ็นต์ Core เท่านั้นที่ล้มเหลว:ตรวจสอบserver_socketการตั้งค่าพอร์ตที่กำหนดเอง CA ที่เชื่อถือได้ และใบรับรองไคลเอ็นต์ เส้นทาง TLS ของ Core อาจต้องการการตรวจสอบสิทธิ์ด้วยใบรับรองร่วมกัน

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