เหตุใด GoDaddy จึงลบ ClientAuth EKU และการเปลี่ยนไปใช้ลำดับชั้นรูท R1 สำหรับการออก DV TLS

หมายเหตุ: หากคุณหรือลูกค้าพบข้อผิดพลาด "รูทที่ไม่น่าเชื่อถือ" หรือห่วงโซ่ใบรับรองโปรดดู ขั้นตอนการแก้ไขปัญหาของเรา

ตั้งแต่วันที่ 15 มิถุนายน 2026 ใบรับรอง SSL / TLS ที่เชื่อถือได้แบบสาธารณะที่ออกให้สำหรับการใช้งานเซิร์ฟเวอร์จะไม่ได้รับอนุญาตให้รวมการใช้งานคีย์แบบขยาย“ การตรวจสอบความถูกต้องของไคลเอ็นต์” (EKU: clientAuth) อีกต่อไป ประเด็นสำคัญที่ต้องทำความเข้าใจมีดังนี้

การเปลี่ยนแปลงนี้เป็นส่วนหนึ่งของการอัปเดตนโยบายโปรแกรมรากของ Chrome: ใบรับรองใหม่จะต้องมีเฉพาะ EKU“ การตรวจสอบความถูกต้องของเซิร์ฟเวอร์”
ใบรับรองสาธารณะใหม่ที่ออกให้หลังวันที่ซึ่งรวมถึง clientAuth จะไม่ได้รับความเชื่อถือจาก Chrome
ใบรับรองที่ออกให้กับ clientAuth ก่อนวันที่ 15 มิถุนายน 2026 จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงนี้และจะยังคงใช้ได้จนกว่าใบรับรองจะหมดอายุหรือถูกเพิกถอน
ใบรับรอง CA ส่วนตัว (สำหรับการใช้งานภายใน) จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงนี้ & mdash; จะใช้กับใบรับรองที่เชื่อถือได้แบบสาธารณะเท่านั้น

กล่าวโดยย่อ: หากองค์กรของคุณใช้ใบรับรอง TLS สาธารณะสำหรับการตรวจสอบความถูกต้องของไคลเอ็นต์ (ผ่าน ClientAuth EKU) คุณจะต้องดำเนินการ ก่อนวันที่ 15 มิถุนายน 2026 สำหรับการใช้งาน TLS ของเว็บไซต์มาตรฐาน (การตรวจสอบความถูกต้องของเซิร์ฟเวอร์เท่านั้น) การเปลี่ยนแปลงนี้ไม่จำเป็นต้องมีการดำเนินการ อย่างไรก็ตามคุณควรตรวจทานใบรับรองการใช้งานแยกฟังก์ชันอย่างเหมาะสมและทำให้แน่ใจว่าคุณสอดคล้องกับรูปแบบความไว้วางใจที่กำลังพัฒนาอยู่

GoDaddy จะดำเนินการเปลี่ยนแปลงนี้อย่างไร

ตัวกลางการลงชื่อ / การออก G2 ปัจจุบันของเราไม่มี EKU อยู่ในรายการซึ่งทำให้ลำดับชั้นดังกล่าวไม่เป็นไปตามข้อกำหนดของโปรแกรมรากของ Chrome ด้วยเหตุนี้การออกจากตัวกลาง G2 จะต้องหยุดลงก่อนวันที่ดังกล่าว

แทนที่จะสร้างตัวกลางการออกใหม่บนห่วงโซ่ G2 & mdash; ซึ่งมีแผนจะหมดอายุ / สิ้นสุดโดย Google ในเดือนเมษายน 2027 & mdash; เรากำลังย้ายการออก DV ไปยังลำดับชั้น R1 ใหม่ของเราเพื่อให้เป็นไปตามข้อ จำกัด ของนโยบายต่อไป

