ไคลเอนต์ ownCloud Desktop อาจหยุดการซิงค์และแจ้งว่าการตรวจสอบใบรับรอง SSL ล้มเหลว แม้ว่าเซิร์ฟเวอร์จะดูเหมือนสามารถเข้าถึงได้ในเบราว์เซอร์ก็ตาม ข้อความดังกล่าวหมายความว่าไคลเอนต์ไม่สามารถตรวจสอบได้ว่าใบรับรองเซิร์ฟเวอร์ HTTPS นั้นถูกต้องสำหรับที่อยู่เซิร์ฟเวอร์และได้รับการเชื่อถือจากสภาพแวดล้อมของไคลเอนต์หรือไม่ นี่คือการตรวจสอบข้อมูลประจำตัว TLS ไม่ใช่ข้อผิดพลาดของรหัสผ่าน และการยอมรับใบรับรองที่ไม่ได้รับการตรวจสอบซ้ำ ๆ อาจทำให้ข้อมูลประจำตัวบัญชีและไฟล์เสี่ยงต่อการถูกดักฟัง
เริ่มต้นด้วยการตรวจสอบที่อยู่เซิร์ฟเวอร์ ความถูกต้องของใบรับรอง และห่วงโซ่ใบรับรอง แก้ไขข้อมูลเหล่านั้นบนเซิร์ฟเวอร์หรือพร็อกซีแบบย้อนกลับหากเป็นไปได้ หากเซิร์ฟเวอร์ใช้หน่วยงานออกใบรับรองส่วนตัว (CA) โดยเจตนา ให้เพิ่มใบรับรองรากที่ได้รับการตรวจสอบแล้วของ CA นั้นลงในที่เก็บใบรับรองที่เชื่อถือได้ของคอมพิวเตอร์ จากนั้นรีสตาร์ทไคลเอนต์เดสก์ท็อปและยืนยันว่าการซิงโครไนซ์กลับมาทำงานต่อโดยไม่มีคำเตือนเกี่ยวกับใบรับรอง
ก่อนอื่น ตรวจสอบก่อนว่าคุณใช้ไคลเอ็นต์และเซิร์ฟเวอร์ ownCloud รุ่นใด
ปัจจุบัน ownCloud มีทั้ง ownCloud Classic Server (เวอร์ชัน 10 และ 11) และ ownCloud Infinite Scale (oCIS) แต่ไม่ได้ใช้แอปพลิเคชันเดสก์ท็อปทุกเวอร์ชันทดแทนกันได้ ณ วันที่ 1 กันยายน 2026 ตามข้อมูลในหน้าดาวน์โหลดของ ownCloud แอปพลิเคชันเดสก์ท็อปเวอร์ชัน 7.1.1 ใช้สำหรับ Infinite Scale ในขณะที่ ownCloud Classic รองรับไคลเอ็นต์เวอร์ชัน 6.x โดยในหน้าดังกล่าวระบุเวอร์ชัน 6.0.3 สำหรับ Classic หากไคลเอ็นต์ได้รับการอัปเกรดเมื่อเร็ว ๆ นี้และแบ็กเอนด์เป็น ownCloud Server 10 หรือ 11 โปรดตรวจสอบความเข้ากันได้ก่อนที่จะสรุปว่าการเชื่อมต่อล้มเหลวเป็นความผิดพลาดของใบรับรอง
โปรดตรวจสอบ URL ที่กำหนดค่าไว้ในบัญชีการซิงค์ให้ถูกต้องด้วย ชื่อโฮสต์ใน URL นั้นต้องตรงกับชื่อในใบรับรองเซิร์ฟเวอร์ สำหรับเซิร์ฟเวอร์แบบคลาสสิกที่ติดตั้งภายใต้พาธ บัญชีอาจมีลักษณะเช่นนี้https://cloud.example.com/owncloudส่วนการติดตั้ง oCIS อาจใช้ URL พื้นฐานที่แตกต่างกัน ให้ใช้ที่อยู่ซึ่งผู้ดูแลระบบของคุณกำหนดค่าไว้ แทนที่จะสลับไปมาระหว่างชื่อโฮสต์ ที่อยู่ IP และโดเมนทางเลือก
พิจารณาสาเหตุที่เป็นไปได้ตามลำดับ
1. ตรวจสอบวันที่ เครือข่าย และชื่อเซิร์ฟเวอร์ให้ถูกต้อง
ตรวจสอบให้แน่ใจว่าวันที่ เวลา และเขตเวลาของคอมพิวเตอร์ถูกต้อง นาฬิกาที่ผิดอย่างร้ายแรงอาจทำให้ใบรับรองที่ยังใช้งานได้ดูเหมือนหมดอายุหรือยังใช้งานไม่ได้ จากนั้น เปิด URL ของ ownCloud จากบัญชีซิงค์ในเบราว์เซอร์บนคอมพิวเตอร์เครื่องเดียวกัน ตรวจสอบรายละเอียดของใบรับรองสำหรับชื่อโฮสต์ วันหมดอายุ และผู้ออกใบรับรอง เบราว์เซอร์ที่โหลดหน้าเว็บโดยไม่มีคำเตือนเป็นเบาะแสที่มีประโยชน์ แต่ไม่ได้พิสูจน์ว่าไคลเอนต์บนเดสก์ท็อปใช้ที่เก็บใบรับรองเดียวกัน หรือว่าคำขอ WebDAV ทุกรายการใช้เส้นทางพร็อกซีเดียวกัน
หากพบปัญหาเฉพาะในโรงแรม สนามบิน โรงเรียน หรือ Wi-Fi สาธารณะ ให้ทำการเข้าสู่ระบบผ่านพอร์ทัลของเครือข่ายนั้นให้เสร็จสิ้นแล้วลองใหม่อีกครั้ง บันทึกการเปลี่ยนแปลงของแอปพลิเคชันเดสก์ท็อป ownCloud ระบุว่า ระบบจะหยุดการซิงค์ชั่วคราวเมื่อพอร์ทัลแบบจำกัดการเข้าถึงทำให้เกิดความไม่ตรงกันของใบรับรอง จากนั้นจะเริ่มการซิงค์ใหม่หลังจากเคลียร์พอร์ทัลแล้ว การที่หน้าพอร์ทัลดักจับ HTTPS ไม่ใช่เหตุผลที่จะต้องเชื่อถือใบรับรองที่ไม่คาดคิดนั้น
2. ตรวจสอบใบรับรองที่เซิร์ฟเวอร์แสดง
ขอให้ผู้ดูแลระบบเซิร์ฟเวอร์ตรวจสอบใบรับรอง TLS บนปลายทางสาธารณะ รวมถึงเว็บเซิร์ฟเวอร์หรือรีเวิร์สพร็อกซีที่ทำหน้าที่ยุติการเชื่อมต่อ HTTPS ใบรับรองควรเป็นปัจจุบัน มีชื่อ DNS ที่ลูกค้าใช้ถูกต้อง และต้องมีใบรับรองระดับกลางที่จำเป็น ข้อผิดพลาดในการติดตั้งที่พบบ่อยคือการกำหนดค่าเฉพาะใบรับรองปลายทางแทนที่จะเป็นห่วงโซ่ใบรับรองทั้งหมด หากใบรับรองได้รับการต่ออายุเมื่อเร็ว ๆ นี้ โปรดตรวจสอบให้แน่ใจว่ารีเวิร์สพร็อกซีแสดงใบรับรองใหม่แทนที่จะเป็นใบรับรองที่หมดอายุแล้ว
บนระบบที่มี OpenSSL คุณสามารถตรวจสอบการเชื่อมต่อ TLS และตรวจสอบชื่อโฮสต์ได้ด้วยคำสั่งนี้ แทนที่ชื่อตัวอย่างด้วยชื่อโฮสต์ของ ownCloud โดยไม่ต้องใส่เส้นทาง URL:
openssl s_client -connect cloud.example.com:443 \
-servername cloud.example.com \
-verify_hostname cloud.example.com \
-verify_return_error </dev/null
ตรวจสอบผลการตรวจสอบและวันที่ของใบรับรอง การทดสอบนี้จะตรวจสอบปลายทางจากคอมพิวเตอร์ที่คุณใช้งาน ไม่ได้จำลองรายละเอียดทั้งหมดของที่เก็บใบรับรองที่เชื่อถือได้ของไคลเอ็นต์เดสก์ท็อป หากผลลัพธ์ระบุว่าใบรับรองหมดอายุ ชื่อโฮสต์ไม่ตรงกัน ผู้ออกใบรับรองหายไป หรือ CA ไม่น่าเชื่อถือ ให้แก้ไขใบรับรองหรือห่วงโซ่ที่ปลายทาง TLS แล้วทดสอบอีกครั้ง อย่าพยายามแก้ไขปัญหาชื่อโฮสต์หรือห่วงโซ่ฝั่งเซิร์ฟเวอร์โดยการติดตั้งใบรับรองที่ไม่เกี่ยวข้องบนเดสก์ท็อปทุกเครื่อง
3. ใช้ใบรับรองที่ได้รับการยอมรับจากสาธารณะเมื่อเซิร์ฟเวอร์เป็นเซิร์ฟเวอร์สาธารณะ
สำหรับบริการ ownCloud ที่เชื่อมต่อกับอินเทอร์เน็ต วิธีแก้ไขที่ตรงไปตรงมาที่สุดมักจะเป็นการใช้ใบรับรองที่ออกโดย CA สาธารณะที่ระบบปฏิบัติการปัจจุบันเชื่อถือ กำหนดค่าปลายทาง HTTPS ด้วยใบรับรองและห่วงโซ่ใบรับรองทั้งหมดสำหรับชื่อโฮสต์สาธารณะ และตรวจสอบว่าการต่ออายุทำงานได้ หากมีการใช้พร็อกซีแบบย้อนกลับจัดการ HTTPS ใบรับรองนั้นจะอยู่บนพร็อกซีดังกล่าว การเปลี่ยนแปลงเฉพาะการกำหนดค่าแอปพลิเคชัน ownCloud จะไม่เปลี่ยนแปลงใบรับรองที่ไคลเอ็นต์ได้รับ
หลังจากผู้ดูแลระบบอัปเดตเอนด์พอยต์แล้ว ให้ทดสอบชื่อโฮสต์ที่ถูกต้องจากเครือข่ายเดียวกันกับคอมพิวเตอร์ที่ได้รับผลกระทบ การตรวจสอบผ่านเบราว์เซอร์และบรรทัดคำสั่งไม่ควรแสดงคำเตือนเกี่ยวกับใบรับรองอีกต่อไป และไคลเอ็นต์ ownCloud ควรเชื่อมต่อใหม่ได้หลังจากลองใหม่หรือรีสตาร์ท หากยังมีเพียงบางเครื่องที่ยังคงล้มเหลว ให้เปรียบเทียบการอัปเดตระบบปฏิบัติการ ที่เก็บความเชื่อถือ การตั้งค่าพร็อกซี และเวอร์ชันไคลเอ็นต์ของเครื่องเหล่านั้น
4. ควรเชื่อถือ CA ส่วนตัวเฉพาะเมื่อเซิร์ฟเวอร์นั้นถูกออกแบบมาให้ใช้งาน CA ส่วนตัวเท่านั้น
องค์กรต่างๆ มักใช้ CA ภายในสำหรับบริการ ownCloud ส่วนตัว ในกรณีนั้น ให้ขอรับใบรับรอง CA หลักขององค์กรผ่านช่องทางที่ได้รับการตรวจสอบสิทธิ์ และตรวจสอบลายนิ้วมือกับผู้ดูแลระบบ ติดตั้ง CA หลักบนคอมพิวเตอร์ไคลเอ็นต์แต่ละเครื่องที่ได้รับผลกระทบโดยใช้กระบวนการจัดการใบรับรองของระบบปฏิบัติการ หรือนโยบายอุปกรณ์ที่ได้รับการจัดการขององค์กร อย่าเพิ่มใบรับรองที่ดาวน์โหลดจากหน้าคำเตือนเป็น CA หลักเพียงเพราะไคลเอ็นต์การซิงค์เสนอให้ ก่อนอื่นให้ตรวจสอบว่าใบรับรองนั้นเป็นของ CA ที่ต้องการ
- Windows:ผู้ดูแลระบบสามารถใช้เครื่องมือจัดการใบรับรอง (Certificates snap-in) ใน Microsoft Management Console และนำเข้าใบรับรองรากที่ได้รับการตรวจสอบแล้วไปยังที่เก็บใบรับรองรากที่เชื่อถือได้ (Trusted Root Certification Authorities) ที่เหมาะสม ปฏิบัติตามนโยบายขององค์กรของคุณว่าการเชื่อถือเป็นแบบต่อผู้ใช้หรือสำหรับคอมพิวเตอร์ทั้งเครื่อง
- macOS:ใช้ Keychain Access เพื่อเพิ่มใบรับรองที่ตรวจสอบแล้วลงใน Keychain ที่เหมาะสม และตรวจสอบการตั้งค่าความน่าเชื่อถือ เอกสารของ Apple อธิบายวิธีการเพิ่มไฟล์ใบรับรองลงใน Keychain; เครื่อง Mac ที่ได้รับการจัดการควรได้รับสิทธิ์การเข้าถึงแบบส่วนตัวผ่านกระบวนการจัดการอุปกรณ์ขององค์กร
- Ubuntu:สำหรับใบรับรอง CA ในรูปแบบ PEM ให้วาง
.crtไฟล์ไว้ใน/usr/local/share/ca-certificates/และเรียกใช้คำsudo update-ca-certificatesสั่งนี้ คำสั่งนี้จะอัปเดตที่เก็บใบรับรองที่เชื่อถือได้ของระบบสำหรับแอปพลิเคชันที่ใช้งาน Ubuntu เตือนว่าแอปพลิเคชัน Snap อาจไม่ใช้ใบรับรองที่เพิ่มลงในที่เก็บของโฮสต์โดยอัตโนมัติ ดังนั้นแพ็กเกจที่จำกัดอาจต้องการโซลูชันความเชื่อถือเฉพาะแพ็กเกจ
หลังจากอัปเดตความเชื่อถือแล้ว ให้รีสตาร์ทไคลเอ็นต์ ownCloud Desktop แพ็กเกจไคลเอ็นต์และระบบปฏิบัติการอาจส่งผลต่อแหล่งเก็บใบรับรองที่ไคลเอ็นต์อ่าน หากติดตั้ง CA แล้วและเบราว์เซอร์เชื่อถือเว็บไซต์ แต่แอปเดสก์ท็อปยังคงใช้งานไม่ได้ ให้ตรวจสอบพฤติกรรมความเชื่อถือและบันทึกของแพ็กเกจไคลเอ็นต์แทนที่จะนำเข้าสำเนาใบรับรองเซิร์ฟเวอร์หลายชุดแบบสุ่ม
อย่าสับสนระหว่างการตั้งค่าความเชื่อถือบนเดสก์ท็อปกับการนำเข้าใบรับรองเซิร์ฟเวอร์ ownCloud
ownCloud Server มีocc security:certificatesคำสั่งสำหรับใบรับรองที่เซิร์ฟเวอร์เองต้องเชื่อถือ เช่น ใบรับรองที่ใช้สำหรับการรวมระบบหรือการจัดเก็บข้อมูลภายนอก นั่นคือที่เก็บใบรับรองที่เชื่อถือได้ฝั่งเซิร์ฟเวอร์ มันไม่ได้แก้ไขการตัดสินใจเรื่องความเชื่อถือที่ทำโดยโปรแกรมซิงค์ข้อมูลบนเดสก์ท็อปของผู้ใช้เมื่อเชื่อมต่อกับเว็บไซต์ ownCloud สำหรับข้อผิดพลาดในการตรวจสอบบนเดสก์ท็อป ให้แก้ไขปลายทาง HTTPS หรือการกำหนดค่าความเชื่อถือของคอมพิวเตอร์ที่ได้รับผลกระทบ
หลีกเลี่ยงการปิดใช้งานการตรวจสอบใบรับรองเป็นวิธีแก้ปัญหาถาวร เอกสารเกี่ยวกับไคลเอ็นต์บรรทัดคำสั่ง ownCloud ระบุ--trustตัวเลือกนี้ไว้ แต่การระงับหรือยอมรับความล้มเหลวในการตรวจสอบไม่ได้แก้ไขใบรับรองที่หมดอายุ ชื่อโฮสต์ที่ไม่ถูกต้อง ห่วงโซ่ CA ที่หายไป หรือการเชื่อมต่อที่ไม่น่าเชื่อถือ ควรใช้การควบคุมความน่าเชื่อถือดังกล่าวภายใต้แผนการทดสอบที่รอบคอบและได้รับการตรวจสอบแล้วเท่านั้น ไม่ใช่ใช้แทนการกำหนดค่า TLS ที่ถูกต้องในบัญชีซิงค์ข้อมูลที่ใช้งานจริง
ตรวจสอบให้แน่ใจว่าการซิงโครไนซ์ทำงานได้อย่างปกติ
- หลังจากแก้ไขใบรับรองหรือแหล่งเก็บข้อมูลความเชื่อถือแล้ว ให้ปิดและเปิดโปรแกรม ownCloud Desktop อีกครั้ง
- ตรวจสอบให้แน่ใจว่าสถานะบัญชีเปลี่ยนจากข้อผิดพลาด SSL หรือการเชื่อมต่อใหม่ เป็นสถานะเชื่อมต่อแล้วหรือกำลังซิงค์ โดยไม่มีคำเตือนเกี่ยวกับใบรับรองใหม่
- สร้างไฟล์ทดสอบขนาดเล็กในโฟลเดอร์ซิงค์และตรวจสอบว่าไฟล์นั้นปรากฏบนเซิร์ฟเวอร์แล้ว จากนั้นทำการเปลี่ยนแปลงเล็กน้อยในเว็บอินเทอร์เฟซและตรวจสอบว่าการเปลี่ยนแปลงนั้นปรากฏบนเดสก์ท็อปแล้ว
- หากสถานะยังไม่ชัดเจน ให้ตรวจสอบบันทึกของไคลเอ็นต์เพื่อดูว่ามีการเชื่อมต่อ HTTPS/WebDAV ที่สำเร็จหรือไม่ คู่มือการแก้ไขปัญหา ownCloud 5.3 ระบุวิธีการเปิด Advanced > Log Settings หรือใช้ F12, Ctrl+L หรือ Cmd+L เพื่อแสดงหน้าต่างบันทึก ชื่อเมนูอาจแตกต่างกันในไคลเอ็นต์เวอร์ชันอื่น
หากเว็บไซต์เปิดขึ้นได้ แต่การซิงค์ยังคงเชื่อมต่อไม่ได้หลังจากตรวจสอบ TLS ผ่านแล้ว ให้ตรวจสอบการตั้งค่า WebDAV และเซิร์ฟเวอร์ต่อไป แอป ownCloud Desktop ใช้ WebDAV สำหรับ ownCloud Classic คู่มือการแก้ไขปัญหาของผู้จำหน่ายแนะนำให้ตรวจสอบว่าสามารถเข้าถึงปลายทาง WebDAV ได้หรือไม่ เมื่อไคลเอนต์ทั้งหมดล้มเหลว แต่การเข้าถึงผ่านเบราว์เซอร์ใช้งานได้ หากข้อผิดพลาดเกี่ยวกับใบรับรองหายไปแล้ว แต่การเข้าสู่ระบบหรือการซิงค์ยังคงล้มเหลว ให้ตรวจสอบข้อผิดพลาดเกี่ยวกับการตรวจสอบสิทธิ์ พร็อกซีแบบย้อนกลับ หรือ WebDAV ที่แสดงในบันทึก
ความสำเร็จมีหน้าตาอย่างไร
ใบรับรองที่แสดงสำหรับชื่อโฮสต์ที่กำหนดค่าไว้นั้นยังไม่หมดอายุ มีชื่อโฮสต์นั้นอยู่ และเชื่อมโยงไปยัง CA ที่คอมพิวเตอร์ไคลเอ็นต์เชื่อถือ ไคลเอ็นต์เดสก์ท็อปเชื่อมต่อใหม่โดยไม่ต้องขอใบรับรอง และไฟล์ทดสอบซิงค์ได้ทั้งสองทิศทาง หากห่วงโซ่ใบรับรองสาธารณะถูกต้อง แต่ไคลเอ็นต์ที่จัดการเพียงเครื่องเดียวยังคงล้มเหลว ให้ตรวจสอบนาฬิกาของคอมพิวเตอร์เครื่องนั้น ที่เก็บความเชื่อถือ พร็อกซีเครือข่าย พอร์ทัลแบบจำกัดสิทธิ์ และเวอร์ชันไคลเอ็นต์ที่เข้ากันได้ต่อไป
การตรวจสอบเหล่านี้มีไว้เพื่อแก้ไขปัญหาการตรวจสอบใบรับรองที่ล้มเหลว ไม่สามารถแก้ไขปัญหาที่ไม่เกี่ยวข้อง เช่น ปัญหาบัญชี WebDAV ไฟร์วอลล์ หรือความพร้อมใช้งานของเซิร์ฟเวอร์ได้ และเมนูที่แสดงอาจแตกต่างกันไปในแต่ละระบบปฏิบัติการและเวอร์ชันของแอป ownCloud Desktop ให้ใช้บันทึกของไคลเอ็นต์และการกำหนดค่าปลายทาง TLS ของเซิร์ฟเวอร์เพื่อระบุว่าฝั่งใดยังคงมีปัญหาอยู่
เอกสารอ้างอิงอย่างเป็นทางการ