แก้ปัญหา Error “การเชื่อมต่อของคุณไม่เป็นส่วนตัว” (SSL Certificate Error) บน Browser

กำลังจะเข้าเว็บตามปกติ แต่จู่ๆ Chrome กลับขึ้นหน้าจอสีขาวพร้อมสามเหลี่ยมเตือนสีแดงว่า “การเชื่อมต่อของคุณไม่เป็นส่วนตัว” หรือภาษาอังกฤษว่า “Your connection is not private” ตามด้วยรหัสลึกลับอย่าง NET::ERR_CERT_DATE_INVALID หลายคนตกใจคิดว่าโดนไวรัสหรือเว็บโดนแฮก ทั้งที่จริงแล้วนี่คือกลไกป้องกันตามปกติของเบราว์เซอร์ที่ตรวจพบความผิดปกติของ SSL Certificate บทความนี้จะพาไล่ดูตั้งแต่ความหมายของ Error รหัสที่พบบ่อย สาเหตุทั้งฝั่งผู้เข้าชมและฝั่งเจ้าของเว็บ พร้อมวิธีแก้ทีละขั้นแบบทำตามได้จริง ต่างจากบทความ แก้ปัญหา SSL หลังติดตั้ง ที่เน้นฝั่งเซิร์ฟเวอร์ บทความนี้จะเจาะมุมของหน้าจอ Error บนเบราว์เซอร์โดยเฉพาะ

Error นี้หมายความว่าอะไรกันแน่

ก่อนโหลดหน้าเว็บผ่าน HTTPS เบราว์เซอร์จะทำขั้นตอนที่เรียกว่า TLS handshake โดยเซิร์ฟเวอร์ต้องส่ง SSL/TLS Certificate มาให้ตรวจสอบ 3 เรื่องหลัก คือ (1) ใบเซอร์ยังอยู่ในอายุใช้งานหรือไม่ (2) ชื่อโดเมนบนใบเซอร์ตรงกับโดเมนที่กำลังเข้าหรือไม่ และ (3) ใบเซอร์ถูกออกโดย Certificate Authority (CA) ที่เบราว์เซอร์เชื่อถือหรือไม่ ถ้าข้อใดข้อหนึ่งไม่ผ่าน เบราว์เซอร์จะไม่ยอมสร้างการเชื่อมต่อที่เข้ารหัสให้ และแสดงหน้าคำเตือนเต็มจอแทนการเปิดเว็บ

จุดสำคัญที่ต้องเข้าใจคือ Error นี้ไม่ได้แปลว่าเครื่องคุณติดมัลแวร์ และไม่ได้แปลว่าเว็บปลายทางโดนแฮกเสมอไป มันแปลเพียงว่า “เบราว์เซอร์ยืนยันไม่ได้ว่าการเชื่อมต่อนี้ปลอดภัย” ซึ่งสาเหตุอาจอยู่ที่เว็บ อยู่ที่เครือข่าย หรืออยู่ที่เครื่องของผู้ใช้เองก็ได้ แต่ละเบราว์เซอร์ใช้ถ้อยคำต่างกันเล็กน้อย เช่น Chrome และ Edge ใช้ “Your connection is not private” ส่วน Firefox ใช้ “Warning: Potential Security Risk Ahead” และ Safari ใช้ “This Connection Is Not Private” แต่กลไกเบื้องหลังเหมือนกันทั้งหมด

รหัส Error ที่พบบ่อยและความหมาย

ใต้ข้อความเตือน เบราว์เซอร์จะแสดงรหัส Error ซึ่งเป็นเบาะแสสำคัญที่สุดในการวินิจฉัย เจอรหัสไหนให้เทียบกับตารางนี้ก่อนเลย

สังเกตว่ารหัสกลุ่ม “วันที่ไม่ถูกต้อง” เป็นกลุ่มเดียวที่สาเหตุอาจอยู่ฝั่งผู้ใช้ล้วนๆ ส่วนรหัสเรื่องชื่อโดเมนและผู้ออกใบเซอร์เกือบทั้งหมดต้องแก้ที่ฝั่งเว็บ

สาเหตุฝั่งผู้เข้าชม และวิธีแก้ทีละขั้น

ถ้าคุณคือผู้เข้าชมเว็บ (ไม่ใช่เจ้าของเว็บ) ให้ไล่เช็กตามลำดับนี้ ซึ่งเรียงจากสาเหตุที่พบบ่อยที่สุดไปหาน้อยที่สุด

1. วันที่และเวลาในเครื่องผิด

