Score:0

การหมดอายุใบรับรองรูทของบริการแบ็กเอนด์

ธง ru

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

  • เดอะ ราก ใบรับรองจะหมดอายุใน 2022
  • เดอะ ระดับกลาง ใบรับรองจะหมดอายุใน 2031
  • เดอะ ใบไม้ ใบรับรองจะหมดอายุใน 2023

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

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

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

ขอบคุณสำหรับข้อมูลเชิงลึกที่คุณสามารถให้ได้!

### ข้อมูลเพิ่มเติม ###

เราใช้การรับรองความถูกต้อง mTLS ระหว่างบริการภายในของเรา:

  • Hashicorp กงสุล Nomad และ Vault
  • MongoDB
  • บริการอื่นๆ อีกเล็กน้อย

ในกรณีเหล่านี้ เราสามารถค้นหาใบรับรองระดับกลางและระดับต้นได้ แต่ไม่พบใบรับรองหลัก

หากฉันตรวจสอบใบรับรองระดับกลาง ฉันจะเห็นว่าใบรับรองหมดอายุภายใน 1 ปี แม้ว่าใบรับรองหลักจะหมดอายุไปแล้วก็ตาม

ฉันทดสอบใบรับรองเหล่านี้โดยใช้ Terraform เพื่อสร้างเซิร์ฟเวอร์ Consul 3 เครื่องในสภาพแวดล้อมใหม่ ใบรับรองการทดสอบได้รับการติดตั้งในแต่ละอินสแตนซ์ และการหมดอายุของใบรับรองหลักไม่ได้ทำให้เกิดปัญหาใดๆ

