เหตุใด Windows 2012 R2 จึงไม่เชื่อถือใบรับรองที่ลงนามด้วยตนเองของฉัน


9

ในสภาพแวดล้อมการทดสอบฉันกำลังถูกระงับการทดสอบบางสิ่งที่ต้องติดตั้งในไม่ช้า (จริง ๆ แล้ว แต่คุณรู้ว่ากำหนดเวลาดำเนินไปอย่างไร ... ) เนื่องจาก Windows ปฏิเสธที่จะเชื่อถือใบรับรองที่ลงนามด้วยตนเองที่เรามีใน สภาพแวดล้อมการทดสอบแบบแยก ในขณะที่ฉันสามารถทำตามขั้นตอนปัญหากับใบรับรอง "ของจริง" และเทคนิค DNS บางประการเพื่อเหตุผลด้านความปลอดภัย / การจำแนกประเภทฉันไม่มีใบรับรองดังกล่าว

ฉันพยายามเชื่อมต่อกับเซิร์ฟเวอร์อีเมลที่ใช้ Linux ชื่อ Zimbra มันกำลังใช้ใบรับรอง OpenSSL ที่ลงชื่อด้วยตนเองที่สร้างขึ้นโดยอัตโนมัติ ในขณะที่หน้าเว็บของ Google ได้เปิดขึ้นโดยเฉพาะอ้างถึงเว็บไซต์ IIS ที่มีใบรับรองที่ลงนามด้วยตนเองของ IIS แต่ฉันไม่คิดว่าวิธีการสร้างหน้าเว็บนั้นเป็นเรื่องสำคัญ

ตามคำแนะนำที่ฉันพบที่นี่และที่นี่สิ่งนี้เป็นเรื่องง่าย ๆ ในการติดตั้งใบรับรองลงในร้านค้า Trusted Root Certification Authority ของเครื่องคอมพิวเตอร์ ซึ่งฉันได้ทำไปแล้วรวมถึงการคัดลอกใบรับรองด้วยตนเองและนำเข้าโดยตรงผ่านสแน็ปอิน MMC การลงชื่อเข้าใช้และการเริ่มระบบใหม่จะไม่เปลี่ยนแปลงอะไรเลย

นี่คือข้อผิดพลาดใบรับรองที่ฉันได้รับทุกครั้ง: ป้อนคำอธิบายรูปภาพที่นี่

และนี่คือเส้นทางการรับรอง (สปอยเลอร์: เป็นเพียงใบรับรองเท่านั้น): ป้อนคำอธิบายรูปภาพที่นี่

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

คำแนะนำเหล่านี้อ้างอิง Vista โดยเฉพาะ (อย่างที่สองไม่ได้พูดถึงระบบปฏิบัติการ) และ IIS ในขณะที่ฉันใช้ Server 2012 R2 เชื่อมต่อกับเซิร์ฟเวอร์ที่ใช้ Linux มีความแตกต่างในตัวช่วยสร้างการนำเข้า (เช่นฉันมีตัวเลือกที่จะนำเข้าสำหรับผู้ใช้ปัจจุบันหรือระบบท้องถิ่นแม้ว่าฉันจะลองทั้งสองอย่าง) ดังนั้นอาจมีบางสิ่งที่แตกต่างที่ฉันต้องทำที่นี่ การตั้งค่าที่ฉันไม่พบที่ต้องเปลี่ยนเพื่อให้เชื่อถือได้จริง ๆใบรับรองที่ฉันได้บอกให้ไว้วางใจ

วิธีที่ถูกต้องในการทำให้ Windows Server 2012 R2 เชื่อถือใบรับรองที่ลงนามด้วยตนเองคืออะไร


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

คุณได้ลองเลือกที่เก็บปลายทางอย่างชัดเจนแล้ว (นำเข้าจากภายในคอนโซล mmc) หรือไม่
JoaoCC

@SujaySarma ไม่ได้มีไว้สำหรับเว็บไซต์ IIS แต่สำหรับแอปพลิเคชั่น Linux ชื่อ Zimbra เป็นใบรับรองที่ลงนามด้วยตนเองของ OpenSSL
Kromey

@ user1703840 ใช่ฉันได้ระบุร้านค้าปลายทางอย่างชัดเจนรวมทั้งอนุญาตให้ Windows เลือกโดยอัตโนมัติผ่านทั้ง MMC และตัวช่วยสร้างการนำเข้าใบรับรองใน IE ผลลัพธ์เดียวกันทั้งสองทางซึ่งไม่มี
Kromey

ฮะ? Linux มาจากไหน คำถามทั้งหมดของคุณและลิงก์ที่คุณโพสต์ (รวมถึงภาพหน้าจอ) จัดการกับ Windows Server 2012 R2 และ IIS กรุณาชี้แจง

คำตอบ:


1

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


ภาพหน้าจอแสดงว่าใบรับรองถูกติดตั้งใน Trusted Root CA และยังแสดงว่าสายโซ่ทั้งหมดเป็นใบรับรองเอง - เป็นรูทดังนั้นจึงอยู่ใน Trusted Root CA น่าจะพอเพียง คำถามคือทำไมมันไม่ได้?
Kromey

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