สาเหตุอันดับหนึ่งของ NET::ERR_CERT_DATE_INVALID คือนาฬิกาเครื่องคลาดเคลื่อน เพราะเบราว์เซอร์ใช้เวลาในเครื่องเทียบกับช่วงอายุของใบเซอร์ ถ้าเครื่องตั้งปีไว้ผิด ใบเซอร์ที่ยังไม่หมดอายุจะถูกมองว่าหมดอายุทันที วิธีแก้บน Windows ไปที่ Settings > Time & Language แล้วเปิด Set time automatically ส่วน macOS ไปที่ System Settings > General > Date & Time เปิด Set time and date automatically มือถือก็เช่นกัน เปิดตั้งเวลาอัตโนมัติจากเครือข่ายเสมอ เครื่องที่ถ่านไบออสเสื่อมหรือปิดเครื่องนานๆ มักเวลาเพี้ยนบ่อยเป็นพิเศษ

2. Wi-Fi สาธารณะที่มี Captive Portal

Wi-Fi ตามโรงแรม สนามบิน หรือร้านกาแฟ มักมีหน้า login (captive portal) ที่ดักจับทุกการเชื่อมต่อก่อนกดยอมรับเงื่อนไข ระหว่างที่ยังไม่ login ระบบจะพยายามตอบกลับด้วยใบเซอร์ของตัวเองแทนใบเซอร์จริงของเว็บ ทำให้เบราว์เซอร์เตือนทันที วิธีแก้คือเปิดหน้าเว็บ HTTP ธรรมดา เช่น http://neverssl.com เพื่อบังคับให้หน้า login เด้งขึ้นมา ล็อกอินให้เสร็จ แล้วค่อยกลับไปเข้าเว็บเดิม

3. Antivirus ที่สแกน HTTPS

โปรแกรมป้องกันไวรัสบางตัวมีฟีเจอร์ HTTPS scanning หรือ SSL inspection ซึ่งทำงานโดยแทรกตัวเองเป็นคนกลาง ถอดรหัสทราฟฟิกด้วยใบเซอร์ของตัวเองแล้วเข้ารหัสใหม่ ถ้าใบเซอร์ของโปรแกรมไม่ถูกติดตั้งใน trust store ของเบราว์เซอร์อย่างถูกต้อง จะเกิด NET::ERR_CERT_AUTHORITY_INVALID กับทุกเว็บ ลองปิดฟีเจอร์สแกน HTTPS ชั่วคราวแล้วทดสอบใหม่ ถ้าหาย ให้อัปเดตโปรแกรมเป็นเวอร์ชันล่าสุดหรือติดตั้งใบเซอร์ของโปรแกรมใหม่ตามคู่มือของผู้ผลิต

4. Cache และ SSL State เก่า

บางครั้งเบราว์เซอร์จำสถานะใบเซอร์เก่าที่เคยมีปัญหาไว้ แม้เว็บจะแก้แล้วก็ยังขึ้นเตือน ให้ลองเคลียร์ cache ของเบราว์เซอร์ (Ctrl+Shift+Delete เลือก Cached images and files) บน Windows สามารถล้าง SSL state เพิ่มได้ที่ Internet Options > Content > Clear SSL state จากนั้นปิดเบราว์เซอร์แล้วเปิดใหม่ อีกทางที่เร็วกว่าคือทดสอบในหน้าต่าง Incognito/Private ซึ่งไม่ใช้ cache เดิม ถ้าใน Incognito เข้าได้ปกติ แสดงว่าปัญหาอยู่ที่ cache หรือ extension

5. Extension และเครือข่ายองค์กร

Extension ประเภท proxy, VPN หรือ ad-blocker บางตัวแทรกแซงการเชื่อมต่อ HTTPS ได้ ลองปิดทีละตัวเพื่อหาตัวการ ส่วนเครื่องในองค์กรที่ IT ติดตั้ง proxy หรือ firewall แบบ SSL inspection ไว้ อาจเจอคำเตือนกับบางเว็บเป็นปกติ กรณีนี้ต้องติดต่อผู้ดูแลระบบขององค์กร เพราะผู้ใช้แก้เองไม่ได้

สาเหตุฝั่งเจ้าของเว็บ: 5 กรณีที่เจอบ่อยที่สุด

ถ้าผู้เข้าชมหลายคนรายงานว่าเจอ Error พร้อมกันจากหลายเครื่องหลายเครือข่าย ให้สันนิษฐานว่าปัญหาอยู่ฝั่งเซิร์ฟเวอร์ของคุณ กรณีที่พบบ่อยเรียงตามสถิติมีดังนี้

