eMudhra ระดับกลาง การประนีประนอม CA: ผลกระทบและคำแนะนำในการแก้ไข

แหล่งที่มา ตรวจสอบเมื่อวันที่ 22 ตุลาคม 2026 ตามเวลาปักกิ่ง Audience: ผู้ใช้แต่ละราย ผู้ดำเนินการเว็บไซต์ นักพัฒนา และผู้ดูแลระบบ

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

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

TL;DR

คีย์ส่วนตัว Eight ระดับกลาง CA ได้รับการยืนยันว่าถูกบุกรุก รายงานปัจจุบันไม่ได้ระบุว่ารูทไพรเวตคีย์หรือการเข้ารหัส HTTPS โดยทั่วไปใช้งานไม่ได้ การอัปเดตครอบคลุมระบบนิเวศความน่าเชื่อถือของสาธารณะเป็นส่วนใหญ่ ความเสี่ยงคงเหลือขึ้นอยู่กับการใช้งานจริง15

1. ผู้ใช้ Individual: อัปเดตเบราว์เซอร์ ระบบปฏิบัติการ และส่วนประกอบด้านความปลอดภัย บน Android ให้อัพเดตบริการ Google Play ด้วย ใช้ Firefox Android 158.0.2 หรือใหม่กว่า 12
2. Servers: อัปเดตแพ็คเกจ ca-certificates/NSS ของการแจกจ่าย และตรวจสอบร้านค้าที่เชื่อถือได้ที่รวมแอปพลิเคชัน การอัปเดตเฉพาะโฮสต์ไม่เพียงพอ 7810
3. Development สภาพแวดล้อม: อัปเดต Node 24 เป็น 24.22.1 หรือรีลีสที่ใหม่กว่าในสาขานั้นตามความเหมาะสม ในสภาพแวดล้อม Python ให้อัพเดตเป็นอย่างน้อย pip 26.2.2, certifi 2026.10.19 และ uv 0.13.4 รับไบนารี Go คงที่หรือสร้างใหม่ อัปเดต Java ตามคำแนะนำของผู้จำหน่าย 12–15
4. เปิดใช้งานการอัปเดต: รีสตาร์ทบริการที่ได้รับผลกระทบและสร้างใหม่และปรับใช้คอนเทนเนอร์อีกครั้ง สำหรับ Cloudflare Tunnel ให้อัพเดต cloudflared เป็น 2026.10.2 หรือใหม่กว่า 7
5. ใบรับรองเว็บไซต์ : แทนที่เชนที่ได้รับผลกระทบ หากมี CA ระดับกลางที่ถูกเพิกถอนหรือบล็อก หรืออาศัยรูทที่ไม่น่าเชื่อถือ การออกใบรับรองใหม่ไม่ได้แทนที่การอัปเดตร้านค้าที่เชื่อถือได้ของไคลเอ็นต์ 158
6. Verification: ทดสอบเส้นทาง TLS จริงของแต่ละแอปพลิเคชัน แยกความแตกต่างการปฏิเสธใบรับรองจากการหมดเวลาและความล้มเหลวของ DNS เปิดใช้งานการตรวจสอบใบรับรองต่อไป อย่าใช้ -k หรือข้ามการตรวจสอบเพื่อระงับข้อผิดพลาด 7

1 ข้อเท็จจริงและสาเหตุของเหตุการณ์

ข้อเท็จจริงที่ยืนยันแล้ว

Mozilla และ Google ได้รับการยืนยันข้อบกพร่องในคีย์ส่วนตัว eMudhra ระดับกลาง CA แปดตัว ผู้วิจัยได้จัดเตรียมหลักฐานการควบคุมคีย์ส่วนตัว Mozilla กู้คืนคีย์อย่างอิสระและทำให้เกิดปัญหาซ้ำ CA ระดับกลาง 6 แห่งให้บริการ TLS และ 2 บริการลงนามโค้ด 25

ข้อบกพร่องอยู่ที่คีย์ที่สร้างขึ้น: CA ระดับกลางเหล่านี้ใช้เส้นโค้ง P-384 แต่คีย์ส่วนตัวเป็นจำนวนเต็มต่ำกว่า 256 ซึ่งยังห่างไกลจากการเลือกคีย์อย่างปลอดภัยโดยการสุ่มจากช่วงขนาดใหญ่ที่ต้องการ การกู้คืนคีย์ที่อ่อนแอเหล่านี้ไม่ได้แสดงให้เห็นว่าคีย์ P-384 ที่สร้างขึ้นอย่างถูกต้องสามารถใช้งานไม่ได้ 2

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

ปัญหากระบวนการสร้างคีย์ยังอยู่ระหว่างการตรวจสอบ

