คำถามที่พบบ่อยเกี่ยวกับการย้ายข้อมูล CA ระดับรูทของ Google Maps Platform

เอกสารนี้ประกอบด้วยส่วนต่อไปนี้

ดูภาพรวมโดยละเอียดของการย้ายข้อมูล CA ระดับรูทของ Google ที่ดำเนินอยู่ได้ที่สิ่งที่จะเกิดขึ้น

คำศัพท์

ด้านล่างนี้เราได้รวบรวมรายการคำที่สำคัญที่สุดที่คุณต้องคุ้นเคยสำหรับเอกสารนี้ ดูภาพรวมที่ครอบคลุมมากขึ้นเกี่ยวกับคำศัพท์ที่เกี่ยวข้องได้ที่คำถามที่พบบ่อยเกี่ยวกับ Google Trust Services

ใบรับรอง SSL/TLS
ใบรับรองจะเชื่อมโยงคีย์การเข้ารหัสกับข้อมูลประจำตัว
ใบรับรอง SSL/TLS ใช้สำหรับตรวจสอบสิทธิ์และสร้างการเชื่อมต่อที่ปลอดภัยไปยังเว็บไซต์ ใบรับรองจะออกและลงนามด้วยวิทยาการเข้ารหัสโดยหน่วยงานที่เรียกว่าผู้ออกใบรับรอง
เบราว์เซอร์ใช้ใบรับรองที่ออกโดยหน่วยงานที่รับรองที่เชื่อถือได้เพื่อให้ทราบว่าข้อมูลที่ส่งนั้นส่งไปยังเซิร์ฟเวอร์ที่ถูกต้องและมีการเข้ารหัสระหว่างการส่ง
Secure Sockets Layer (SSL)
Secure Sockets Layer เป็นโปรโตคอลที่ใช้งานกันอย่างแพร่หลายที่สุดและใช้ในการเข้ารหัสการสื่อสารทางอินเทอร์เน็ต เนื่องจากโปรโตคอล SSL ไม่ถือว่ามีความปลอดภัยอีกต่อไปและไม่ควรนำมาใช้
Transport Layer Security (TLS)
Transport Layer Security พัฒนาต่อมาจาก SSL
ผู้ออกใบรับรอง (CA)
ผู้ออกใบรับรองเปรียบเสมือนสำนักงานหนังสือเดินทางดิจิทัลสำหรับอุปกรณ์และบุคคล โดยออกเอกสาร (ใบรับรอง) ที่ผ่านการเข้ารหัสเพื่อรับรองว่านิติบุคคล (เช่น เว็บไซต์) เป็นบุคคลตามที่กล่าวอ้าง
ก่อนออกใบรับรอง CA จะมีหน้าที่รับผิดชอบในการยืนยันว่าชื่อในใบรับรองเชื่อมโยงกับบุคคลหรือนิติบุคคลที่ขอใบรับรอง
คำว่า "ผู้ออกใบรับรอง" อาจหมายถึงทั้งองค์กรอย่าง Google Trusted Services และระบบที่ออกใบรับรอง
ที่เก็บใบรับรองรูท
ที่เก็บใบรับรองรูทประกอบด้วยชุดผู้ออกใบรับรองที่เชื่อถือโดยผู้ให้บริการซอฟต์แวร์แอปพลิเคชัน เว็บเบราว์เซอร์และระบบปฏิบัติการส่วนใหญ่มีที่จัดเก็บใบรับรองรูทของตนเอง
หากต้องการรวมอยู่ในที่เก็บใบรับรองระดับรูท ผู้ออกใบรับรองจะต้องปฏิบัติตามข้อกำหนดที่เข้มงวดของผู้จำหน่ายซอฟต์แวร์แอปพลิเคชัน
โดยทั่วไปแล้ว ข้อกำหนดเหล่านี้รวมถึงการปฏิบัติตามมาตรฐานอุตสาหกรรม เช่น ข้อกำหนดของ CA/Browser Forum
ผู้ออกใบรับรองรูท
ผู้ออกใบรับรองรูท (หรือที่ถูกต้องกว่าคือใบรับรองของผู้ออกใบรับรอง) คือใบรับรองที่อยู่บนสุดในเชนใบรับรอง
โดยปกติแล้วใบรับรอง Root CA จะได้รับการลงนามด้วยตนเอง คีย์ส่วนตัวที่เชื่อมโยงกับอุปกรณ์เหล่านี้จะจัดเก็บไว้ในสถานที่ที่มีความปลอดภัยสูง และได้รับการดูแลรักษาในสถานะออฟไลน์เพื่อปกป้องจากการเข้าถึงที่ไม่ได้รับอนุญาต
ผู้ออกใบรับรองกลาง
ผู้ออกใบรับรองระดับกลาง (หรือที่ถูกต้องกว่าคือใบรับรองของผู้ออกใบรับรอง) คือใบรับรองที่ใช้ลงนามในใบรับรองอื่นๆ ในกลุ่มใบรับรอง
โดยพื้นฐานแล้ว CA ระดับกลางจะมีการเปิดใช้การออกใบรับรองออนไลน์ในขณะที่อนุญาตให้ใบรับรอง Root CA ทำงานแบบออฟไลน์ได้
CA ระดับกลางหรือที่เรียกว่า CA ย่อย
ผู้ออกใบรับรอง
ใบรับรองของผู้ออกใบรับรอง (หรือที่เรียกอีกอย่างว่าใบรับรอง) คือใบรับรองที่ใช้ลงนามใบรับรองระดับล่างสุดในเชนใบรับรอง
ใบรับรองที่อยู่ด้านล่างสุดนี้เรียกโดยทั่วไปว่าใบรับรองสมาชิก ใบรับรองเอนทิตีปลายทาง หรือใบรับรอง Leaf ในเอกสารนี้ เราจะใช้คำว่าใบรับรองเซิร์ฟเวอร์
ด้วย
เชนใบรับรอง
ใบรับรองจะลิงก์กับผู้ออกใบรับรอง (ซึ่งลงนามแบบเข้ารหัสโดย) ชุดใบรับรองประกอบด้วยใบรับรองใบไม้ (Leaf-Certificate) ใบรับรองของผู้ออกใบรับรองทั้งหมด และใบรับรองรูท
การรับรองข้าม
ไคลเอ็นต์ของผู้ให้บริการซอฟต์แวร์แอปพลิเคชันต้องอัปเดตคีย์สโตร์ใบรับรองรูทให้รวมใบรับรอง CA ใหม่เพื่อให้ผลิตภัณฑ์เชื่อถือได้ ผลิตภัณฑ์ที่มีใบรับรอง CA ใหม่จะใช้เวลาสักระยะจึงจะใช้งานได้อย่างแพร่หลาย
ใบรับรอง CA สามารถ "ลงนามครอส" โดย CA ที่เก่ากว่าอีกรายหนึ่งได้เพื่อเพิ่มความเข้ากันได้กับไคลเอ็นต์รุ่นเก่า ซึ่งจะสร้างใบรับรอง CA ใบที่ 2 สำหรับข้อมูลประจำตัวเดียวกัน (ชื่อและคู่คีย์)
ลูกค้าจะสร้างเชนใบรับรองอื่นขึ้นไปยังรูทที่เชื่อถือ ทั้งนี้ขึ้นอยู่กับ CA ที่รวมอยู่ในที่เก็บใบรับรองรูท

