เบราว์เซอร์และการตรวจสอบใบรับรอง

บทนำ

HTTPS (ผ่าน SSL /TLS) ใช้ การเข้ารหัสคีย์สาธารณะ เพื่อป้องกันการสื่อสารของเบราว์เซอร์ไม่ให้อ่านหรือแก้ไขในระหว่างการขนส่งทางอินเทอร์เน็ต เซิร์ฟเวอร์จัดเตรียมการเยี่ยมชมเบราว์เซอร์ด้วยคีย์สาธารณะที่ใช้เพื่อสร้างการเชื่อมต่อที่เข้ารหัสสำหรับการแลกเปลี่ยนข้อมูลที่ตามมาทั้งหมด

อย่างไรก็ตามเพิ่งได้รับ การทำงาน กุญแจสาธารณะเพียงอย่างเดียวไม่รับประกันว่ามัน (และโดยการขยายเซิร์ฟเวอร์) เป็นเจ้าของแน่นอนโดยระยะไกลที่ถูกต้อง หรือ (เช่น บุคคล บริษัท หรือองค์กร) Man-in-the-กลาง ผู้โจมตีสามารถจัดการเครือข่ายเพื่อรับกุญแจของตัวเองซึ่งจะส่งผลต่อการสื่อสารใด ๆ

เบราว์เซอร์ป้องกันสิ่งนี้ด้วย ที่ถูกตรวจสอบ เซิร์ฟเวอร์ HTTPS ที่ใช้ ใบรับรองซึ่งเป็นเอกสารดิจิทัลที่ ผูก คีย์สาธารณะสำหรับบุคคลใดบุคคลหนึ่ง การเชื่อมโยงจะได้รับการยืนยันโดยการมี c ที่เชื่อถือได้ผู้มีอำนาจออกใบรับรอง (CA) เช่น SSL.com ตรวจสอบตัวตนของเจ้าของใบรับรองที่คาดหวังผ่านการตรวจสอบอัตโนมัติและด้วยตนเองกับฐานข้อมูลที่ผ่านการรับรอง

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

โปรดทราบว่ากระบวนการตรวจสอบใบรับรอง (อธิบายไว้โดยละเอียดในเอกสารมาตรฐาน RFC 5280) ค่อนข้างซับซ้อน ในบทความนี้เราจะพยายามนำคุณไปตามเส้นทางเดียว (เบราว์เซอร์ที่ตรวจสอบ SSL ของโฮสต์ /TLS ใบรับรอง) และสำรวจรายละเอียดที่ซับซ้อนที่ผ่านมาซึ่งไม่สำคัญกับผู้ใช้ส่วนใหญ่

หมายเหตุ ณ เดือนสิงหาคม 2024 RFC 9618 เอกสารของ Internet Engineering Task Force (IETF)ได้อัปเดตอัลกอริทึมสำหรับการตรวจสอบข้อจำกัดนโยบายในใบรับรองดิจิทัล X.509 จาก RFC 5280

ใบรับรองและรูปแบบ X.509

ใบรับรองเป็นไฟล์ดิจิทัลทุกประการ ซึ่งหมายความว่าใบรับรองต้องเป็นไปตามรูปแบบไฟล์เพื่อจัดเก็บข้อมูล (เช่น ลายเซ็น คีย์ ผู้ออก ฯลฯ) ในขณะที่เป็นส่วนตัว PKI การกำหนดค่าสามารถใช้รูปแบบใดก็ได้สำหรับใบรับรองที่เชื่อถือได้ต่อสาธารณะ PKI(กล่าวคือ เบราว์เซอร์ที่ไว้วางใจ) จะต้องเป็นไปตาม RFC 5280 ซึ่งกำหนดให้ต้องใช้ X.509 v3 จัดรูปแบบ

X.509 v3 อนุญาตให้ใบรับรองรวมข้อมูลเพิ่มเติมเช่นข้อ จำกัด การใช้งานหรือข้อมูลนโยบายเช่น ส่วนขยายโดยแต่ละส่วนขยายจะเป็นอย่างใดอย่างหนึ่ง วิกฤติ or ไม่สำคัญ. หากไคลเอ็นต์พบส่วนขยายที่ไม่สำคัญและไม่รู้จัก ไคลเอ็นต์สามารถละเว้นส่วนขยายนั้นได้ หากส่วนขยายนั้นสำคัญและไม่รู้จัก หรือไม่สามารถประมวลผลได้ จะต้องปฏิเสธใบรับรอง