คำอธิบายเบื้องต้นของ eMudhra ติดตามปัญหาไปจนถึงพิธีสร้างคีย์ในเดือนเมษายน 2025 คำอธิบายเกี่ยวข้องกับขั้นตอนการห่อหุ้มคีย์และการแยกแคปซูล: นอกเหนือจากคีย์ที่รัดกุมดั้งเดิมแล้ว ยังมีชุดคีย์ที่อ่อนแออีกชุดหนึ่งปรากฏขึ้น และคีย์ที่อ่อนแอจะถูกนำมาใช้ในการขอใบรับรองและการออกใบรับรองในภายหลัง บริษัทยังคงกล่าวว่าสาเหตุที่แท้จริงยังไม่ได้รับการพิจารณาอย่างแน่ชัด 6

ดังนั้นสิ่งที่สามารถระบุได้ก็คือคีย์เหล่านี้อ่อนแอมากและถูกบุกรุก ความล้มเหลวนี้ไม่สามารถอธิบายเพิ่มเติมได้เนื่องจากแหล่งที่มาของตัวเลขสุ่มฮาร์ดแวร์บางตัวของ HSM ได้รับการพิสูจน์แล้วว่ามีข้อบกพร่อง และไม่สามารถอธิบายได้ว่าเป็นการพัฒนาด้านการเข้ารหัสทั่วไปของ RSA, ECC หรือ TLS

ความไม่ไว้วางใจใบรับรองหลักหมายถึงอะไร

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

Google ได้กำหนดเวลาการลบ emSign ECC Root CA - G3 เพื่อปกป้องผู้ใช้ของที่เก็บราก Chrome ที่ไม่ได้รับการอัปเดตจาก CRLSet คาดว่าการถอดรูทสโตร์จะถูกผลักดันในช่วงเวลาที่เกี่ยวข้องตั้งแต่วันที่ 27 ถึง 28 ตุลาคม ตามเวลาปักกิ่ง เวลาเดิมของ Google คือเช้าวันที่ 27 ตุลาคม ตามเวลาแปซิฟิกของสหรัฐอเมริกา แผนนี้แยกจากการบล็อกคีย์สาธารณะฉุกเฉินที่เคยใช้งานก่อนหน้านี้ 1

การไม่ไว้วางใจรูทเป็นการวัดการตอบสนอง มันไม่ได้พิสูจน์ตัวเองว่าคีย์ส่วนตัวรูทถูกบุกรุก

2 เหตุใดผลกระทบที่อาจเกิดขึ้นจึงครอบคลุมระบบนิเวศความไว้วางใจของสาธารณะ

คีย์ที่ถูกบุกรุกและเส้นทางความไว้วางใจที่ได้รับผลกระทบ

วัตถุพิพากษา	ขอบเขตของเหตุการณ์นี้
ระบุคีย์ที่มีปัญหา	คีย์ส่วนตัว CA ระดับกลาง 8 อันสำหรับ eMudhra
แพลตฟอร์มที่อาจต้องมีการดำเนินการ	ที่เก็บรูทสาธารณะ เบราว์เซอร์ ระบบปฏิบัติการ รันไทม์ภาษา ชุดซอฟต์แวร์ และระบบนิเวศของคอนเทนเนอร์
ข้อมูลประจำตัวที่อาจถูกแอบอ้าง TLS	เว็บไซต์หรือบริการที่ลูกค้าเยี่ยมชมซึ่งยังคงยอมรับกลุ่มใบรับรองปลอมที่เกี่ยวข้อง
หมายความว่าอุปกรณ์ทั้งหมดถูกบุกรุกหรือไม่?	ไม่; เงื่อนไขความน่าเชื่อถือ ที่ตั้งเครือข่ายของผู้โจมตี และกลยุทธ์การตรวจสอบอื่นๆ จะเป็นตัวกำหนดความสามารถในการใช้ประโยชน์
หมายความว่าใบรับรองทางกฎหมายทั้งหมดไม่ถูกต้องใช่หรือไม่	ไม่; การทำให้ใช้งานไม่ได้ที่เกี่ยวข้องนั้นขึ้นอยู่กับรากหรือกลุ่มใบรับรองที่ไคลเอนต์ไม่น่าเชื่อถือ

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

เว็บไซต์ที่ใช้ CA อื่นอาจถูกแอบอ้างเช่นกัน

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

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

ผลกระทบทั้งสามจะต้องได้รับการจัดการแยกกัน

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

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

Deploymentครอบคลุมความเสี่ยง: ระบบปฏิบัติการอาจได้รับการแก้ไขในขณะที่ trust store ที่รวมแอปพลิเคชัน สภาพแวดล้อมเสมือน คอนเทนเนอร์อิมเมจเก่า หรือโปรแกรมที่คอมไพล์ยังคงลักษณะการตรวจสอบความถูกต้องแบบเก่า

ขอบเขตทั้งสามนี้ไม่เหมือนกัน การตอบสนองของ Cloudflare ครอบคลุมถึงการตรวจสอบตัวตนระยะไกล, trust stores ที่แชร์, อิมเมจพื้นฐาน และแอปพลิเคชันแต่ละรายการ ซึ่งแสดงให้เห็นว่าเหตุใดสองงานหลังจึงต้องจัดการแยกกัน 7