ข้อมูลทั่วไป

จะเกิดอะไรขึ้น

ภาพรวม

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

หลังจากระยะแรก ความปลอดภัย TLS ของบริการ Google Maps Platform ได้รับการรับประกันโดย GS Root R2 ซึ่งเป็นผู้ออกใบรับรองรูท (CA) ที่มีชื่อเสียงและเชื่อถือได้เป็นอย่างมาก ซึ่ง Google ได้มาจาก GMO GlobalSign เพื่อช่วยให้การเปลี่ยนไปใช้ CA รูท Google Trust Service (GTS) ที่ออกเองของเราเป็นไปอย่างราบรื่น

ในทางปฏิบัติ ไคลเอ็นต์ TLS ทั้งหมด (เช่น เว็บเบราว์เซอร์ สมาร์ทโฟน และแอปพลิเคชันเซิร์ฟเวอร์) ได้เชื่อถือใบรับรองรูทนี้ จึงสามารถสร้างการเชื่อมต่อที่ปลอดภัยกับเซิร์ฟเวอร์ Google Maps Platform ในช่วงแรกของการย้ายข้อมูลได้

อย่างไรก็ตาม CA อาจออกใบรับรองที่ใช้งานได้เกินเวลาที่ใบรับรองหมดอายุโดยการออกแบบไม่ได้ เนื่องจาก GS Root R2 จะหมดอายุในวันที่ 15 ธันวาคม 2021 Google จึงจะย้ายข้อมูลบริการของตนเองไปยัง CA ใหม่ ซึ่งก็คือ GTS Root R1 Cross โดยใช้ใบรับรองที่ออกโดย CA รูทของ Google เอง GTS Root R1

แม้ว่าระบบปฏิบัติการสมัยใหม่และไลบรารีไคลเอ็นต์ TLS ส่วนใหญ่ จะเชื่อถือ CA รูทของ GTS อยู่แล้ว และเพื่อให้การเปลี่ยนระบบแบบเดิมเป็นไปอย่างราบรื่น Google จึงได้การลงนามข้ามระบบจาก GMO GlobalSign โดยใช้ GlobalSign Root CA - R1 ซึ่งเป็น CA ระดับรูทที่เก่าแก่ที่สุดและน่าเชื่อถือที่สุดที่มีให้บริการในปัจจุบัน

ดังนั้น ไคลเอ็นต์ Google Maps Platform ของลูกค้าส่วนใหญ่จะจดจำ CA รูทที่เชื่อถือได้เหล่านี้ (หรือทั้ง 2 รายการ) อยู่แล้ว และจะไม่ได้รับผลกระทบใดๆ จากระยะที่ 2 ของการย้ายข้อมูล

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

คุณควรยืนยันระบบในกรณีต่อไปนี้

  • บริการของคุณใช้แพลตฟอร์มที่ไม่ใช่แบบมาตรฐานหรือดั้งเดิม และ/หรือคุณดูแลที่เก็บใบรับรองรูทของตนเอง
  • คุณไม่ได้ดำเนินการในปี 2017-2018 ในช่วงแรกของการย้ายข้อมูล CA ระดับรูทของ Google หรือไม่ได้ติดตั้งใบรับรองทั้งชุดจากแพ็กเกจ CA รูทของ Google ที่เชื่อถือได้

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

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

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

สรุปทางเทคนิค

ตามที่ได้ประกาศไปเมื่อวันที่ 15 มีนาคม 2021 ในบล็อกด้านความปลอดภัยของ Google, GS Root R2 ทาง Google Maps Platform ระดับรูทของ CA ได้ใช้ไปตั้งแต่ต้นปี 2018 จะหมดอายุในวันที่ 15 ธันวาคม 2021 ดังนั้น Google จะเปลี่ยนไปใช้ CA GTS Root R1 Cross ที่ออกใหม่ในปีนี้ ซึ่งหมายความว่าบริการของเราจะค่อยๆ เปลี่ยนไปใช้ใบรับรองใบแจ้งยอด TLS ที่ออกโดย CA ใหม่นี้

ไคลเอ็นต์และระบบ TLS สมัยใหม่เกือบทั้งหมดได้รับการกำหนดค่าล่วงหน้าด้วยใบรับรอง GTS Root R1 หรือควรได้รับผ่านการอัปเดตซอฟต์แวร์ตามปกติ นอกจากนี้ GlobalSign Root CA - R1 ควรพร้อมใช้งานบนระบบเก่ารุ่นเก่าด้วย

อย่างไรก็ตาม คุณควรยืนยันระบบเป็นอย่างน้อยหากเป็นไปตาม 2 ประเด็นต่อไปนี้

  • บริการของคุณทำงานบนแพลตฟอร์มที่ไม่ใช่มาตรฐานหรือแพลตฟอร์มเดิม และ/หรือคุณดูแลรักษาที่เก็บใบรับรองรูทของคุณเอง
  • คุณไม่ได้ดำเนินการในปี 2017-2018 ในช่วงแรกของการย้ายข้อมูล CA รูทของ Google หรือคุณไม่ได้ติดตั้งใบรับรองทั้งชุดจากแพ็กเกจ CA รูทที่เชื่อถือได้ของ Google

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

เพื่อให้แอปพลิเคชันพร้อมรองรับอนาคตในอนาคต

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

ฉันจะรับข้อมูลอัปเดตเกี่ยวกับระยะการย้ายข้อมูลนี้ได้อย่างไร

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

ฉันจะรับการแจ้งเตือนล่วงหน้าเกี่ยวกับการย้ายข้อมูลในอนาคตได้อย่างไร

เราขอแนะนำให้คุณติดตามบล็อกด้านความปลอดภัยของ Google นอกจากนี้ เราจะพยายามอัปเดตเอกสารเฉพาะผลิตภัณฑ์โดยเร็วที่สุดตามประกาศที่เผยแพร่ในบล็อก

โปรดสมัครรับการแจ้งเตือนของ Google Maps Platform ด้วย เนื่องจากเราโพสต์ข้อมูลอัปเดตในฟอรัมเกี่ยวกับการเปลี่ยนแปลงที่อาจส่งผลต่อลูกค้าจำนวนมากอยู่เป็นประจำ

เราใช้บริการต่างๆ ของ Google การย้ายข้อมูล CA รูทจะส่งผลต่อรายการทั้งหมดไหม

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

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

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

วิธีตรวจสอบว่าต้องอัปเดตที่เก็บใบรับรองรูทหรือไม่

ทดสอบสภาพแวดล้อมของแอปพลิเคชันกับปลายทางการทดสอบที่แสดงด้านล่าง

  • หากสร้างการเชื่อมต่อ TLS กับปลายทางการทดสอบ GTS Root R1 Cross ได้ คุณก็จะไม่ได้รับผลกระทบจากการหมดอายุของ GS Root R2
  • หากสร้างการเชื่อมต่อ TLS กับปลายทางทดสอบ GTS Root R1 ได้ ก็มีความเป็นไปได้ว่าแอปพลิเคชันจะได้รับการปกป้องจากการหมดอายุของ GTS Root R1 Cross และ GlobalSign Root CA - R1 ในปี 2028

