Anda memasang token, alat milik penyedia sendiri melihatnya, tetapi klien VPN tetap meminta berkas kunci privat. Permintaan itu bukan bukti bahwa token tidak didukung. Biasanya itu berarti profil tidak pernah memberi tahu klien untuk memakai token, sehingga klien kembali ke masukan sertifikat dan kunci yang diharapkannya secara bawaan.

Dua nilai terpisah harus benar sebelum fallback itu berhenti: penyedia yang mengekspos token, dan identitas sertifikat di dalamnya. Keduanya diberikan oleh opsi berbeda dan mudah tertukar.

Klien meminta berkas karena profil memang menyuruhnya

Profil bawaan mengharapkan berkas sertifikat dan berkas kunci privat, atau satu bundel PKCS#12. Bila masukan itu tidak ada, klien tidak punya apa pun untuk dimuat dan berperilaku hampir seperti saat berkas tidak ada, sehingga gejalanya terbaca sebagai jalur rusak, bukan mekanisme yang hilang. Jalur PKCS#11 menggantikan masukan itu, bukan menambahkannya, jadi profil yang masih menyebut berkas kunci akan terus memakai berkas tersebut. Hapus masukan berkas dengan sengaja dan biarkan token memasok kedua bagiannya.

Opsi penyedia menyebut pustaka middleware, bukan perangkat dan bukan sertifikat. Apakah klien terpaket dapat memuat pustaka itu bergantung pada cara pustaka tersebut dibangun, termasuk dukungan p11-kit opsional yang diaktifkan sebagian build dan dilewati build lain. Tutorial umum tidak dapat memberi tahu Anda susunan mana yang dimiliki paket Anda.

Identitas terserialisasi adalah nilai yang berbeda

Identitas sertifikat adalah untai terserialisasi panjang yang dihasilkan proses penemuan, dan itu bukan jalur pustaka, bukan PIN token, dan bukan nama akun VPN. Untai itu sering memuat karakter yang perlu dikutip, dan nilai tanpa kutip dapat terpotong atau terbaca salah tanpa galat yang jelas. Gunakan opsi penemuan identitas milik klien untuk mendaftar apa yang diekspos token, lalu salin entri yang dimaksud dengan tepat. Memilih objek pertama dalam daftar adalah cara perangkat akhirnya menyajikan sertifikat yang salah.

Keluaran penemuan juga menjawab pertanyaan sebelumnya: apakah token terlihat sama sekali melalui penyedia itu. Jika tidak mendaftar apa pun, masalahnya berada di atas klien VPN dan menjadi milik middleware.

Proses yang melakukan koneksi harus menjangkau token

Operasi token yang berhasil di sesi desktop Anda tidak membuktikan apa pun tentang layanan sistem. Layanan itu dapat berjalan sebagai pengguna lain, di ruang nama mount yang berbeda, dengan jalur modul yang melewati pustaka penyedia, atau tanpa izin membuka simpul perangkat. Tentukan proses mana yang benar-benar memegang koneksi dan uji dari konteks itu.

Penanganan PIN layak mendapat keputusan tersendiri. Implementasi acuan menawarkan cache PIN dan jalur autentikasi terlindungi, dan keduanya ada agar operator dapat memilih alur kerja alih-alih mengarangnya. Jangan mengubah persyaratan tanpa pengawasan menjadi PIN teks biasa di dalam profil bersama, karena itu menukar perlindungan token dengan kenyamanan. Di tempat token melarang ekspor kunci, penandatanganan terjadi di perangkat dan PIN adalah satu-satunya rahasia lokal. Perlakukan dengan kehati-hatian yang tersirat di dalamnya.

Apa yang tidak digantikan token

Token mengautentikasi klien di bawah kebijakan yang diterapkan, dan itu tidak menggantikan pemeriksaan klien terhadap server. Sertifikat yang berhasil dipilih bukan izin menerima sertifikat gerbang yang tak terduga, dan kedua verifikasi melindungi arah yang berlawanan.

Pendaftaran tetap harus terjadi pada penerbit, dan gerbang tetap harus mengesahkan identitas.

Untuk penerimaan, pisahkan tahapannya: penyedia dimuat, sertifikat yang dimaksud ditemukan, kunci privat dipakai dengan otorisasi lokal, VPN mengautentikasi, dan operasi sumber daya berhasil. Berhentilah pada tahap pertama yang gagal alih-alih berputar di antara kata sandi dan memasang ulang tumpukan kripto.

Catat versi, kepemilikan modul, pengenal publik yang dipilih, dan galat yang sudah dibersihkan, dan biarkan PIN serta bundel kredensial di luar catatan itu.

Artikel terkait