Sertifikat klien bertanda tangan sendiri? Server VPN tetap menolaknya

Operator mengirim alamat dan nama pengguna, lalu klien meminta file CA, sertifikat, dan kunci. Membuat ketiganya secara lokal terasa seperti langkah berikutnya yang wajar. Hasilnya sertifikat yang hanya dipercaya mesin Anda sendiri. Kepercayaan server berakar pada CA yang tidak Anda kendalikan, jadi jabat tangan berakhir sebelum dimulai.

Kepercayaan hidup di server, bukan di profil Anda

Autentikasi sertifikat adalah perbandingan. Klien menyajikan sertifikat; gateway memeriksa apakah sertifikat itu ditandatangani salah satu CA dalam konfigurasinya.

Profil Anda menyebut file CA yang harus dipakai klien untuk memverifikasi server. Profil itu tidak bisa menyebut CA yang harus dipakai server untuk memverifikasi Anda. Separuh konfigurasi itu bukan milik Anda.

Sertifikat buatan sendiri gagal dalam perbandingan ini meski secara teknis sempurna. Sertifikat itu punya tanda tangan sah, subjek, dan tanggal, tetapi penerbitnya adalah CA yang belum pernah didengar gateway. Kesalahan muncul saat jabat tangan, setelah server sudah meminta sertifikat. Tidak ada yang bisa mengubah jawaban dari profil klien.

Mengapa sertifikat bertanda tangan sendiri tidak bisa menggantikan

Sertifikat bertanda tangan sendiri ditandatangani oleh kuncinya sendiri. Tanda tangan diverifikasi terhadap file yang sama, sehingga sertifikat itu konsisten dengan dirinya sendiri dan tidak berguna sebagai kredensial bagi gateway orang lain.

Gateway tidak menanyakan apakah sertifikat konsisten secara internal. Gateway menanyakan apakah penerbit tepercaya menandatanganinya.

Itulah sebabnya pesan kesalahan membingungkan. Klien dapat melaporkan kegagalan verifikasi yang terdengar seperti masalah server, sementara server mencatat penerbit tak dikenal. Keduanya menggambarkan ketidakcocokan yang sama dari ujung yang berlawanan.

Jalur CSR menyimpan kunci privat Anda

Anda masih bisa melakukan sebagian besar pekerjaan secara lokal. Buat pasangan kunci, bangun permintaan penandatanganan sertifikat di sekitar bagian publik, dan kirim permintaan itu ke operator. Hanya permintaan yang meninggalkan mesin Anda. Bagian privat tetap di tempat Anda membuatnya.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Operator menandatangani permintaan dengan CA mereka dan mengembalikan sertifikat. Kunci privat Anda tidak pernah berpindah, dan hasilnya berantai ke jangkar yang dipercaya gateway.

Layanan terkelola sering melewati CSR dan menerbitkan seluruh bundel. Itu pertukaran yang wajar bila penyedia yang sama sudah menerminasi terowongan dan memegang CA. Penyimpanan kunci tidak menjadi lebih baik dengan menyimpannya, karena penyedia bisa membuat yang baru kapan saja.

Bundel diimpor, bukan dipasang

Bundel vendor dengan nama yang terdengar aman sering kali berupa profil OpenVPN. Isinya konfigurasi dan kadang sertifikat, dan bundel itu tidak memasang apa pun. Impor file ke klien yang berbicara protokol tersebut, dan koneksi pun terkonfigurasi.

Aturan penanganan mengikuti isinya. Jika profil menyematkan kunci privat, itu kredensial dan layak diperlakukan seperti kata sandi: tanpa email, tanpa repositori, tanpa folder unduhan bersama. Saat operator mengirim ca.crt, client.crt, dan client.key secara terpisah, simpan bersamanya dengan izin ketat dan arahkan profil ke sana.

Tambahkan pemeriksaan yang mungkin dilewati operator

Profil buatan router kadang tidak memiliki verifikasi peer. remote-cert-tls server mewajibkan sertifikat peer membawa tujuan autentikasi server, sehingga sertifikat klien tidak bisa diputar ulang sebagai server. Satu baris itu adalah perubahan kecil dengan alasan yang jelas.

verify-x509-name melangkah lebih jauh saat operator bisa menyebut subjek atau SAN yang diharapkan. Keduanya tambahan kecil pada profil, dan keduanya dapat dipertahankan. Periksa apa yang Anda terima sebelum mengimpornya.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Setelan verifikasi bukan perbaikan untuk rantai yang rusak. Jika penerbitnya salah, jawabannya adalah sertifikat dari CA yang benar, bukan flag yang mematikan pemeriksaan. Mematikan verifikasi mengubah kegagalan autentikasi menjadi kegagalan yang tidak terdeteksi.

Minta satu bundel: sertifikat otoritas dalam bentuk PEM, sertifikat klien yang ditandatangani otoritas itu, kunci yang Anda buat sendiri atau yang tiba melalui saluran yang Anda percayai, dan nama server persis yang harus disajikan sertifikat. Catat tanggal kedaluwarsa di pesan yang sama, karena sertifikat kedaluwarsa tampak seperti gangguan jaringan berbulan-bulan kemudian.