โดยทั่วไปแล้ว ระบบจะใช้งานร่วมกับการเปลี่ยนแปลง CA รูทนี้ได้ในกรณีต่อไปนี้

  • บริการของคุณทำงานบนระบบปฏิบัติการหลักที่ได้รับการดูแลรักษา และคุณได้ทำแพตช์ทั้งระบบปฏิบัติการและไลบรารีที่บริการของคุณใช้ไม่ได้ดูแลรักษาที่เก็บใบรับรองรูทของคุณเอง หรือ
  • คุณทำตามคำแนะนำก่อนหน้านี้ของเราและติดตั้ง CA รูททั้งหมดจากแพ็กเกจ CA รูทที่เชื่อถือได้ของ Google
หากไม่ดำเนินการในขั้นตอนแรก

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

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

มีเครื่องมือง่ายๆ ที่ใช้ยืนยันที่เก็บใบรับรองรูทได้ไหม

คุณอาจพบว่าเครื่องมือบรรทัดคำสั่ง 2 รายการ ได้แก่ curl และ openssl มีประโยชน์ในการสืบสวน ทั้ง 2 อย่างนี้มีให้บริการบนแพลตฟอร์มส่วนใหญ่ และมีตัวเลือกมากมายสำหรับการทดสอบการตั้งค่า

โปรดดูวิธีการรับ curl ได้ที่ส่วนการรับ curl ด้านล่าง

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

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

ดูวิธีการทดสอบที่ชัดเจนได้ที่ส่วนวิธีตรวจสอบว่าที่เก็บใบรับรองรูทของฉันต้องอัปเดตหรือไม่

การทดสอบที่เก็บใบรับรองรูทเริ่มต้น

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

การยืนยันแพ็กเกจ CA รูทที่เชื่อถือได้ของ Google

ดาวน์โหลดแพ็กเกจ CA รูทที่เชื่อถือได้ของ Google แล้วทำตามขั้นตอนต่อไปนี้

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

การย้ายข้อมูล CA ระดับรูทของ Google จะดำเนินต่อไปอย่างไรและเมื่อไร

  1. ระยะที่ 1 (การย้ายข้อมูลไปยัง GS Root R2) ซึ่งประกาศไปเมื่อเดือนมกราคม 2017 เริ่มขึ้นในช่วงปลายปี 2017 และเสร็จสิ้นในช่วงครึ่งแรกของปี 2018
  2. ระยะที่ 2 (การย้ายข้อมูลไปยัง GTS Root R1 Cross)ได้ประกาศไปเมื่อเดือนมีนาคม 2021 และจะเริ่มใช้งานในช่วงไม่กี่เดือนข้างหน้าก่อน GS Root R2 จะหมดอายุลงในวันที่ 15 ธันวาคม 2021

กำหนดการสำหรับเฟสการย้ายข้อมูลในภายหลังจะประกาศล่วงหน้าก่อนวันหมดอายุของใบรับรองในอนาคต

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

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

แผนการเปิดตัวทั่วไปสำหรับบริการแต่ละอย่างของ Google

  1. การเปิดตัวแบบทีละขั้นจะเริ่มในศูนย์ข้อมูลแห่งเดียว
  2. เราจะทยอยขยายการให้บริการไปยังศูนย์ข้อมูลอื่นๆ จนครอบคลุมทั่วโลก
  3. หากตรวจพบปัญหาร้ายแรงในขั้นตอนใดก็ตาม การทดสอบจะย้อนกลับชั่วคราวระหว่างที่ปัญหาได้รับการแก้ไข
  4. ตามข้อมูลจากการทำซ้ำครั้งก่อน บริการอื่นๆ ของ Google จะรวมอยู่ในการเปิดตัวด้วยจนกว่าบริการของ Google ทั้งหมดจะค่อยๆ ย้ายข้อมูลไปยังใบรับรองใหม่

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

นักพัฒนาแอป Google Maps Platform จำนวนมากขึ้นจะเริ่มได้รับใบรับรองใหม่เมื่อมีการย้ายข้อมูลไปยังศูนย์ข้อมูลใหม่ การเปลี่ยนแปลงนี้จะปรับให้เข้ากับพื้นที่ของคุณเนื่องจากคําขอของไคลเอ็นต์มีแนวโน้มที่จะส่งต่อไปยังเซิร์ฟเวอร์ในศูนย์ข้อมูลที่อยู่ใกล้เคียงกันทางภูมิศาสตร์

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

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

สิ่งที่ควรระวัง

ไคลเอ็นต์ที่ไม่ได้กําหนดค่าด้วยใบรับรองรูทที่จําเป็นจะยืนยันการเชื่อมต่อ TLS กับแพลตฟอร์ม Google Maps ไม่ได้ ในกรณีนี้ ไคลเอ็นต์มักจะออกคำเตือนว่าการตรวจสอบใบรับรองล้มเหลว

ลูกค้าอาจส่งคําขอ Google Maps Platform ต่อ หรืออาจปฏิเสธที่จะส่งคําขอต่อ ทั้งนี้ขึ้นอยู่กับการกําหนดค่า TLS

ข้อกำหนดขั้นต่ำสำหรับไคลเอ็นต์ TLS เพื่อสื่อสารกับ Google Maps Platform มีอะไรบ้าง

ใบรับรอง Google Maps Platform ใช้ Subject Alternative Names (SAN) ของ DNS ดังนั้นการจัดการใบรับรองของไคลเอ็นต์จะต้องสามารถรองรับ SAN ที่อาจมีไวลด์การ์ดเดี่ยวเป็นป้ายกำกับด้านซ้ายสุดในชื่อ เช่น *.googleapis.com

สำหรับข้อกำหนดอื่นๆ โปรดดูส่วนข้อกำหนดที่แนะนำสำหรับไคลเอ็นต์ TLS เพื่อสื่อสารกับ Google มีอะไรบ้างในคำถามที่พบบ่อยเกี่ยวกับ GTS

แอปพลิเคชันประเภทใดที่เสี่ยงต่อการหยุดทำงาน

แอปพลิเคชันใช้ที่เก็บใบรับรองรูทของระบบโดยนักพัฒนาแอปไม่ได้จำกัด

แอปพลิเคชันเว็บเซอร์วิสของ Google Maps Platform

หากคุณใช้ระบบปฏิบัติการหลัก เช่น Ubuntu, Red Hat, Windows 10 หรือ Server 2019, OS X) ที่ยังคงมีการบำรุงรักษาและได้รับการอัปเดตเป็นประจำ ที่เก็บใบรับรองรูทเริ่มต้นควรมีใบรับรอง GTS Root R1 อยู่แล้ว

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

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

แอปพลิเคชัน Google Maps Platform ฝั่งไคลเอ็นต์

โดยทั่วไปแอปพลิเคชัน Maps JavaScript API จะอาศัยใบรับรองรูทของเว็บเบราว์เซอร์ที่ใช้งานแอปพลิเคชัน ดูรายละเอียดเพิ่มเติมได้ในส่วนแอปพลิเคชัน JavaScript มีความเสี่ยงที่จะใช้งานไม่ได้ไหม

