PKCS#11 URI Mana yang Dibutuhkan OpenConnect untuk Token?

Kartu pintar yang sudah memuat kunci yang benar tetap harus diberi tahu objek mana di dalamnya yang dipakai. OpenConnect tidak menginginkan berkas .key salinan dalam situasi itu; ia menginginkan PKCS#11 URI yang menamai sertifikat dan, ketika pencarian otomatis tidak dapat menyelesaikan pekerjaan, kunci privat di sebelahnya. Bagian yang menyulitkan adalah URI yang sah secara sintaksis tidak membuktikan apa pun. URI itu harus menamai pendaftaran yang sudah dipercaya gateway, bukan sekadar objek yang bersedia dibuka kartu.

Apa yang diinginkan klien alih-alih kunci hasil ekspor

Opsi -c biasanya menerima jalur berkas, tetapi ketika nilainya diurai sebagai PKCS#11 URI, OpenConnect memperlakukannya sebagai rujukan ke objek di dalam token, bukan ke berkas di disk. Opsi -k berperilaku sama untuk kunci privat. Tidak ada yang diekspor, dan kunci tidak pernah meninggalkan perlindungan yang diberikan kartu. Yang dibutuhkan klien dari Anda adalah nama yang disepakati modul token, penyimpanan sertifikat, dan pendaftaran gateway.

Pada batasan terakhir itulah sebagian besar percobaan berhenti. Sebuah URI bisa terbentuk dengan sempurna dan tetap memilih sertifikat yang akan ditolak gateway, karena keabsahan dan keterkaitan adalah dua pertanyaan terpisah. Pemeriksaan yang layak dilakukan adalah perbandingan dengan catatan pendaftaran, bukan pencarian objek pertama yang kebetulan terbuka.

Dua URI, dua tugas berbeda

URI sertifikat menjawab identitas mana yang Anda klaim. URI itu menunjuk objek sertifikat yang kunci publik dan baris subjeknya cocok dengan profil akun atau perangkat yang diterbitkan administrator VPN. Sertifikat yang sama biasanya datang bersama objek kunci privat yang disimpan di sebelahnya, dan pasangan itulah yang benar-benar dibutuhkan jabat tangan TLS.

URI kunci menjawab di mana materi privat yang cocok berada ketika OpenConnect tidak dapat menyimpulkannya. Dengan hanya -c disetel, klien membangun pencarian kunci dari properti sertifikat; memberikan -k menggantikan dugaan dengan rujukan objek yang eksplisit. PIN token adalah masukan ketiga yang tidak terkait: ia membuka kartu untuk operasi, dan tidak pernah mengidentifikasi objek.

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

Semua yang ada di dalam string berkutip itu adalah data. Titik koma memisahkan atribut URI dan escape persen mengodekan karakter yang jika tidak akan merusak penguraian, jadi seluruh argumen harus selamat melewati shell.

Menemukan URI yang cocok dengan pendaftaran Anda

GnuTLS menyertakan p11tool, yang mendaftar apa yang benar-benar dapat dijangkau pengguna saat ini melalui p11-kit. Mulailah dengan p11tool --list-tokens, lalu daftarkan objek sertifikat pada token yang Anda pedulikan. Tambahkan --login ketika objek hanya muncul setelah PIN, dan bandingkan subjek serta penerbit dengan catatan pendaftaran alih-alih memilih apa pun yang muncul pertama.

Jika token tidak muncul sama sekali, masalahnya ada di bawah OpenConnect: p11-kit tidak memiliki modul terdaftar untuk middleware itu, atau modul itu terdaftar untuk akun lain. Pendaftaran seluruh sistem berada di bawah /etc/pkcs11/modules, dan direktori per pengguna dapat memuat hal yang sama tanpa menyentuh salinan sistem. Periksa bahwa jalur penyedia dalam berkas modul menunjuk pustaka yang benar-benar dipasang perangkat lunak pembaca.

Saat menyalin URI dari daftar, pertahankan tanda kutip di sekelilingnya. Titik koma tanpa tanda kutip memotong argumen pada atribut pertama dan klien lalu melaporkan objek yang tidak dapat ditemukannya.

Ketika pencarian kunci otomatis menyerah

OpenConnect dapat menurunkan pencarian kunci dari URI sertifikat, tetapi pencocokan tepat yang dilakukannya bergantung pada versi, dan penanganan tipe objek serta label telah berubah seiring waktu. Saran untuk memendekkan URI sampai berhasil menggambarkan akal-akalan lama, bukan persyaratan. Jika pencarian turunan gagal, namai kunci secara eksplisit dengan -k alih-alih mengubah URI sertifikat menjadi sesuatu yang lebih kabur.

Pastikan kunci ada dan terlihat dengan p11tool --list-keys sebelum menyalahkan klien. Lalu periksa bahwa objek ditandai dapat dipakai untuk penandatanganan atau dekripsi, karena kunci yang dibuat dengan atribut salah tidak dapat menyelesaikan jabat tangan, seberapa pun benarnya URI. Jangan memindahkan nilai pkcs11-id terserialisasi dari profil OpenVPN ke opsi OpenConnect; kedua klien memakai format pengenal berbeda meski berbicara dengan kartu yang sama.

Jika URI terurai dan PIN diterima tetapi autentikasi tetap gagal, berhentilah menyetel URI. Bacalah kesalahan gateway itu sendiri, karena kegagalan berikutnya berada di atas token.

Kegagalan yang hanya tampak seperti masalah URI

Gateway yang berbicara protokol lain akan gagal secara identik apakah URI Anda benar atau salah. OpenConnect menggantikan klien vpnc lama bukan tanpa alasan, dan dukungan kartu tidak membuat protokol gateway yang tidak kompatibel menjadi kompatibel. Pastikan protokol yang diharapkan server dan susunan autentikasinya sebelum menghabiskan satu jam lagi pada atribut objek.

Validasi identitas server juga lapisan tersendiri. Klien memverifikasi sertifikat gateway terhadap penyimpanan kepercayaannya, dan pemeriksaan itu berjalan setelah kartu menyelesaikan bagiannya. Izin pembaca dan layanan pcscd yang berhenti menghasilkan gejala luar yang sama, token yang tidak terbaca, dengan perbaikan yang jauh lebih sederhana.

Bekerjalah dari objek ke luar: apakah p11tool melihat token, apakah ia melihat sertifikat dan kunci, apakah OpenConnect menerima URI, dan baru kemudian tanyakan apakah gateway menerima identitas itu. Setiap langkah punya pesan kesalahannya sendiri, dan setiap langkah lebih murah diuji daripada langkah berikutnya.