Score:10

SSL Certs ที่มีไวด์การ์ดสองตัวทำงานได้หรือไม่ (โดยเฉพาะบน Let's Encrypt)

ธง vn

ฉันต้องการรวมไวด์การ์ดสองใบในใบรับรอง SSL (จะ) ลงนามโดย Let's Encrypt: *.*.thhost3.de. ใบรับรองนี้จะตรงกับชื่อโฮสต์ใดๆ ที่ตรงกับกฎนั้นหรือไม่ (เช่น ตัวอย่าง.example.thhost3.de, สวัสดี.world.thhost3.de) และ Let's Encrypt ยอมรับไวด์การ์ดดังกล่าวในใบรับรองที่ลงนามได้หรือไม่

Score:10
ธง cl
A.B

ไม่สิ่งนี้ไม่ควร (ในความหมายของ RFC ของ "ไม่ควร") ทำงานเป็น บันทึกไว้ใน RFC 6125 (การเป็นตัวแทนและการตรวจสอบบริการแอปพลิเคชันบนโดเมน ข้อมูลประจำตัวภายในโครงสร้างพื้นฐานคีย์สาธารณะทางอินเทอร์เน็ตโดยใช้ X.509 (PKIX) ใบรับรองในบริบทของ Transport Layer Security (TLS)):

หากไคลเอนต์จับคู่ตัวระบุอ้างอิงกับที่นำเสนอ
ตัวระบุซึ่งส่วนชื่อโดเมน DNS มีสัญลักษณ์แทน
อักขระ '*' ใช้กฎต่อไปนี้:

  1. ไคลเอนต์ไม่ควรพยายามจับคู่ตัวระบุที่นำเสนอซึ่งอักขระตัวแทนประกอบด้วยป้ายกำกับอื่นที่ไม่ใช่ ป้ายซ้ายสุด (เช่น ไม่ตรงกับ bar.*.example.net)

  2. หากอักขระตัวแทนเป็นอักขระเดียวของป้ายกำกับซ้ายสุดในตัวระบุที่นำเสนอ ไคลเอนต์ไม่ควรเปรียบเทียบ กับสิ่งใดนอกจากป้ายกำกับด้านซ้ายสุดของตัวระบุอ้างอิง (เช่น *.example.com จะตรงกับ foo.example.com แต่ไม่ bar.foo.example.com หรือ example.com)

[...]

รวมสองสิ่งนี้เข้าด้วยกัน:

  • คุณไม่สามารถมีไวด์การ์ดที่อื่นนอกจากส่วนซ้ายสุด (คั่นด้วยจุด) ของใบรับรอง: ไวลด์การ์ดภายในไม่ถูกต้อง
  • คุณไม่สามารถมีใบรับรองไวด์การ์ดที่ตรงกับส่วนฉลากเพิ่มเติม (เช่น: คั่นด้วยจุด) ทางด้านซ้าย: หมายความว่าหากใช้ไวด์การ์ดเดียวที่ถูกต้อง จะไม่มีส่วนใดที่เหลือเพิ่มเติมที่สามารถจับคู่ได้ (เช่น hello.world thhost3.de ไม่ตรงกับใบรับรอง *.thhost3.de)

สิ่งที่คุณทำได้คือออกใบรับรองที่มีชิ้นส่วน SAN จำนวนมากซึ่งอาจมีไวด์การ์ด (ที่ถูกต้อง) แต่ฉันไม่แน่ใจว่าคุณจะได้รับสิ่งนี้จาก Let's Encrypt หรือไม่

แก้ไข: *.stackexchange.com ลงนามโดย Let's Encrypt ด้วย SAN หลายตัวที่มีไวด์การ์ด

ตัวอย่าง:

$ openssl s_client -เชื่อมต่อ stackexchange.com:443 </dev/null 2>/dev/null| opensl x509 -noout -ข้อความ | grep -A1 'X509v3 Subject Alternative Name' | tr ',' '\n'
            X509v3 ชื่อสำรองของหัวเรื่อง: 
                DNS:*.askubuntu.com
 DNS:*.blogoverflow.com
 DNS:*.mathoverflow.net
 DNS:*.meta.stackexchange.com
 DNS:*.meta.stackoverflow.com
 DNS:*.serverfault.com
 DNS:*.sstatic.net
 DNS:*.stackexchange.com
 DNS:*.stackoverflow.com
 DNS:*.stackoverflow.email
 DNS:*.superuser.com
 DNS:askubuntu.com
 [...]
cn flag
"กำลังออกใบรับรองที่มีชิ้นส่วน SAN จำนวนมาก" ใช่ คุณสามารถออกใบรับรองนั้นได้ (เช่น ใบรับรองที่ลงนามด้วยตนเอง) แต่ไม่มีเบราว์เซอร์ใด (อย่างน้อยเท่าที่ฉันรู้) ยอมรับสิ่งนั้น ดังนั้นสิ่งเหล่านี้จึงไร้ประโยชน์อย่างยิ่ง :)
cn flag
ไม่ สิ่งที่ฉันหมายถึงคือ: ใบรับรองตัวแทนคู่ (หรือมากกว่า) ดังนั้น *.*.serverfault.com จะไม่ได้รับการยอมรับจากเบราว์เซอร์ แม้ว่าคุณจะลงนามใบรับรองดังกล่าวแล้วก็ตาม
A.B avatar
cl flag
A.B
@TobiasMädel อา ใช่ ฉันเห็นด้วยกับสิ่งนี้
ro flag
Tim
มีเหตุผลที่เป็นเอกสารหรือไม่ว่าเหตุใดจึงเป็นสิ่งที่ “ไม่ควร” เมื่อเทียบกับ “สิ่งที่ต้องไม่”
sa flag
และทำไมสิ่งนี้ถึงเป็น "ไม่ควร" ซึ่งตรงข้ามกับ "ต้อง"
U. Windl avatar
it flag
ประเด็นคือว่า RA (Registration Authority) จะยอมรับ CSR (คำขอลงนามใบรับรอง) ดังกล่าวจริงหรือไม่เมื่อเรื่องไม่ได้รับอนุญาต เป็นการสนทนาที่ไร้ประโยชน์ทีเดียวว่าใบรับรองดังกล่าวจะทำอะไรได้เว้นแต่คุณจะได้รับจริงๆ ดูคำจำกัดความของ **ชื่อโดเมน Wildcard** ใน https://letsencrypt.org/documents/isrg-cp-v3.3/

โพสต์คำตอบ

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