เอกสารนี้ประกอบด้วยส่วนต่างๆ ดังต่อไปนี้
โปรดดูภาพรวมโดยละเอียดเพิ่มเติมเกี่ยวกับการย้ายข้อมูล CA รูทของ Google ที่ดำเนินอยู่ที่หัวข้อเกิดอะไรขึ้น
คำศัพท์
เราได้รวบรวมรายการคำศัพท์ที่สำคัญที่สุดที่คุณต้องคุ้นเคยสำหรับเอกสารนี้ไว้ที่ด้านล่าง หากต้องการดูภาพรวมที่ครอบคลุมยิ่งขึ้นของคำศัพท์ที่เกี่ยวข้อง โปรดไปที่คำถามที่พบบ่อยเกี่ยวกับ Google Trust Services
- ใบรับรอง SSL/TLS
- ใบรับรองจะผูกคีย์การเข้ารหัสกับข้อมูลประจำตัว
- ใบรับรอง SSL/TLS ใช้เพื่อตรวจสอบสิทธิ์และสร้างการเชื่อมต่อที่ปลอดภัยกับเว็บไซต์ ใบรับรองจะออกและลงชื่อแบบเข้ารหัสโดยเอนทิตีที่เรียกว่าผู้ออกใบรับรอง
- เบราว์เซอร์จะใช้ใบรับรองที่ออกโดยผู้ออกใบรับรองที่เชื่อถือได้เพื่อให้ทราบว่า ระบบส่งข้อมูลที่ส่งไปยังเซิร์ฟเวอร์ที่ถูกต้องและมีการเข้ารหัสขณะส่ง
- Secure Sockets Layer (SSL)
- Secure Sockets Layer เป็นโปรโตคอลที่ใช้งานกันอย่างแพร่หลายที่สุดเพื่อเข้ารหัสการสื่อสารทางอินเทอร์เน็ต โปรโตคอล SSL ไม่ถือว่าปลอดภัยแล้วและไม่ควรนำมาใช้
- Transport Layer Security (TLS)
- Transport Layer Security คือระบบสืบทอดจาก SSL
- ผู้ออกใบรับรอง (CA)
- ผู้ออกใบรับรองเปรียบเสมือนสำนักงานหนังสือเดินทางดิจิทัลสำหรับอุปกรณ์และบุคคล โดยจะออกเอกสารที่มีการป้องกันด้วยการเข้ารหัส (ใบรับรอง) เพื่อยืนยันว่าเอนทิตี (เช่น เว็บไซต์) เป็นบุคคลที่กล่าวอ้าง
- ก่อนที่จะออกใบรับรอง CA มีหน้าที่ยืนยันว่าชื่อในใบรับรองเชื่อมโยงกับบุคคลหรือนิติบุคคลที่ขอ
- คำว่า "ผู้ออกใบรับรอง" อาจหมายถึงทั้ง 2 องค์กร เช่น Google Trust Services และระบบที่ออกใบรับรอง
- ที่เก็บใบรับรองรูท
- ที่เก็บใบรับรองรูทประกอบด้วยชุดผู้ออกใบรับรองที่ผู้จัดหาซอฟต์แวร์แอปพลิเคชันเชื่อถือ เว็บเบราว์เซอร์และระบบปฏิบัติการส่วนใหญ่มีที่เก็บใบรับรองรูทเป็นของตัวเอง
- หากต้องการรวมไว้ในที่เก็บใบรับรองรูท ผู้ออกใบรับรองต้องปฏิบัติตามข้อกำหนดที่เข้มงวดที่กำหนดโดยผู้จัดหาซอฟต์แวร์แอปพลิเคชัน
- โดยปกติแล้วจะรวมถึงการปฏิบัติตามมาตรฐานอุตสาหกรรม เช่น ข้อกำหนดของ CA/Browser Forum
- ผู้ออกใบรับรองรูท
- ผู้ออกใบรับรองรูท (หรือเรียกกันว่าใบรับรองของหน่วยงานนั้น) คือใบรับรองระดับสูงสุดในเชนใบรับรอง
- โดยปกติแล้วใบรับรอง CA ระดับรูทจะมีการลงนามด้วยตนเอง ระบบจะจัดเก็บคีย์ส่วนตัวที่เชื่อมโยงกับคีย์ไว้ในสถานบริการที่ปลอดภัยสูง และเก็บรักษาไว้ในสถานะออฟไลน์เพื่อปกป้องคีย์เหล่านั้นจากการเข้าถึงโดยไม่ได้รับอนุญาต
- ผู้ออกใบรับรองระดับกลาง
- Intermediate Certificate Authority (หรือที่เรียกกันว่าใบรับรองที่ถูกต้อง) คือใบรับรองที่ใช้ลงนามใบรับรองอื่นๆ ในกลุ่มใบรับรอง
- โดยพื้นฐานแล้ว CA ระดับกลางมีไว้เพื่อเปิดใช้การออกใบรับรองออนไลน์ แต่ทำให้ใบรับรอง Root CA สามารถมีสถานะออฟไลน์ต่อไปได้
- CA ระดับกลางยังเรียกว่า CA ย่อย
- ผู้ออกใบรับรองที่ออก
- "ผู้ออกใบรับรองที่ออกใบรับรอง" หรือเรียกกันว่าใบรับรองอย่างถูกต้องคือใบรับรองที่ใช้ในการลงนามใบรับรองด้านล่างสุดในสายใบรับรอง
- ใบรับรองที่อยู่ท้ายสุดนี้โดยทั่วไปเรียกว่าใบรับรองผู้สมัครใช้บริการ ใบรับรองเอนทิตีปลายทาง หรือใบรับรอง Leaf ในเอกสารนี้ เราจะใช้คำว่าใบรับรองเซิร์ฟเวอร์ด้วย
- ชุดใบรับรอง
- ใบรับรองจะลิงก์กับ (ลงนามแบบเข้ารหัสโดย) ผู้ออกบัตร เชนใบรับรองประกอบด้วยใบย่อยสำคัญ ใบรับรองของผู้ออกใบรับรองทั้งหมด และใบรับรองรูท
- การเซ็นชื่อไขว้
- ไคลเอ็นต์ของผู้ให้บริการซอฟต์แวร์แอปพลิเคชันต้องอัปเดตที่เก็บใบรับรองรูทเพื่อรวมใบรับรอง CA ใหม่เพื่อให้ผลิตภัณฑ์เชื่อถือ อาจใช้เวลาสักระยะก่อนที่ผลิตภัณฑ์ที่มีใบรับรอง CA ใหม่จะใช้กันอย่างแพร่หลาย
- ใบรับรอง CA อาจมีการ "ลงชื่อแบบข้าม" โดย CA เก่ารายอื่นที่ได้รับการยอมรับ เพื่อเพิ่มความเข้ากันได้กับไคลเอ็นต์รุ่นเก่า วิธีนี้จะสร้างใบรับรอง CA ใบที่ 2 สำหรับข้อมูลประจำตัวเดียวกัน (ชื่อและคู่คีย์) เดียวกันได้อย่างมีประสิทธิภาพ
- ไคลเอ็นต์จะสร้างสายใบรับรองที่แตกต่างกันจนถึงรูทที่เชื่อถือได้ ทั้งนี้ขึ้นอยู่กับ CA ที่รวมอยู่ในที่เก็บใบรับรองรูท
ข้อมูลทั่วไป
จะเกิดอะไรขึ้น
ภาพรวม
ในปี 2017 Google ได้เริ่มโครงการที่ใช้เวลาหลายปีเพื่อออกและใช้ใบรับรองหลักของตนเอง ซึ่งเป็นลายเซ็นดิจิทัลซึ่งเป็นพื้นฐานของความปลอดภัยทางอินเทอร์เน็ต TLS ที่ HTTPS ใช้
หลังจากระยะแรก GS Root R2 ได้รับการรับประกันความปลอดภัย TLS ของบริการ Google Maps Platform ซึ่งเป็นหน่วยงานผู้ให้การรับรองรูท (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 ที่ออกใหม่ ซึ่งหมายความว่าบริการของเราจะค่อยๆ เปลี่ยนไปใช้ใบรับรองลีฟ TLS ที่ออกโดย CA ใหม่นี้
ไคลเอ็นต์และระบบ TLS สมัยใหม่เกือบทั้งหมดจะได้รับการกำหนดค่าล่วงหน้าด้วยใบรับรอง GTS Root R1 หรือควรได้รับผ่านการอัปเดตซอฟต์แวร์ตามปกติ และ GlobalSign Root CA - R1 ควรจะมีอยู่ในระบบเดิม
อย่างไรก็ตาม คุณควรตรวจสอบระบบอย่างน้อยหากเป็นไปตามเงื่อนไขทั้งสองข้อต่อไปนี้
- บริการของคุณทำงานบนแพลตฟอร์มเดิมหรือแพลตฟอร์มที่ไม่ใช่แบบมาตรฐาน และ/หรือคุณมีที่เก็บใบรับรองรูทของคุณเอง
- คุณไม่ได้ดำเนินการในปี 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 ที่เชื่อถือได้
มีเครื่องมือง่ายๆ ที่ฉันใช้ยืนยันที่เก็บใบรับรองรูทได้ไหม
คุณอาจพบว่าเครื่องมือบรรทัดคำสั่ง 2 รายการ curl และ openssl มีประโยชน์ในการตรวจสอบ ทั้ง 2 อย่างนี้ใช้ได้กับแพลตฟอร์มส่วนใหญ่ และมีตัวเลือกมากมาย
สำหรับการทดสอบการตั้งค่า
สำหรับวิธีการรับ curl โปรดดูที่ส่วนการรับ Curl ด้านล่าง
คำสั่ง openssl ที่แสดงด้านล่างมีไว้สำหรับเวอร์ชัน 1.1.1 ขึ้นไป
เวอร์ชันก่อนหน้า 1.1.1 จะไม่รองรับแล้ว ถ้าคุณใช้เวอร์ชันก่อนหน้า ให้อัปเกรดหรือแก้ไขคำสั่งเหล่านี้ตามความจำเป็นสำหรับเวอร์ชันของคุณ สำหรับวิธีการรับ openssl โปรดดูที่ส่วนการใช้งาน OpenSSL ด้านล่าง
คุณยังสามารถดูเครื่องมือที่มีประโยชน์เพิ่มเติมได้ในส่วนฉันจะหาเครื่องมือที่ต้องการได้จากที่ใดด้านล่าง
ดูวิธีการทดสอบที่เป็นรูปธรรมได้ที่ส่วนวิธีตรวจสอบว่าที่เก็บใบรับรองรูทของฉันจำเป็นต้องอัปเดตหรือไม่
การทดสอบที่เก็บใบรับรองรูทเริ่มต้น
curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.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 จะดำเนินต่อไปอย่างไรและเมื่อใด
- เฟสแรก (การย้ายข้อมูลไปยัง 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) ดังนั้นการจัดการใบรับรองของไคลเอ็นต์ต้องรองรับ 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 ระดับกลางได้ทุกเมื่อ ทั้ง 2 อย่างนี้อาจเกิดขึ้นเมื่อใดก็ได้โดยไม่ต้องแจ้งให้ทราบล่วงหน้า และจะมีผลกับใบรับรองเซิร์ฟเวอร์แต่ละตัว เช่น ใบรับรองที่ 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 เอง, ผู้ผลิตฮาร์ดแวร์ เช่น โทรศัพท์, Set-top box, ทีวี, คอนโซลเกม, เครื่องพิมพ์ เป็นต้น
ดังนั้น จึงเป็นไปได้อย่างยิ่งว่าระบบใดๆ ที่ดูแลอยู่ในปัจจุบันจะรองรับ GTS Root CA ใหม่ของ Google อยู่แล้ว ซึ่งรวมถึง GTS Root R1 และแม้แต่ระบบเดิมก็มีโอกาสสูงที่จะรองรับ GlobalSign Root CA - R1 ซึ่งจะใช้สำหรับใบรับรองที่ Google ออกให้แบบข้ามลายเซ็นตลอดปีต่อๆ ไป
อย่างไรก็ตาม เนื่องจากลำดับเวลาในการรวมใบรับรองของบุคคลที่สามนั้นอยู่นอกเหนือการควบคุมของ Google ส่วนใหญ่แล้ว คำแนะนำทั่วไปที่ดีที่สุดที่เรามอบให้ได้คือเพื่อให้แน่ใจว่าคุณใช้การอัปเดตระบบที่มีอยู่เป็นประจำ
บุคคลที่สามบางราย เช่น โปรแกรมใบรับรอง CA ของ Mozilla อาจบันทึกลำดับเวลาการรวมใบรับรองของพวกเขาเองไว้แล้ว
การแก้ปัญหา
ฉันจะหาเครื่องมือที่ต้องการได้จากที่ไหน
กำลังม้วนกระดาษ
หากการเผยแพร่ระบบปฏิบัติการไม่ได้ระบุ curl คุณดาวน์โหลดได้จาก https://curl.haxx.se/ คุณจะดาวน์โหลดแหล่งที่มาและคอมไพล์เครื่องมือด้วยตนเองหรือดาวน์โหลดไบนารีที่คอมไพล์ไว้ล่วงหน้าก็ได้ หากแพลตฟอร์มของคุณรองรับ
การรับ OpenSSL
หากการเผยแพร่ระบบปฏิบัติการไม่ได้ระบุ openssl คุณจะดาวน์โหลดแหล่งที่มาได้จาก https://www.openssl.org/ และคอมไพล์เครื่องมือ ดูรายชื่อไบนารีที่สร้างโดยบุคคลที่สามได้ใน https://www.openssl.org/community/binaries.html
อย่างไรก็ตาม บิลด์เหล่านี้ไม่รองรับหรือรับรองโดยทีม OpenSSL ด้วยวิธีที่เจาะจง
การรับ Wireshark, Tshark หรือ Tcpdump
แม้ว่า Linux ส่วนใหญ่จะมี wireshark, แต่เครื่องมือบรรทัดคำสั่ง tshark และ tcpdump แต่เวอร์ชัน 2 รายการแรกที่คอมไพล์ไว้ล่วงหน้าสำหรับระบบปฏิบัติการอื่นๆ จะดูได้ที่ https://www.wireshark.org
ดูซอร์สโค้ดของ Tcpdump และ LibPCAP ได้ที่ https://www.tcpdump.org
ดูเอกสารสำหรับเครื่องมือที่มีประโยชน์เหล่านี้ได้ในคู่มือผู้ใช้ Wireshark ในหน้าคู่มือ Tshark และในหน้าคู่มือของ Tcpdump ตามลำดับ
การรับ Java Keytool
ควรจัดส่งเครื่องมือบรรทัดคำสั่ง keytool พร้อมกับ Java
Developerment 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.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
ดังที่พูดถึงในคำถาม แอปบนอุปกรณ์เคลื่อนที่มีความเสี่ยงที่จะหยุดทำงานไหม ตั้งแต่เวอร์ชัน 4.0 เป็นต้นไป Android ได้อนุญาตให้ผู้ใช้เครื่องโทรศัพท์ยืนยันรายการใบรับรองที่เชื่อถือได้ในการตั้งค่า ตารางนี้จะแสดงเส้นทางเมนูการตั้งค่า ดังต่อไปนี้
| เวอร์ชัน Android | เส้นทางเมนู |
|---|---|
| 1.x, 2.x, 3.x | ไม่มีข้อมูล |
| 4.x, 5.x, 6.x, 7.x | การตั้งค่า > การรักษาความปลอดภัย > ข้อมูลรับรองที่เชื่อถือได้ |
| 8.x, 9 | การตั้งค่า > ความปลอดภัยและตำแหน่ง > การเข้ารหัสและข้อมูลเข้าสู่ระบบ > ข้อมูลเข้าสู่ระบบที่เชื่อถือได้ |
| 10+ | การตั้งค่า > การรักษาความปลอดภัย > ขั้นสูง > การเข้ารหัสและข้อมูลเข้าสู่ระบบ > ข้อมูลเข้าสู่ระบบที่เชื่อถือได้ |
ตารางนี้แสดงให้เห็นถึงความพร้อมใช้งานน่าจะของใบรับรองรูทที่สำคัญที่สุดตามเวอร์ชัน Android ตามการยืนยันด้วยตนเองโดยใช้อิมเมจระบบของอุปกรณ์เสมือน Android (AVD) ที่พร้อมใช้งานในปัจจุบัน ซึ่งกลับไปใช้ ca-certificates ตาม AOSP ในประวัติเวอร์ชันของที่เก็บ Git ซึ่งไม่มีอิมเมจระบบอีกต่อไป
| เวอร์ชัน Android | รูท GTS 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 Trust Store
แม้ว่า Apple จะไม่แสดงชุดใบรับรองรูทที่เชื่อถือได้เริ่มต้นโดยตรงต่อผู้ใช้โทรศัพท์ แต่บริษัทก็มีลิงก์ไปยังชุด CA รูทที่เชื่อถือได้สำหรับ iOS เวอร์ชัน 5 ขึ้นไปจากบทความสนับสนุนของ Apple
- รายการใบรับรองรูทที่เชื่อถือได้ใน iOS 12.1.3, macOS 10.14.3, watchOS 5.1.3 และ tvOS 12.1.2
- iOS 5 และ iOS 6: รายการใบรับรองรูทที่เชื่อถือได้
อย่างไรก็ตาม ใบรับรองเพิ่มเติมที่ติดตั้งในอุปกรณ์ iOS ควรปรากฏในการตั้งค่า > ทั่วไป > โปรไฟล์ ถ้าไม่ได้ติดตั้งใบรับรองเพิ่มเติมไว้ รายการเมนูโปรไฟล์อาจไม่แสดง
ตารางนี้แสดงความพร้อมใช้งานของใบรับรองรูทที่สำคัญที่สุด สำหรับ iOS เวอร์ชันตามแหล่งที่มาข้างต้น
| เวอร์ชัน iOS | รูท GTS 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
- แพลตฟอร์ม Java, ข้อมูลอ้างอิงเกี่ยวกับเครื่องมือรุ่นมาตรฐาน: เครื่องมือคีย์
- วิธีดูตำแหน่งของ cacerts ของการติดตั้ง Java เริ่มต้น
- วิธีนำเข้าใบรับรองแบบ Selfsigned ลงใน Java Keystore ที่พร้อมใช้งานกับแอปพลิเคชัน Java ทั้งหมดตามค่าเริ่มต้น
ที่เก็บใบรับรองรูทของ 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 คืออะไร
กฎการเข้ารหัสเฉพาะ (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 เป็นรูปแบบไฟล์ใบรับรองที่ใช้กันโดยทั่วไปแสดงอยู่ด้านล่าง
ดูรายการตัวเลือกทั้งหมดที่ใช้ได้ในเอกสารประกอบเกี่ยวกับ Command Line Utilities ของ 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 Keytool
ฉันจะดูใบรับรองที่ติดตั้งในที่เก็บใบรับรองรูทของฉันได้อย่างไร
ซึ่งจะแตกต่างกันไปตามระบบปฏิบัติการและไลบรารี SSL/TLS อย่างไรก็ตาม โดยทั่วไปเครื่องมือที่อนุญาตให้นำเข้าและส่งออกใบรับรองจากและเข้าหรือออกจากที่จัดเก็บใบรับรองรูทจะมีตัวเลือกในการแสดงใบรับรองที่ติดตั้งไว้
นอกจากนี้ หากคุณส่งออกใบรับรองรูทที่เชื่อถือได้ไปยังไฟล์ PEM ได้สำเร็จ หรือใบรับรองรูทของคุณมีไฟล์ PEM ที่จัดเก็บไว้อยู่แล้ว คุณอาจลองเปิดไฟล์ในโปรแกรมแก้ไขข้อความใดก็ได้เนื่องจากเป็นรูปแบบไฟล์ข้อความธรรมดา
ไฟล์ PEM อาจมีป้ายกำกับอย่างถูกต้อง โดยให้ข้อมูลของผู้ออกใบรับรองที่เกี่ยวข้องที่มนุษย์อ่านได้ (ตัวอย่างจากกลุ่ม CA รูทของ Google ที่เชื่อถือได้) ดังนี้
# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
ไฟล์อาจมีเพียงส่วนของใบรับรอง ในกรณีดังกล่าว ชื่อไฟล์ เช่น GTS_Root_R1.pem อาจอธิบายถึง CA ที่มีใบรับรอง นอกจากนี้ สตริงใบรับรองระหว่างโทเค็น -----BEGIN CERTIFICATE----- และ -----END CERTIFICATE----- จะไม่ซ้ำกันสำหรับ CA แต่ละรายการ
อย่างไรก็ตาม แม้ว่าจะไม่มีเครื่องมือข้างต้น เนื่องจากใบรับรองแต่ละใบในแพ็กเกจ CA หลักที่เชื่อถือได้ของ Google มีการติดป้ายกำกับอย่างถูกต้อง คุณจึงจับคู่ CA รากจากตัวแพ็กเกจได้อย่างน่าเชื่อถือจากที่เก็บใบรับรองรูทของคุณ โดยใช้ Issuer หรือเปรียบเทียบสตริงใบรับรองไฟล์ PEM
เว็บเบราว์เซอร์อาจใช้ที่เก็บใบรับรองรูทของตัวเองหรือจะใช้ใบรับรองที่เป็นค่าเริ่มต้นที่ระบบปฏิบัติการระบุไว้ก็ได้ อย่างไรก็ตาม เบราว์เซอร์ที่ทันสมัยทั้งหมดควรอนุญาตให้คุณจัดการหรือดูชุด CA ระดับรูทที่เบราว์เซอร์นั้นเชื่อถือเป็นอย่างน้อย ดูรายละเอียดเพิ่มเติมได้ที่แอปพลิเคชัน JavaScript มีความเสี่ยงที่จะหยุดทำงานไหม
สำหรับคำแนะนำเฉพาะสำหรับโทรศัพท์มือถือ โปรดดูคำถามแยกต่างหากฉันจะตรวจสอบใบรับรองรูทที่เชื่อถือได้ในโทรศัพท์มือถือของฉันได้อย่างไร
ภาคผนวก
หากต้องการข้อมูลเพิ่มเติม
โปรดใช้เอกสารประกอบของระบบปฏิบัติการเป็นหลัก เอกสารสำหรับภาษาโปรแกรมของแอปพลิเคชัน รวมถึงเอกสารประกอบจากไลบรารีภายนอกที่แอปพลิเคชันของคุณใช้อยู่
แหล่งข้อมูลอื่นๆ รวมถึงคำถามที่พบบ่อยนี้อาจล้าสมัยหรืออาจไม่ถูกต้อง และไม่ควรถือเป็นข้อมูลที่เชื่อถือได้ อย่างไรก็ตาม คุณอาจยังหาข้อมูลที่เป็นประโยชน์ในชุมชนถาม& ตอบในสแต็ก Exchange ได้ เช่นเดียวกับเว็บไซต์ต่างๆ เช่น AdamW ใน Linux และอื่นๆ อีกมากมายและบล็อกการยืนยัน และอื่นๆ
โปรดดูคำถามที่พบบ่อยเกี่ยวกับ Google Trust Services
หากต้องการทราบรายละเอียดเพิ่มเติมเกี่ยวกับหัวข้อขั้นสูง เช่น การปักหมุดใบรับรอง โปรดดูโครงการความปลอดภัยของเว็บแอปพลิเคชันแบบเปิด (OWASP) การปักหมุดใบรับรองและคีย์สาธารณะ บทความและPinning Cheat Sheet ที่ให้ข้อมูล สำหรับคำแนะนำเฉพาะสำหรับ Android โปรดดูเอกสารการฝึกอบรม แนวทางปฏิบัติแนะนำสำหรับความปลอดภัยและความเป็นส่วนตัวของ Android ความปลอดภัยด้วย HTTPS และ SSL อย่างเป็นทางการ สำหรับการสนทนาเกี่ยวกับการปักหมุดใบรับรองกับคีย์สาธารณะใน Android คุณสามารถใช้ประโยชน์จากบล็อกโพสต์ของ Matthew Dolan ได้ Android Security: SSL Pinning
เอกสารการฝึกอบรมแนวทางปฏิบัติแนะนำด้านความปลอดภัยและความเป็นส่วนตัวของ Android การกำหนดค่าความปลอดภัยของเครือข่าย และบล็อกโพสต์ของ JeroenHD Android 7 Nougat และผู้ออกใบรับรองให้ข้อมูลเพิ่มเติมเกี่ยวกับการจัดการใบรับรองที่เชื่อถือได้เพิ่มเติมใน Android
สำหรับรายการทั้งหมดของ CA รูทที่ AOSP เชื่อถือ โปรดดูที่เก็บของ ca-certificates สำหรับเวอร์ชันต่างๆ ที่อิงตามส้อม Android ที่ไม่เป็นทางการ เช่น LineageOS โปรดดูที่เก็บที่เหมาะสมซึ่งผู้ให้บริการระบบปฏิบัติการเตรียมไว้ให้