3 CA และผู้ให้บริการใบรับรองที่ได้รับผลกระทบ

ผู้ให้บริการและประเภทผลกระทบ

ผู้ให้บริการหรือระบบ	บทบาทในเหตุการณ์ครั้งนี้	ขอบเขตที่ต้องแยกแยะ
eMudhra／emSign	คีย์ส่วนตัวระดับกลาง CA ถูกทำลายโดยตรง	คุณไม่สามารถเขียนรากของ eMudhra ทั้งหมดและใบรับรองทั้งหมดเป็นแคร็กได้
Sectigo โซ่ข้ามลายเซ็นที่เกี่ยวข้อง	มีการออกใบรับรองข้าม A สำหรับคีย์สาธารณะที่ได้รับผลกระทบชุดเดียวกัน ซึ่งสร้างเส้นทางที่เชื่อถือได้อื่น	จำเป็นต้องบล็อกใบรับรองข้ามหรือคีย์สาธารณะที่เกี่ยวข้อง คีย์ส่วนตัวรูท Sectigo ยังไม่ได้รับการพิสูจน์ว่าถูกบุกรุก
ระดับใบรับรองที่เกี่ยวข้องสำหรับ Internet2/InCommon	ใบรับรองที่ถูกต้องตามกฎหมายบางใบรับรองต้องใช้รูท emSign ECC ที่จะลบออก ซึ่งเกี่ยวข้องกับการย้ายข้อมูล	มันเป็นผลกระทบที่เป็นหลักประกันของความไม่ไว้วางใจรูทและไม่สามารถนับได้ว่าเป็นจุดกึ่งกลางของคีย์ที่อ่อนแอ 8 คีย์นั้น CA
Let’s Encrypt, DigiCert, Google Trust Services, GlobalSign ฯลฯ	ไม่อยู่ในรายชื่อบุคคลที่คีย์ส่วนตัวถูกบุกรุกในรายงานนี้	ใบรับรองที่ถูกต้องตามกฎหมายจะไม่เป็นโมฆะอย่างสม่ำเสมอ ลูกค้าที่มีช่องโหว่อาจยังคงยอมรับใบรับรองปลอมที่แอบอ้างเป็นเว็บไซต์ที่พวกเขาให้บริการ
CDN แพลตฟอร์มคลาวด์ ตัวแทนจำหน่ายใบรับรอง	อาจจัดเตรียมใบรับรองที่เกี่ยวข้องหรือใช้ร้านค้าที่เชื่อถือได้สาธารณะเมื่อเชื่อมต่อกับต้นทางและ API	หากต้องการตรวจสอบสายใบรับรองและเครื่องมือตรวจสอบความถูกต้อง อย่าเพิ่งดูที่แพลตฟอร์มหรือชื่อผลิตภัณฑ์

ประกาศของ Mozilla บันทึกคีย์ที่ถูกบุกรุกและลายเซ็นข้าม Sectigo การอภิปรายเกี่ยวกับเหตุการณ์สาธารณะของ Google กล่าวถึงการย้ายลำดับชั้น Internet2/InCommon ที่ถูกต้องตามกฎหมาย บริการแก้ไขที่อยู่ของ 25 Cloudflare และความไว้วางใจของลูกค้า พวกเขาไม่ได้บ่งบอกถึงการประนีประนอมของคีย์ส่วนตัว Cloudflare ของ CA 7

สายใบรับรอง TLS และลายเซ็นข้าม

ความสัมพันธ์ต่อไปนี้จะอธิบายเฉพาะพาธที่เกี่ยวข้องกับ TLS ในครั้งนี้เท่านั้น ไม่รวมเส้นทางการลงนามโค้ด และไม่ได้หมายความว่าเส้นทางเหล่านี้ยังคงเชื่อถือได้บนทุกแพลตฟอร์ม 17

emSign Root TLS CA - G3 เป็นผู้ออกโดยตรงรายหนึ่งของตัวกลาง TLS ที่ได้รับผลกระทบ และตัวมันเองสามารถเป็น Trust Anchor ในร้านค้าบางแห่งได้ emSign ECC Root CA - G3 มีเลเยอร์การลงนามข้ามอีกชั้นหนึ่ง AAA Certificate Services ของ Sectigo สร้างเส้นทางเพิ่มเติมไปยังคีย์สาธารณะ CA ระดับกลางเดียวกัน 17

ดังนั้นจึงมีสองรายละเอียดที่แตกต่างกันเมื่อทำการซ่อม:

• Block CA ระดับกลางหรือคีย์สาธารณะ: ซึ่งสามารถรักษาลำดับชั้นที่ถูกต้องตามกฎหมายอื่นๆ ภายใต้รูทเดียวกัน โดยที่เครื่องมือตรวจสอบความถูกต้องสนับสนุนกลไกนั้น
• Remove root trust: ซึ่งสามารถปกป้องไคลเอ็นต์โดยไม่มีความสามารถในการบล็อก CA ระดับกลาง แต่อาจส่งผลต่อความเข้ากันได้ เส้นทางอื่นๆ ทั้งหมดที่ลูกค้ายอมรับจะต้องครอบคลุมด้วย 5