เส้นทางการรับรองและการประมวลผลเส้นทาง

CA ใช้กุญแจส่วนตัวเพื่อลงนามในใบรับรองที่ออกทั้งหมดด้วยการเข้ารหัส ลายเซ็นดังกล่าวสามารถ เข้ารหัส พิสูจน์ว่าใบรับรองนั้นออกโดย CA เฉพาะเจาะจง และไม่ได้รับการแก้ไขใดๆ หลังจากลงนามแล้ว

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

เบราว์เซอร์มาพร้อมกับรายการรากที่เชื่อถือได้ในตัว (เหล่านี้มีรากมาจาก CA ที่ผ่านเกณฑ์ที่เข้มงวดของเบราว์เซอร์สำหรับการรวม) ในการตรวจสอบใบรับรองเบราว์เซอร์จะได้รับใบรับรองตามลำดับโดยแต่ละใบรับรองได้ลงนามในใบรับรองถัดไปตามลำดับโดยเชื่อมต่อรูทของ CA ที่ลงชื่อเข้ากับเซิร์ฟเวอร์ ใบรับรอง.

ลำดับของใบรับรองนี้เรียกว่า เส้นทางการรับรอง. รูทของพา ธ เรียกว่า a เชื่อใจสมอ และใบรับรองของเซิร์ฟเวอร์เรียกว่าไฟล์ ใบไม้ or เอนทิตีที่สิ้นสุด ใบรับรอง

การก่อสร้างเส้นทาง

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

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

การตรวจสอบเส้นทาง

หลังจากสร้างเส้นทางการรับรองผู้สมัครแล้วเบราว์เซอร์จะตรวจสอบความถูกต้องโดยใช้ข้อมูลที่มีอยู่ในใบรับรอง เส้นทางจะถูกต้องหากเบราว์เซอร์สามารถพิสูจน์ได้ด้วยการเข้ารหัสโดยเริ่มจากใบรับรองที่ลงนามโดยตรงโดย Trust anchor คีย์ส่วนตัวที่เกี่ยวข้องของใบรับรองแต่ละอันจะถูกใช้เพื่อออกรายการถัดไปในเส้นทางไปจนถึงใบรับรอง leaf

ข้อกำหนดพื้นฐานกำหนดให้ชื่อเรื่องและผู้ออกเอกสารทั่วทั้ง เส้นทางที่เป็นไปได้ทั้งหมด be เหมือนกันแบบไบต์ต่อไบต์ซึ่งทำให้การสร้างเส้นทางที่เชื่อถือได้ง่ายขึ้น

อัลกอริทึมการตรวจสอบเส้นทางการรับรอง

ตามที่ระบุไว้ก่อนหน้านี้ ณ เดือนสิงหาคม 2024 RFC 9618 เอกสารของ Internet Engineering Task Force (IETF)ได้อัปเดตอัลกอริทึมสำหรับการตรวจสอบข้อจำกัดนโยบายในใบรับรองดิจิทัล X.509 จาก RFC 5280 โดยพื้นฐานแล้ว เบราว์เซอร์จะวนซ้ำผ่านใบรับรองทั้งหมดในเส้นทางโดยเริ่มจากจุดยึดความน่าเชื่อถือ (เช่น ใบรับรองราก) เพื่อตรวจสอบข้อมูลพื้นฐานและส่วนขยายที่สำคัญของใบรับรองแต่ละใบ

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

การประมวลผลใบรับรองขั้นพื้นฐาน

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

1. เบราว์เซอร์ตรวจสอบความสมบูรณ์ของใบรับรอง

การขอ ลายเซ็น ในใบรับรองสามารถตรวจสอบได้โดยใช้การเข้ารหัสคีย์สาธารณะปกติ หากลายเซ็นไม่ถูกต้องใบรับรองนั้นจะถูกพิจารณาว่ามีการแก้ไขหลังจากการออกและจะถูกปฏิเสธ

2. เบราว์เซอร์ตรวจสอบความถูกต้องของใบรับรอง

ใบรับรอง ช่วงเวลาที่มีผลบังคับใช้ เป็นช่วงเวลาที่ CA เซ็นชื่อรับรองว่าจะรักษาข้อมูลเกี่ยวกับสถานะ เบราว์เซอร์ปฏิเสธใบรับรองใด ๆ ที่มีช่วงเวลาที่มีผลบังคับใช้ซึ่งสิ้นสุดก่อนหรือเริ่มหลังจากวันที่และเวลาของการตรวจสอบความถูกต้อง

