Login VPN dengan sertifikat di Mac: identitas, pemakaian kunci, atau kepercayaan pada gateway?

Login VPN berbasis sertifikat meminta sesuatu yang lebih sempit daripada kata sandi kepada Mac: pakai kunci privat tertentu ini, dalam konteks eksekusi ini, untuk membuktikan identitas kepada gateway itu. Ketika gagal, pesannya biasanya hanya menjelaskan hal terakhir yang salah, dan hal itu jarang menjadi penyebabnya. Menelusuri tiga keputusan itu sesuai urutan sistem mengambilnya membuat diagnosis tetap jujur, dan mencegah masalah izin lokal diperlakukan sebagai kegagalan validasi rantai.

Telusuri login sesuai urutan yang dipakai Mac

Pertama klien memilih identitas: sertifikat yang dipasangkan dengan kunci privat yang bisa dipakai, tersedia melalui penyimpanan atau penyedia kredensial yang didukung. Lalu komponen VPN meminta operasi kriptografis dilakukan dengan kunci itu, dan model otorisasi lokal menjawab. Hanya setelah keduanya berhasil, jabat tangan jarak jauh terjadi, ketika Mac menilai gateway dan gateway menilai bukti klien.

Baca tabel dari atas ke bawah dan berhenti pada baris pertama yang gagal. Semua yang ada di bawah kegagalan belum terbukti, itulah sebabnya “sertifikatnya tidak tepercaya” menjadi kesimpulan yang begitu umum dan begitu tidak dapat diandalkan.

Apa yang sebenarnya dicakup izin lokal

Dalam model keychain macOS, butir yang dilindungi membawa aturan akses khusus per operasi dan daftar aplikasi tepercaya. Menandatangani dengan kunci privat adalah salah satu operasi itu, dan aturannya berlaku untuk berkas yang dapat dieksekusi yang melakukannya, bukan untuk sertifikat sebagai dokumen. Rujukan kontrol akses Apple juga menarik garis antara model ini dan keychain iCloud serta pengaturan grup akses, sehingga saran yang ditulis untuk yang satu tidak berpindah ke yang lain.

Ada dua akibat. Sertifikat publik yang terlihat dalam daftar tidak membuktikan bahwa komponen latar VPN dapat menjangkau kunci itu sama sekali. Dan izin yang diberikan kepada aplikasi depan tidak mengatakan apa pun tentang pembantu atau ekstensi jaringan yang terpisah, karena keduanya kode berbeda dengan identitas berbeda.

Kenali implementasi sebenarnya dan mekanisme berbagi kredensial yang didukungnya, bukan menyalin jalur berkas eksekusi dari klien lama. Pastikan lebih dulu identitas mana yang akan ditawarkan sistem:

security find-identity -v -p ssl-client

Membaca errSecInteractionNotAllowed

Status itu melaporkan interaksi yang tidak diizinkan dengan Security Server, dan tidak mengatakan apa pun tentang rantai sertifikat. Bacalah bersama operasi yang menghasilkannya: permintaan tanda tangan yang dikeluarkan dari konteks yang tidak dapat menampilkan dialog akan gagal seperti ini bahkan ketika kunci dan sertifikatnya sama-sama sah sepenuhnya. Operasi yang mencatatnya, bukan penyimpanan sertifikat, adalah tempat untuk memulai. Apa pun yang Anda ubah soal jangkar kepercayaan akan membiarkan galat itu tetap persis di tempatnya.

Jadi perlakukan kode itu sebagai alasan untuk memeriksa konteks eksekusi dan otorisasi. Memperlakukannya sebagai bukti bahwa CA gateway tidak tepercaya mengirim Anda ke separuh masalah yang salah, dan perubahan yang Anda buat di sana tidak akan memengaruhi galat itu sama sekali.

Perbaiki secara sempit, bukan luas

Mulailah dari petunjuk pendaftaran atau impor milik pemilik koneksi. Catat versi klien, cakupan profil, identitas yang dipilih, dan galat lokal pertama yang relevan, karena keempat fakta itulah yang dibutuhkan serah terima ke dukungan dan yang menjadi dasar perbandingan nanti. Profil terkelola atau identitas yang didukung perangkat keras mungkin memerlukan administrator atau penyedia untuk memperbaiki serah terima itu, dan tidak ada jumlah klik lokal yang menggantikannya.

Di tempat produk mengharapkan persetujuan pengguna, pastikan komponen mana yang meminta dan setujui hanya akses itu melalui alur yang didukung. Di tempat komponen tidak punya cara memunculkan dialog dalam konteks tempat ia berjalan, penyediaan harus mengikuti jalur yang didokumentasikan vendor, bukan dialog yang dipancing dari jendela terminal lain.

Dua perubahan dibundel bersama dalam saran lama, dan keduanya terlalu luas. Memberi setiap aplikasi akses ke kunci privat memperlebar pemakaian kunci lokal jauh melampaui kebutuhan, dan menyetel sertifikat ke Always Trust mengubah penilaian sertifikat untuk segala hal di mesin. Tidak satu pun darinya menyatakan “implementasi VPN yang disetujui ini, memakai identitas yang dimaksudkan ini”.

Periksa secara lokal sebelum membaca gateway

Setelah perbaikan, pastikan operasi lokal berhasil sebelum Anda menafsirkan tanggapan apa pun dari sisi seberang. Jika penandatanganan kini bekerja, penolakan nama, rantai, atau penerimaan klien sesudahnya adalah hasil baru dan bukan kambuhnya masalah lama, dan itu milik keputusan lain dengan pemilik lain.

Serah terima yang berguna menyebutkan keputusan mana dari tiga itu yang gagal dan berhenti di situ. Serah terima itu tidak pernah menyertakan kunci privat, dan tidak pernah menyetel ulang butir keychain yang tidak berkaitan dengan harapan bahwa keadaan bersih akan menolong. Tetapkan kedua kebiasaan itu sebelum insiden, bukan selama insiden, ketika godaan untuk mencoba semuanya sekaligus paling kuat. Tiket yang berbunyi “keychain dibangun ulang” hampir tidak memberi tahu pembaca berikutnya apa pun tentang kerusakan aslinya.