แก้ไขข้อผิดพลาด "การตรวจสอบใบรับรอง SSL ล้มเหลว" ใน Matrix Synapse Federation

ข้อผิดพลาดทั่วไปของ Matrix Synapse ดูเหมือนจะง่ายอย่างน่าหลอกลวง: ไคลเอนต์ในเครือข่ายท้องถิ่นสามารถล็อกอินได้ พร็อกซีแบบย้อนกลับของคุณออนไลน์อยู่ และ Synapse เองอาจดูเหมือนทำงานได้ปกติ แต่โฮมเซิร์ฟเวอร์ระยะไกลไม่สามารถเชื่อมต่อกับคุณได้ บันทึกฝั่งหนึ่งอาจมีวลีเช่นcertificate verify failed, hostname mismatch, unable to get local issuer certificate, หรือข้อผิดพลาดในการร้องขอการเชื่อมต่อทั่วไปที่เกิดจากการตรวจสอบ TLS

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

1. ระบุว่าการรวมโฮสต์เนมกำลังตรวจสอบความถูกต้องอยู่จริงหรือไม่

ก่อนที่จะเปลี่ยน Nginx, Caddy, Synapse หรือ DNS ให้ตรวจสอบชื่อใบรับรองที่ Matrix คาดหวัง คำตอบขึ้นอยู่กับระบบของคุณserver_nameและการค้นหาเซิร์ฟเวอร์

หากชื่อเซิร์ฟเวอร์ Matrix ของคุณคือexample.comและคุณไม่ได้มอบหมายการเชื่อมต่อ (federation) เซิร์ฟเวอร์โฮมอื่นๆ มักจะลองใช้บริการการเชื่อมต่อที่เชื่อมโยงกับชื่อนั้น ซึ่งโดยทั่วไปจะใช้พอร์ต TCP 8448 หากคุณให้บริการhttps://example.com/.well-known/matrix/serverค่าm.serverสามารถมอบหมายการเชื่อมต่อให้กับชื่อโฮสต์อื่น เช่นmatrix.example.com:443ในกรณีนั้น ชื่อโฮสต์ที่มอบหมายจะเป็นส่วนหนึ่งของเส้นทางการตรวจสอบ TLS Matrix ยังรองรับการค้นหาแบบ SRV ด้วย แต่เอกสารของ Synapse แนะนำให้.well-knownใช้การมอบหมายสำหรับการใช้งานทั่วไป เนื่องจากเข้าใจและกำหนดค่าได้ง่ายกว่า พฤติกรรมที่มีอำนาจนั้นได้รับการบันทึกไว้ในการค้นหาเซิร์ฟเวอร์ในข้อกำหนดของ Matrixและการมอบหมายการเชื่อมต่อของ Synapse

curl -fsS https://example.com/.well-known/matrix/server

การตอบสนองแบบมอบหมายอำนาจอาจมีลักษณะดังนี้:

{
  "m.server": "matrix.example.com:443"
}

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

2. จำลองความล้มเหลวในการตรวจสอบใบรับรองด้วย OpenSSL

เมื่อคุณทราบปลายทางของการเชื่อมต่อเครือข่ายที่คาดหวังแล้ว ให้ทดสอบโดยตรงด้วยการตรวจสอบ SNI และชื่อโฮสต์ วิธีนี้จะช่วยแยกปัญหาการระบุตัวตน TLS ออกจากปัญหาของแอปพลิเคชัน Synapse

openssl s_client   -connect example.com:8448   -servername example.com   -verify_hostname example.com   -showcerts </dev/null

สำหรับโฮสต์ที่ได้รับมอบหมายบนพอร์ต 443 ให้เปลี่ยนทั้งเป้าหมายการเชื่อมต่อและชื่อโฮสต์ที่คาดหวัง:

openssl s_client   -connect matrix.example.com:443   -servername matrix.example.com   -verify_hostname matrix.example.com   -showcerts </dev/null

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

ข้อผิดพลาด OpenSSL ที่พบบ่อยที่สุดมักหมายความว่าอย่างไร

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

3. แก้ไขปัญหาชื่อโฮสต์ไม่ตรงกันที่รีเวิร์สพร็อกซี

ความไม่ตรงกันของชื่อโฮสต์มักเกิดขึ้นบ่อย โดยเฉพาะอย่างยิ่งเมื่อเว็บไซต์ที่ลูกค้าใช้งานและปลายทางของสหพันธ์ใช้โฮสต์เสมือนที่แตกต่างกัน ตัวอย่างเช่นexample.comอาจเป็นโฮสต์เว็บไซต์หนึ่ง ในขณะที่ Synapse ทำหน้าที่เป็นพร็อกซี หาก ไฟล์matrix.example.comของคุณ มอบหมายให้ ปลายทาง TLS บนโฮสต์นั้นจะต้องให้บริการใบรับรองที่ถูกต้องสำหรับ.well-knownmatrix.example.com:443matrix.example.com

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

sudo nginx -T | less

ตรวจสอบserver_nameพอร์ตการรับฟังและเส้นทางของใบรับรอง โดยทั่วไปแล้วส่วน TLS จะใช้ห่วงโซ่ใบรับรองแบบเต็ม:

