“การเชื่อมต่อของคุณไม่เป็นส่วนตัว”: คำเตือนใบรับรอง SSL

ข้อผิดพลาดนี้หมายถึงอะไร

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

รหัสข้อผิดพลาดบอกว่าการตรวจข้อใดล้มเหลว:

• NET::ERR_CERT_DATE_INVALID: ใบรับรองหมดอายุ หรือวันเริ่มต้นอยู่ในอนาคต (หรือนาฬิกาของผู้เข้าชมผิด)
• NET::ERR_CERT_COMMON_NAME_INVALID: ใบรับรองเป็นของชื่ออื่น เช่น สำหรับ www.example.com แต่ไม่ใช่สำหรับ example.com
• NET::ERR_CERT_AUTHORITY_INVALID: เบราว์เซอร์สืบย้อนใบรับรองไปถึงผู้ออกใบรับรองที่น่าเชื่อถือไม่ได้: self-signed ผู้ออกที่ไม่รู้จัก หรือใบรับรองระดับกลางหายไป
• NET::ERR_CERT_REVOKED: ใบรับรองถูกผู้ออกเพิกถอน
• SSL_ERROR_BAD_CERT_DOMAIN และ SEC_ERROR_EXPIRED_CERTIFICATE คือเวอร์ชันของ Firefox สำหรับข้อผิดพลาดเรื่องชื่อและวันที่

สาเหตุที่พบบ่อย

1. ใบรับรองหมดอายุ ใบรับรอง Let's Encrypt มีอายุ 90 วัน การต่ออายุอัตโนมัติล้มเหลวเป็นสัปดาห์โดยไม่มีใครสังเกตจนถึงวันที่หมด ใบรับรองแบบเสียเงินหมดอายุหลังหนึ่งปีและอีเมลแจ้งต่ออายุถูกส่งไปที่ที่อยู่เก่า
2. ต่ออายุแล้วแต่ไม่ได้รีโหลด certbot เขียนใบรับรองใหม่ลงดิสก์ แต่เว็บเซิร์ฟเวอร์ยังให้บริการใบเก่าจากหน่วยความจำ เพราะไม่มี reload hook
3. ชื่อผิด ใบรับรองครอบคลุม example.com แต่ผู้เข้าชมมาที่ www.example.com หรือเพิ่มซับโดเมนใหม่โดยไม่มีใบรับรอง
4. ใบรับรองระดับกลางหายไป เซิร์ฟเวอร์ส่งเฉพาะใบรับรองของตัวเอง ไม่ส่งสายใบรับรอง เบราว์เซอร์บนเดสก์ท็อปมักเติมช่องว่างจากแคช โทรศัพท์และแอปล้มเหลว
5. ปัญหานาฬิกา บนคอมพิวเตอร์ของผู้เข้าชม วันที่ผิดทำให้ทุกใบรับรองดูเหมือนหมดอายุหรือยังไม่เริ่มมีผล บนเซิร์ฟเวอร์ นาฬิกาผิดทำให้การต่ออายุล้มเหลว
6. CDN หรือพร็อกซีด้านหน้ามีใบรับรองของตัวเอง ที่หมดอายุหรือไม่ครอบคลุมชื่อ ขณะที่เซิร์ฟเวอร์ต้นทางปกติ

หากคุณเป็นผู้เข้าชม

ตรวจวันที่และเวลาของคอมพิวเตอร์ก่อน แบตเตอรี่ CMOS ที่หมดหรือการซิงก์เวลาที่ถูกปิดทำให้ทุกเว็บไซต์ล้มเหลว จากนั้นลองเครือข่ายอื่น หากคำเตือนปรากฏเฉพาะเว็บไซต์เดียวและในทุกอุปกรณ์ ใบรับรองของเว็บไซต์คือปัญหาและเจ้าของต้องแก้ การคลิกผ่าน “ดำเนินการต่อไปยังเว็บไซต์ (ไม่ปลอดภัย)” ไม่เป็นไรสำหรับเว็บไซต์ที่คุณรู้จัก แต่ไม่ใช่สำหรับสิ่งที่มีการล็อกอินหรือการชำระเงิน

หากเป็นเว็บไซต์ของคุณ: ตรวจสอบก่อน

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

# เซิร์ฟเวอร์ส่งอะไรจริง ๆ
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# อะไรอยู่บนดิสก์
sudo certbot certificates

# นาฬิกาของเซิร์ฟเวอร์ถูกต้องไหม
timedatectl

หากวันที่บนดิสก์ใหม่กว่าวันที่ที่เซิร์ฟเวอร์ส่ง คุณเจอกรณีที่ 2: ต่ออายุแล้วแต่ไม่ได้รีโหลด