“ลบราก Sectigo/eMudhra ทั้งหมด” ไม่ควรถือเป็นขั้นตอนทั่วไปที่ไม่เลือกปฏิบัติ และไม่ควรลบใบรับรองที่มีชื่อคล้ายกันเท่านั้น หมายความว่าเส้นทางทั้งหมดถูกปิด

4 ระบบปฏิบัติการและเบราว์เซอร์ครอบคลุม

แพลตฟอร์มหลัก

แพลตฟอร์ม	นิสัยที่รู้จัก	ขอบเขตที่ควรตรวจสอบเมื่อใช้งาน
Windows และ Windows Server	การแจกจ่าย Microsoft ถูกบล็อกผ่านการอัปเดตรายการความน่าเชื่อถือของใบรับรองอัตโนมัติ	ไม่ว่าอุปกรณ์จะได้รับการอัปเดตหรือไม่ CA bundle แบบสแตนด์อโลนไม่จำเป็นต้องใช้เส้นทางการตรวจสอบของ Windows
macOS, iOS, iPadOS ฯลฯ แพลตฟอร์ม Apple	ผู้ประสานงานเหตุการณ์ยืนยันว่า Apple ได้ปรับใช้การปิดล้อมที่เกี่ยวข้องแล้ว	ไม่รับประกันว่าทุกเวอร์ชันเก่าและแอปของบุคคลที่สามจะได้รับความคุ้มครองเท่ากัน
Android	Google กระจายบล็อกที่เทียบเท่าผ่านบริการ Google Play	ROM ที่ไม่มีบริการ Google Play ควรได้รับการตรวจสอบตามประกาศของผู้ผลิต ใช้ตัวตรวจสอบในตัวสำหรับการตรวจสอบเพิ่มเติม
Ubuntu	มีการแก้ไขชุดใบรับรองระบบ รวมถึงเวอร์ชันปัจจุบันและเวอร์ชันเก่าหลายเวอร์ชัน	ESM เวอร์ชันเก่ารองรับเงื่อนไข แพคเกจใบรับรองภายในคอนเทนเนอร์ และไลบรารีในตัวของแอปพลิเคชัน
Debian และ Devuan	Debian บันทึก ca-certificates แล้ว	คุณต้องตรวจสอบสาขาจริงที่ใช้และแพ็คเกจที่ติดตั้ง และคุณไม่สามารถคัดลอกหมายเลขเวอร์ชันของสาขาอื่นได้
RHEL และอนุพันธ์	รายชื่ออย่างเป็นทางการคือ RHEL 6, 7, 8, 9, 10 และครอบคลุมผลิตภัณฑ์และรูปภาพที่เกี่ยวข้องซึ่งอาจได้รับผลกระทบ	จากการตรวจสอบนี้ ประกาศยังไม่ได้แสดงรายการการแก้ไขและข้อผิดพลาดทั้งหมด “ไม่พบการอัปเดต” ไม่สามารถถือว่าไม่ได้รับผลกระทบ
Fedora, Arch, Gentoo, Alpine ฯลฯ	ผู้ดูแลเหตุการณ์ได้รวบรวมบันทึกการซ่อมแซมที่เกี่ยวข้อง	ยืนยันอย่างเป็นอิสระจากการเปิดตัว สาขาเวอร์ชัน และรูปภาพ
FreeBSD	แสดงรายการเวอร์ชันที่รองรับทั้งหมดอย่างเป็นทางการ และจัดให้มีการซ่อมแซมร้านค้าที่เชื่อถือได้ของระบบ	หลังจากการอัพเดต ให้รีสตาร์ทกระบวนการ daemon ที่เกี่ยวข้องตามประกาศ ตรวจสอบร้านค้าที่เชื่อถือได้ของแอปพลิเคชันอิสระแยกต่างหาก

สำหรับข้อมูลสรุปของ Windows, Apple และรีลีส โปรดดูที่ 4 สำหรับ Android ดูที่ 1; สำหรับ Ubuntu, Debian, RHEL และ FreeBSD บันทึกของผู้ออกจะแสดงใน 8–11 ตามลำดับ

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

การป้องกันเบราว์เซอร์แตกต่างจากการป้องกันระบบปฏิบัติการ

Chrome ใช้ CRLSet เพื่อกระจายบล็อกฉุกเฉิน Firefox ใช้กลไก เช่น OneCRL Firefox ได้รับการเผยแพร่พร้อมข้อมูลการบล็อกเพื่อให้การป้องกันเพิ่มเติมสำหรับการกำหนดค่าที่ไม่ได้รับการตั้งค่าระยะไกลอย่างเหมาะสม 13

