ก่อนแปลง: คีย์ SSH กับใบรับรอง OpenVPN

การนำเข้าล้มเหลวด้วยข้อผิดพลาดใบรับรอง ขั้นตอนที่เห็นได้ชัดจึงดูเหมือนการแปลง ความคิดแบบนั้นพาคนไปในเส้นทางที่นำสกุลไฟล์เปลี่ยน แต่การปฏิเสธยังคงเหมือนเดิมทุกประการ บรรทัด ssh-ed25519 ใน authorized_keys กับใบรับรองไคลเอนต์ OpenVPN เป็นวัตถุข้อมูลรับรองที่แยกจากกัน มีผู้ออก วิธีเข้ารหัส และเส้นทางการเพิกถอนที่ต่างกัน การไล่ตรวจตามลำดับนี้จะบอกคุณได้ภายในหนึ่งนาทีว่าการแปลงช่วยได้หรือไม่

คุณถือวัตถุอะไรอยู่จริง

มีห้าสิ่งที่คนเรียกว่าคีย์ และมีเพียงหนึ่งเดียวที่เป็นสิ่งที่โปรไฟล์ TLS ต้องการ คีย์สาธารณะ SSH คือข้อความหนึ่งบรรทัดที่มีคำนำหน้าชนิดและเพย์โหลด base64 ใบรับรอง OpenSSH คือคีย์นั้นพร้อมลายเซ็น principals และตัวเลือก ซึ่งสร้างโดย ssh-keygen ที่ทำหน้าที่เป็น CA ขนาดเล็กของตัวเอง ใบรับรอง X.509 เป็นโครงสร้างที่ต่างออกไปโดยสิ้นเชิง โดยบรรจุหัวข้อ ช่วงเวลาที่ใช้ได้ ส่วนขยาย และลายเซ็นจากผู้ออกใบรับรอง คีย์ส่วนตัวคือครึ่งที่เป็นความลับ และชุดที่ออกให้มักเป็นใบรับรองพร้อมห่วงโซ่ของมันพร้อมคีย์ส่วนตัวในไฟล์เดียว

การทดสอบแรกใช้คำสั่งเดียว ชี้ openssl ไปที่ไฟล์และขอให้วิเคราะห์โครงสร้างใบรับรอง:

openssl x509 -in client.crt -noout -subject -issuer

ถ้าล้มเหลวด้วยข้อผิดพลาดโหลดไม่ได้หรือ PEM ไฟล์นั้นไม่ใช่ใบรับรอง X.509 ไม่ว่าคุณจะตั้งชื่อว่าอะไร การเปลี่ยนชื่อไม่เขียน ASN.1 ภายในใหม่ และการห่อบรรทัดคีย์สาธารณะด้วยข้อความส่วนหัว PEM ก็ไม่ได้ทำเช่นกัน

โปรไฟล์ขอใบรับรองเลยหรือไม่

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

การกำหนดค่าคีย์แบบคงที่รุ่นเก่าเป็นกรณีที่สาม เกิดขึ้นก่อนการจับมือ TLS และคาดหวังไฟล์ความลับที่แชร์ไว้ก่อนแล้ว จึงเป็นเหตุผลที่การวางคีย์สาธารณะในช่องนั้นก็ใช้ไม่ได้เช่นกัน อ่านว่าโปรไฟล์ขออะไรจริง ๆ ก่อนตัดสินว่าข้อมูลรับรองผิด

การเข้ารหัสใหม่ทำได้และทำไม่ได้อะไร

คีย์ส่วนตัวมีคอนเทนเนอร์ทางเลือกที่ชอบด้วยกฎหมายจริง คีย์ RSA หรือ EC เดียวกันสามารถเขียนเป็น PEM แบบดั้งเดิม เป็น PKCS#8 หรือภายในชุด PKCS#12 และเครื่องมือยินดีแปลงระหว่างกัน คีย์สาธารณะก็มีเรื่องราวคล้ายกัน ssh-keygen สามารถส่งออกรูปแบบ RFC 4716 ของคีย์ SSH และ OpenSSH ก็เข้าใจรูปแบบใบรับรองของตัวเองด้วย ทั้งหมดนั้นเป็นการนำเสนอ และการนำเสนอไม่ใช่ความไว้วางใจ

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

นี่คือขั้นตอนที่ความพยายามส่วนใหญ่ล้มเหลวอย่างเงียบ ๆ ไฟล์ตอนนี้ลงท้ายด้วย .crt ไคลเอนต์อ่านได้โดยไม่บ่น และการจับมือก็ยังถูกตัดเพราะ อีกฝ่ายไม่สามารถสร้างห่วงโซ่ถึงผู้ออกที่เชื่อถือได้

ผู้ออกใบรับรองเข้ามาในภาพตรงไหน

การลงทะเบียนจริงเริ่มจากคู่คีย์ที่คุณควบคุมและคำขอลงนามใบรับรองที่บรรจุหัวข้อที่ผู้ดูแลคาดหวัง ผู้ดูแลตรวจสอบสิทธิ์ ลงนามคำขอด้วยคีย์ CA และคืนใบรับรองที่ออกให้พร้อมห่วงโซ่กลางใด ๆ ที่ไคลเอนต์ต้องแสดง จากนั้นไคลเอนต์ต้องมีใบรับรอง CA ที่ลงนามให้ เพราะนั่นคือสิ่งที่ทำให้ยืนยันได้ว่าเซิร์ฟเวอร์ที่กำลังคุยด้วยอยู่ในการติดตั้งเดียวกัน

ไฟล์สุดท้ายนั้นลืมง่ายและแทนที่ไม่ได้ คีย์ลงนามของ CA เองไม่เคยอยู่ในคอนฟิกของไคลเอนต์ และไม่มีการแปลงภายในเครื่องใดสร้างห่วงโซ่ที่คุณควรได้รับ

ต้นทุนของการใช้คีย์ SSH ซ้ำ

สมมติว่าการแปลงให้สิ่งที่ยอมรับได้จริง การใช้คู่คีย์เดียวทั้งสำหรับเข้าถึง SSH และรับรองตัวตน VPN ยังคงผูกการตัดสินใจด้านความปลอดภัยสองอย่างเข้าด้วยกัน การลบบรรทัดใน authorized_keys หยุดการเข้าสู่ระบบ SSH และไม่ทำอะไรกับใบรับรองที่ CA ของ VPN ออกให้กับคีย์สาธารณะเดียวกันไปแล้ว ฝั่ง VPN ถูกเพิกถอนผ่านกลไกของตัวเอง นั่นคือรายการเพิกถอนใบรับรองหรือบันทึกการลงทะเบียนของผู้ดูแล

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