สําหรับแอปพลิเคชันบนอุปกรณ์เคลื่อนที่แบบเนทีฟที่ใช้ Maps SDK สําหรับ Android, Maps SDK สําหรับ iOS, Places SDK สําหรับ Android หรือ Places SDK สําหรับ iOS กฎเดียวกันนี้จะมีผลกับแอปที่เรียกใช้เว็บเซอร์วิสของ Google Maps Platform

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

แอปใช้กลุ่มใบรับรองของตัวเองหรือใช้ฟีเจอร์ความปลอดภัยขั้นสูง เช่น การปักหมุดใบรับรอง

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

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

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

เหตุใดฉันจึงควรซิงค์ที่เก็บใบรับรองรูทกับแพ็กเกจรูท CA ของ Google ที่เชื่อถืออยู่เสมอ

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

ดังนั้น หากต้องการเตรียมระบบให้พร้อมรับอนาคต เราขอแนะนําอย่างยิ่งให้คุณตรวจสอบว่าที่เก็บใบรับรองรูทมีใบรับรองทั้งหมดจากกลุ่ม และทําให้เป็นนิสัยในการซิงค์ทั้ง 2 อย่าง

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

โปรดดูคำถาม ฉันจะรับการแจ้งเตือนล่วงหน้าเกี่ยวกับการย้ายข้อมูลในอนาคตได้อย่างไร เพื่อดูวิธีรับข้อมูลอัปเดตเกี่ยวกับการย้ายข้อมูล CA ระดับรูทในอนาคต การเก็บใบรับรองรูทให้ซิงค์กับรายการที่ดูแลจัดการเป็นประจำจะช่วยปกป้องบริการของคุณจากการหยุดชะงักในอนาคตอันเนื่องมาจากการเปลี่ยนแปลง CA และจะช่วยให้บริการทำงานต่อไปได้หลังจากการหมดอายุของทั้ง GTS Root R1 Cross และ GlobalSign Root CA - R1

นอกจากนี้ โปรดดูคำถามที่ว่าฉันกำลังสร้างผลิตภัณฑ์ที่เชื่อมต่อกับบริการของ Google ฉันต้องเชื่อถือใบรับรอง CA ใดบ้างในคำถามที่พบบ่อยเกี่ยวกับ GTS เพื่อดูคำแนะนำเพิ่มเติม

เหตุใดฉันจึงไม่ควรติดตั้งใบรับรอง CA ระดับกลางหรือใบรับรองใบสุดท้าย

เพราะจะทำให้แอปพลิเคชันของคุณเสียหายได้ทุกเมื่อที่เราลงทะเบียนใบรับรองใหม่หรือเปลี่ยน CA ระดับกลาง บริการอย่างใดอย่างหนึ่งนี้อาจเกิดขึ้นได้ทุกเมื่อโดยไม่ต้องแจ้งให้ทราบล่วงหน้า และมีผลกับใบรับรองของเซิร์ฟเวอร์แต่ละรายการอย่างเท่าเทียมกัน เช่น ใบรับรองที่ maps.googleapis.com ให้บริการ รวมถึง CA ระดับกลางของเรา เช่น GTS Root R1 Cross

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

การติดตั้งใช้งานไลบรารี TLS สมัยใหม่ควรยืนยันเชนความน่าเชื่อถือดังกล่าวได้โดยอัตโนมัติ ตราบใดที่ผู้ออกใบรับรองรูทเชื่อถือได้

แอปพลิเคชัน JavaScript มีความเสี่ยงที่จะใช้งานไม่ได้ไหม

ใบรับรองรูทของ GTS ได้รับการฝังไว้อย่างดีและได้รับความเชื่อถือจากเบราว์เซอร์สมัยใหม่ส่วนใหญ่ และเครื่องหมายข้ามระบบจาก GMO GlobalSign ควรดูแลให้การย้ายข้อมูลเป็นไปอย่างราบรื่นแม้สำหรับผู้ใช้ปลายทางส่วนใหญ่ที่ใช้เบราว์เซอร์เวอร์ชันเก่า ซึ่งรวมถึงเบราว์เซอร์ที่รองรับอย่างเป็นทางการทั้งหมดสำหรับ Maps JavaScript API

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

แอปบนอุปกรณ์เคลื่อนที่มีความเสี่ยงที่จะขัดข้องไหม

อุปกรณ์ Android และ Apple iOS ที่ยังคงได้รับการอัปเดตเป็นประจำจากผู้ผลิตอุปกรณ์ก็คาดว่าจะใช้งานได้ต่อไปในอนาคต โทรศัพท์ Android รุ่นเก่าส่วนใหญ่จะมีใบรับรอง GlobalSign Root CA - R1 เป็นอย่างน้อย แม้ว่ารายการใบรับรองที่เชื่อถือได้อาจแตกต่างกันไปตามผู้ผลิตโทรศัพท์มือถือ รุ่นอุปกรณ์ และเวอร์ชัน Android

อย่างไรก็ตาม การรองรับ Root CA ของ GTS รวมถึง GTS Root R1 อาจยังถูกจำกัดใน Android เวอร์ชันก่อน 10

สำหรับอุปกรณ์ iOS ทาง Apple จะดูแลรักษารายการ CA รูทที่เชื่อถือได้สำหรับ iOS เวอร์ชันล่าสุดแต่ละเวอร์ชันไว้ในหน้าการสนับสนุน อย่างไรก็ตาม iOS เวอร์ชัน 5 ขึ้นไปทั้งหมดรองรับ GlobalSign Root CA - R1

iOS รองรับ CA รูท GTS รวมถึง GTS Root R1 มาตั้งแต่เวอร์ชัน 12.1.3

ดูรายละเอียดเพิ่มเติมได้ที่คำถามฉันจะตรวจสอบใบรับรองรูทที่เชื่อถือได้ในโทรศัพท์เคลื่อนที่ได้อย่างไร

เบราว์เซอร์หรือระบบปฏิบัติการของฉันจะมีใบรับรองรูท Google Trust Service เมื่อใด

ในช่วงหลายปีที่ผ่านมา Google ได้ทํางานร่วมกับบุคคลที่สามรายใหญ่ทุกรายอย่างครอบคลุมเพื่อดูแลรักษากลุ่มใบรับรองรูทที่เชื่อถือได้และใช้งานกันอย่างแพร่หลาย ตัวอย่างเช่น ผู้ผลิตระบบปฏิบัติการ เช่น Apple และ Microsoft รวมถึงทีม Android และ ChromeOS ของ Google เอง นักพัฒนาเบราว์เซอร์ เช่น Mozilla, Apple, Microsoft รวมถึงทีม Chrome ของ Google เอง ผู้ผลิตฮาร์ดแวร์ เช่น โทรศัพท์ กล่องรับสัญญาณทีวี ทีวี คอนโซลเกม เครื่องพิมพ์ และอื่นๆ