การกำหนดค่าบางอย่างของ Firefox Android ไม่ได้ใช้รายการที่อัปเดตอย่างถูกต้องเมื่อเริ่มต้นระบบ ซึ่ง Mozilla ระบุว่าจะได้รับการแก้ไขโดย 158.0.2. ดังนั้น สถานะของ 158.0.1 รุ่นแรกๆ จึงไม่สามารถขยายให้รวมการกำหนดค่า Android Firefox ทั้งหมดที่ได้รับการป้องกันได้ 2

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

ขอบเขตการป้องกันเพื่อความโปร่งใสของใบรับรอง

Google ยืนยันว่าก่อนที่จะใช้งานบล็อก TLS ตัวกลาง CA หกตัวไม่ได้ออกใบรับรอง TLS ที่ป้อนบันทึก CT ดังนั้นไคลเอ็นต์ Chrome ที่บังคับใช้ CT จึงมีการป้องกันเพิ่มเติม ข้อเท็จจริงนี้ไม่ได้ตัดความเป็นไปได้ที่ไคลเอ็นต์อื่นที่ไม่ได้เรียกใช้งาน CT ได้ยอมรับใบรับรองที่ไม่มีเอกสาร 15

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

5 สภาพแวดล้อมการพัฒนาและพื้นฐานการซ่อมแซมรันไทม์

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

ส่วนประกอบ	เวอร์ชันที่ยืนยันหรือวิธีการอัพเดต	ข้อควรพิจารณาในการปรับใช้
Node.js 24	24.22.1 หรืออัปเดตเวอร์ชันเสถียรของสาขาเดียวกัน	ประกอบด้วยการอัปเดตที่เก็บรูทและการปฏิเสธพวงกุญแจสาธารณะที่ถูกบล็อก ตรวจสอบเส้นทาง Node ที่บริการใช้จริงและรีสตาร์ท
Python certifi	2026.10.19 หรือเวอร์ชันที่ใหม่กว่า	ตรวจสอบสภาพแวดล้อมการทำงานจริงแต่ละรายการ คุณไม่สามารถอัปเดตแพ็คเกจเดียวภายใต้ Python ส่วนกลางได้
pip	26.2.2 หรือเวอร์ชันที่ใหม่กว่า	อัปเดต pip แยกกันในสภาพแวดล้อมเสมือนเก่า และตรวจสอบเวอร์ชันหลังจากสร้างสภาพแวดล้อมใหม่แล้ว
uv	0.13.4 หรือเวอร์ชันที่ใหม่กว่า	อัปเดตสำเนาของเครื่องมือตามที่ติดตั้งจริง
Go	1.27.3 หรือ 1.26.10 ซึ่งเป็นเวอร์ชันอัปเดตของสาขาที่เกี่ยวข้องก็มีให้ใช้งานเช่นกัน	สร้างและปรับใช้โปรแกรมที่เกี่ยวข้องหลังจากอัปเดตห่วงโซ่เครื่องมือ หรือรับไบนารีการซ่อมแซมของผู้จำหน่าย
Oracle JDK	แพทช์ Critical สำหรับบรรทัดเวอร์ชันที่รองรับที่สอดคล้องกัน	ผู้เผยแพร่ JDK ต่างๆ ติดตามประกาศของตนเอง ไม่มีหมายเลขเวอร์ชันเดียวที่ใช้กับรุ่น Java ทั้งหมด
Cloudflare Tunnel	cloudflared 2026.10.2 หรือเวอร์ชันที่ใหม่กว่า	อัปเดตบริการที่ทำงานอยู่ การใช้งานคอนเทนเนอร์จำเป็นต้องเปลี่ยนอิมเมจและปรับใช้ใหม่
Cloudflare One／WARP	เวอร์ชันไคลเอ็นต์คงที่ซึ่งสอดคล้องกับแพลตฟอร์มหรือเวอร์ชันเสถียรที่อัปเดต	การวัดผลฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ได้รับการยืนยันแยกกัน สำหรับเวอร์ชันแพลตฟอร์มเฉพาะ โปรดดูภาคผนวก 7

คำแนะนำดั้งเดิมสำหรับ Node, Python, Go, Oracle และ Cloudflare มีอยู่ใน 13, 12, 14, 15, 7 ตามลำดับ

ปัญหาฐานข้อมูลใบรับรองอิสระ Python

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

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

Go และโปรแกรมคอมไพล์อื่นๆ

การแก้ไขสำหรับ Go ได้เปลี่ยนตรรกะการตรวจสอบสำหรับ crypto/x509 14 จากมุมมองของกลไกการปรับใช้ การอัพเดตคอมไพลเลอร์บนเครื่องพัฒนาจะไม่เขียนไบนารี่ที่ใช้งานอยู่แล้วใหม่ หากต้องการได้รับการบล็อกเลเยอร์โค้ดใหม่ ควรสร้างแอปพลิเคชันใหม่และเปลี่ยนใหม่ หรือควรใช้เวอร์ชันอัปเดตที่ผู้จำหน่ายจัดเตรียมไว้ให้ โปรแกรมรุ่นเก่าจะได้รับประโยชน์จากการอัปเดตรูทระบบหรือไม่นั้นขึ้นอยู่กับเส้นทางการตรวจสอบจริงที่ใช้