ลองเรียกใช้คำสั่งนี้บนกล่องที่คุณพยายามรับใบรับรอง: openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 30 -sha256 -nodesและนำเข้าใบรับรองนั้นไปยังที่เก็บ CA หลักที่เชื่อถือได้ (รวมถึงการกำหนดค่าให้เป็นใบรับรองและคีย์ที่ใช้โดย Zimbra แน่นอน)
flashbang

โอ้ฉันเห็นสิ่งที่คุณหมายถึง ขอโทษฉันเข้าใจผิด แต่ถ้าไม่ใช่รูทนั่นจะไม่ปรากฏในหน้าต่างเส้นทางการรับรองหรือไม่ ไม่ว่าในกรณีใดโชคไม่ดีที่ฉันไม่สามารถทดสอบสิ่งนี้ได้อีกต่อไป - ฉันได้รับใบรับรองที่ถูกต้องตามกฎหมายของเราแล้วพร้อมกับการแฮ็กข้อมูลในhostsไฟล์ทำให้ทำงานได้อย่างนั้น
Kromey

ใบรับรองของคุณมาจากรูท CA ขึ้นอยู่กับภาพหน้าจอ หากคุณดูรายละเอียดใบรับรองสำหรับidp.godaddy.comเส้นทางทั้งหมดจะถูกนำเสนอและคุณสามารถใช้สิ่งนั้นเป็นการเปรียบเทียบ หากคุณดูที่คุณสมบัติของใบรับรองใน MMC จะมีการรับรองความถูกต้องของเซิร์ฟเวอร์ในวัตถุประสงค์ของใบรับรองหรือไม่ (คลิกขวาที่ใบรับรองในภาพหน้าจอที่สองและเลือกคุณสมบัติ)
John Auld

1

จากสิ่งที่ฉันสามารถทำงานได้คุณต้องเพิ่ม zmaster เป็น Trusted source CA เนื่องจากเป็นสิทธิ์ในการออก WS2k12 พยายามตรวจสอบใบรับรองกับโฮสต์ที่ไม่รู้อะไรเลย คุณพูดถูกแล้วว่าวิธีการสร้างไม่สำคัญ แต่เป็นแหล่งที่ตรวจสอบได้ นี่เป็นเอฟเฟกต์ที่คุณประสบ: WS2k12 ไม่เชื่อถือใบรับรองเพียงเพราะมีชื่อ $ Random_issuing_authority เท่านั้นจึงต้องสามารถตรวจสอบใบรับรองได้


มันเป็นใบรับรองที่ลงนามด้วยตนเอง - โดยการวางใบรับรองในที่เก็บ Trusted Root CA คุณเป็นผู้กำหนด บริษัท ที่เชื่อถือได้
Chris McKeown

นั่นคือสิ่งที่ฉันได้ทำไปแล้ว - ดูภาพหน้าจอที่สามแสดงใบรับรองของ zmaster ภายใน Trusted Root CA store
Kromey

0

ฉันมีปัญหาเดียวกันกลับกลายเป็นว่าโซลูชันของฉันคืออัปเดตไฟล์. crt และ. key สำหรับเมลเซิร์ฟเวอร์ตามที่ใช้โดย dovecot Exim4 บนจดหมายมีชุดใบรับรอง / คีย์ที่ปรับปรุงแล้ว แต่ dovecot ยังคงชี้ไปที่ชุดใบรับรอง / คีย์เก่า

คู่ใบรับรอง / คีย์เก่าทำงานได้ดีกับสถานการณ์ส่วนใหญ่ แต่ไม่ใช่กับ outlook.com หรือกับ MS Outlook 2013

ปัญหาเกี่ยวกับ outlook.com ทำให้ฉันอัพเกรดใบรับรอง exim4 เมื่อเร็ว ๆ นี้ตอนนี้ dovecot [และเซิร์ฟเวอร์เว็บเมล] ก็ใช้ไฟล์ใบรับรอง (และคีย์) ใหม่ด้วย เมลเซิร์ฟเวอร์เองก็เพิ่งอัพเกรด [จาก Debian squeeze-lts ไปเป็น wheezy] เมื่อเร็ว ๆ นี้การตั้งค่าเก่านั้นใช้ได้ดีกับชุดใบรับรอง / กุญแจเก่า แต่หลังจากการอัพเกรดฉันต้องสร้างชุดใบรับรอง / คีย์ใหม่ก่อน ผลิตภัณฑ์ MS จะทำงานอย่างถูกต้องกับเซิร์ฟเวอร์อีเมล


0

ฉันคิดว่าปัญหาคือคุณเข้าถึงทรัพยากรได้อย่างไร สำหรับเครือข่ายท้องถิ่นของคุณคุณอาจใช้ชื่อโฮสต์แทนชื่อโดเมนแบบเต็ม อย่างไรก็ตามคุณได้ออกใบรับรองกับชื่อโดเมนแบบเต็ม


คำถามนี้มีคำตอบที่ยอมรับแล้ว
BE77Y

-1

ติดตั้งใบรับรองไปยังผู้ออกใบรับรองหลักที่เชื่อถือได้และผู้เผยแพร่ที่เชื่อถือได้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.