ดังนั้นจึงมีแนวโน้มสูงว่าระบบใดๆ ที่ดูแลรักษาในปัจจุบันรองรับ GTS Root CA ใหม่ของ Google อยู่แล้ว ซึ่งรวมถึง GTS Root R1 และแม้แต่ระบบเก่าก็มีแนวโน้มที่จะรองรับ GlobalSign Root CA - R1 ด้วยเช่นกัน ซึ่งจะใช้สำหรับการลงนามแบบข้ามใบรับรองที่ออกโดย Google ในปีหน้า

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

บุคคลที่สามบางราย เช่น โปรแกรมใบรับรอง CA ของ Mozilla อาจบันทึกลำดับเวลาการรวมใบรับรองของตนเองไว้

การแก้ปัญหา

ฉันจะหาเครื่องมือที่ต้องการได้จากที่ไหน

การรับค่าโค้ง

หากระบบปฏิบัติการของคุณไม่มี curl คุณสามารถดาวน์โหลดได้จาก https://curl.haxx.se/ คุณสามารถดาวน์โหลดซอร์สโค้ดและคอมไพล์เครื่องมือด้วยตนเอง หรือดาวน์โหลดไฟล์ไบนารีที่คอมไพล์ไว้ล่วงหน้าก็ได้ หากมีสำหรับแพลตฟอร์มของคุณ

การรับ OpenSSL

หากระบบปฏิบัติการของคุณไม่มี openssl คุณสามารถดาวน์โหลดซอร์สโค้ดจาก https://www.openssl.org/ แล้วคอมไพล์เครื่องมือ ดูรายการไบนารีที่สร้างโดยบุคคลที่สามได้ที่ https://www.openssl.org/community/binaries.html อย่างไรก็ตาม ทีม OpenSSL ไม่ได้รองรับหรือรับรองบิลด์เหล่านี้ในลักษณะใดๆ โดยเฉพาะ

การรับ Wireshark, Tshark หรือ Tcpdump

แม้ว่าระบบปฏิบัติการลีนุกซ์ส่วนใหญ่จะมี wireshark, เครื่องมือบรรทัดคำสั่ง tshark และ tcpdump แต่คุณดูเวอร์ชันที่คอมไพล์ไว้ล่วงหน้าของ 2 รายการแรกสำหรับระบบปฏิบัติการอื่นๆ ได้ที่ https://www.wireshark.org

ดูซอร์สโค้ดของ Tcpdump และ LibPCAP ได้ที่ https://www.tcpdump.org

เอกสารประกอบสําหรับเครื่องมือที่มีประโยชน์เหล่านี้มีอยู่ในคู่มือผู้ใช้ Wireshark, หน้า Man ของ Tshark และหน้า Man ของ Tcpdump ตามลําดับ

การรับเครื่องมือคีย์ Java

เครื่องมือบรรทัดคำสั่ง keytool ควรมาพร้อมกับ Java Development Kit (JDK) หรือ Java Runtime Environment (JRE) ทุกเวอร์ชัน ติดตั้งแอปเหล่านี้เพื่อรับ keytool. อย่างไรก็ตาม การใช้ keytool อาจไม่จำเป็นสำหรับการยืนยันใบรับรองรูท เว้นแต่แอปพลิเคชันจะสร้างขึ้นโดยใช้ Java

สิ่งที่ต้องทำเมื่อเวอร์ชันที่ใช้งานจริงหยุดทำงาน

ขั้นตอนหลักที่คุณต้องทำคือติดตั้งใบรับรองรูทที่จำเป็นจากแพ็กเกจ CA รูทของ Google ที่เชื่อถือได้ลงในที่เก็บใบรับรองรูทที่แอปพลิเคชันของคุณใช้

  1. ทำงานร่วมกับผู้ดูแลระบบเพื่ออัปเกรดที่เก็บใบรับรองรูทในเครื่อง
  2. โปรดดูคำแนะนำที่ตรงกับระบบของคุณในคำถามที่พบบ่อยนี้
  3. หากต้องการความช่วยเหลือเพิ่มเติมเกี่ยวกับแพลตฟอร์มหรือระบบที่เฉพาะเจาะจง โปรดติดต่อช่องทางการสนับสนุนทางเทคนิคที่ผู้ให้บริการระบบของคุณมอบให้
  4. หากต้องการความช่วยเหลือทั่วไป โปรดติดต่อทีมสนับสนุนของเราตามที่อธิบายไว้ในส่วนการติดต่อทีมสนับสนุนของ Google Maps Platform หมายเหตุ: สำหรับปัญหาเฉพาะแพลตฟอร์ม เราจะให้คำแนะนำอย่างดีที่สุดเท่านั้น
  5. ติดดาวปัญหาสาธารณะ 186840968 สำหรับอัปเดตที่เกี่ยวข้องกับการย้ายข้อมูลในภายหลัง

การติดต่อทีมสนับสนุนของ Google Maps Platform

การแก้ปัญหาเบื้องต้น

ดูวิธีการแก้ปัญหาทั่วไปได้ที่ส่วนวิธีตรวจสอบว่าที่เก็บใบรับรองรูทของฉันต้องอัปเดตหรือไม่

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

หากปัญหาไม่ได้รับการแก้ไขและคุณตัดสินใจติดต่อฝ่ายสนับสนุนของ Google Maps Platform โปรดเตรียมข้อมูลต่อไปนี้ด้วย

  1. เซิร์ฟเวอร์ที่ได้รับผลกระทบอยู่ที่ไหน
  2. บริการของคุณกำลังเรียกใช้ที่อยู่ IP ใดของ Google
  3. API ใดที่ได้รับผลกระทบจากปัญหานี้
  4. ปัญหาเกิดขึ้นเมื่อไหร่

  5. เอาต์พุตของคำสั่งต่อไปนี้

    curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

ดูวิธีการรับเครื่องมือที่จำเป็นได้ที่คำถามฉันจะหาซื้อเครื่องมือที่จำเป็นได้จากที่ใด

การยื่นเคสขอรับความช่วยเหลือ

โปรดทำตามวิธีการสร้างเคสขอรับความช่วยเหลือในส่วนการสนับสนุนและแหล่งข้อมูลของ Google Maps Platform

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

  • ที่อยู่ IP สาธารณะของคุณคืออะไร
  • ที่อยู่ IP สาธารณะของเซิร์ฟเวอร์ DNS คืออะไร
  • หากเป็นไปได้ การบันทึกแพ็กเก็ต tcpdump หรือ Wireshark ของการเจรจา TLS ที่ล้มเหลวกับ https://maps.googleapis.com/ ในรูปแบบ PCAP จะใช้จำนวนสแนปชอตที่มีขนาดใหญ่พอในการจับภาพแพ็กเก็ตทั้งหมดโดยไม่ตัดให้สั้นลง (เช่น การใช้ -s0 ใน tcpdump เวอร์ชันเก่า)
  • หากเป็นไปได้ บันทึกที่ตัดตอนมาจากบริการของคุณซึ่งแสดงสาเหตุของความล้มเหลวในการเชื่อมต่อ TLS ที่แน่นอน หากเป็นไปได้ให้ใส่ข้อมูลเชนใบรับรองเซิร์ฟเวอร์แบบเต็ม

ดูวิธีการใช้เครื่องมือที่จำเป็นในคำถามฉันจะหาเครื่องมือที่ต้องการได้จากที่ใด

