Cara membuat kunci klien VPN dan mengirim CSR untuk ditandatangani

Cepat atau lambat, seorang pengguna VPN menawarkan untuk mengirim kunci privat lewat email agar administrator dapat membuat sertifikat, dan tawaran itulah yang harus ditolak. Alur yang berhasil menjaga kunci tetap di klien sejak perintah pertama: klien membuatnya, mengirim permintaan penandatanganan sertifikat, penerbit memverifikasi dan mengotorisasinya, dan sertifikat yang ditandatangani kembali untuk duduk di samping kunci yang membuatnya. Daftar periksa di bawah ini gagal secara tertutup pada setiap langkah, dan itulah intinya, karena dua dari lima langkah adalah langkah yang orang lewati saat mereka tergesa-gesa.

Langkah 1: buat kunci di tempat kunci itu akan hidup

Buat di mesin yang akan menyimpan kunci, dan biarkan di sana. Kunci perangkat lunak masuk ke berkas dengan izin ketat; kunci yang didukung perangkat keras atau di penyimpanan terkelola tidak pernah menjadi berkas, dan jalur pendaftarannya biasanya alat terpisah, bukan perintah OpenSSL. Bagaimanapun, tidak ada yang perlu melihat separuh privatnya.

Alur perangkat lunak terlihat seperti ini, dengan kunci dan permintaan dibuat dalam satu sesi:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

Baris umask lebih penting daripada kelihatannya. Tanpanya kunci ditulis dapat dibaca semua orang pada sistem yang permisif secara bawaan, dan menyalin berkas itu nanti menyebarkannya. Memakai ulang kunci yang ada sah bila kunci itu sudah terlindungi dan sesuai kebijakan Anda; membuat kunci baru per perangkat lebih mudah dipertanggungjawabkan.

Langkah 2: taruh identitas di permintaan, bukan di email

Putuskan apa yang sebenarnya diautentikasi VPN sebelum permintaan dibuat, karena jawaban itu berada di dalam CSR. OpenVPN secara tradisional mengaitkan identitas klien dengan nama umum sertifikat, dan alat seperti strongSwan mencocokkan string identitas dengan subjek atau nama alternatif subjek. Email yang mengatakan nama saya alice bukan bukti, dan permintaan yang subjeknya mengatakan hal yang sama hanya sedikit lebih baik.

Tambahkan nama alternatif subjek ketika verifikator Anda memeriksa salah satunya, karena pencocokan modern sering mengabaikan CN lama:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

Jaga CN tetap pendek, stabil, dan terikat pada akun alih-alih model laptop. Nama yang berisi nomor seri perangkat pengguna adalah masalah dukungan yang menunggu penggantian perangkat keras pertama.

Langkah 3: verifikasi permintaan sebelum menandatanganinya

Penerbit memverifikasi dua hal berbeda, dan mencampuradukkannya adalah kesalahan klasik. Pertama, bahwa permintaan konsisten secara internal: tanda tangan diverifikasi terhadap kunci publik yang dibawanya. Kedua, bahwa pemohon berhak atas apa yang diminta permintaan, dan tidak ada pemeriksaan kriptografis yang bisa menjawabnya.

Bagian mekanisnya adalah satu perintah, dan perintah itu harus mencetak hasil verifikasi bersama subjek:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

Perhatikan apa yang dibuktikan. Permintaan yang lolos verifikasi hanya menunjukkan bahwa pengirim memegang kunci privat yang cocok pada saat pengiriman; itu tidak membuktikan pengirim adalah orang yang disebut dalam subjek, dan tidak mengotorisasi akses grup atau rute yang diminta. Tinjauan pendaftaran adalah gerbang terpisah, dan permintaan untuk grup yang tidak disetujui siapa pun harus ditolak alih-alih diedit diam-diam.

Langkah 4: otorisasi, lalu tanda tangani dengan ekstensi eksplisit

Penandatanganan adalah tempat CA memutuskan kebijakan alih-alih menerima permintaan apa adanya. Validitas, penggunaan kunci, dan ekstensi peran berada di berkas ekstensi, bukan di nilai bawaan yang tidak akan Anda ingat enam bulan kemudian. Sertifikat klien untuk autentikasi VPN membutuhkan autentikasi klien sebagai tujuannya.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

Gunakan -CAserial dengan berkas serial yang ada jika sudah ada yang dipakai, dan simpan kunci CA secara offline atau di penyimpanan terlindungi yang dinamai kebijakan Anda. Nomor seri sertifikat harus unik per penerbit; membuat ulang berkas serial dari nol berisiko tabrakan yang membuat pencabutan menjadi ambigu.

Catat apa yang diterbitkan: nomor seri, subjek, identitas yang diminta, orang yang menyetujui, dan kedaluwarsa. Catatan itulah yang menjadi dasar keputusan pencabutan nanti, dan catatan itu tidak dapat dibangun ulang hanya dari sertifikat jika jejak pendaftaran hanya hidup di kotak surat.

Langkah 5: pasang di samping kunci yang cocok dan buktikan pasangannya

Klien menerima sertifikat dan rantai penerbit, tidak pernah kunci. Sebelum menghubungkan, pastikan sertifikat benar-benar berpasangan dengan kunci yang sudah ada di disk, karena pasangan yang tidak cocok menghasilkan kegagalan jabat tangan yang membingungkan jauh kemudian:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

Kedua digest harus cocok. Lalu hubungkan dan pastikan identitas yang dicatat server adalah yang Anda otorisasi, bukan sekadar bahwa terowongan menyala. Jika kunci hilang atau perangkat diganti, jawabannya adalah pencabutan plus permintaan baru dari perangkat baru; meminta administrator mengirim balik kunci dari tempat lain tidak memulihkan yang asli dan diam-diam merusak model yang membuat permintaan itu aman.