เรากำลังเปลี่ยนสายการออก DV สาธารณะเพื่อให้ออกใบรับรองใบ DV ใหม่จากลำดับชั้นของ TLS Root CA - R1 ของ GoDaddy โดยใช้ GoDaddy TLS Intermediate CA DV - R1v1 ที่ออกใบรับรอง CA godaddy.com ซึ่งหมายความว่าห่วงโซ่ผู้ออกที่นำเสนอโดยเซิร์ฟเวอร์ (leaf + ระดับกลาง) อาจแตกต่างจากที่บางระบบเคยเห็นในอดีตและเครื่องมือภายในใด ๆ ที่สันนิษฐานว่าต้องมีการอัพเดตชื่อของกลางหรือลำดับโซ่เดิมที่เฉพาะเจาะจงเพื่อยอมรับห่วงโซ่ R1 ใหม่

นอกจากนี้ Leaf Certificate ที่ออกจากลำดับชั้นนี้จะไม่มี ClientAuth EKU เวิร์กโฟลว์ใด ๆ ที่ใช้ใบรับรองใบ DV ที่สามารถใช้งานได้สำหรับการตรวจสอบความถูกต้องไคลเอ็นต์ TLS จะต้องย้ายไปยังโปรไฟล์ใบรับรอง / เส้นทาง PKI ที่เหมาะสม ในระหว่างการเปิดตัวใบรับรองจะยังคงใช้งานได้ในเบราว์เซอร์เนื่องจากไคลเอ็นต์ทำการตรวจสอบความถูกต้องโดยใช้เส้นทางความน่าเชื่อถือแบบข้ามลงนาม R1 → G2 ที่เผยแพร่ในที่เก็บของเรา (Certs.godaddy.com)

วิธีที่ใบรับรองยังคงใช้งานเบราว์เซอร์ในระหว่างการเปลี่ยนผ่าน R1 (เครื่องหมายกากบาท R1 → G2)

ในขณะที่เราย้ายการออก DV TLS แบบสาธารณะไปยังลำดับชั้น R1 รูท R1 ยังคงอยู่ในขั้นตอนของการได้รับความเชื่อถือ / เผยแพร่ในวงกว้างในเบราว์เซอร์และ OS Trust Store เพื่อให้แน่ใจว่าใบรับรอง R1 ที่ออกใหม่จะทำงานในเบราว์เซอร์ทันทีเราใช้เส้นทางความน่าเชื่อถือแบบ Cross-Signed กลับไปยังรูท G2 ที่เชื่อถือได้อยู่แล้ว

ในทางปฏิบัติใบรับรอง Leaf จะออกภายใต้ CA ที่ออก R1 DV แต่ไคลเอ็นต์จะตรวจสอบความถูกต้องโดยสร้าง chain ไปยัง GoDaddy Class 2 Root - G2 โดยใช้ Cross Certificate R1 → G2 ที่เผยแพร่แล้ว อาร์ติแฟกต์ที่เกี่ยวข้องในที่เก็บ ได้แก่ G2 Trust Anchor (gdroot-g2), เครื่องหมายรับรองข้าม (gd_tls_root-r1-cross-g2), ตัวกลางการออก R1 DV (gd_tls_issuing_dv-r1v1) และรากลำดับชั้นดั้งเดิม (gd_tls_root-r1) ) Certs.godaddy.com วิธีการข้ามเครื่องหมายนี้ช่วยให้เบราว์เซอร์ตรวจสอบความถูกต้องของห่วงโซ่ได้ในปัจจุบัน (ทอดสมอที่ G2) ในขณะที่ความไว้วางใจ R1 แพร่กระจายเมื่อเวลาผ่านไป
r1 - เส้นทางเครื่องหมายกากบาท g2

ทำไมจึงมีการเปลี่ยนแปลงนี้

มีสาเหตุหลายประการในการย้ายออกจากใบรับรองที่สนับสนุนทั้ง serverAuth และ ClientAuth (หรือที่เรียกว่าใบรับรองแบบผสม):

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

การเปลี่ยนแปลงนี้มีประโยชน์อย่างไร

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

ใครบ้างที่ไม่ได้รับผลกระทบ

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

ใครได้รับผลกระทบ

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

สิ่งที่คุณต้องทำ