โพสต์เกี่ยวกับปัญหาสาธารณะ 186840968

เมื่อโพสต์ความคิดเห็นเกี่ยวกับปัญหาสาธารณะ 186840968 ขอให้ระบุข้อมูลในส่วนการแก้ปัญหาเบื้องต้น

ฉันจะระบุที่อยู่สาธารณะของ DNS ได้อย่างไร

ใน Linux คุณเรียกใช้คำสั่งต่อไปนี้ได้

dig -t txt o-o.myaddr.l.google.com

ใน Windows คุณใช้ nslookup ในโหมดอินเทอร์แอกทีฟได้ ดังนี้

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

วิธีตีความเอาต์พุตของ curl

การเรียกใช้ curl ด้วยแฟล็ก -vvI จะให้ข้อมูลที่เป็นประโยชน์มาก วิธีการตีความเอาต์พุตมีดังนี้

  • บรรทัดที่ขึ้นต้นด้วย "*" จะแสดงเอาต์พุตจากการเจรจา TLS รวมถึงข้อมูลการสิ้นสุดการเชื่อมต่อ
  • บรรทัดที่ขึ้นต้นด้วย ">" จะแสดงคำขอ HTTP ขาออกที่ curl ส่ง
  • บรรทัดที่ขึ้นต้นด้วย "<" จะแสดงการตอบกลับ HTTP ที่ได้รับจากเซิร์ฟเวอร์
  • หากโปรโตคอลเป็น HTTPS การมีบรรทัด ">" หรือ "<" หมายความว่า TLS จับมือกันสำเร็จ

ใช้กลุ่มใบรับรองรูทและไลบรารี TLS

การรัน curl ด้วย Flag -vvI จะพิมพ์ที่เก็บใบรับรองรูทที่ใช้ด้วย แต่เอาต์พุตที่แน่นอนอาจแตกต่างกันไปตามระบบตามที่แสดงที่นี่

เอาต์พุตจากเครื่อง Red Hat Linux ที่มี curl ลิงก์กับ NSS อาจประกอบด้วยบรรทัดต่อไปนี้

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

เอาต์พุตจากเครื่อง Ubuntu หรือ Debian Linux อาจมีบรรทัดต่อไปนี้

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

เอาต์พุตจากเครื่อง Ubuntu หรือ Debian Linux โดยใช้ไฟล์ PEM ของใบรับรองรูทของ Google ที่ใช้แฟล็ก --cacert อาจมีบรรทัดต่อไปนี้

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

User Agent

คำขอขาออกจะมีส่วนหัว User-Agent ซึ่งอาจให้ข้อมูลที่เป็นประโยชน์เกี่ยวกับ curl และระบบของคุณ

ตัวอย่างจากเครื่อง Red Hat Linux

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

แฮนด์เชค TLS ล้มเหลว

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

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

แฮนด์เชค TLS สําเร็จ

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

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

วิธีพิมพ์ใบรับรองเซิร์ฟเวอร์ที่ได้รับในรูปแบบที่มนุษย์อ่านได้

สมมติว่าเอาต์พุตอยู่ในรูปแบบ PEM เช่น เอาต์พุตจาก openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null คุณสามารถพิมพ์ใบรับรองที่แสดงได้โดยทำตามขั้นตอนต่อไปนี้

  • คัดลอกใบรับรองที่เข้ารหัส Base 64 ทั้งหมด รวมถึงส่วนหัวและส่วนท้าย

    -----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

  • จากนั้นให้ทำดังนี้

    openssl x509 -inform pem -noout -text
````

  • จากนั้นวางเนื้อหาของบัฟเฟอร์สำเนาลงในเทอร์มินัล

  • กดปุ่ม Return

ดูตัวอย่างอินพุตและเอาต์พุตได้ที่ส่วนวิธีพิมพ์ใบรับรอง PEM ในรูปแบบที่มนุษย์อ่านได้

ใบรับรองของ Google แบบข้ามการรับรองมีลักษณะอย่างไรใน OpenSSL

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

การจัดการใบรับรองที่เชื่อถือได้

ฉันจะตรวจสอบใบรับรองรูทที่เชื่อถือได้ในโทรศัพท์มือถือได้อย่างไร

ใบรับรองที่เชื่อถือได้ของ Android

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

เวอร์ชันของ Android เส้นทางเมนู
1.x, 2.x, 3.x ไม่มี
4.x, 5.x, 6.x, 7.x การตั้งค่า > ความปลอดภัย > ข้อมูลเข้าสู่ระบบที่เชื่อถือได้
8.x 9 การตั้งค่า > ความปลอดภัยและตำแหน่ง > การเข้ารหัสและข้อมูลเข้าสู่ระบบ > ข้อมูลเข้าสู่ระบบที่เชื่อถือได้
10+ การตั้งค่า > ความปลอดภัย > ขั้นสูง > การเข้ารหัสและข้อมูลเข้าสู่ระบบ > ข้อมูลเข้าสู่ระบบที่เชื่อถือได้

ตารางนี้แสดงแนวโน้มที่จะมีใบรับรองรูทที่สำคัญที่สุดสำหรับ Android แต่ละเวอร์ชัน โดยอิงตามการยืนยันด้วยตนเองโดยใช้อิมเมจระบบของอุปกรณ์เสมือน (AVD) ของ Android ที่มีให้บริการในปัจจุบัน ซึ่งจะเปลี่ยนไปใช้ประวัติเวอร์ชันของที่เก็บ Git ca-certificates ของ AOSP หากไม่มีอิมเมจระบบให้บริการแล้ว

เวอร์ชันของ Android GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (ใช้ได้ถึงวันที่ 15 ธ.ค. 2021)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

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

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

อย่างไรก็ตาม เนื่องจากนักพัฒนาแอปพลิเคชันบุคคลที่สามไม่สามารถกำหนดค่าความปลอดภัยของเครือข่ายสำหรับการรับส่งข้อมูลที่มาจาก Google Play Services APK ได้ การดำเนินการดังกล่าวจึงอาจช่วยแก้ปัญหาได้เพียงบางส่วนเท่านั้น

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

iOS Trust Store

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

อย่างไรก็ตาม ใบรับรองเพิ่มเติมใดๆ ที่ติดตั้งในอุปกรณ์ iOS ควรจะปรากฏในการตั้งค่า > ทั่วไป > โปรไฟล์ หากไม่ได้ติดตั้งใบรับรองเพิ่มเติม รายการเมนูโปรไฟล์อาจไม่แสดง

ตารางนี้แสดงความพร้อมใช้งานของใบรับรองรูทที่สำคัญที่สุดตามเวอร์ชัน iOS โดยอิงตามแหล่งที่มาข้างต้น

เวอร์ชัน iOS GTS Root R1 GlobalSign Root CA - R1 GlobalSign Root R2 (ใช้ได้ถึงวันที่ 15 ธ.ค. 2021)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

ใบรับรองรูทของระบบของฉันจัดเก็บไว้ที่ใดและฉันจะอัปเดตได้อย่างไร

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

  • /usr/local/share/ca-certificates: Debian, Ubuntu, RHEL และ CentOS เวอร์ชันเก่า
  • /etc/pki/ca-trust/source/anchors และ /usr/share/pki/ca-trust-source: Fedora, RHEL และ CentOS เวอร์ชันใหม่
  • /var/lib/ca-certificates: OpenSUSE

