หน้านี้ได้รับการแปลโดย Cloud Translation API

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

ประเด็นสำคัญ: เอกสารนี้มีวัตถุประสงค์เพื่อเป็นเครื่องมือช่วยเหลือทั่วไปสำหรับลูกค้า Google Maps Platform ทุกรายที่ต้องการเตรียมแอปพลิเคชันให้พร้อมสำหรับการย้ายข้อมูล CA ในอนาคต แม้ว่าลูกค้าส่วนใหญ่จะไม่สังเกตเห็นการย้ายข้อมูลเหล่านี้ แต่ นักพัฒนาแอปที่ดูแลที่เก็บใบรับรองรูทของตนเอง (Truststore) หรือผู้ที่ ใช้ระบบเดิมที่ผู้ให้บริการระบบไม่ได้อัปเดตอีกต่อไปอาจ ประสบปัญหาบริการหยุดชะงักหากไม่มีใบรับรองรูทที่จำเป็นใหม่ หรือหากคุณปักหมุดไปยังรูทที่เฉพาะเจาะจง หากบริการของคุณหยุดทำงาน เนื่องจากไม่มีใบรับรองรูท โปรดดูสิ่งที่ต้องทำเมื่อเกิดการหยุดทำงานในสภาพแวดล้อมการผลิตด้านล่าง

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

ดูภาพรวมแบบละเอียดเพิ่มเติมได้ที่เรื่องนี้เกี่ยวกับอะไร

คำศัพท์

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

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

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

เรื่องนี้เกี่ยวกับอะไร

สรุป: หากไม่ปฏิบัติตามคำแนะนำที่ https://pki.goog/faq/#connecting-to-google คุณมีแนวโน้มสูงที่จะ ประสบปัญหาการหยุดทำงานที่เกี่ยวข้องกับใบรับรองในอนาคต

ประเด็นสำคัญ: ในปี 2021 Google ได้ทำการย้ายข้อมูลหลายปีไปยังผู้ออกใบรับรอง (CA) รูทของตนเอง Google Trust Services (GTS) ซึ่งเริ่มตั้งแต่ปี 2017 เสร็จสมบูรณ์แล้ว ระบบจะใช้ผู้ออกใบรับรองรูทเพื่อยืนยันความปลอดภัย ของการเชื่อมต่อ TLS ทั้งหมดกับ Google Maps Platform เอกสารนี้อธิบาย วิธีที่นักพัฒนาแอปจะมั่นใจได้ว่าแอปพลิเคชันไคลเอ็นต์ของตนเชื่อมต่อกับบริการของ Google Maps Platform ได้อย่างปลอดภัย โดยใช้ใบรับรองรูทใหม่เหล่านี้ โปรแกรมรูทของระบบปฏิบัติการและเบราว์เซอร์หลักๆ กำหนดให้ใบรับรองรูทมีอายุสั้นลงในอนาคต ดังนั้นการหมุนเวียนดังกล่าวจะเกิดขึ้นด้วยความถี่ที่เพิ่มขึ้น

ภาพรวม

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

หลังจากระยะแรก ความปลอดภัย 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 ก็ได้ซื้อการลงนามข้ามจาก GMO GlobalSign โดยใช้ GlobalSign Root CA - R1 ซึ่งเป็นหนึ่งใน CA รูทที่เก่าแก่ที่สุดและได้รับความน่าเชื่อถือมากที่สุด เพื่อให้มั่นใจว่าระบบเดิมส่วนใหญ่จะเปลี่ยนไปใช้ได้อย่างราบรื่น

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

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

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

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

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

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

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

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

ประเด็นสำคัญ: GS Root R2 ซึ่งเป็นผู้ออกใบรับรองรูท ก่อนหน้านี้ Google Maps Platform ใช้ หมดอายุเมื่อวันที่ 15 ธันวาคม 2021 ดังนั้น บริการของเราจึงต้องเปลี่ยนไปใช้ใบรับรองที่ออกโดยผู้ออกใบรับรองรายอื่น ซึ่งก็คือ GTS Root R1 Cross และนักพัฒนาแอปควรคาดการณ์ว่าไคลเอ็นต์ Google Maps Platform ของตนจะตรวจสอบสิทธิ์กับ CA นี้ในอีกไม่กี่ปีข้างหน้า เพื่อการเปลี่ยนผ่านที่ราบรื่น GTS Root R1 Cross จึงได้รับการลงนามร่วม ทั้งจาก GTS Root R1 ของ Google เองและ GlobalSign Root CA - R1

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

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

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

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

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

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

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

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

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

เราจะประกาศใบรับรองรูทใหม่ที่ https://pki.goog/updates/ และมีฟีด RSS ที่คุณสามารถติดตามเพื่อรับการแจ้งเตือนเกี่ยวกับการอัปเดต เราจะประกาศเฉพาะรูทใหม่เท่านั้น เราจะไม่ประกาศการเปลี่ยนแปลงเชนใบรับรองที่เปลี่ยนระหว่างรูทที่มีอายุการใช้งาน และอาจเกิดขึ้นได้ทุกเมื่อ คุณต้องไม่ปักหมุดไปยังรูทหรืออินเทอร์มีเดียรายการเดียว และต้องเชื่อถือชุดรูททั้งหมดของ Google ที่ระบุไว้ใน https://pki.goog/faq/#connecting-to-google หากต้องการให้มั่นใจว่าการเชื่อมต่อกับ Google จะเชื่อถือได้

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

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

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

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

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

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

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

