PKCS#11 URI Mana yang OpenConnect Perlukan untuk Token?

Kad pintar yang sudah menyimpan kunci yang betul tetap perlu diberitahu objek mana padanya hendak digunakan. OpenConnect tidak mahu fail .key yang disalin dalam situasi itu; ia mahu PKCS#11 URI yang menamakan sijil dan, apabila carian automatik tidak dapat menyelesaikan kerja, kunci peribadi di sebelahnya. Bahagian yang menyusahkan ialah URI yang sah dari segi sintaks tidak membuktikan apa-apa. Ia mesti menamakan pendaftaran yang sudah dipercayai oleh gerbang, bukan sekadar objek yang sanggup dibuka oleh kad.

Apa yang klien mahu daripada kunci yang dieksport

Pilihan -c biasanya mengambil laluan fail, tetapi apabila nilai dihuraikan sebagai PKCS#11 URI, OpenConnect menganggapnya sebagai rujukan kepada objek di dalam token dan bukan fail pada cakera. Pilihan -k berkelakuan sama untuk kunci peribadi. Tiada apa yang dieksport, dan kunci tidak pernah meninggalkan perlindungan yang diberikan oleh kad. Apa yang klien perlukan daripada anda ialah nama yang dipersetujui oleh modul token, stor sijil dan pendaftaran gerbang.

Pada kekangan terakhir itulah kebanyakan percubaan terhenti. Sesuatu URI boleh terbentuk dengan sempurna dan masih memilih sijil yang akan ditolak oleh gerbang, kerana kesahan dan kerelevanan adalah dua soalan berasingan. Semakan yang berbaloi ialah perbandingan dengan rekod pendaftaran, bukan carian objek pertama yang kebetulan terbuka.

Dua URI, dua tugas berbeza

URI sijil menjawab identiti mana yang anda tuntut. Ia menunjuk kepada objek sijil yang kunci awam dan baris subjeknya sepadan dengan profil akaun atau peranti yang dikeluarkan oleh pentadbir VPN. Sijil yang sama biasanya datang bersama objek kunci peribadi yang disimpan di sebelahnya, dan pasangan itulah yang sebenarnya diperlukan oleh jabat tangan TLS.

URI kunci menjawab di mana bahan peribadi yang sepadan berada apabila OpenConnect tidak dapat menyimpulkannya. Dengan hanya -c ditetapkan, klien membina carian kunci daripada sifat sijil; memberikan -k menggantikan tekaan dengan rujukan objek yang jelas. PIN token ialah input ketiga yang tidak berkaitan: ia membuka kad untuk operasi itu, dan ia tidak pernah mengenal pasti objek.

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

Semua yang ada dalam rentetan berpetik itu ialah data. Titik bertindih memisahkan atribut URI dan escape peratus mengekod aksara yang jika tidak akan merosakkan penghuraian, jadi keseluruhan argumen mesti selamat melalui shell.

Mencari URI yang sepadan dengan pendaftaran anda

GnuTLS menyertakan p11tool, yang menyenaraikan apa yang benar-benar boleh dicapai oleh pengguna semasa melalui p11-kit. Mulakan dengan p11tool --list-tokens, kemudian senaraikan objek sijil pada token yang anda minati. Tambah --login apabila objek hanya muncul selepas PIN, dan bandingkan subjek serta pengeluar dengan rekod pendaftaran daripada memilih apa yang muncul dahulu.

Jika token tidak muncul sama sekali, masalahnya terletak di bawah OpenConnect: p11-kit tiada modul berdaftar untuk middleware itu, atau modul itu didaftarkan untuk akaun lain. Pendaftaran seluruh sistem berada di bawah /etc/pkcs11/modules, dan direktori per pengguna boleh menyimpan perkara yang sama tanpa menyentuh salinan sistem. Periksa sama ada laluan penyedia dalam fail modul menunjuk kepada pustaka yang benar-benar dipasang oleh perisian pembaca.

Apabila menyalin URI daripada senarai, kekalkan tanda petik di sekelilingnya. Titik bertindih tanpa petik memotong argumen pada atribut pertama dan klien kemudian melaporkan objek yang tidak dapat ditemuinya.

Apabila carian kunci automatik mengalah

OpenConnect boleh memperoleh carian kunci daripada URI sijil, tetapi padanan tepat yang dilakukannya bergantung pada versi, dan pengendalian jenis objek serta label telah berubah dari semasa ke semasa. Nasihat supaya memendekkan URI sehingga ia berfungsi menerangkan helah lama, bukan keperluan. Jika carian yang diperoleh gagal, namakan kunci secara jelas dengan -k daripada mengubah URI sijil menjadi sesuatu yang lebih kabur.

Pastikan kunci wujud dan kelihatan dengan p11tool --list-keys sebelum menyalahkan klien. Kemudian periksa sama ada objek ditandakan sebagai boleh digunakan untuk tandatangan atau penyahsulitan, kerana kunci yang dijana dengan atribut yang salah tidak dapat menyelesaikan jabat tangan, betapa pun betulnya URI itu. Jangan pindahkan nilai pkcs11-id bersiri daripada profil OpenVPN ke pilihan OpenConnect; kedua-dua klien menggunakan format pengecam yang berbeza walaupun bercakap dengan kad yang sama.

Jika URI diselesaikan dan PIN diterima tetapi pengesahan masih gagal, berhenti menala URI. Baca ralat gerbang itu sendiri, kerana kegagalan seterusnya berada di atas token.

Kegagalan yang hanya kelihatan seperti masalah URI

Gerbang yang bertutur protokol lain akan gagal secara identik sama ada URI anda betul atau salah. OpenConnect menggantikan klien vpnc lama atas sebab tertentu, dan sokongan kad tidak menjadikan protokol gerbang yang tidak serasi menjadi serasi. Pastikan protokol yang dijangka oleh pelayan dan susunan pengesahan sebelum menghabiskan satu jam lagi pada atribut objek.

Pengesahan identiti pelayan juga merupakan lapisan berasingan. Klien mengesahkan sijil gerbang terhadap stor kepercayaannya, dan semakan itu berjalan selepas kad sudah menyelesaikan bahagiannya. Kebenaran pembaca dan perkhidmatan pcscd yang berhenti menghasilkan gejala luaran yang sama, token yang tidak dapat dibaca, dengan pembetulan yang jauh lebih mudah.

Bekerjalah dari objek ke luar: adakah p11tool melihat token, adakah ia melihat sijil dan kunci, adakah OpenConnect menerima URI, dan barulah tanya sama ada gerbang menerima identiti itu. Setiap langkah mempunyai mesej ralatnya sendiri, dan setiap satu lebih murah diuji daripada langkah berikutnya.