ภาชนะบรรจุและการใช้งานบรรจุภัณฑ์

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

6 คำแนะนำในการดำเนินการซ่อมแซม

กำหนดวัตถุตรวจสอบก่อน

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

โครงการ	สิ่งที่ต้องมีการบันทึก
การใช้งานและการใช้งาน	เบราว์เซอร์, ไคลเอนต์การชำระเงิน API, บริการส่งอีเมล, เครื่องมือดาวน์โหลด, Reverse Proxy ฯลฯ
ตำแหน่งปฏิบัติการ	โฮสต์ คอนเทนเนอร์ เครื่องเสมือน แอปพลิเคชันเดสก์ท็อป หรืออุปกรณ์เคลื่อนที่
ตรวจสอบการใช้งาน	เครื่องมือตรวจสอบระบบปฏิบัติการ, OpenSSL, Node, ไลบรารี Python, Java หรือการใช้งานแบบกำหนดเองของแอปพลิเคชัน
แหล่งที่เชื่อถือได้	แพ็คเกจระบบ CA, certifi, ร้านค้าที่เชื่อถือได้ JDK, CA bundle ในตัวหรือการกำหนดค่าระดับองค์กร
สถานะการซ่อม	เวอร์ชันที่ติดตั้ง แหล่งแพตช์ ไม่ว่าจะรีสตาร์ทหรือปรับใช้ใหม่
ผลการยอมรับ	ไม่ว่าเชนที่ได้รับผลกระทบจะถูกปฏิเสธ การเชื่อมต่อทางธุรกิจตามปกติจะสำเร็จหรือไม่ และเวลาตรวจสอบ

คู่มือนักพัฒนาสำหรับ Cloudflare ระบุไว้โดยเฉพาะว่า SDK อาจมอบหมายการตรวจสอบให้กับส่วนประกอบอื่นๆ การอัปเดตเฉพาะ SDK ระดับบนสุดเท่านั้นที่ไม่จำเป็นต้องเปลี่ยนนโยบายความน่าเชื่อถือที่แท้จริง 7

ระบบปฏิบัติการและเบราว์เซอร์

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

แพลตฟอร์ม Apple: อัปเดตระบบ ส่วนประกอบด้านความปลอดภัย และแอปพลิเคชันให้เสร็จสมบูรณ์ สำหรับเครื่องมือการพัฒนาบน macOS ให้ตรวจสอบแบ็คเอนด์ TLS ไฟล์ใบรับรอง และแหล่งที่มาของการติดตั้งด้วย ไม่สามารถตัดสินได้ว่าเครื่องทั้งหมดได้รับการซ่อมแซมเพียงเพราะ Safari ปฏิเสธห่วงโซ่การทดสอบ 4

Android: อัปเดตบริการ Google Play บนอุปกรณ์ที่มี Google ระบุว่าการรีสตาร์ทอุปกรณ์สามารถกระตุ้นการอัปเดตได้ทันที สำหรับอุปกรณ์ที่ไม่มีบริการเหล่านั้น ให้ปฏิบัติตามผู้จำหน่ายหรือคำแนะนำของ ROM คำชี้แจงความครอบคลุมของ Google ไม่สามารถใช้ได้กับอุปกรณ์ Android ทุกเครื่องโดยอัตโนมัติ 1

Ubuntu/Debian: อัปเดตแพ็คเกจใบรับรองจากที่เก็บที่รองรับ และตรวจสอบคำแนะนำสำหรับการแจกจ่ายที่ติดตั้ง ตัวอย่างเช่น ระบบที่ใช้ APT สามารถใช้:

sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificates

การอัปเดตที่เกี่ยวข้องสำหรับ Ubuntu 22.04, 24.04, 26.04 และ 26.10 เป็นการสนับสนุนมาตรฐาน เวอร์ชันก่อนหน้าควรตรวจสอบการสนับสนุน ESM และสถานะคลังสินค้า หลังจากที่คำสั่งสิ้นสุดสำเร็จแล้ว คุณยังควรเปรียบเทียบเวอร์ชันฟิกซ์แพ็กในกระดานข่าว 89

RHEL และผลิตภัณฑ์ที่เกี่ยวข้อง: ตรวจสอบแพ็คเกจใบรับรองและข้อผิดพลาดด้านความปลอดภัยตามช่องทางผลิตภัณฑ์ การตรวจสอบเวอร์ชันสามารถทำได้โดยใช้:

rpm -q ca-certificates

ใช้กลไกการอัปเดต DNF/YUM ที่รองรับเพื่อรับโปรแกรมแก้ไขของผู้จำหน่าย หากช่องยังไม่ได้ให้การแก้ไข อย่าถือว่า “ไม่มีแพ็คเกจที่อัปเดตได้” ว่าปลอดภัย เมื่อจำเป็นต้องลบ Root Trust ชั่วคราว ให้ใช้มาตรการที่ระบุไว้อย่างชัดเจนโดยผู้ผลิต และประเมินความเข้ากันได้ของใบรับรองธุรกิจที่ถูกต้องตามกฎหมาย 10

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