3. เบราว์เซอร์ตรวจสอบสถานะการเพิกถอนใบรับรอง

เมื่อมีการออกใบรับรองคาดว่าจะมีการใช้งานตลอดช่วงเวลาที่มีผลบังคับใช้ แน่นอนสถานการณ์ต่างๆอาจทำให้ใบรับรองไม่ถูกต้องก่อนที่จะหมดอายุตามธรรมชาติ

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

รายการเพิกถอนใบรับรอง (CRL)

รายชื่อการเพิกถอนใบรับรอง (CRL) ได้กลายเป็นมาตรฐานอุตสาหกรรมสำหรับการตรวจสอบการเพิกถอนใบรับรองตั้งแต่ปี 2024 เป็นต้นมา CA จะออกรายชื่อใบรับรองที่ถูกเพิกถอนพร้อมลงนามและประทับเวลาเป็นระยะๆ ซึ่งเบราว์เซอร์สามารถดาวน์โหลดและแคชไว้ในเครื่องได้

แม้ว่า CRL จะถูกมองว่ามีประสิทธิภาพน้อยกว่าวิธีการตรวจสอบแบบเรียลไทม์ แต่ในปัจจุบันอุตสาหกรรมได้ตระหนักถึงข้อได้เปรียบที่สำคัญที่ทำให้ CRL เป็นแนวทางที่ต้องการ:

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

ณ เดือนมีนาคม 2024 ฟอรัม CA/Browser กำหนดให้ CA ที่ได้รับความไว้วางใจจากสาธารณะทั้งหมดต้องจัดเตรียม CRL ในขณะที่ทำให้วิธีการเพิกถอนอื่นๆ เป็นทางเลือกผู้ให้บริการออกใบรับรองรายใหญ่บางรายได้ยุติการให้บริการเพิกถอนแบบอื่นแล้ว และเลือกใช้วิธีการ CRL เพียงอย่างเดียวแทน

โปรโตคอลสถานะใบรับรองออนไลน์ (OCSP)

โปรโตคอลสถานะใบรับรองออนไลน์ (OCSP) อธิบายไว้ใน RFC 6960, ได้รับการออกแบบมาเพื่อให้สามารถตรวจสอบการเพิกถอนใบรับรองแบบเรียลไทม์ โดยอนุญาตให้เบราว์เซอร์สอบถามเซิร์ฟเวอร์ OCSP (ผู้ตอบกลับ) เกี่ยวกับใบรับรองเฉพาะ แม้ว่า OCSP จะถูกนำมาใช้อย่างแพร่หลายในช่วงปี 2010 ซึ่งเป็นการปรับปรุงจากการดาวน์โหลด CRL เป็นระยะๆ แต่อุตสาหกรรมส่วนใหญ่ก็หันเหออกจากแนวทางนี้ไปมาก

• ปัจจุบัน OCSP เป็นทางเลือกสำหรับ CA ที่ได้รับความไว้วางใจจากสาธารณะ (มีผลตั้งแต่เดือนมีนาคม 2024) ความสำคัญของ OCSP คือ การลดลง; ตัวอย่างเช่น, ขอเข้ารหัส ลบ URL OCSP ในเดือนพฤษภาคม 2025 และปิดระบบตอบสนองใน สิงหาคม.
• เบราว์เซอร์บางตัวได้ปิดการตรวจสอบ OCSP ไว้หรือใช้งานในลักษณะที่ให้ประโยชน์ด้านความปลอดภัยขั้นต่ำ

การเย็บ OCSP: เป็นตัวแปรที่เรียกว่า การเย็บ OCSP ยังคงมีประโยชน์ในบางสถานการณ์ที่เซิร์ฟเวอร์รวมการตอบสนอง OCSP โดยตรงใน TLS การจับมือกัน (handshake) หลีกเลี่ยงการสอบถามไคลเอ็นต์แยกต่างหากไปยังผู้ตอบสนอง OCSP อย่างไรก็ตาม การทำเช่นนี้จำเป็นต้องมีการกำหนดค่าเซิร์ฟเวอร์เฉพาะ เซิร์ฟเวอร์/CDN ส่วนใหญ่รองรับการ Stapling แต่ประโยชน์ใช้สอยของ Stapling กำลังลดลง เนื่องจาก CA ขนาดใหญ่ยกเลิก OCSP

