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

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

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

คำศัพท์

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

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

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

หากพบปัญหาในการเชื่อมต่อกับบริการ Google Maps Platform คุณควรยืนยันระบบในกรณีต่อไปนี้

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

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

เพื่อช่วยแก้ปัญหานี้

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

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

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

เพื่อให้การเปลี่ยนผ่านนี้ราบรื่น

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

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

อย่างไรก็ตาม คุณควรยืนยันระบบอย่างน้อยหากทั้ง 2 ข้อต่อไปนี้ตรงกับสถานการณ์ของคุณ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • หากสร้างการเชื่อมต่อ TLS กับปลายทางการทดสอบครอสของ GTS Root R1 ได้ คุณจะไม่ได้รับผลกระทบจากการหมดอายุของ 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 Name (SAN) ของ DNS ดังนั้นการจัดการใบรับรองของลูกค้าต้องรองรับ SAN ที่อาจมีไวลด์การ์ดรายการเดียวเป็นป้ายกำกับด้านซ้ายสุดในชื่อ เช่น *.googleapis.com

แม้ว่าระบบจะยังคงรองรับ TLS เวอร์ชันเดิม 1.0 และ 1.1 แต่เราไม่แนะนำให้ใช้ TLS เวอร์ชันเหล่านี้ และขอแนะนำให้ใช้ TLS 1.3 หากเป็นไปได้

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

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

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

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

หากคุณใช้ระบบปฏิบัติการหลักที่ยังคงได้รับการดูแลรักษาและได้รับการอัปเดตเป็นประจำ ที่เก็บใบรับรองรูทเริ่มต้นควรมีใบรับรอง 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

อย่างไรก็ตาม การรองรับ 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

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

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

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

การรับ Keytool ของ 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 โปรดเตรียมข้อมูลต่อไปนี้ให้พร้อม

  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 พร้อม Flag -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 ที่ระบุโดยใช้ Flag --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 ที่มีให้ใช้งานในปัจจุบัน โดยจะใช้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

นักพัฒนาซอฟต์แวร์ .NET ของ Windows อาจพบว่าบทความต่อไปนี้ของ 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 Platform, 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 on Linux and more และconfirm blog และอื่นๆ

โปรดดูคำถามที่พบบ่อยเกี่ยวกับ 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 เวอร์ชันแยกอย่างเป็นทางการ เช่น LineageOS โปรดดูที่ที่เก็บข้อมูลที่เหมาะสมซึ่งจัดหาโดยผู้ให้บริการระบบปฏิบัติการ