server {
    listen 443 ssl;
    server_name matrix.example.com;

    ssl_certificate /etc/letsencrypt/live/matrix.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/matrix.example.com/privkey.pem;

    location /_matrix {
        proxy_pass http://127.0.0.1:8008;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

ตรวจสอบและโหลดใหม่หลังจากที่การทดสอบการกำหนดค่าสำเร็จแล้วเท่านั้น:

sudo nginx -t && sudo systemctl reload nginx

Synapse แนะนำให้ใช้ Reverse Proxy สำหรับการใช้งานทั่วไป และแยกความแตกต่างระหว่างพอร์ตไคลเอ็นต์ปกติ 443 กับพอร์ต Federation เริ่มต้น 8448 โปรดศึกษาเอกสารอย่างเป็นทางการของ Synapse เกี่ยวกับ Reverse Proxyสำหรับข้อกำหนดของ Proxy ในปัจจุบัน

4. ให้บริการห่วงโซ่ใบรับรองที่สมบูรณ์

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

หลักการเดียวกันนี้ใช้ได้เมื่อ TLS สิ้นสุดที่ Nginx, Caddy, HAProxy หรือพร็อกซีอื่นๆ: กำหนดค่าพร็อกซีเหล่านั้นให้แสดงห่วงโซ่การเข้ารหัสที่ถูกต้องครบถ้วน ตรวจสอบสิ่งที่ถูกส่งจริง ไม่ใช่แค่สิ่งที่อยู่บนดิสก์:

openssl s_client   -connect matrix.example.com:443   -servername matrix.example.com   -showcerts </dev/null

คุณควรจะเห็นใบรับรองระดับสูงสุด (leaf certificate) ตามด้วยใบรับรองระดับกลางที่จำเป็น ใบรับรอง CA ระดับราก (root CA) โดยทั่วไปไม่จำเป็นต้องส่งมาจากเซิร์ฟเวอร์ เนื่องจากโดยปกติแล้วไคลเอ็นต์จะเชื่อถือ CA ระดับรากผ่านทางที่เก็บความเชื่อถือ (trust store) อยู่แล้ว

5. ตรวจสอบ DNS และการค้นหา Matrix เพื่อหาเส้นทางที่ล้าสมัยหรือแยกส่วน

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

dig +short A example.com
dig +short AAAA example.com
dig +short A matrix.example.com
dig +short AAAA matrix.example.com

นอกจากนี้ โปรดตรวจสอบบันทึก SRV ของสหพันธ์ที่คุณใช้งานโดยเจตนาด้วย:

dig +short SRV _matrix-fed._tcp.example.com

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

เมื่อมีทั้ง A และ AAAA อยู่ ให้ทำการตรวจสอบ TLS กับแต่ละเส้นทางหากจำเป็น หากตัวกระจายโหลดอยู่ด้านหน้าโหนดพร็อกซีหลายตัว ให้ตรวจสอบว่าทุกโหนดมีใบรับรองและห่วงโซ่ใบรับรองปัจจุบันที่เหมือนกัน

6. แก้ไขปัญหาความไว้วางใจระหว่าง CA เอกชนโดยไม่ลดทอนความเชื่อมโยงของ CA สาธารณะ

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

federation_custom_ca_list:
  - /etc/synapse/ca/private-federation-ca.pem

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

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

7. ตรวจสอบการซ่อมแซมที่เลเยอร์ TLS ก่อน

หลังจากทำการเปลี่ยนแปลงแล้ว ให้ทำซ้ำคำสั่ง OpenSSL ที่ล้มเหลวก่อนหน้านี้อีกครั้ง เป้าหมายคือการตรวจสอบชื่อโฮสต์และห่วงโซ่การเชื่อมต่อให้สำเร็จสำหรับปลายทางที่การค้นหาของ Matrix ระบุ

จากนั้นส่งคำขอ HTTPS ไปยังเอนด์พอยต์ของเฟเดอเรชัน สำหรับเอนด์พอยต์โดยตรงบนพอร์ต 8448:

curl -v https://example.com:8448/_matrix/federation/v1/version

สำหรับเอนด์พอยต์ที่ได้รับมอบหมายบนพอร์ต 443:

curl -v https://matrix.example.com/_matrix/federation/v1/version

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

8. ตรวจสอบบันทึกของ Synapse และแยกแยะข้อผิดพลาด TLS ออกจากข้อผิดพลาดการเชื่อมต่อระดับสูงกว่า

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

สำหรับการติดตั้งบนระบบที่ใช้ systemd จุดเริ่มต้นทั่วไปคือ:

journalctl -u matrix-synapse -n 200 --no-pager

สำหรับ Docker ให้ใช้บันทึกคอนเทนเนอร์สำหรับบริการ Synapse ของคุณ ค้นหาในช่วงเวลาที่มีการพยายามเชื่อมต่อใหม่ แทนที่จะพึ่งพาข้อความใบรับรองเก่าๆ ที่อาจไม่เกี่ยวข้องอีกต่อไป

ตารางการตัดสินใจอย่างรวดเร็ว

จะรู้ได้อย่างไรว่าปัญหาได้รับการแก้ไขแล้วจริงๆ

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

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

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