แอพพลิเคชั่นและรูปภาพ

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

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

การย้ายใบรับรองเว็บไซต์

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

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

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

7 ตรวจสอบว่าการแก้ไขมีผลจริง

การตรวจสอบเวอร์ชันและการตรวจสอบพฤติกรรมจะดำเนินการแยกกัน

การตรวจสอบเวอร์ชันใช้เพื่อยืนยันว่ามีการใช้แพตช์หรือส่วนประกอบคงที่แล้ว การตรวจสอบพฤติกรรมใช้เพื่อยืนยันว่าแอปพลิเคชันใช้เส้นทางการตรวจสอบที่คาดหวังจริง ๆ การตรวจสอบทั้งสองแก้ปัญหาที่แตกต่างกัน และทั้งสองรายการไม่สามารถแทนที่ได้ด้วย “คำสั่งอัปเดตดำเนินการสำเร็จ”

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

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

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

เงื่อนไขการสำเร็จที่แนะนำ

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

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

8 ปริมาณข้อมูล HTTPS ในอดีตและขอบเขตความเสี่ยง

คีย์สามประเภทมีการใช้งานที่แตกต่างกัน

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

การได้รับคีย์ส่วนตัว CA ไม่เทียบเท่ากับการได้รับคีย์ส่วนตัวของเว็บไซต์หรือคีย์เซสชันทั้งหมด การเชื่อมต่อปกติของ A พร้อมการส่งต่อความลับโดยใช้การแลกเปลี่ยนคีย์ชั่วคราวจะไม่เปิดเผยเซสชันในอดีตโดยอัตโนมัติเพียงเพราะคีย์การเซ็นชื่อระยะยาวถูกโจมตีในภายหลัง สำหรับแอ็ตทริบิวต์ความปลอดภัยที่เกี่ยวข้องของ TLS 1.3 โปรดดูที่ RFC 8446 16

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

การตัดสินที่ทำได้และไม่สามารถทำได้ในปัจจุบัน

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

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

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

ภาคผนวก A ได้รับผลกระทบชื่อ CA ระดับกลาง

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

กลาง CA	วัตถุประสงค์	องค์กรที่เกี่ยวข้อง
EM EV TLS CA - G3B	TLS	eMudhra BV
EM OV TLS CA - G3B	TLS	eMudhra BV
EM DV TLS CA - G3B	TLS	eMudhra BV
EM EV TLS CA - G3C	TLS	eMudhra Inc
EM OV TLS CA - G3C	TLS	eMudhra Inc
EM DV TLS CA - G3C	TLS	eMudhra Inc
EM OV CS CA - G3B	การลงนามรหัส	eMudhra BV
EM OV CS CA - G3C	การลงนามรหัส	eMudhra Inc

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

ลิงก์อ้างอิงภาคผนวก B

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

ข้อเท็จจริงของเหตุการณ์และการจัดการแพลตฟอร์ม

[1] Google Chrome และ Android ประกาศอย่างเป็นทางการ อธิบายข้อบกพร่องของคีย์ส่วนตัว, การบล็อก SPKI, การกระจายบริการ Google Play, การป้องกัน CT และแผนการลบที่เก็บรูท Chrome Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates

[2] Mozilla Bugzilla 2083449 บันทึกเหตุการณ์ ประกอบด้วยรายงานต้นฉบับ การตรวจสอบอิสระ การตรวจสอบกระบวนการสร้าง การแก้ไขในภายหลังสำหรับ Firefox Android และการอภิปรายเกี่ยวกับการย้ายใบรับรองทางกฎหมาย เน้นที่ความคิดเห็นที่ 5, 11, 29 และ 30 eMudhra Private key compromise of Intermediate Certificates

[3] Mozilla Firefox ประกาศด้านความปลอดภัย คำอธิบายของการแจกจ่ายในกรณีฉุกเฉิน OneCRL และการกำจัด Firefox/NSS ในภายหลัง Protecting Firefox users following the compromise of eMudhra intermediate certificates

[4] ผู้ประสานงานเหตุการณ์ Dennis Jackson สรุปการบำรุงรักษาและพอร์ทัลการตรวจจับ ให้คำแนะนำเพิ่มเติมเกี่ยวกับสถานะการซ่อมแซมแพลตฟอร์มและซอฟต์แวร์ การเข้าทดสอบ วัสดุห่วงโซ่ใบรับรองสาธารณะ และสภาพแวดล้อม เช่น Windows/macOS ผลการทดสอบแสดงถึงเส้นทางการตรวจสอบจริงที่ทดสอบเท่านั้น eMudhra Intermediate CA Compromise