วิธีการทำงานจริง ๆ ในปัจจุบันในเบราว์เซอร์: ตั้งแต่วันที่ 15 มีนาคม 2024 ฟอรัม CA/B กำหนดให้ CA ที่ได้รับความไว้วางใจจากสาธารณะเผยแพร่ CRL ในขณะที่ OCSP เป็นทางเลือก เบราว์เซอร์สมัยใหม่โดยทั่วไปจะไม่สอบถาม OCSP หรือดาวน์โหลด CRL ต่อเว็บไซต์ แต่จะใช้กลไกแบบรวมที่สร้างจาก CRL ที่เผยแพร่โดย CA: CRLSets ของ Chrome และ CRLite ของ Firefox ส่งข้อมูลการเพิกถอนที่รวดเร็วและรักษาความเป็นส่วนตัวให้กับไคลเอ็นต์ ส่งผลให้บทบาทของ OCSP บนเว็บสาธารณะลดน้อยลง ตัวอย่างเช่น Let's Encrypt ได้ลบ URL ของ OCSP ออกในเดือนพฤษภาคม 2025 และปิดระบบตอบสนอง OCSP ในเดือนสิงหาคม 2025

4. เบราว์เซอร์ตรวจสอบผู้ออก

ปกติแล้วใบรับรองจะเชื่อมโยงกับสองเอนทิตี:

1. การขอ บริษัท ผู้ออกหลักทรัพย์ซึ่งเป็นนิติบุคคลที่มีรหัสการลงนามและ
2. การขอ หรือซึ่งหมายถึงเจ้าของกุญแจสาธารณะที่ใบรับรองจะตรวจสอบความถูกต้อง

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

การประมวลผลข้อ จำกัด

รูปแบบ X.509 v3 ช่วยให้ CA สามารถกำหนดข้อ จำกัด หรือข้อ จำกัด เกี่ยวกับวิธีการตรวจสอบความถูกต้องของใบรับรองแต่ละรายการและใช้เป็นส่วนขยายที่สำคัญ ใบรับรองทั้งหมดในเส้นทางสามารถกำหนดข้อ จำกัด เพิ่มเติมที่ใบรับรองต่อมาทั้งหมดจะต้องปฏิบัติตาม

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

5. เบราว์เซอร์ตรวจสอบข้อ จำกัด ของชื่อ

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

6. เบราว์เซอร์ตรวจสอบข้อ จำกัด นโยบาย

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

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

7. เบราว์เซอร์ตรวจสอบข้อ จำกัด พื้นฐาน (ความยาวเส้นทาง)

รูปแบบ X.509 v3 ช่วยให้ผู้ออกสามารถกำหนดความยาวเส้นทางสูงสุดที่ใบรับรองสามารถรองรับได้ ซึ่งให้การควบคุมระยะทางในการวางใบรับรองในเส้นทางการรับรอง สิ่งนี้สำคัญมาก - เบราว์เซอร์ที่ใช้ในการเพิกเฉยต่อความยาวเส้นทางการรับรองจนกว่านักวิจัยจะแสดงให้เห็นในปี 2009 การเสนอเขาใช้ใบรับรองใบไม้ของเว็บไซต์ของเขาเพื่อสร้างใบรับรองที่ถูกต้องสำหรับเว็บไซต์อีคอมเมิร์ซขนาดใหญ่ได้อย่างไร

8. เบราว์เซอร์ตรวจสอบการใช้งานที่สำคัญ

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

9. เบราว์เซอร์ยังคงประมวลผลส่วนขยายที่สำคัญทั้งหมดที่เหลืออยู่

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

การจัดการใบรับรองสมัยใหม่: อายุการใช้งานที่สั้นลงและระบบอัตโนมัติ

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

ระยะเวลาใช้งานใบรับรองที่สั้นลง

ในเดือนเมษายน พ.ศ. 2025 ฟอรัม CA/Browser ได้อนุมัติการตัดสินใจสำคัญ (บัตรลงคะแนน SC-081v3) เพื่อลดระยะเวลาการใช้ใบรับรองลงอย่างมากในแต่ละระยะ:

• ปัจจุบัน (ถึงมีนาคม 2026):สูงสุด 398 วัน (ประมาณ 13 เดือน)
• March 15, 2026: สูงสุด 200 วัน
• March 15, 2027: สูงสุด 100 วัน
• March 15, 2029: สูงสุด 47 วัน