1. ใบเซอร์หมดอายุ

พบบ่อยที่สุด โดยเฉพาะเว็บที่ติดตั้งใบเซอร์แบบ manual แล้วลืมต่ออายุ ใบเซอร์ Let's Encrypt มีอายุเพียง 90 วัน ส่วนใบเซอร์แบบเสียเงินมักมีอายุ 1 ปี ตรวจวันหมดอายุได้จากการคลิกไอคอนรูปกุญแจ/สไลเดอร์หน้า URL แล้วดู Certificate details หรือใช้คำสั่ง openssl ตามหัวข้อด้านล่าง วิธีป้องกันถาวรคือเปิดต่ออายุอัตโนมัติ อ่านรายละเอียดใน คู่มือต่ออายุ SSL Certificate

2. ชื่อโดเมนไม่ตรงกับใบเซอร์

ใบเซอร์ระบุชื่อโดเมนที่คุ้มครองไว้ชัดเจนในฟิลด์ Common Name และ Subject Alternative Name (SAN) ถ้าออกใบเซอร์ให้ example.com แต่ผู้ใช้เข้า www.example.com ซึ่งไม่อยู่ใน SAN จะเกิด NET::ERR_CERT_COMMON_NAME_INVALID ทันที ทางแก้คือออกใบเซอร์ใหม่ให้ครอบคลุมทั้ง www และ non-www หรือใช้ Wildcard SSL สำหรับทุก subdomain รวมถึงกรณีชี้ subdomain ใหม่มาที่เซิร์ฟเวอร์แล้วลืมออกใบเซอร์เพิ่มด้วย

3. Intermediate Chain ไม่ครบ

ใบเซอร์ทำงานเป็นสายโซ่ จากใบเซอร์ของเว็บ ผ่าน intermediate CA ไปจนถึง root CA ที่เบราว์เซอร์เชื่อถือ ถ้าเซิร์ฟเวอร์ติดตั้งเฉพาะใบเซอร์ของเว็บโดยไม่ใส่ไฟล์ CA bundle (intermediate) เบราว์เซอร์บางตัวจะประกอบสายโซ่ไม่ได้และขึ้น SEC_ERROR_UNKNOWN_ISSUER อาการเด่นของกรณีนี้คือ “บางเครื่องเข้าได้ บางเครื่องเข้าไม่ได้” เพราะเบราว์เซอร์เดสก์ท็อปมักมี cache ของ intermediate อยู่แล้วขณะที่มือถือไม่มี อ่านเชิงลึกได้ที่บทความ ทำความเข้าใจ SSL Certificate Chain

4. ใบเซอร์แบบ Self-Signed

ใบเซอร์ที่เซ็นเองโดยไม่ผ่าน CA ใช้เข้ารหัสได้จริงแต่ยืนยันตัวตนไม่ได้ เบราว์เซอร์จึงเตือน NET::ERR_CERT_AUTHORITY_INVALID เสมอ เหมาะเฉพาะการทดสอบภายในเท่านั้น เว็บจริงที่เปิดให้คนทั่วไปเข้าต้องใช้ใบเซอร์จาก CA ที่เชื่อถือได้ ไม่ว่าจะเป็น Let's Encrypt แบบฟรี หรือใบเซอร์แบบเสียเงินอย่าง RapidSSL

5. Mixed Content และการตั้งค่าอื่น

แม้ใบเซอร์ถูกต้อง แต่ถ้าหน้าเว็บ HTTPS โหลดรูป สคริปต์ หรือ CSS ผ่าน http:// เบราว์เซอร์จะลดสถานะกุญแจเป็น “Not secure” หรือบล็อกทรัพยากรนั้น แม้ไม่ขึ้นหน้าเตือนเต็มจอแต่ก็ทำลายความน่าเชื่อถือเช่นกัน วิธีไล่แก้อ่านได้ในบทความ แก้ปัญหา Mixed Content นอกจากนี้การเปิดใช้โปรโตคอล TLS เวอร์ชันเก่า (1.0/1.1) ก็ทำให้เบราว์เซอร์ใหม่ปฏิเสธการเชื่อมต่อด้วย ERR_SSL_PROTOCOL_ERROR ได้

วิธีแก้ฝั่งเจ้าของเว็บบน DirectAdmin

