เหตุใด SSL Cipher-Suite ของ Window จึงถูก จำกัด ภายใต้ใบรับรอง SSL ที่แน่นอน


14

ปัญหา: Windows Server 2008 R2 จะรองรับเฉพาะชุดรหัส ssl ต่อไปนี้เมื่อใช้ใบรับรองบางอย่างบนเซิร์ฟเวอร์:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

สิ่งนี้ป้องกันไม่ให้ไคลเอนต์ XP เชื่อมต่อกับเซิร์ฟเวอร์เนื่องจาก XP Cryptographic API ไม่สนับสนุน ciphers AES ใด ๆ โดยค่าเริ่มต้น
เป็นผลให้ข้อผิดพลาดต่อไปนี้ปรากฏในบันทึกของเซิร์ฟเวอร์เมื่อพยายามเชื่อมต่อโดยใช้อินเทอร์เน็ต explorer หรือเดสก์ท็อประยะไกล (เนื่องจากใช้ CAPI ของ Microsoft)

Schannel Error 36874 "การเชื่อมต่อ TLS 1.0 นั้นได้รับมาจากแอปพลิเคชันไคลเอนต์ระยะไกล แต่ dodne ของชุดรหัสที่รองรับโดยไคลเอนต์นั้นได้รับการสนับสนุนจากเซิร์ฟเวอร์การร้องขอการเชื่อมต่อ SSL ล้มเหลว"
Schannel Error 36888 "การแจ้งเตือนที่ร้ายแรงต่อไปนี้ถูกสร้างขึ้น: 40. สถานะข้อผิดพลาดภายในคือ 1204"


2
Gary หากคุณแก้ไขคำถามของคุณเองโปรดทำเครื่องหมายว่าตอบแล้ว
เบอร์นีไวท์

คำตอบ:


14

หากใบรับรองที่ใช้บนเซิร์ฟเวอร์ถูกสร้างขึ้นโดยใช้ตัวเลือก Legacy Key ในแบบฟอร์มคำขอใบรับรองไพรเวตคีย์สำหรับใบรับรองนั้นจะถูกเก็บไว้ในเฟรมเวิร์ก Cryptographic API ดั้งเดิมของ Microsoft เมื่อเว็บเซิร์ฟเวอร์พยายามประมวลผลคำขอโดยใช้เฟรมเวิร์ก Cryptographic Next Generation (CNG) ใหม่ปรากฏว่ามีบางสิ่งที่เกี่ยวข้องกับคีย์ส่วนตัวของ RSA ที่เก็บไว้ในเฟรมเวิร์กดั้งเดิมไม่สามารถใช้ได้กับเฟรมเวิร์กใหม่ ดังนั้นการใช้ RSA cipher Suites จึงมีข้อ จำกัด อย่างมาก

โซลูชัน:
สร้างคำขอใบรับรองโดยใช้แม่แบบ CNG Key ในตัวช่วยสร้างคำขอใบรับรองที่กำหนดเอง

MMC | ตัวจัดการใบรับรองคอมพิวเตอร์เฉพาะที่ โฟลเดอร์ใบรับรองส่วนบุคคล (คลิกขวา) | งานทั้งหมด -> การทำงานขั้นสูง | สร้างคำขอที่กำหนดเอง | "ดำเนินการต่อโดยไม่มีนโยบายการลงทะเบียน" | เลือก "(ไม่มีเทมเพลต) คีย์ CNG" | ดำเนินการตามคำขอใบรับรองให้เสร็จตามที่คุณต้องการ

การยืนยันว่ารหัสอยู่ในตำแหน่งที่ถูกต้อง:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

เครื่องมือสำหรับการตรวจสอบ cipher-suites ที่ถูกต้อง:
http://pentestit.com/2010/05/16/ssltls-audit-audit-audb-servers-ssl-ciphers/
https://www.ssllabs.com/

การตั้งค่าชุดรหัส SSL:
http://support.microsoft.com/kb/245030
http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order -in-อินเทอร์เน็ตสำรวจ-7-on-หน้าต่าง vista.aspx

เราใช้เวลาหนึ่งสัปดาห์ในการคิดออก ฉันหวังว่านี่จะช่วยคนที่มีปัญหาเดียวกัน


ใครรู้วิธีการทำเช่นนี้ - หรือวิธีการแก้ปัญหา - สำหรับใบรับรองลงนามด้วยตนเอง
MGOwen

ขอบคุณมากสำหรับการทำงานและแบ่งปันผลลัพธ์ของคุณ! เราเปิดเคสการสนับสนุนของ Microsoft และ Microsoft เองไม่สามารถค้นหาสาเหตุที่ลูกค้าไม่สามารถเชื่อมต่อได้ เรามีปัญหาตรงตามที่คุณอธิบาย แต่ตามtechnet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx Microsoft แนะนำให้ใช้เทมเพลต Legacy Key เพื่อเก็บถาวรความเข้ากันได้ที่ดีที่สุด! การทำงานที่ดี!

2

รับปัญหาเดียวกันนี้ด้วยตัวเองอย่างแน่นอนและโพสต์นี้ช่วยฉันได้นานมากขอบคุณมาก!

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

นี่คือวิธี:

openssl pkcs12 -in mycert.pfx -out mycert.cer -nodes