การเปลี่ยนแปลงการตรวจสอบการควบคุมโดเมน (DCV)

นอกจากอายุการใช้งานของใบรับรองแล้ว ระยะเวลาการใช้ซ้ำสำหรับข้อมูลการตรวจสอบโดเมนก็ลดลงเช่นกัน:

• มีนาคม: ใช้งานซ้ำได้สูงสุด 200 วัน
• มีนาคม: ใช้งานซ้ำได้สูงสุด 100 วัน
• มีนาคม: ใช้งานซ้ำได้สูงสุด 10 วัน

ซึ่งหมายความว่าองค์กรต่างๆ จะต้องตรวจสอบความเป็นเจ้าของโดเมนบ่อยมากขึ้น ทำให้ระบบอัตโนมัติมีความจำเป็นต่อการจัดการใบรับรองในทางปฏิบัติ

เหตุใดการเปลี่ยนแปลงเหล่านี้จึงมีความสำคัญ

ประโยชน์ด้านความปลอดภัย:

• อายุการใช้งานของใบรับรองที่สั้นลงจะลดช่วงเวลาการเปิดเผยเมื่อคีย์ถูกบุกรุก
• การตรวจสอบที่บ่อยขึ้นช่วยให้มั่นใจว่าการเป็นเจ้าของโดเมนยังคงเป็นปัจจุบัน
• การปรับใช้การปรับปรุงความปลอดภัยที่รวดเร็วยิ่งขึ้นทั่วทั้งเว็บ

ผลกระทบต่อการดำเนินงาน:

• การจัดการใบรับรองด้วยตนเองกลายเป็นเรื่องที่แทบจะเป็นไปไม่ได้
• องค์กรต่างๆ จะต้องนำการจัดการวงจรชีวิตใบรับรองอัตโนมัติมาใช้
• จำเป็นต้องมีขั้นตอนการตรวจสอบโดเมนบ่อยขึ้น

ข้อกำหนดด้านระบบอัตโนมัติ

การเปลี่ยนแปลงเหล่านี้ทำให้ระบบอัตโนมัติสำหรับใบรับรองไม่เพียงแต่เป็นประโยชน์ แต่ยังจำเป็นอย่างยิ่ง องค์กรต่างๆ ควรพิจารณาสิ่งต่อไปนี้อย่างจริงจัง:

• Implement ACME (สภาพแวดล้อมการจัดการใบรับรองอัตโนมัติ) หรือโปรโตคอลที่คล้ายคลึงกัน
• ปรับใช้ โซลูชันการจัดการวงจรชีวิตใบรับรอง
• เตรียมโครงสร้างพื้นฐานสำหรับการต่ออายุและการตรวจสอบบ่อยครั้ง
• เตรียมพร้อมสำหรับการเปลี่ยนผ่านไปสู่อายุการใช้งานใบรับรองที่สั้นลง

การบูรณาการความโปร่งใสของใบรับรอง

เบราว์เซอร์สมัยใหม่ต้องการหรือตรวจสอบบันทึกความโปร่งใสของใบรับรอง (Certificate Transparency: CT) มากขึ้น ซึ่งบันทึกเหล่านี้จะเป็นสาธารณะที่ตรวจสอบได้สำหรับใบรับรองที่ออกให้ทั้งหมด วิธีนี้จะช่วยตรวจจับ:

• ใบรับรองที่ออกไม่ถูกต้อง
• การออกใบรับรองโดยไม่ได้รับอนุญาต
• ปัญหาการปฏิบัติตามข้อกำหนดของ CA

สรุป

ภูมิทัศน์ดิจิทัลยังคงเป็นระบบที่ซับซ้อนของส่วนประกอบที่เชื่อมโยงกัน และความปลอดภัยของเบราว์เซอร์ยังคงเป็นพื้นที่ที่ต้องมีการพัฒนาอย่างต่อเนื่อง ซึ่งรวมถึง: 

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

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

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

สำหรับข้อมูลล่าสุดเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดในการจัดการใบรับรองและแนวทางของ SSL.com ต่อการเปลี่ยนแปลงในอุตสาหกรรมเหล่านี้ โปรดไปที่ หน้าเปรียบเทียบใบรับรอง.

ขอขอบคุณที่เลือก SSL.com ซึ่งเราเชื่อว่า ปลอดภัยมากขึ้น อินเทอร์เน็ตคือ ดีกว่า อินเตอร์เน็ต