การตรวจสอบใบรับรอง SSL

ต้นทุนของการพลาดต่ออายุ SSL

ใบรับรอง SSL ที่หมดอายุเวลา 23:59:59 จะไม่เสื่อมถอยอย่างนุ่มนวล เมื่อเวลา 00:00:00 ของวันถัดไป เบราว์เซอร์ทุกตัวจะเริ่มแสดงคำเตือนด้านความปลอดภัยแบบเต็มหน้าจอ ลูกค้า API ทุกตัวจะล้มเหลวที่ขั้นตอน TLS handshake, ตัวเชื่อมต่อ webhook ทุกตัวจะแจ้งข้อผิดพลาด เครื่องมือค้นหาทุกตัวจะลดอันดับเว็บไซต์ของคุณ อีเมลทุกฉบับจะตีกลับถ้าใบรับรองนี้ครอบคลุมถึง SMTP ด้วย การแก้ไขนั้นเร็ว - reissue, redeploy - แต่ช่องว่างระหว่างหมดอายุกับแก้ไขนั้นโหดร้ายเพราะไม่มีใครสังเกตเห็นใบรับรอง ก่อน เที่ยงคืน มีแต่หลังจากนั้น

การตรวจสอบ SSL มีไว้เพื่อให้คุณสังเกตเห็นก่อนถึงเที่ยงคืน มอนิเตอร์จะอ่านใบรับรองจากโฮสต์จริง วิเคราะห์ช่วงอายุการใช้งาน และแจ้งเตือนล่วงหน้า - 30 วัน, 14 วัน, 7 วัน, 3 วัน, 1 วัน - เพื่อให้การต่ออายุไม่ใช่เรื่องประหลาดใจ

สิ่งที่ถูกตรวจสอบ

สำหรับทุกเว็บไซต์ HTTPS ที่ถูกตรวจสอบ DiagnoSEO Uptime Monitoring จะสร้างการเชื่อมต่อ TLS รับใบรับรองจาก peer และวิเคราะห์ข้อมูล จากนั้นจะแสดงใน dashboard ดังนี้:

• ความถูกต้อง: ใบรับรองอยู่ในช่วงเวลาที่ถูกต้องหรือไม่?
• วันก่อนหมดอายุ: นับถอยหลังแบบ rolling แสดงเป็นป้ายสี (เขียว >30 วัน, ส้ม 8-30, แดง <8)
• วันที่หมดอายุ: วันที่แน่นอน
• ผู้ออก: ใครเป็นผู้ออกใบรับรอง (Let's Encrypt, DigiCert, GlobalSign ฯลฯ)
• Subject: common name ที่อยู่ในใบรับรอง

หากใบรับรองไม่มีความถูกต้อง - หมดอายุ ชื่อโฮสต์ไม่ถูกต้อง chain เสียลงลายมือชื่อเองโดยไม่ควรเป็น - มอนิเตอร์จะรายงาน SSL invalid ทันทีโดยไม่คำนึงถึงสถานะ HTTP สถานะ “HTTPS พังแต่เซิร์ฟเวอร์ยังออนไลน์” จะเห็นได้ทันที

เกณฑ์แจ้งเตือน

เครื่องมือนี้จะส่งแจ้งเตือน SSL ในห้าช่วง: 30, 14, 7, 3 และ 1 วันก่อนหมดอายุ โดยแต่ละช่วงจะเป็น alert แยกต่างหาก หากคุณเปิดใช้งานทั้งอีเมลและ Telegram คุณจะได้รับเตือนห้าครั้งเมื่อใกล้หมดอายุ — แจ้งเตือนจะเร่งความเร่งด่วนมากขึ้น ครั้งแรก (30 วัน) สำหรับการวางแผน 14 วันคือ "คราวนี้จริงจัง ทำให้เสร็จสัปดาห์นี้" ส่วนแจ้งเตือน 7, 3 และ 1 วัน มีไว้ในกรณีที่ยังไม่ได้ต่ออายุแล้วจำเป็นต้องเร่งมือทันที

สามารถปิดแจ้งเตือนต่อช่องทางได้ - บางทีมอยากได้ alert SSL ทางอีเมลเท่านั้น ไม่ต้องการผ่าน Slack/Telegram (ที่อาจหายไปกลางเสียงรบกวน) ตั้งค่าได้ในส่วนการแจ้งเตือน

เหตุใด auto-renewal ไม่เพียงพอ

หากคุณใช้ Let's Encrypt กับ certbot หรือเครื่องมือที่คล้ายกัน คุณอาจคิดว่าการตรวจสอบ SSL ไม่จำเป็น — แต่จริงๆ ไม่ใช่ Auto-renewal สามารถล้มเหลวได้หลายวิธี: อีเมลใน certbot ผิด ACME challenge ล้มเหลวเพราะ firewall เปลี่ยน cron ต่ออายุหยุดทำงาน การ restart container ทำให้สถานะต่ออายุหายไป หรือ DNS เปลี่ยนทำให้ validation domain ล้มเหลว ทุกกรณีนี้ใบรับรองจะมุ่งสู่การหมดอายุ และ auto-renewal ไม่สามารถช่วยคุณ Monitoring SSL จึงเป็นตาข่ายนิรภัยที่คอยจับข้อผิดพลาดที่ automation พลาดไป

สำหรับใบรับรองภายใน (CA บริษัท, mutual TLS) โดยทั่วไปจะไม่มี auto-renewal - Monitoring SSL เป็นสัญญาณเชิงรุกเดียวที่บอกให้ต่ออายุใบรับรอง

การตั้งค่า

Monitoring SSL จะถูกเปิดใช้งานอัตโนมัติสำหรับทุก monitor HTTPS ใน DiagnoSEO Uptime Monitoring ไม่จำเป็นต้องตั้งค่าเอง ครั้งต่อไปที่มีการตรวจสอบแบบละเอียด (ภายใน 24 ชั่วโมงหลังเพิ่ม monitor หรือหลังคลิก "ตรวจสอบตอนนี้") แถว SSL จะเติมข้อมูลผู้ออก วันที่หมดอายุ และจำนวนวันที่เหลือ จากนั้น monitoring จะจับตาใบรับรองและแจ้งเตือนแบบ 30/14/7/3/1 วัน

สำหรับ monitor ที่ไม่ใช่ HTTPS SSL จะถูกละเว้น สำหรับ monitor ที่ตั้งค่า SSL port แบบ custom เครื่องมือจะลองกับพอร์ตที่ตรงกัน (ค่าเริ่มต้น 443; 465 สำหรับ SMTPS, 993 สำหรับ IMAPS ฯลฯ ตามประเภท monitor)

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

• ฉันควรได้รับแจ้งเตือนก่อน SSL หมดอายุนานเท่าไหร่?

  ระดับแจ้งเตือนมาตรฐานคือ 30, 14, 7, 3 และ 1 วันก่อนหมดอายุ สามสิบวันให้เวลาวางแผนต่ออายุในเวลางาน ช่วงแจ้งเตือนสั้นๆ จะเพิ่มความเร่งด่วน หากคุณพึ่ง auto-renewal (Let's Encrypt กับ certbot) การเตือน 7 วัน คือจังหวะที่ควรตรวจสอบว่าต่ออายุผ่านแล้วจริงหรือไม่ — ความเสียหายแบบเงียบๆ จากการต่ออายุล้มเหลวพบได้บ่อย และจะถูกจับได้โดย monitoring ที่เป็นอิสระจากระบบหลัก

• Monitoring SSL ตรวจพบปัญหา chain หรือ hostname ไม่ตรงได้หรือไม่?

  ได้ มอนิเตอร์จะ handshake TLS จริงและเช็คใบรับรองจากเซิร์ฟเวอร์ ถ้าใบรับรองหมดอายุ ลงลายมือชื่อเอง CN/SAN ไม่ตรงกับ hostname หรือเซ็นโดย CA ที่ไม่รู้จัก การตรวจสอบจะล้มเหลวพร้อมบอก error เฉพาะ เหล่านี้คือปัญหา "ใบรับรองยังถูกแต่ติดตั้งผิด" ที่ browser ก็เตือนเช่นกัน

• ถ้าใบรับรองยังถูกแต่ขาด intermediate CA จะเป็นอย่างไร?

  ถ้าขาด intermediate certificate จะเกิดข้อผิดพลาด "chain incomplete" ใน client TLS หลายตัว (เช่น curl, อุปกรณ์ Android เก่า) แม้ browser บน PC จะกู้ chain เองได้ การตรวจสอบ SSL ของเราต้องใช้ chain ที่ครบและถูก — ถ้าขาด intermediate การตรวจจะล้มเหลว แจ้งเตือนให้ทราบก่อนที่ผู้ใช้ mobile จะเจอปัญหา

• สามารถ monitor SSL บนพอร์ตเฉพาะ (เช่น 8443, เซิร์ฟเวอร์อีเมล) ได้ไหม?

  ได้ — ตั้งค่า URL ของ monitor พร้อมพอร์ต (เช่น https://api.example.com:8443/) มอนิเตอร์จะเชื่อมต่อไปยังพอร์ตนี้เพื่อ handshake TLS และอ่านใบรับรอง สามารถใช้กับ SMTP STARTTLS, IMAP/POP3 TLS และโปรโตคอลอื่นๆ ที่ wrap TLS บนพอร์ต custom ได้เช่นเดียวกัน

• การ monitoring SSL ใช้เครดิตเพิ่มเติมหรือไม่?

  ไม่ TLS handshake และการเช็คใบรับรองเกิดขึ้นเป็นส่วนหนึ่งของทุกการตรวจสอบ HTTPS — ไม่มีต้นทุนแยกต่างหาก การแจ้งเตือนหมดอายุทั้ง 5 ระดับก็ฟรี Lookup WHOIS เพื่อตรวจสอบโดเมนหมดอายุเป็นฟีเจอร์เสริมเดียวที่ทำงานในรอบรายวัน