เส้นทางใบรับรองอื่นๆ อาจรวมถึง

  • /etc/ssl/certs: Debian, Ubuntu
  • /etc/pki/tls/certs: RHEL, CentOS

ใบรับรองบางรายการในไดเรกทอรีเหล่านี้มีแนวโน้มที่จะเป็นลิงก์สัญลักษณ์ไปยังไฟล์ในไดเรกทอรีอื่น

ร้านค้าใบรับรองรูท OpenSSL

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

openssl version -d

คำสั่งจะแสดงผล OPENSSLDIR ซึ่งสอดคล้องกับไดเรกทอรีระดับบนสุดที่คุณจะดูไลบรารีและการกำหนดค่าได้

OPENSSLDIR: "/usr/lib/ssl"

ที่เก็บใบรับรองรูทอยู่ในไดเรกทอรีย่อย certs

ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

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

ดูวิธีการรับ openssl ได้ที่ส่วนการรับ OpenSSL

ร้านค้าใบรับรองรูทของ Java

แอปพลิเคชัน Java อาจใช้ที่เก็บใบรับรองรูทของตนเอง ซึ่งในระบบ Linux มักจะอยู่ที่ /etc/pki/java/cacerts หรือ /usr/share/ca-certificates-java ซึ่งจัดการได้โดยใช้เครื่องมือบรรทัดคำสั่ง keytool ของ Java

หากต้องการนําเข้าใบรับรองแต่ละใบไปยังที่เก็บใบรับรอง Java ให้ใช้คําสั่งต่อไปนี้ 

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

เพียงแทนที่ cert.pem ด้วยไฟล์ใบรับรองที่เกี่ยวข้องกับใบรับรองรูทที่แนะนำแต่ละรายการ alias ด้วยชื่อแทนใบรับรองที่ไม่ซ้ำกันแต่มีความหมาย และ certs.jks ด้วยไฟล์ฐานข้อมูลใบรับรองที่ใช้ในสภาพแวดล้อมของคุณ

โปรดดูข้อมูลเพิ่มเติมในบทความต่อไปนี้ของ Oracle และ Stack Overflow

ร้านค้าใบรับรองรูท NSS ของ Mozilla

โดยค่าเริ่มต้น แอปพลิเคชันที่ใช้ Mozilla NSS อาจใช้ฐานข้อมูลใบรับรองทั้งระบบที่โดยทั่วไปอยู่ภายใต้ /etc/pki/nssdb หรือร้านค้าเริ่มต้นเฉพาะของผู้ใช้ภายใต้ ${HOME}/.pki/nssdb ด้วยเช่นกัน

หากต้องการอัปเดตฐานข้อมูล NSS ให้ใช้เครื่องมือ certutil

หากต้องการนําเข้าไฟล์ใบรับรองแต่ละไฟล์ไปยังฐานข้อมูล NSS ให้ใช้คําสั่งต่อไปนี้

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

เพียงแทนที่ cert.pem ด้วยไฟล์ใบรับรองที่สอดคล้องกับใบรับรองรูทที่แนะนำแต่ละรายการ แทนที่ cert-name ด้วยชื่อเล่นใบรับรองที่สื่อความหมาย และแทนที่ certdir ด้วยเส้นทางฐานข้อมูลใบรับรองที่ใช้ในสภาพแวดล้อม

ดูข้อมูลเพิ่มเติมได้ที่คู่มืออย่างเป็นทางการของ NSS Tools certutil รวมถึงเอกสารประกอบของระบบปฏิบัติการ

ที่เก็บใบรับรองรูทของ Microsoft .NET

นักพัฒนาซอฟต์แวร์ Windows .NET อาจพบว่าบทความของ Microsoft ต่อไปนี้มีประโยชน์ในการอัปเดตที่เก็บใบรับรองรูท

รูปแบบไฟล์ใบรับรอง

ไฟล์ PEM คืออะไร

Privacy- Enhanced Mail (PEM) คือรูปแบบไฟล์ข้อความมาตรฐานที่ไม่เป็นความจริงสำหรับการจัดเก็บและส่งใบรับรองการเข้ารหัสลับ คีย์ ฯลฯ โดยได้รับการจัดเป็นมาตรฐานที่ไม่ได้รับอนุญาตใน RFC 7468

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

เครื่องมือ เช่น openssl ยังใช้เพื่อถอดรหัสใบรับรองทั้งหมดเป็นรูปแบบที่มนุษย์อ่านได้ ดูข้อมูลเพิ่มเติมได้ที่ส่วนวิธีพิมพ์ใบรับรอง PEM ในรูปแบบที่มนุษย์อ่านได้

ไฟล์ ".crt" คืออะไร

เครื่องมือที่อนุญาตให้ส่งออกใบรับรองในรูปแบบ PEMมักใช้นามสกุลไฟล์ ".crt" เพื่อระบุว่าไฟล์ใช้การเข้ารหัสข้อความ

ไฟล์ DER คืออะไร

กฎการเข้ารหัสที่โดดเด่น (DER) เป็นรูปแบบไบนารีมาตรฐานสำหรับการเข้ารหัสใบรับรอง ใบรับรองในไฟล์ PEM โดยทั่วไปคือใบรับรอง DER ที่เข้ารหัส Base64

ไฟล์ ".cer" คืออะไร

ไฟล์ที่ส่งออกซึ่งมีนามสกุล ".cer" อาจมีใบรับรองที่เข้ารหัสด้วย PEM แต่โดยทั่วไปจะเป็นไฟล์ไบนารีซึ่งเป็นใบรับรองที่เข้ารหัสด้วย DER ตามแบบแผน โดยทั่วไปไฟล์ ".cer" จะมีใบรับรองเพียงใบเดียว

ระบบปฏิเสธการนำเข้าใบรับรองทั้งหมดจากroots.pem

ระบบบางอย่าง เช่น Java keytool จะนำเข้าใบรับรองได้เพียงใบเดียวจากไฟล์ PEM แม้ว่าจะมีใบรับรองหลายใบก็ตาม ดูคำถาม ฉันจะแยกใบรับรองแต่ละรายการออกจากroots.pem ได้อย่างไร เพื่อดูวิธีแยกไฟล์ก่อน

ฉันจะแยกใบรับรองแต่ละรายการจากroots.pem ได้อย่างไร

คุณแยก roots.pem ออกเป็นใบรับรองคอมโพเนนต์ได้โดยใช้สคริปต์ Bash ง่ายๆ ต่อไปนี้

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

ซึ่งจะสร้างไฟล์ PEM หลายไฟล์ที่คล้ายกับไฟล์ที่แสดงที่นี่

ls -l *.pem
-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

คุณจะนำเข้าไฟล์ PEM แต่ละรายการ เช่น 02265526.pem แยกต่างหาก หรือแปลงเป็นรูปแบบไฟล์ที่ที่เก็บใบรับรองยอมรับได้เพิ่มเติม

วิธีแปลงระหว่างไฟล์ PEM กับรูปแบบที่ระบบรองรับ

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

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

