OpenConnect ต้องใช้ PKCS#11 URI แบบใดสำหรับโทเคน

สมาร์ตการ์ดที่มีคีย์ที่ถูกต้องอยู่แล้วก็ยังต้องได้รับการบอกว่าควรใช้วัตถุใดบนการ์ด ในสถานการณ์นั้น OpenConnect ไม่ต้องการไฟล์ .key ที่คัดลอกมา แต่ต้องการ PKCS#11 URI ที่ระบุชื่อใบรับรอง และเมื่อการค้นหาอัตโนมัติทำงานไม่สำเร็จ ก็ต้องระบุคีย์ส่วนตัวที่อยู่ข้าง ๆ ด้วย ส่วนที่ยุ่งยากคือ URI ที่ถูกต้องตามไวยากรณ์ไม่ได้พิสูจน์อะไรเลย มันต้องระบุชื่อการลงทะเบียนที่เกตเวย์ไว้วางใจอยู่แล้ว ไม่ใช่เพียงวัตถุที่การ์ดยินดีจะเปิด

สิ่งที่ไคลเอ็นต์ต้องการแทนคีย์ที่ส่งออก

ตัวเลือก -c ปกติรับพาธไฟล์ แต่เมื่อค่าถูกแยกวิเคราะห์เป็น PKCS#11 URI OpenConnect จะถือว่าเป็นข้อมูลอ้างอิงถึงวัตถุภายในโทเคน ไม่ใช่ไฟล์บนดิสก์ ตัวเลือก -k ทำงานแบบเดียวกันกับคีย์ส่วนตัว ไม่มีอะไรถูกส่งออก และคีย์ไม่เคยออกจากการป้องกันที่การ์ดให้ไว้ สิ่งที่ไคลเอ็นต์ต้องการจากคุณคือชื่อที่โมดูลโทเคน ที่เก็บใบรับรอง และการลงทะเบียนของเกตเวย์เห็นตรงกัน

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

สอง URI สองงานที่ต่างกัน

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

URI ของคีย์ตอบว่าวัตถุดิบส่วนตัวที่ตรงกันอยู่ที่ใดเมื่อ OpenConnect ไม่สามารถอนุมานได้ เมื่อตั้งค่าเพียง -c ไคลเอ็นต์จะสร้างการค้นหาคีย์จากคุณสมบัติของใบรับรอง การระบุ -k จะแทนที่การเดาด้วยการอ้างอิงวัตถุที่ชัดเจน PIN ของโทเคนเป็นอินพุตที่สามที่ไม่เกี่ยวข้อง มันปลดล็อกการ์ดสำหรับการดำเนินการ และไม่เคยระบุวัตถุใด ๆ

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

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

การค้นหา URI ที่ตรงกับการลงทะเบียนของคุณ

GnuTLS มาพร้อม p11tool ซึ่งแสดงรายการสิ่งที่ผู้ใช้ปัจจุบันเข้าถึงได้จริงผ่าน p11-kit เริ่มด้วย p11tool --list-tokens แล้วแสดงรายการวัตถุใบรับรองบนโทเคนที่คุณสนใจ เพิ่ม --login เมื่อวัตถุปรากฏหลัง PIN เท่านั้น และเปรียบเทียบหัวเรื่องกับผู้ออกกับบันทึกการลงทะเบียนแทนการเลือกสิ่งที่ปรากฏก่อน

ถ้าโทเคนไม่ปรากฏเลย ปัญหาอยู่ใต้ OpenConnect กล่าวคือ p11-kit ไม่มีโมดูลที่ลงทะเบียนสำหรับมิดเดิลแวร์นั้น หรือโมดูลลงทะเบียนไว้สำหรับบัญชีอื่น การลงทะเบียนระดับระบบอยู่ใต้ /etc/pkcs11/modules และไดเรกทอรีต่อผู้ใช้สามารถเก็บสิ่งเดียวกันได้โดยไม่แตะสำเนาของระบบ ตรวจสอบว่าพาธของผู้ให้บริการในไฟล์โมดูลชี้ไปที่ไลบรารีที่ซอฟต์แวร์ของผู้อ่านติดตั้งจริง

เมื่อคัดลอก URI จากรายการ ให้เก็บเครื่องหมายคำพูดรอบ ๆ ไว้ อัฒภาคที่ไม่มีเครื่องหมายคำพูดจะตัดอาร์กิวเมนต์ที่แอตทริบิวต์แรก และไคลเอ็นต์จะรายงานวัตถุที่หาไม่พบ

เมื่อการค้นหาคีย์อัตโนมัติยอมแพ้

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

ยืนยันว่าคีย์มีอยู่และมองเห็นได้ด้วย p11tool --list-keys ก่อนจะโทษไคลเอ็นต์ จากนั้นตรวจสอบว่าวัตถุถูกทำเครื่องหมายว่าใช้สำหรับการลงชื่อหรือถอดรหัสได้ เพราะคีย์ที่สร้างด้วยแอตทริบิวต์ผิดไม่สามารถทำการจับมือให้เสร็จได้ ไม่ว่า URI จะถูกต้องเพียงใด อย่าย้ายค่า pkcs11-id ที่ถูกทำให้เป็นอนุกรมจากโปรไฟล์ OpenVPN ไปยังตัวเลือกของ OpenConnect ไคลเอ็นต์ทั้งสองใช้รูปแบบตัวระบุที่ต่างกันแม้จะคุยกับการ์ดเดียวกัน

ถ้า URI แก้ไขได้และ PIN ถูกยอมรับแต่การรับรองความถูกต้องยังล้มเหลว ให้หยุดปรับ URI อ่านข้อผิดพลาดของเกตเวย์เอง เพราะความล้มเหลวถัดไปอยู่เหนือโทเคน

ความล้มเหลวที่ดูเหมือนปัญหา URI เท่านั้น

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

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

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