หากคุณได้รับการโฮสต์นอก GoDaddy : ตรวจสอบให้แน่ใจว่ามีการติดตั้งกลุ่มแบบเต็มที่ได้รับจากปลายทางการดาวน์โหลดหรืออินเทอร์เฟซลูกค้าเมื่ออัพเดตใบรับรองครั้งต่อไป
หากคุณใช้ใบรับรองในกรณีการใช้งานใด ๆ ที่ขึ้นอยู่กับ ClientAuth (mTLS) : ตรวจสอบให้แน่ใจว่าคุณได้โอนย้ายเวิร์กโฟลว์เหล่านั้นเพื่อใช้ใบรับรองที่ลงนามด้วยตนเองหรือโซลูชัน CA ส่วนตัว

นอกจากนี้ทีมควรยืนยันว่าไม่มีคุณลักษณะภายในหรือเอกสารประกอบที่ถือว่าใบรับรองใบ DV รวมถึง ClientAuth EKU เนื่องจากใบรับรอง Leaf ที่ออกโดย R1 จะไม่ รวมไว้ด้วย

นี่หมายความว่าใบรับรองทั้งหมดที่ออกหลังจากวันที่ 15 มิถุนายน 2026 จะไม่ถูกต้องหรือไม่

ไม่ใบรับรองที่ออกก่อนวันที่ 15 มิถุนายน 2026 ซึ่งรวมถึง ClientAuth จะยังคงถูกต้อง (จนกว่าจะหมดอายุ) ภายใต้รูปแบบความไว้วางใจที่มีอยู่ การเปลี่ยนแปลงจะมีผลกับใบรับรองสาธารณะใหม่ที่ออกในหรือหลังจากวันดังกล่าวเท่านั้น

หากฉันใช้ใบรับรองสำหรับ HTTPS ของเว็บไซต์ทั่วไปเท่านั้น (การตรวจสอบความถูกต้องของเซิร์ฟเวอร์) ฉันต้องทำอะไรหรือไม่

หากโฮสติ้งของคุณอยู่นอก GoDaddy คุณยังต้องตรวจสอบให้แน่ใจว่ามีการใช้งานกลุ่มอย่างถูกต้อง

“ การรับรองความถูกต้องของไคลเอ็นต์” ในบริบทนี้คืออะไร

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

ฉันยังสามารถใช้ใบรับรอง ClientAuth ได้เลยหรือไม่

ใช่ & mdash; แต่เพื่อความไว้วางใจแบบสาธารณะคุณจะต้องใช้ใบรับรองที่ออกให้สำหรับการตรวจสอบความถูกต้องของไคลเอ็นต์โดยเฉพาะ (นั่นคือ EKU ของไคลเอ็นต์เฉพาะ) หรือใช้ CA ส่วนตัวสำหรับระบบภายในของคุณ ใบรับรองเซิร์ฟเวอร์สาธารณะที่มี EKU ของไคลเอ็นต์จะไม่ได้รับการเชื่อถือใน Chrome อีกต่อไปหากออกหลังจากวันที่ 15 มิถุนายน 2026

เบราว์เซอร์อื่นจะบังคับใช้การเปลี่ยนแปลงนี้หรือเพียงแค่ Chrome

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

สิ่งนี้ใช้กับใบรับรอง CA ภายใน / ส่วนตัวหรือไม่

ไม่ & mdash; การเปลี่ยนแปลงจะมีผลต่อใบรับรอง SSL / TLS แบบสาธารณะที่เชื่อถือได้เท่านั้น (ที่เชื่อถือได้โดยร้านค้ารูทสาธารณะ) โครงสร้างพื้นฐาน CA ส่วนตัวที่ใช้สำหรับการตรวจสอบความถูกต้องภายในไคลเอ็นต์จะไม่ได้รับผลกระทบโดยตรง

เมื่อใดที่เราต้องเตรียมพร้อมสำหรับการเปลี่ยนแปลงนี้

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

ข้อมูลเพิ่มเติม

ตั้งค่าและติดตั้ง SSL Certificate ของฉัน
หากคุณหรือลูกค้าเห็นข้อผิดพลาด "รูทที่ไม่น่าเชื่อถือ" หรือห่วงโซ่ใบรับรองโปรดดู ขั้นตอนการแก้ไขปัญหาของเรา

เครื่องหมายรับรอง SSL วิธีใช้