[5] Mozilla ประกาศสำหรับผู้จัดจำหน่ายและผู้ดูแลร้านค้าที่เชื่อถือได้ อธิบาย TLS 6 ตัวและตัวกลางการลงนามโค้ด 2 ตัว CA, Sectigo การเซ็นชื่อข้าม การเพิกถอน และขอบเขตการประมวลผลความน่าเชื่อถือของรูท และแสดงรายการใบรับรองที่ถูกต้องและการระบุคีย์สาธารณะ oss-security eMudhra Intermediates Compromise

[6] eMudhra คำชี้แจงกิจกรรมอย่างเป็นทางการ จัดเตรียมคำอธิบายเบื้องต้นของผู้ผลิตเกี่ยวกับกระบวนการสร้างคีย์ สาเหตุที่แท้จริงจะยังคงขึ้นอยู่กับข้อสรุปของการสอบสวนที่เสร็จสมบูรณ์ eMudhra Statement on Recent Certificate Security Incident

[7] Cloudflare คำแนะนำเกี่ยวกับเหตุการณ์อย่างเป็นทางการและการซ่อมแซม ครอบคลุม WARP, Cloudflare Tunnel, การตรวจสอบไซต์ต้นทาง, การขึ้นต่อกันของรันไทม์, การอัปเดตรูปภาพ และวิธีการตรวจสอบ 8 eMudhra certificates are compromised Here is what you need to know

ระบบปฏิบัติการและการแจกแจง

[8] Ubuntu ประกาศการซ่อมอย่างเป็นทางการ แสดงรายการแพ็คเกจการแก้ไข ca-certificates ช่องทางการสนับสนุน และขั้นตอนการอัปเดตเป้าหมายสำหรับแต่ละเวอร์ชัน eMudhra CA compromise fixes available

[9] Debian ปัญหาอย่างเป็นทางการและบันทึกการซ่อมแซม บันทึกการแก้ไขของผู้ดูแลและแพ็คเกจการเผยแพร่ที่เกี่ยวข้องควรถือเป็นมาตรฐาน และข้อเสนอแนะชั่วคราวในช่วงต้นในการอภิปรายปัญหาไม่ควรถือเป็นวิธีแก้ปัญหาขั้นสุดท้าย Debian bug 1151413 eMudhra Intermediate CA key compromise

[10] Red Hat ประกาศด้านความปลอดภัยอย่างเป็นทางการ RHSB 2026 012 แสดงรายการ RHEL 6 ถึง 10 ผลกระทบของผลิตภัณฑ์และคอนเทนเนอร์ที่เกี่ยวข้อง และรายการแก้ไขและรายการกำจัดระหว่างกาล Certificate compromise eMudhra

[11] FreeBSD ประกาศด้านความปลอดภัยอย่างเป็นทางการ ระบุสาขาของระบบที่ได้รับผลกระทบ เวอร์ชันการซ่อมแซม และข้อกำหนดในการรีสตาร์ทบริการ FreeBSD SA 26 73 caroot

รันไทม์และโปรโตคอล

[12] Python คำอธิบายเหตุการณ์อย่างเป็นทางการ ให้พื้นฐานการซ่อมแซมสำหรับ pip, certifi, uv ฯลฯ อธิบายปัญหาของร้านค้าอิสระ pip เก่า และจัดเตรียมวิธีการอัปเกรดเริ่มต้นด้วยการตรวจสอบ SHA-256 Information for Python users regarding eMudhra emSign CA certificate security incident

[13] Node.js 24.22.1 เปิดตัวอย่างเป็นทางการ ประกอบด้วยการอัปเดตที่เก็บรูท NSS และปฏิเสธการเปลี่ยนแปลงที่มีกลุ่มใบรับรองคีย์สาธารณะที่ถูกบล็อก Node.js 24.22.1 security release

[14] Go การรักษาความปลอดภัยอย่างเป็นทางการ คำอธิบายการปรับปรุงการกรองห่วงโซ่ใบรับรอง crypto/x509 สำหรับ Go 1.27.3/1.26.10. Go 1.27.3 and Go 1.26.10 are released

[15] Oracle JDK คำแนะนำในการกำจัดอย่างเป็นทางการ อธิบายแพทช์ที่สำคัญของ JDK และมาตรการการกำหนดค่าที่เกี่ยวข้องเมื่อไม่สามารถอัปเกรดได้ทันที Distrusting eMudhra Intermediate Certificates in Oracle JDK

[16] TLS 1.3 มาตรฐานโปรโตคอล RFC 8446 ดูภาคผนวก E.1 สำหรับคำแนะนำในการตรวจสอบตัวตน การแลกเปลี่ยนคีย์ชั่วคราว และการส่งต่อความลับ The Transport Layer Security Protocol Version 1.3

[17] ใบรับรองหลักที่เกี่ยวข้องกับเหตุการณ์และข้อมูลความสัมพันธ์การออก ใช้เพื่อทำความเข้าใจความสัมพันธ์ของผู้ออกโดยตรงและการลงนามข้ามสาย; สถานะการรวมที่เก็บรูทไม่สามารถแทนที่สถานะการเพิกถอนหรือการบล็อกล่าสุดของไคลเอ็นต์ได้ Root certificate relationships JSON