br flag
ไม่น่าเป็นไปได้ที่คุณจะทดสอบสิ่งนี้อย่างเพียงพอ ฉันจะไม่ดำเนินการต่ออย่างแน่นอนหากไม่มีการทดสอบเพิ่มเติมอีกมาก อย่างไรก็ตาม คำถามของคุณค่อนข้างคลุมเครือและไม่ได้ให้ข้อมูลอะไรมากนัก คุณได้ทำการทดสอบอะไรบ้าง? บุคคลที่พึ่งพาในสถานการณ์นี้คืออะไร? คุณจำที่จะติดตั้ง root CA ใหม่ที่มีอายุสั้นเป็น trust-anchor ในกลุ่มที่พึ่งพาก่อนที่จะทำการทดสอบหรือไม่
StefB avatar
ru flag
@garethTheRed ขอบคุณสำหรับข้อมูลของคุณ ฉันได้เพิ่มรายละเอียดเพิ่มเติมเล็กน้อยที่ส่วนท้ายของคำอธิบาย เกี่ยวกับการหมดอายุของใบรับรองหลักที่ไม่ก่อให้เกิดปัญหาใดๆ เป็นไปได้ไหมว่านี่เป็นเพราะสมมติฐานคือใบรับรองหลัก *ควร* หมดอายุก่อนใบรับรองระดับกลางและออก นอกจากนี้ หากฉันเข้าใจถูกต้อง ในกรณีที่เลวร้ายที่สุด ฉันสามารถสร้างใบรับรองหลักใหม่โดยใช้ไพรเวตคีย์เดียวกัน และตัวกลางและลีฟจะยังคงใช้งานได้จนกว่าจะหมดอายุ ใช่ไหม
br flag
ได้ หากคุณใช้คีย์เดียวกัน _and_ หัวเรื่องเดียวกัน คุณสามารถแทนที่ใบรับรองรูทที่หมดอายุด้วยใบรับรองใหม่นี้ได้ นั่นอาจเป็นทางเลือกที่ปลอดภัยที่สุดของคุณ คุณบอกว่าคุณตรวจสอบ แต่คุณไม่ได้อธิบายวิธีการ คุณใช้เครื่องมืออะไรในการตรวจสอบ ดูเพิ่มเติมที่ @dave_thompson_085 [ความคิดเห็นด้านล่าง](https://serverfault.com/questions/1083180/backend-services-root-certificate-expiration?noredirect=1#comment1414293_1083221)
StefB avatar
ru flag
ในการทดสอบ ฉันปรับใช้คลัสเตอร์ของ 3 Consul Instance ที่ใช้ mTLS เพื่อสื่อสาร ตามที่ระบุไว้ก่อนหน้านี้ ฉันไม่เห็นข้อผิดพลาดใด ๆ หากฉันทำให้ใบรับรองหลักหมดอายุ แต่ถ้าฉันทำให้ใบรับรองกลางหมดอายุ ฉันจะได้รับข้อผิดพลาดทันที ฉันไม่คิดว่าจะใช้ใบรับรองหลักในสถานการณ์นั้นเลย และฉันจะต้องตรวจสอบบริการภายในอื่นๆ ทั้งหมด ฉันจะวางแผนอัปเดตใบรับรองรูทเพื่อให้แน่ใจว่าเราจะไม่ประสบปัญหาเมื่อรูทปัจจุบันจะหมดอายุ ขอบคุณสำหรับความช่วยเหลือของคุณ!
Score:0
ธง cn

ฟังก์ชันการตรวจสอบใบรับรองที่สอดคล้องกับ RFC 5280 กำหนดให้ใบรับรองทั้งหมดในห่วงโซ่ (รวมถึงใบรับรองรูท) ต้องอยู่ภายในระยะเวลาที่มีผลบังคับใช้ ณ เวลาที่ตรวจสอบความถูกต้อง นั่นคือ ฟังก์ชันการตรวจสอบความถูกต้องของใบรับรองที่เหมาะสมจะล้มเหลวในการตรวจสอบเชนใบรับรองของคุณหลังจากที่รูทหมดอายุ (ในปี 2022)

RFC 5280 §6.1.3.a.3:

ระยะเวลาที่ใช้ได้ของใบรับรองรวมถึงเวลาปัจจุบัน

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

  1. มีใบรับรองข้ามซึ่งเปลี่ยนเส้นทางคุณไปยังรูทอื่น
  2. ฟังก์ชันการตรวจสอบใบรับรองได้รับการกำหนดค่าไม่ถูกต้องและละเว้นข้อผิดพลาดในการตรวจสอบบางอย่าง
dave_thompson_085 avatar
jp flag
5280 ไม่ต้องการ; 6.1.3 ใช้กับ 'certificate i for i in 1..n' ตามที่กำหนดไว้ใน 6.1 ซึ่งไม่รวม trust anchor (เช่น root) -- ซึ่งไม่จำเป็นต้องเป็นใบรับรองเลย และอาจไม่ _have_ ระยะเวลาที่ใช้งานได้หมายเหตุ (b) ในหน้า 73 และชัดเจนยิ่งขึ้นในย่อหน้าที่สองถึงสุดท้ายในหน้า 73 การใช้งาน **ส่วนใหญ่** จะใช้ใบรับรองสำหรับจุดยึด และ TTBOMK จะตรวจสอบความถูกต้อง แต่ข้อยกเว้นที่น่าสังเกตคือ LetsEncrypt กำลังดำเนินการต่อไป ใช้เส้นทางเสริมไปยังราก DST X3 ซึ่งหมดอายุในวันที่ 30 กันยายน เนื่องจากโทรศัพท์ Android รุ่นเก่าที่ยังไม่ได้อัปเดตยังคงเชื่อถือ แต่ _don't_ เชื่อถือราก ISRG X1 (ใหม่กว่า)
cn flag
Let's encrypt แก้ไขปัญหาของพวกเขาโดยใช้ใบรับรองข้าม ไม่งั้นเว็บจะล่ม ซึ่งหมายความว่าต้องมีรูทที่ไม่หมดอายุอย่างน้อยหนึ่งรายการในห่วงโซ่ที่เป็นไปได้ทั้งหมด
dave_thompson_085 avatar
jp flag
แน่นอนว่าไม่จำเป็นสำหรับเชนทั้งหมดที่จะถูกต้อง ITYM จะต้องมี _a_ chain ไปยังรูทที่ยังไม่หมดอายุ แต่นั่นไม่ใช่ความจริงสำหรับ Android ตามที่อธิบายไว้ใน https://letsencrypt.org/2020/12/21/extending-android-compatibility.html (อันที่จริง มันไม่จริงสำหรับ Java โดยทั่วไป แต่ไม่เหมือนกับ Android ที่ฝังอยู่ในอุปกรณ์โดยผู้จำหน่ายที่เลิกสนับสนุน ปกติแล้ว Java บนระบบคอมพิวเตอร์สามารถอัปเดตได้และไม่ต้องการแฮ็คนี้)

โพสต์คำตอบ

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