ทดสอบสภาพแวดล้อมของแอปพลิเคชันกับรูททั้งหมดในส่วน "CA รูท" ของ https://pki.goog/repository/

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

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

ข้อควรระวัง: ลูกค้าที่ใช้ระบบเฉพาะทาง เช่น อุปกรณ์ฝังตัว มิดเดิลแวร์สำหรับแอปพลิเคชันและการผสานรวมระดับองค์กร หรือฐานข้อมูลเชิงสัมพันธ์ ที่เรียกใช้บริการ Google Maps Platform จากกระบวนการที่จัดเก็บไว้ หรือผู้ใช้ ที่ใช้เบราว์เซอร์รุ่นเดิมที่ล้าสมัยหรือระบบปฏิบัติการที่ไม่มีการบำรุงรักษาอีกต่อไป อาจได้รับผลกระทบในแง่ลบจากระยะที่ 2 ของการย้ายข้อมูล CA หลัก โดยเฉพาะหากไม่ได้ดำเนินการใดๆ ในระยะแรก

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

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

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

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

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

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

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

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

ตัวอย่างนี้ใช้สำหรับ GTS R1 และควรทำการทดสอบกับรูท GTS ทั้งหมด

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; \

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ใบรับรอง Google Maps Platform ใช้ Subject Alternative Names (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 อยู่แล้ว

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

สำหรับอุปกรณ์ 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 และ ChromeOS ของ Google เอง ผู้พัฒนาเบราว์เซอร์ เช่น Mozilla, Apple, Microsoft รวมถึงทีม Chrome ของ Google เอง ผู้ผลิตฮาร์ดแวร์ เช่น โทรศัพท์ กล่องรับสัญญาณ ทีวี คอนโซลเกม เครื่องพิมพ์ และอื่นๆ

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

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

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

การแก้ปัญหา

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

การดัดผม

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

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

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

การแก้ปัญหาขั้นแรก

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

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

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

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

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

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;
curl -vvI https://good.gtsr2.demosite.pki.goog/; \
openssl s_client -connect good.gtsr2.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr3.demosite.pki.goog/; \
openssl s_client -connect good.gtsr3.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr4.demosite.pki.goog/; \
openssl s_client -connect good.gtsr4.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

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

เมื่อโพสต์ความคิดเห็นในปัญหาแบบสาธารณะ 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

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

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

{# disableFinding(LINE_OVER_80)}

…
---
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 โดยอิงจากการยืนยันด้วยตนเองโดยใช้อิมเมจระบบของ Android Virtual Device (AVD) ที่มี และย้อนกลับไปที่ประวัติเวอร์ชันของที่เก็บ Git ของ ca-certificates ของ AOSP ในกรณีที่ไม่มีอิมเมจระบบอีกต่อไป

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

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

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

อย่างไรก็ตาม เนื่องจากนักพัฒนาแอปพลิเคชันของบุคคลที่สามจะไม่สามารถมีอิทธิพลต่อ การกำหนดค่าความปลอดภัยของเครือข่ายของการรับส่งข้อมูลที่มาจาก 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 certutil รวมถึงเอกสารประกอบของระบบปฏิบัติการ

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

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

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

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

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

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

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

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

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

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

Distinguished Encoding 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 Platform, Standard Edition: keytool {: .external}

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

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

certutil -L -d certdir

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

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

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

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

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

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

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

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 ได้ที่ส่วน การรับ 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 รูทจากชุดกับ CA รูทจากที่เก็บใบรับรองรูทได้อย่างน่าเชื่อถือ ไม่ว่าจะโดยใช้ Issuer หรือโดยการเปรียบเทียบสตริงใบรับรองไฟล์ PEM

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

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

ภาคผนวก

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

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

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

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

หากต้องการดูข้อมูลเบื้องต้นเกี่ยวกับวิทยาการเข้ารหัส PKI ใบรับรอง และ ห่วงโซ่ใบรับรอง คุณอาจดูเพลย์ลิสต์ PKI Bootcamp บน YouTube โดย Paul Turner

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

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

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

คำศัพท์

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

เรื่องนี้เกี่ยวกับอะไร

ภาพรวม

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

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

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

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

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

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

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

ยืนยันชุด CA รูทที่เชื่อถือได้ของ Google

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การแก้ปัญหา

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

การดัดผม

การรับ OpenSSL

การดาวน์โหลด Wireshark, Tshark หรือ Tcpdump

การรับ Keytool ของ Java

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

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

การแก้ปัญหาขั้นแรก

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

โพสต์ในปัญหาที่เปิดเผยต่อสาธารณะ 186840968

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

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

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

User Agent

แฮนด์เชค TLS ไม่สำเร็จ

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

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

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

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

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

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

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

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

ที่เก็บใบรับรองรูท OpenSSL

ที่เก็บใบรับรองรูทของ Java

ที่เก็บใบรับรองรูทของ Mozilla NSS

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

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

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

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

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

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

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

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

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

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

ฉันจะแปลงไฟล์ PEM เป็น PKCS #7 ได้อย่างไร

ฉันจะแปลงไฟล์ PEM เป็น PKCS #12 (PFX) ได้อย่างไร

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

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

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

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

การพิมพ์ไฟล์ใบรับรองโดยใช้ OpenSSL

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

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

ภาคผนวก

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