ภาพรวมสินค้า
การเริ่มต้น กันยายน 15, 2025, SSL.com ของ TLS เซิร์ฟเวอร์ ใบรับรอง จะออกให้โดยไม่ต้อง includไอเอ็นจี การตรวจสอบลูกค้า การขยายการใช้งานคีย์แบบขยาย (EKU) นี้ เปลี่ยนแปลง ได้รับคำแนะนำจาก นโยบายโปรแกรมรูทของ Google Chrome. Here, เราอธิบายว่า EKU คืออะไร ทำไมการเปลี่ยนแปลงนี้จึงเกิดขึ้น และอาจเกิดขึ้นได้อย่างไร ทั่วโลก สภาพแวดล้อมของเซิร์ฟเวอร์ และการดำเนินการที่คุณอาจต้องดำเนินการ นอกจากนี้ เรายัง ให้ คำถามที่พบบ่อยและคำแนะนำทางเทคนิคสำหรับสถานการณ์ต่างๆ
การอัปเดตที่สำคัญ: ตั้งแต่วันที่ 15 มีนาคม 2027 เป็นต้นไป Google Chrome จะไม่รองรับใบรับรองปลายทางที่มี ClientAuth EKU อีกต่อไป โปรดทราบว่าการเปลี่ยนแปลงนี้มีผลเฉพาะกับ Chrome เท่านั้น ดังนั้นจึงไม่จำเป็นต้องกังวลเกี่ยวกับแหล่งเก็บใบรับรองหลักอื่นๆ หรือบริการของ Google เช่น Gmail และ Google Trust Services
หากคุณใช้ ClientAuth ในสภาพแวดล้อมที่ใช้ Chrome เราขอแนะนำให้คุณติดต่อทีมงานของเรา เพื่อที่เราจะได้ร่วมกันหาทางออกที่ดีที่สุดสำหรับองค์กรของคุณ
Extended Key Usages (EKUs) คืออะไร?
การใช้งานคีย์ขยาย (EKU), เป็นส่วนขยายใบรับรองที่กำหนดฟังก์ชันที่ตั้งใจไว้ของคีย์สาธารณะภายในใบรับรองดิจิทัล โดยสร้างชุดแอปพลิเคชันที่ได้รับอนุญาตแบบมีโครงสร้าง เพื่อให้แน่ใจว่าคีย์จะถูกใช้เฉพาะสำหรับการดำเนินการเข้ารหัสเฉพาะเท่านั้น ฟังก์ชันนี้ถูกควบคุมโดย ตัวระบุวัตถุ (OID)ตัวระบุตัวเลขเฉพาะที่จัดหมวดหมู่การใช้งานที่ได้รับอนุญาตแต่ละรายการ เช่น การลงนามรหัส การรับรองความถูกต้องของเซิร์ฟเวอร์ การรับรองความถูกต้องของไคลเอนต์ หรืออีเมลที่ปลอดภัย เมื่อการรับรองความถูกต้องเป็นแบบใช้ใบรับรอง หน่วยงานตรวจสอบจะตรวจสอบใบรับรองเพื่อระบุตัวระบุออบเจ็กต์ (OID) ภายใน EKU การฝังส่วนขยาย EKU ผู้ออกใบรับรอง (CA) จำกัดขอบเขตของใบรับรองให้เป็นบทบาทที่กำหนดไว้ล่วงหน้า โดยแต่ละวัตถุประสงค์ที่กำหนดไว้จะถูกแมปกับ OID อย่างชัดเจน
ตัวอย่างเช่น:
- TLS การตรวจสอบความถูกต้องของเว็บเซิร์ฟเวอร์ – ระบุว่าสามารถใช้ใบรับรองเพื่อตรวจสอบความถูกต้องของเซิร์ฟเวอร์ (เช่น เว็บไซต์ HTTPS) OID ที่สอดคล้องกับการตรวจสอบสิทธิ์เซิร์ฟเวอร์คือ 1.3.6.1.5.5.7.3.1
- TLS การตรวจสอบสิทธิ์ไคลเอนต์เว็บ – ระบุว่าใบรับรองสามารถใช้โดยไคลเอนต์เพื่อพิสูจน์ตัวตนกับเซิร์ฟเวอร์ (เช่น ใบรับรองไคลเอนต์สำหรับการเชื่อมต่อร่วมกัน TLS). OID ที่กำหนดให้กับการตรวจสอบสิทธิ์ไคลเอนต์คือ 1.3.6.1.5.5.7.3.2
เบราว์เซอร์และเซิร์ฟเวอร์ต้องการเพียง เซิร์ฟเวอร์Auth มศว ไปยัง สร้าง การเชื่อมต่อที่ปลอดภัยสำหรับ HTTPS แต่ ประวัติศาสตร์มากมาย TLS ใบรับรองเซิร์ฟเวอร์รวมทั้ง เซิร์ฟเวอร์Auth และ ลูกค้าตรวจสอบสิทธิ์ อีเคยู. ด้านล่างนี้เป็นตัวอย่างของ ใบรับรองดังกล่าว:
มีอะไร เกิดขึ้น?
เริ่มวันที่ 15 กันยายน, 2025, SSL.com จะ ปัญหา TLS ใบรับรองที่รวมเฉพาะ เซิร์ฟเวอร์Auth มศว (และ ไม่ ลูกค้าตรวจสอบสิทธิ์) สำหรับใบรับรองเซิร์ฟเวอร์ กล่าวอีกนัยหนึ่ง SSL ใหม่/TLS ใบรับรองสำหรับเว็บไซต์หรือเซิร์ฟเวอร์ของคุณจะใช้ได้เฉพาะกับ “การตรวจสอบสิทธิ์เซิร์ฟเวอร์” เท่านั้น
เหตุใดจึงต้องถอด ลูกค้าตรวจสอบสิทธิ์ EKU จากใบรับรองเซิร์ฟเวอร์?
มีเหตุผลหลายประการสำหรับการมอบหมายนี้:
- ความปลอดภัยและขอบเขต: สาธารณะ TLS ใบรับรองคือ ควรตรวจสอบความถูกต้องของเซิร์ฟเวอร์เท่านั้น บนเว็บ การลบออกทำให้แยกฟังก์ชันการทำงานของเซิร์ฟเวอร์และไคลเอนต์ได้อย่างชัดเจน EKU ของ ClientAuth ใช้สำหรับการตรวจสอบสิทธิ์เครื่องและผู้ใช้ด้วย Mutual TLS (mTLS) และสถานการณ์การยืนยันตัวตนอื่น ๆ
- ป้องกันการกำหนดค่าผิดพลาด: ระบบบางระบบอาจเชื่อถือ ใด ใบรับรองจาก CA สาธารณะสำหรับการตรวจสอบสิทธิ์ไคลเอนต์หากมี EKU อยู่ ซึ่งอาจเป็นความเสี่ยงด้านความปลอดภัย
- ความต้องการของเบราว์เซอร์: เบราว์เซอร์หลักไม่ต้องการหรือตรวจสอบ clientAuth EKU ในใบรับรองของเว็บไซต์
- ย่อ PKI สถาปัตยกรรม: โดยการแยกการใช้งาน CA สามารถรักษาลำดับชั้นใบรับรองที่แตกต่างกันสำหรับเซิร์ฟเวอร์ได้ TLS เมื่อเทียบกับวัตถุประสงค์อื่น ๆ
การปฏิบัติตามข้อกำหนดของอุตสาหกรรม
การเปลี่ยนแปลงนโยบายนี้คือ ในปัจจุบัน กำลัง เข้าสู่ระยะ by Google Chrome โปรแกรมรูท.
ผลกระทบต่อสภาพแวดล้อมเซิร์ฟเวอร์
สำหรับการใช้งานเซิร์ฟเวอร์ส่วนใหญ่ การเปลี่ยนแปลงนี้จะเกิดขึ้น มีผลกระทบน้อย or ไม่มีผลกระทบ. นี่คือสิ่งที่คาดหวัง:
- เซิร์ฟเวอร์เว็บมาตรฐาน (HTTPS): ไม่มีผลกระทบ ใบรับรองที่อัปเดตจะยังคงใช้งานได้ตามปกติ
- ใบรับรองที่มีอยู่: ใบรับรองใดๆ ที่ออกให้ ก่อน ระบบตัดอัตโนมัติจะยังคงทำงานต่อไปจนกว่าจะหมดอายุ
- ซึ่งกันและกัน TLS (mTLS) และสถานการณ์ใบรับรองไคลเอนต์: หากคุณกำลังใช้ TLS ใบรับรองเซิร์ฟเวอร์สำหรับ การตรวจสอบลูกค้าคุณจะต้องได้รับใบรับรองแยกต่างหากด้วย ไคลเอนต์Auth EKU จากแหล่งอื่น
- ระบบองค์กรที่ต้องการทั้งสอง EKU: ระบบเก่าหรือระบบองค์กรบางระบบคาดหวังให้มี EKU ทั้งสองแบบ คุณควรตรวจสอบว่าจำเป็นต้องอัปเดตเพื่อให้เป็นไปตามกฎใหม่หรือไม่
- ใบรับรองสำหรับไคลเอนต์ API, อุปกรณ์ IoT ฯลฯ: หากกรณีการใช้งานของคุณใช้ clientAuth EKU คุณจะต้องได้รับใบรับรองการตรวจสอบสิทธิ์ไคลเอนต์โดยเฉพาะ SSL.com เสนอ ใบรับรองการตรวจสอบสิทธิ์ไคลเอ็นต์.
การดำเนินการที่จำเป็นสำหรับลูกค้า
- จัดทำรายการใบรับรองของคุณ: ระบุใด ๆ TLS ใบรับรองที่ใช้งานและตรวจสอบ EKU ของ clientAuth
- ระบุกรณีการใช้งานคู่: ตรวจสอบว่าระบบใดของคุณต้องพึ่งพา TLS ใบรับรองสำหรับการยืนยันตัวตนลูกค้า
- แผนการต่ออายุ/ออกใบรับรองใหม่: ใบรับรองในอนาคตจะออกโดยไม่มี clientAuth EKU ตามค่าเริ่มต้น
- ออกใหม่ล่วงหน้าหากจำเป็น: หากคุณต้องการอัปเดตใบรับรองของคุณโดยตรง คุณสามารถออกใบรับรองใหม่ได้ก่อนกำหนดเส้นตาย
- รับใบรับรองการตรวจสอบสิทธิ์ไคลเอนต์หากจำเป็น: รับประกันใบรับรองแยกด้วย ไคลเอนต์Auth EKU หากมีความจำเป็น.
- อัปเดตเอกสารและการกำหนดค่า: แก้ไขสคริปต์การร้องขอใบรับรองอัตโนมัติหรือเอกสารประกอบใดๆ ที่เคยสันนิษฐานว่าจะมีทั้งสอง EKU
คำถามที่พบบ่อย (คำถามที่พบบ่อย)
คำถามที่ 1 EKU สำหรับ “การพิสูจน์ตัวตนไคลเอนต์” คืออะไร และเหตุใดจึงอยู่ในใบรับรองของฉัน
EKU "การตรวจสอบสิทธิ์ไคลเอนต์" ระบุว่าไคลเอนต์สามารถใช้ใบรับรองเพื่อยืนยันตัวตนกับเซิร์ฟเวอร์ได้ CA บางแห่งในอดีตรวมไว้ด้วย TLS ใบรับรองตามค่าเริ่มต้น แต่ไม่จำเป็นสำหรับการรักษาความปลอดภัยของเว็บไซต์ปกติ
คำถามที่ 2 เบราว์เซอร์จะปฏิเสธใบรับรองของฉันหรือไม่หากมี clientAuth EKU หลังจากวันที่ 15 กันยายน?
ไม่ เบราว์เซอร์จะไม่เริ่มปฏิเสธใบรับรองที่มีอยู่ซึ่งมี clientAuth EKU ทันที การเปลี่ยนแปลงนี้เกี่ยวข้องกับการออกใบรับรองใหม่
ไตรมาสที่ 3. ปัจจุบันของฉัน TLS ใบรับรองระบุว่า “การรับรองความถูกต้องของไคลเอนต์” ภายใต้การใช้งานคีย์ขยาย ใบรับรองนี้ไม่ถูกต้องอีกต่อไปหรือไม่
ไม่ มันยังคงใช้ได้ คุณไม่จำเป็นต้องเปลี่ยนทันที เมื่อคุณต่ออายุ ใบรับรองใหม่จะไม่รวม EKU ของ clientAuth
คำถามที่ 4 ฉันจะตรวจสอบได้อย่างไรว่าใบรับรองมี clientAuth EKU หรือไม่
คุณสามารถตรวจสอบรายละเอียดใบรับรองโดยใช้ OpenSSL, PowerShell หรือเครื่องมือ GUI เพื่อตรวจสอบ การใช้งานคีย์ขยาย การขยาย.
คำถามที่ 5 ระบบของเราต้องการให้ใบรับรองเซิร์ฟเวอร์มีทั้ง EKU ของ serverAuth และ clientAuth เราควรทำอย่างไร
คุณควรอัปเดตระบบของคุณเพื่อต้องการเพียง เซิร์ฟเวอร์Auth สำหรับใบรับรองเซิร์ฟเวอร์ หากจำเป็นต้องมีการตรวจสอบสิทธิ์ไคลเอนต์ ให้ขอรับใบรับรองแยกต่างหากด้วย ไคลเอนต์Auth EKU จาก SSL.com
คำถามที่ 6 ฉันยังสามารถรับใบรับรองที่เชื่อถือได้แบบสาธารณะโดยใช้ EKU ของการตรวจสอบสิทธิ์ไคลเอนต์เพียงอย่างเดียวได้หรือไม่
CA บางแห่ง เช่น SSL.com เสนอบริการเฉพาะ ใบรับรองการตรวจสอบสิทธิ์ไคลเอนต์ สิ่งเหล่านี้แยกจาก TLS ใบรับรองและโดยทั่วไปใช้สำหรับการตรวจสอบสิทธิ์ขององค์กร
คำถามที่ 7 การดำเนินการนี้ส่งผลต่อ EKU อื่น ๆ หรือประเภทใบรับรอง (เช่น การลงนามรหัส อีเมล ฯลฯ) หรือไม่
ไม่ การเปลี่ยนแปลงนี้เฉพาะเจาะจง TLS ใบรับรองเซิร์ฟเวอร์การลงนามรหัสและใบรับรองอีเมลมีข้อกำหนด EKU ของตัวเอง
คำถามที่ 8 เราใช้การตรวจสอบใบรับรองไคลเอ็นต์บนเว็บไซต์ของเรา การเปลี่ยนแปลงนี้จะส่งผลต่อสิ่งนั้นหรือไม่
ไม่ร่วมครับ TLS (mTLS) การตรวจสอบสิทธิ์ยังคงใช้งานได้ อย่างไรก็ตาม โปรดตรวจสอบให้แน่ใจว่าใบรับรองไคลเอนต์ที่ผู้ใช้นำเสนอยังคงมีอยู่ ไคลเอนต์Auth EKU ถ้าจำเป็น
คำถามที่ 9 การเปลี่ยนแปลงนี้เกี่ยวข้องกับการเปลี่ยนแปลงที่กำลังจะมีขึ้นในอนาคตเกี่ยวกับอายุการใช้งานใบรับรองที่สั้นลง (ใบรับรอง 90 วัน) หรือไม่
ไม่ สิ่งเหล่านี้เป็นการเปลี่ยนแปลงอุตสาหกรรมที่แยกจากกัน แม้ว่าทั้งสองอย่างจะมีจุดมุ่งหมายเพื่อปรับปรุงความปลอดภัยและแนวทางปฏิบัติในการจัดการใบรับรองก็ตาม
คำถามที่ 10 ฉันจะดูข้อกำหนดอย่างเป็นทางการเกี่ยวกับการเปลี่ยนแปลงนี้ได้ที่ไหน
การขอ นโยบายโปรแกรมรูทของ Google Chrome ให้แนวทางเกี่ยวกับการห้ามใช้ EKU ของไคลเอนต์Auth TLS ใบรับรองเซิร์ฟเวอร์
สรุป
การลบ clientAuth EKU ออกจาก TLS ใบรับรองเซิร์ฟเวอร์เป็นการเปลี่ยนแปลงนโยบายทั่วทั้งอุตสาหกรรมที่จะช่วยเพิ่มความปลอดภัยและป้องกันการใช้งานในทางที่ผิด สำหรับผู้ใช้ส่วนใหญ่ จะไม่มีผลกระทบที่เห็นได้ชัด อย่างไรก็ตาม หากคุณใช้ EKU ของ clientAuth คุณควรดำเนินการเชิงรุกเพื่อรับใบรับรองประเภทที่ถูกต้องสำหรับความต้องการของคุณ
หากคุณมีคำถามหรือต้องการความช่วยเหลือ โปรดติดต่อทีมสนับสนุนของเราได้ที่ สนับสนุน@ssl.com.