สำหรับผู้ใช้โฮสติ้งที่มาพร้อม DirectAdmin ขั้นตอนออกใบเซอร์ใหม่หรือแก้ใบเซอร์หมดอายุใช้เวลาไม่ถึง 5 นาที

1. ล็อกอิน DirectAdmin แล้วเลือกโดเมนที่ต้องการ จากนั้นเข้าเมนู SSL Certificates
2. เลือกแท็บ Free & automatic certificate from Let's Encrypt
3. ติ๊กเลือกทุก entry ที่ต้องการคุ้มครอง โดยเฉพาะทั้ง example.com และ www.example.com (นี่คือจุดที่คนพลาดจนเกิด COMMON_NAME_INVALID บ่อยที่สุด)
4. กด Save ระบบจะยืนยันโดเมนอัตโนมัติและติดตั้งใบเซอร์พร้อม chain ให้ครบในขั้นตอนเดียว
5. กลับมาที่หน้า SSL Certificates ตรวจว่าสถานะเป็น certificate ที่ออกใหม่ และระบบจะต่ออายุให้อัตโนมัติก่อนหมดอายุ โดยไม่ต้องตั้ง cron เอง

อย่าลืมเปิด Force SSL with https redirect ในหน้าเดียวกัน เพื่อบังคับให้ทุกการเข้าชมวิ่งผ่าน HTTPS เสมอ ขั้นตอนแบบละเอียดพร้อมภาพรวมข้อดีข้อจำกัดอ่านได้ที่ ติดตั้ง Let's Encrypt บน DirectAdmin ถ้าออกใบเซอร์แล้วยังขึ้น Error ให้เคลียร์ cache เบราว์เซอร์ หรือรอ DNS/propagation สักครู่ก่อนทดสอบซ้ำจากเครือข่ายอื่น

วิธีตรวจสอบใบเซอร์ด้วยเบราว์เซอร์

ก่อนแก้อะไร ควรดูข้อมูลจริงของใบเซอร์ก่อน ทำได้โดยไม่ต้องใช้เครื่องมือพิเศษ

• Chrome/Edge: คลิกไอคอนสไลเดอร์ (Tune) หน้า URL > Connection is secure > Certificate is valid จะเห็นผู้ออก วันหมดอายุ และรายชื่อโดเมนใน SAN
• Firefox: คลิกรูปกุญแจ > Connection secure > More information > View Certificate ดูรายละเอียดครบทั้ง chain ได้ในแท็บเดียว
• หน้า Error โดยตรง: บน Chrome คลิกที่ข้อความรหัส Error หรือปุ่ม Advanced จะมีคำอธิบายเพิ่มเติมว่าใบเซอร์ผิดตรงไหน เช่น หมดอายุเมื่อวันที่เท่าไร

ข้อมูลสามจุดที่ควรจดออกมาคือ Issued to (ออกให้โดเมนอะไร), Issued by (ใครออกให้) และ Valid from/to (ช่วงอายุ) สามค่านี้ตอบได้เกือบทุกเคสว่าปัญหาคืออะไร

วิธีตรวจสอบใบเซอร์ด้วย openssl

สำหรับสายเทคนิคหรือผู้ดูแลเซิร์ฟเวอร์ คำสั่ง openssl ให้ข้อมูลละเอียดกว่าและใช้ทดสอบจากเครื่องไหนก็ได้

# ดูใบเซอร์ทั้งหมดที่เซิร์ฟเวอร์ส่งมา (เช็ก chain ครบไหม)
openssl s_client -connect example.com:443 -servername example.com

# ดูเฉพาะวันหมดอายุ
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

# ดูชื่อโดเมนทั้งหมดใน SAN
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

จุดที่ต้องดูในผลลัพธ์ของคำสั่งแรกคือบรรทัด Verify return code ท้ายสุด ถ้าเป็น 0 (ok) แปลว่า chain สมบูรณ์ ถ้าขึ้น 21 (unable to verify the first certificate) แปลว่า intermediate ขาด และถ้าขึ้น 10 (certificate has expired) คือหมดอายุ ส่วนพารามิเตอร์ -servername จำเป็นเสมอบนเซิร์ฟเวอร์ที่มีหลายเว็บ (SNI) มิฉะนั้นอาจได้ใบเซอร์ของเว็บอื่นบนเครื่องเดียวกันมาแทน

เจอ Error บนมือถือ ต่างจากคอมไหม