จากนั้นแบ่งไฟล์ cer เป็นสามคีย์ใบรับรองและใบรับรองกลาง [s]

openssl pkcs12 -export -out mycert-new.pfx -inkey mycert.key \
-in mycert.crt -certfile mycert-intermediate.crt

จากนั้นหากคุณนำเข้าไฟล์. pfx ใหม่ลงใน IIS ระบบจะใช้รหัสทั้งหมดที่คุณคาดว่าจะเห็น

ดังนั้นไม่จำเป็นต้องออกใบรับรองใหม่


สิ่งนี้ใช้ได้ผลกับฉันในสถานการณ์ที่คล้ายกัน แต่คำถามตรงข้ามกับคำถามเดิม: บทบาท AD FS บน Windows Server 2012 R2 ต้องการให้คุณใช้ Legacy API สำหรับคำขอใบรับรอง - แต่จากนั้นจะแสดง ciphers 2 AES เพียงอย่างเดียว แสดงไว้ข้างต้น! การส่งออกการทำซ้ำกุญแจด้วย OpenSSL และการนำเข้าอีกครั้งจะแก้ปัญหาเดียวกัน - โปรโตคอลอื่น ๆ ก็เริ่มทำงานได้ทันที ขอบคุณ @gelilloadbad!
eWall

0

ขอบคุณโพสต์ของคุณช่วยฉันแม้ว่าปัญหาของฉันจะไม่เหมือนกันทุกประการ

อย่างไรก็ตามสาเหตุเป็นความผิดพลาดในการกำหนดค่า WINHTTP SERVER API ในส่วนของฉัน IP ของฉันเปลี่ยนไปและเมื่อฉันใส่ใบรับรองเซิร์ฟเวอร์ใหม่ลงในเครื่อง "MY" ฉันไม่สนใจรหัสส่งคืน ALREADY_EXISTS สำหรับ HttpSetServiceConfiguration

ดังนั้นฉันจึงใช้ใบรับรอง TLS ของเซิร์ฟเวอร์ก่อนหน้าซึ่งมีชื่อสามัญผิดและไม่ตรงกับชื่อเซิร์ฟเวอร์ใหม่ของฉัน

หากคุณไม่ทำ HttpDeleteServiceConfiguration () หรือบรรทัดคำสั่ง "netsh http delete sslcert 0.0.0.0:8443" อย่างถูกต้องคุณจะได้รับข้อผิดพลาดที่น่ารังเกียจด้วยอาการเหล่านี้:

1) ใน TLS ไคลเอ็นต์ Hello ของคุณจะได้พบกับแพ็คเก็ต TCP จากเซิร์ฟเวอร์ของคุณทันทีด้วยการตั้งค่า Ack และ Reset bits (ฉันคิดว่าการแจ้งเตือนความล้มเหลวของการจับมือกัน)

2) ตัวแสดงเหตุการณ์ได้รับ "การแจ้งเตือนที่ร้ายแรงต่อไปนี้ถูกสร้างขึ้น: 40 สถานะข้อผิดพลาดภายในคือ 107"

"ได้รับการร้องขอการเชื่อมต่อ SSL 3.0 จากแอปพลิเคชันไคลเอนต์ระยะไกล แต่ไม่มีการรองรับชุดรหัสที่รองรับโดยแอปพลิเคชันไคลเอนต์ไคลเอนต์เซิร์ฟเวอร์ร้องขอการเชื่อมต่อ SSL ล้มเหลว"

ดังนั้นก่อนที่คุณจะไล่จับชุดรหัสไม่ตรงกันให้ตรวจสอบให้แน่ใจว่าคุณใช้ใบรับรองเซิร์ฟเวอร์ที่คุณต้องการใช้กับ:

         netsh http show sslcert

และตรวจสอบค่าแฮช!


คำตอบนี้ไม่ชัดเจนและไม่สมเหตุสมผล คุณควรตั้งเป้าหมายที่จะตอบโดยตรง "ทำไม SSL Cipher-Suite ของ Window ถึงถูก จำกัด ภายใต้ใบรับรอง SSL ที่แน่นอน" และติดตามด้วยคำอธิบายข้อผิดพลาด Schannel
เบอร์นีไวท์

0

นี่อาจเป็นปัญหา KeySpec = 2 - AT_SIGNATURE

certutil -verifystore -v "Thumbprint of cert" ของฉันเพื่อตรวจสอบค่า KeySpec หากเป็น 2 คุณจะต้องส่งออกใบรับรองเป็นไฟล์ PFX จากนั้นเรียกใช้ certutil -importpfx AT_KEYEXCHANGE เพื่อแก้ไข


นั่นคือปัญหาในกรณีของฉันเช่นกัน ในความเป็นจริงคำตอบนี้เป็นเพียงคำตอบเดียวที่พยายามชี้สาเหตุ อย่างไรก็ตามคำตอบจะได้รับประโยชน์จากคำอธิบายว่าทำไม AT_SIGNATURE จึงไม่เพียงพอสำหรับชุดรหัสที่ไม่ใช่ ECDHE - เพราะสำหรับชุดรหัส RSA นั้นไม่เพียง แต่ใช้สำหรับการพิสูจน์ตัวตน (ลายเซ็น) แต่ยังสำหรับการแลกเปลี่ยนคีย์
Jakub Berezanski
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.