Login PIV gagal di Windows dengan EAP-TLS? Periksa jalur penandatanganan

Tampilkan sertifikat kartu PIV di setiap dialog Windows dan login VPN tetap bisa gagal, karena keterlihatan dan kegunaan adalah sifat yang berbeda. Sertifikat adalah objek publik; login memerlukan operasi kunci privat yang dilakukan kartu menurut aturan aksesnya sendiri. Di antara kedua fakta itu ada empat tahap yang gagal dengan empat cara berbeda: pemilihan profil, pemilihan sertifikat, penandatanganan lokal, dan validasi di sisi server. Menelusurinya secara berurutan mengubah kesalahan jabat tangan yang umum menjadi pertanyaan spesifik bagi pemilik bagian berikutnya.

Mulai dari profil dan metode EAP

Buka properti koneksi dan baca metode EAP mana yang sebenarnya dipakai profil, lalu baca sertifikat mana yang dikonfigurasi untuk dipilih metode tersebut. Banyak penerapan memiliki metode luar berbasis sertifikat dan metode dalam sekaligus, dan sertifikat yang dikonfigurasi pada tingkat koneksi tidak otomatis menjadi sertifikat yang disajikan di dalam EAP-TLS. Jika profil memilih sertifikat berdasarkan penerbit atau filter subjek, filter itu memilih dari apa yang dapat dilihat Windows di penyimpanan terkait, bukan dari apa yang kebetulan dimiliki kartu. Filter yang tidak cocok dengan apa pun kembali ke prompt atau ke kegagalan senyap tergantung konfigurasi profil, karena itu sidik jari yang dipilih layak dicatat sebelum perubahan apa pun.

Tetapkan juga apakah koneksi berjalan sebagai pengguna yang masuk atau sebagai mesin. Fakta tunggal itu menentukan penyimpanan sertifikat mana yang masuk cakupan dan konteks keamanan mana yang melakukan penandatanganan.

Pastikan sertifikat mana yang dipilih

Bandingkan sidik jari yang dipilih Windows dengan persyaratan: penggunaan untuk autentikasi klien, rantai yang berakhir di akar tepercaya, identitas yang dipetakan kebijakan server autentikasi, dan masa berlaku yang mencakup saat percobaan yang sebenarnya. Ini pemeriksaan terpisah dan yang terakhir menangkap lebih banyak kejutan daripada yang orang duga, terutama dengan sertifikat yang diterbitkan secara bergulir dan profil tersimpan yang masih menunjuk ke pilihan kemarin.

Konteks pengguna dan mesin adalah separuh pemeriksaan lainnya. Sertifikat di penyimpanan pribadi pengguna tidak terlihat oleh layanan yang berjalan sebagai mesin, dan sertifikat mesin tidak disajikan oleh pertukaran EAP dalam mode pengguna kecuali profil menyatakannya. Mengimpor ulang sertifikat ke penyimpanan yang salah menghasilkan sertifikat yang terlihat dan kredensial login yang tidak terlihat. Baca jalur penyimpanan di profil, bukan jalur di dialog yang kebetulan terbuka.

Uji operasi kunci tanpa menebak PIN

Setelah pemilihan diselesaikan, pertanyaannya adalah apakah kartu akan melakukan penandatanganan. Windows memerlukan penyedia kartu yang didukung atau minidriver untuk mencapai kunci privat, dan perangkat menerapkan aturan PIN dan kehadirannya sendiri pada operasi tersebut. Kartu yang dikonfigurasi untuk menuntut sentuhan pada setiap tanda tangan berperilaku berbeda dari kartu yang menyimpan verifikasi untuk satu sesi, dan keduanya adalah konfigurasi sah yang mengubah kapan prompt muncul. Perbedaan itu menjelaskan login yang berhasil pada penyisipan baru dan gagal setelah melanjutkan, tanpa ada sertifikat yang salah.

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

Perintah pertama menginventarisasi kartu dan melaporkan status pembaca serta penyedia, yang didokumentasikan di panduan Microsoft untuk men-debug kartu pintar. Perintah kedua mendaftar apa yang benar-benar dapat dilihat konteks pengguna. Tidak satu pun membuktikan autentikasi berhasil; keduanya mempersempit di mana prosesnya berhenti.

Jangan menebak PIN. Kartu memberlakukan batas percobaan ulang, dan beberapa upaya optimistis mengubah masalah izin menjadi kredensial terblokir yang memerlukan pemulihan administratif. Jika penandatanganan lokal gagal, catat status penyedia dan status kartu alih-alih mencoba variasi. Ulangi percobaan sekali dengan profil yang sama, sertifikat yang sama, dan jalur pembaca yang diketahui baik, lalu bandingkan kedua catatan; mengubah beberapa variabel sekaligus menghasilkan cerita, bukan hasil.

Baca kedua sisi jabat tangan

Tanda tangan yang selesai belum berarti diterima. Server autentikasi harus menerima rantai, memeriksa pencabutan, memetakan identitas menurut aturannya saat ini, dan mengizinkan permintaan; klien pada gilirannya harus memvalidasi sertifikat server seperti yang diminta profil. Peringatan TLS yang dihasilkan server terlihat di log klien sama seperti yang dihasilkan secara lokal, karena itu sisi yang memancarkannya lebih penting daripada teks peringatannya.

Kumpulkan peristiwa Windows dan peristiwa di sisi server dengan stempel waktu yang selaras, lalu tentukan sisi mana yang menghasilkan kegagalan pertama. RFC 5216 menjelaskan langkah pembuktian kepemilikan dalam EAP-TLS, dan peringatan jabat tangan yang umum tidak menyebutkan penyebab kunci lokal dengan sendirinya. Perbandingan stempel waktu itulah yang mengubah dua log menjadi urutan.

Jaga batas tetap lurus dalam laporan

Tulis laporan sebagai empat tahap dengan satu putusan masing-masing: profil dan konteks mana yang berjalan, sertifikat mana yang dipilih Windows, apakah kartu menandatangani, dan apa yang diputuskan server. Struktur itu membuat langkah berikutnya jelas dan mencegah perbaikan umum berupa menonaktifkan validasi untuk melewati tahap yang tidak diidentifikasi siapa pun.

Sertifikat perangkat lunak sebagai pembanding sementara adalah uji administrator yang sah, tetapi mengubah model kredensial dan jaminan, jadi tempatnya di perubahan yang disetujui, bukan di akal-akalan produksi yang senyap. Disiplin yang sama berlaku untuk percobaan PIN dan untuk penerbitan ulang kredensial sebelum tahap yang gagal diketahui. Kartu pengganti yang gagal dengan cara identik adalah bukti mahal bahwa masalahnya tidak pernah ada di kartu.