หลักการเดียวกันทั้งหมด แต่มีจุดต่างที่ควรรู้ อย่างแรกมือถือรุ่นเก่ามากๆ อาจไม่มี root certificate รุ่นใหม่ในเครื่อง ทำให้เข้าเว็บที่ใช้ CA ใหม่ไม่ได้ทั้งที่คอมเข้าได้ปกติ ทางแก้ที่ปลอดภัยคืออัปเดตระบบปฏิบัติการ อย่างที่สองแอปบางตัวมี in-app browser ที่จัดการใบเซอร์ต่างจากเบราว์เซอร์หลัก ให้ลองเปิดลิงก์เดิมใน Chrome หรือ Safari ตรงๆ เพื่อแยกปัญหา และอย่างที่สามมือถือที่เชื่อม Wi-Fi ค้างไว้กับ captive portal ที่หมดเซสชันแล้วจะเจอเตือนทุกเว็บ ให้สลับเป็น 4G/5G ทดสอบ ถ้าผ่าน 4G เข้าได้ปกติก็ชัดเจนว่าปัญหาอยู่ที่ Wi-Fi นั้น

ป้องกันไม่ให้เกิดซ้ำ: Checklist สำหรับเจ้าของเว็บ

• เปิดต่ออายุใบเซอร์อัตโนมัติเสมอ อย่าพึ่งการจดโน้ตเตือนตัวเอง
• ออกใบเซอร์ให้ครอบคลุมทั้ง www และ non-www ทุกครั้ง และเพิ่ม subdomain ใหม่เข้าใบเซอร์ทันทีที่เปิดใช้
• หลังติดตั้งหรือต่ออายุ ให้ทดสอบด้วย openssl หรือเครื่องมือ SSL checker ภายนอกทุกครั้ง อย่าทดสอบแค่เบราว์เซอร์ตัวเองเพราะอาจมี cache
• ตรวจ Verify return code ให้เป็น 0 (ok) เพื่อยืนยันว่า chain ครบ
• ตั้งระบบแจ้งเตือนวันหมดอายุล่วงหน้าอย่างน้อย 14 วัน เผื่อเวลาแก้ปัญหา
• ถ้าใช้ CDN หรือ proxy อย่าง Cloudflare ต้องดูใบเซอร์ทั้งขา browser-CDN และขา CDN-origin ให้ถูกต้องทั้งคู่

คำถามที่พบบ่อย (FAQ)

Error การเชื่อมต่อของคุณไม่เป็นส่วนตัว อันตรายไหม

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

ทำไมเจอ Error นี้ทุกเว็บที่เข้า

ถ้าเจอทุกเว็บ ปัญหาแทบทั้งหมดอยู่ที่เครื่องหรือเครือข่ายของคุณเอง ไม่ใช่ที่เว็บ สาเหตุยอดนิยมคือวันที่และเวลาในเครื่องผิด, Wi-Fi สาธารณะที่มี captive portal ยังไม่กดยอมรับ, โปรแกรม antivirus ที่เปิดฟีเจอร์สแกน HTTPS หรือ root certificate ในเครื่องเสียหาย ให้ตั้งเวลาอัตโนมัติและลองเปลี่ยนเครือข่ายก่อน

NET::ERR_CERT_DATE_INVALID หมายถึงอะไร

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

กด Proceed anyway ต่อไปยังเว็บไซต์ ได้ไหม

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

เว็บของฉันขึ้น Error นี้กับผู้เข้าชม ต้องแก้อย่างไร

ตรวจ 3 จุดหลักคือ ใบเซอร์หมดอายุหรือยัง, ชื่อโดเมนบนใบเซอร์ตรงกับ URL ที่ผู้ใช้พิมพ์หรือไม่ (รวม www และ non-www) และติดตั้ง intermediate chain ครบหรือไม่ ผู้ใช้โฮสติ้งที่มี DirectAdmin สามารถออกใบเซอร์ Let's Encrypt ใหม่พร้อมเปิดต่ออายุอัตโนมัติได้จากเมนู SSL Certificates ภายในไม่กี่นาที

Let's Encrypt ฟรีกับ SSL แบบเสียเงิน เลือกอะไรดี

ด้านการเข้ารหัสปลอดภัยเท่ากัน Let's Encrypt เหมาะกับเว็บทั่วไปและต่ออายุอัตโนมัติทุก 90 วัน ส่วน SSL แบบเสียเงินอย่าง RapidSSL DV (ราคา 1,000 บาท/ปี) มีอายุใบเซอร์ยาวกว่า มีประกันความเสียหาย (warranty) และเหมาะกับเว็บธุรกิจที่ต้องการความน่าเชื่อถือและการซัพพอร์ตในการติดตั้ง