ดูวิธีการรับ openssl ได้ที่ส่วนการรับ OpenSSL

ฉันจะแปลงไฟล์ PEM เป็นรูปแบบ DER ได้อย่างไร

เมื่อใช้ openssl คุณออกคำสั่งต่อไปนี้เพื่อแปลงไฟล์จาก PEM เป็น DER ได้

openssl x509 -in roots.pem -outform der -out roots.der
ฉันจะแปลงไฟล์ PEM เป็น PKCS #7 ได้อย่างไร

เมื่อใช้ openssl คุณสามารถออกคำสั่งต่อไปนี้เพื่อแปลงไฟล์จาก PEM เป็น PKCS #7

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b
ฉันจะแปลงไฟล์ PEM เป็น PKCS #12 (PFX) ได้อย่างไร

เมื่อใช้ openssl คุณสามารถออกคำสั่งต่อไปนี้เพื่อแปลงไฟล์จาก PEM เป็น PKCS #12

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

คุณต้องระบุรหัสผ่านของไฟล์เมื่อสร้างที่เก็บถาวร PKCS #12 โปรดเก็บรหัสผ่านไว้ในที่ปลอดภัย หากไม่ได้นำเข้าไฟล์ PKCS #12 ลงในระบบทันที

การแสดงรายการ พิมพ์ และส่งออกใบรับรองจากที่เก็บใบรับรองรูท

ฉันจะส่งออกใบรับรองจาก Java Key Store เป็นไฟล์ PEM ได้อย่างไร

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

keytool -v -list -keystore certs.jks

เพียงแทนที่ certs.jks ด้วยไฟล์ฐานข้อมูลใบรับรองที่ใช้ในสภาพแวดล้อมของคุณ คำสั่งนี้จะแสดงชื่อแทนของใบรับรองแต่ละรายการด้วย ซึ่งคุณจะต้องระบุหากต้องการส่งออก

หากต้องการส่งออกใบรับรองแต่ละรายการในรูปแบบ PEM ให้ใช้คำสั่งต่อไปนี้

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

เพียงแทนที่ certs.jks ด้วยไฟล์ฐานข้อมูลใบรับรองที่ใช้ในสภาพแวดล้อมของคุณ แล้วระบุ alias และ alias.pem ที่สอดคล้องกับใบรับรองที่ต้องการส่งออก

สำหรับข้อมูลเพิ่มเติม โปรดดูที่คู่มือแพลตฟอร์ม Java, ข้อมูลอ้างอิงเครื่องมือ Standard Edition: keytool

ฉันจะส่งออกใบรับรองจากที่เก็บใบรับรองรูท NSS เป็นไฟล์ PEM ได้อย่างไร

เมื่อใช้ certutil คุณออกคำสั่งต่อไปนี้เพื่อแสดงรายการใบรับรองทั้งหมดในที่เก็บใบรับรองได้ พร้อมกับชื่อเล่นที่คุณใช้ส่งออกใบรับรองทั้งหมดได้

certutil -L -d certdir

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

หากต้องการส่งออกใบรับรองแต่ละรายการในรูปแบบ PEM ให้ใช้คำสั่งต่อไปนี้

certutil -L -n cert-name -a -d certdir > cert.pem

เพียงแทนที่ certdir ด้วยเส้นทางฐานข้อมูลใบรับรองที่ใช้ในสภาพแวดล้อม แล้วระบุ cert-name และ cert.pem ที่สอดคล้องกับใบรับรองที่ต้องการส่งออก

ดูข้อมูลเพิ่มเติมได้ที่คู่มืออย่างเป็นทางการของ NSS Tools certutil รวมถึงเอกสารประกอบของระบบปฏิบัติการ

วิธีพิมพ์ใบรับรอง PEM ในรูปแบบที่มนุษย์อ่านได้

ในตัวอย่างต่อไปนี้ เราสมมติว่าคุณมีไฟล์ GTS_Root_R1.pem ที่มีเนื้อหาต่อไปนี้

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----
การพิมพ์ไฟล์ใบรับรองโดยใช้ OpenSSL

การออกคำสั่ง

openssl x509 -in GTS_Root_R1.pem -text

ควรแสดงผลลัพธ์ที่คล้ายกับตัวอย่างต่อไปนี้

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

ดูวิธีการรับ openssl ได้ที่ส่วนการรับ OpenSSL

การพิมพ์ใบรับรองโดยใช้ Java Keytool

การออกคำสั่งต่อไปนี้

keytool -printcert -file GTS_Root_R1.pem

ควรแสดงผลในลักษณะต่อไปนี้

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

ดูวิธีการรับ keytool ได้ที่ส่วนการรับ Java Keytool

ฉันจะดูว่าติดตั้งใบรับรองใดไว้ในที่เก็บใบรับรองรูทบ้างได้อย่างไร

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

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

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

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

ไฟล์นี้อาจมีแค่ส่วนของใบรับรองเท่านั้น ในกรณีเช่นนี้ ชื่อไฟล์ เช่น GTS_Root_R1.pem อาจอธิบายว่าใบรับรองเป็นของ CA ใด นอกจากนี้ เรายังรับประกันว่าสตริงใบรับรองระหว่างโทเค็น -----BEGIN CERTIFICATE----- กับ -----END CERTIFICATE----- จะไม่ซ้ำกันสำหรับ CA แต่ละราย

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

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

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

ภาคผนวก

หากต้องการข้อมูลเพิ่มเติม

โปรดใช้เอกสารประกอบของระบบปฏิบัติการ เอกสารประกอบของภาษาโปรแกรมแอปพลิเคชัน และเอกสารประกอบจากไลบรารีภายนอกที่แอปพลิเคชันของคุณใช้เป็นหลักเสมอ

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

โปรดดูคำถามที่พบบ่อยเกี่ยวกับ Google Trust Services ด้วย

หากต้องการรายละเอียดเพิ่มเติมเกี่ยวกับหัวข้อขั้นสูง เช่น การปักหมุดใบรับรอง ให้อ่านบทความ Open Web Application Security Project (OWASP) การปักหมุดใบรับรองและคีย์สาธารณะ และข้อมูลสรุปของการปักหมุด หากต้องการทราบวิธีการเฉพาะสำหรับ Android โปรดดูเอกสารการฝึกอบรมอย่างเป็นทางการเกี่ยวกับแนวทางปฏิบัติแนะนำสำหรับความปลอดภัยและความเป็นส่วนตัวของ Android การรักษาความปลอดภัยด้วย HTTPS และ SSL หากต้องการทราบการพูดคุยเกี่ยวกับใบรับรองกับการปักหมุดคีย์สาธารณะใน Android คุณอาจพบว่าบล็อกโพสต์ของ Matthew Dolan เรื่องการรักษาความปลอดภัยของ Android: การปักหมุด SSL มีประโยชน์

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

ดูรายการ CA รูททั้งหมดที่ AOSP เชื่อถือได้ที่ที่เก็บ Git ของ ca-certificates สําหรับเวอร์ชันใดก็ตามที่ใช้ Android Fork ที่ไม่เป็นทางการ เช่น LineageOS โปรดดูที่เก็บที่เหมาะสมจากผู้ให้บริการระบบปฏิบัติการ