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

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

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

ภาพรวม

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

หลังจากผ่านระยะแรกแล้ว Google ได้รับประกันความปลอดภัย TLS ของบริการ Google Maps Platform จาก GS Root R2 ซึ่งเป็นหน่วยงานผู้ให้การรับรองรูท (CA) ที่รู้จักกันอย่างกว้างขวางและกว้างขวาง ซึ่ง Google ได้มาจาก GMO GlobalSign เพื่อช่วยให้การเปลี่ยนไปใช้ CA รูทของ Google Trust Services (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 ได้ใช้ Cross-Sign จาก 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 ซึ่งเป็น CA Google Maps Platform หลักที่เริ่มใช้งานมาตั้งแต่ต้นปี 2018 จะหมดอายุในวันที่ 15 ธันวาคม 2021 ดังนั้นในระหว่างปีนี้ Google จะย้ายข้อมูลไปยัง CA GTS Root R1 Cross ที่ออกใหม่ ซึ่งหมายความว่าบริการของเราจะค่อยๆ เปลี่ยนไปใช้ใบรับรอง Leaf ของ 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 ได้ คุณไม่ควรได้รับผลกระทบจากวันหมดอายุของ GS Root R2
  • หากคุณสร้างการเชื่อมต่อ TLS กับปลายทางการทดสอบ GTS Root R1 ได้ แอปพลิเคชันของคุณอาจได้รับการปกป้องจากการหมดอายุของ GTS Root R1 Cross และ GlobalSign Root CA - R1 ในปี 2028

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

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

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

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

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

เครื่องมือบรรทัดคำสั่ง curl และ openssl ที่มีอยู่ 2 รายการอาจมีประโยชน์ในการตรวจสอบ ทั้ง 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.demo.pki.goog/; \
openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -connect good.gtsr1x.demo.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.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

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

  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 Platform ได้ ในกรณีนี้ ไคลเอ็นต์จะออกคำเตือนว่าการตรวจสอบใบรับรองล้มเหลว

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

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

ใบรับรอง Google Maps Platform ใช้ Subject Alternative Name (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 แบบ Leaf หรือระดับกลาง

การทำเช่นนี้เสี่ยงต่อการทำให้แอปพลิเคชันของคุณเสียหาย ณ จุดที่เราลงทะเบียนใบรับรองใหม่ หรือเปลี่ยน 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

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

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

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

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

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

อย่างไรก็ตาม เนื่องจากลำดับเวลาในการรวมใบรับรองของบุคคลที่สามมักอยู่นอกเหนือการควบคุมของ 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 ในหน้า Tshark และในหน้า Man ของ Tcpdump ตามลำดับ

การรับ Java Keytool

คุณควรจัดส่งเครื่องมือบรรทัดคำสั่ง 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.demo.pki.goog/; \
openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -connect good.gtsr1x.demo.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 ที่มีแฟล็ก -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.demo.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.demo.pki.goog

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

---
…

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

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

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

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

เวอร์ชัน 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 ประวัติเวอร์ชันของที่เก็บ Git ที่อิมเมจระบบไม่พร้อมใช้งานอีกต่อไป

เวอร์ชัน 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 สำหรับความปลอดภัยและความเป็นส่วนตัว การกำหนดค่าความปลอดภัยของเครือข่าย

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

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

ร้านค้าความน่าเชื่อถือของ iOS

แม้ว่า 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 ที่ใช้ อย่างไรก็ตาม ใน Linux ส่วนใหญ่ ใบรับรองรูทเริ่มต้นจะอยู่ในเส้นทางใดเส้นทางหนึ่งต่อไปนี้

  • /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

การจัดเก็บใบรับรองรูท Mozilla NSS

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

การจัดเก็บใบรับรองรูทของ Microsoft .NET

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

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

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

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

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

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

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

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

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

Distinguished Encrypting Rules (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, ข้อมูลอ้างอิงเครื่องมือรุ่นมาตรฐาน: เครื่องมือคีย์

ฉันจะส่งออกใบรับรองจากที่เก็บใบรับรองรูท 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 อย่างเป็นทางการ รวมถึงเอกสารประกอบของระบบปฏิบัติการ

วิธีพิมพ์ใบรับรอง 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

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

ซึ่งจะแตกต่างกันไปตามระบบปฏิบัติการและไลบรารี 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 รูทจากแพ็กเกจดังกล่าวจากที่เก็บใบรับรองรูทตาม 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 Best Practices for Security & Privacy Network Security Configuration และบล็อกโพสต์ของ JeroenHD Android 7 Nougat และผู้ออกใบรับรอง ให้ข้อมูลเพิ่มเติมเกี่ยวกับการจัดการใบรับรองที่เชื่อถือได้เพิ่มเติมใน Android

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