วิธีแก้บนเซิร์ฟเวอร์ของคุณเอง

1. ต่ออายุด้วย certbot

sudo certbot renew
# หรือ ถ้า renew บอกว่า "not yet due" แต่ใบรับรองที่ให้บริการเก่า:
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # หรือ apache2

หากการต่ออายุล้มเหลว ผลลัพธ์บอกเหตุผล เหตุผลที่พบบ่อย: พอร์ต 80 ถูกบล็อกหรือเปลี่ยนเส้นทางไปที่ที่ certbot ไม่คาดคิด (การท้าทาย HTTP-01 ต้องให้ /.well-known/acme-challenge/ เข้าถึงได้ผ่าน HTTP ธรรมดา) ระเบียน DNS ชี้ไปที่เซิร์ฟเวอร์อื่น หรือถึง rate limit หลังพยายามล้มเหลวหลายครั้ง แก้สาเหตุและรัน sudo certbot renew --dry-run จนผ่าน

2. ทำให้การรีโหลดเป็นอัตโนมัติ

# Debian/Ubuntu: certbot ติดตั้ง timer ตรวจดู
systemctl list-timers | grep certbot

# เพิ่ม deploy hook เพื่อให้เว็บเซิร์ฟเวอร์ใช้ใบรับรองใหม่
printf '#!/bin/sh\nsystemctl reload nginx\n' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh

3. เพิ่มชื่อที่หายไป

sudo certbot --nginx -d example.com -d www.example.com -d shop.example.com --expand

แฟลก --expand แทนที่ใบรับรองเดิมด้วยใบที่ครอบคลุมทุกชื่อที่ระบุ

4. แก้สายใบรับรอง

เมื่อใช้ certbot ชี้เว็บเซิร์ฟเวอร์ไปที่ fullchain.pem ไม่ใช่ cert.pem:

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

Apache: SSLCertificateFile กับ fullchain.pem สำหรับใบรับรองที่ซื้อ ดาวน์โหลดใบรับรองระดับกลาง (“CA bundle”) จากผู้ออกและต่อท้ายไฟล์ใบรับรอง ทดสอบด้วย sudo nginx -t (Apache: sudo apachectl configtest) รีโหลด แล้วตรวจสายใบรับรองด้วยเครื่องมือตรวจ SSL

5. แก้นาฬิกา

sudo timedatectl set-ntp true
timedatectl

เซิร์ฟเวอร์ที่นาฬิกาคลาดเคลื่อนเกินไม่กี่นาทีทำให้การตรวจสอบใบรับรองล้มเหลวทั้งสองทิศทาง

6. Shared hosting หรือตัวสร้างเว็บไซต์

ผู้ให้บริการโฮสติ้งส่วนใหญ่ออกและต่ออายุใบรับรอง Let's Encrypt จากแผงควบคุม (“SSL/TLS”, “Security”, “Let's Encrypt”) เปิดดู ตรวจว่าใบรับรองครอบคลุมทั้ง example.com และ www.example.com แล้วคลิกต่ออายุหรือออกใหม่ หากแผงบอกว่าใบรับรองใช้ได้แต่เบราว์เซอร์ไม่เห็นด้วย ผู้ให้บริการโฮสติ้งมีปัญหาการรีโหลดหรือสายใบรับรองในฝั่งของพวกเขา

เมื่อเป็นปัญหาของผู้ให้บริการโฮสติ้ง

สวัสดี ตั้งแต่ประมาณ 06:00 UTC เบราว์เซอร์แสดง “การเชื่อมต่อของคุณไม่เป็นส่วนตัว” (NET::ERR_CERT_DATE_INVALID) สำหรับเว็บไซต์ของฉัน example.com แผงควบคุมแสดงใบรับรองที่ใช้ได้ เว็บเซิร์ฟเวอร์จึงน่าจะให้บริการใบเก่า กรุณารีโหลดใบรับรองบนเซิร์ฟเวอร์และตรวจการต่ออายุอัตโนมัติสำหรับโดเมนของฉัน

ป้องกันครั้งต่อไป

ใบรับรองที่หมดอายุเป็นระบบล่มเพียงอย่างเดียวที่ทราบวันล่วงหน้า การมอนิเตอร์ใบรับรอง SSLเตือนคุณก่อนหมดอายุ และเตือนอีกครั้งหากสายใบรับรองหรือชื่อผิด ฟรี 5 รายการ บนเซิร์ฟเวอร์ของคุณเอง Quick Fix ต่ออายุใบรับรองในที่ที่ตั้งค่า certbot ไว้และรีโหลดเว็บเซิร์ฟเวอร์ ในราคาคงที่ Deep Fix ตั้งค่าการต่ออายุในที่ที่ยังไม่มี