Cara menjana kunci klien VPN dan menghantar CSR untuk ditandatangani

Lambat laun, pengguna VPN menawarkan untuk menghantar kunci peribadi melalui e-mel supaya pentadbir boleh membuat sijil, dan tawaran itulah yang perlu ditolak. Aliran yang berkesan menyimpan kunci pada klien sejak arahan pertama: klien menjananya, menghantar permintaan tandatangan sijil, pengeluar mengesahkan dan membenarkannya, dan sijil yang ditandatangani kembali untuk duduk di sebelah kunci yang menciptanya. Senarai semak di bawah gagal secara tertutup pada setiap langkah, dan itulah maksudnya, kerana dua daripada lima langkah ialah langkah yang orang langkau apabila tergesa-gesa.

Langkah 1: jana kunci di tempat ia akan hidup

Jana pada mesin yang akan menyimpan kunci, dan biarkan ia di situ. Kunci perisian masuk ke fail dengan kebenaran ketat; kunci yang disokong perkakasan atau dalam stor terurus tidak pernah menjadi fail, dan laluan pendaftarannya biasanya alat berasingan dan bukan arahan OpenSSL. Walau apa pun, tiada siapa perlu melihat separuh peribadi.

Aliran perisian kelihatan seperti ini, dengan kunci dan permintaan dicipta 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 boleh dibaca semua orang pada sistem yang permisif secara lalai, dan menyalin fail itu kemudian menyebarkannya. Menggunakan semula kunci sedia ada adalah sah apabila ia sudah dilindungi dan sepadan dengan dasar anda; menjana yang baharu bagi setiap peranti lebih mudah dipertanggungjawabkan.

Langkah 2: letakkan identiti dalam permintaan, bukan dalam e-mel

Tentukan apa yang sebenarnya diautentikasi oleh VPN sebelum permintaan dicipta, kerana jawapan itu terletak di dalam CSR. OpenVPN secara tradisional mengikat identiti klien kepada nama umum sijil, dan alat seperti strongSwan memadankan rentetan identiti dengan subjek atau nama alternatif subjek. E-mel yang berkata nama saya alice bukan bukti, dan permintaan yang subjeknya berkata perkara sama hanya sedikit lebih baik.

Tambah nama alternatif subjek apabila pengesah anda memeriksa satu, kerana pemadanan moden sering mengabaikan CN lama:

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

Kekalkan CN pendek, stabil dan terikat pada akaun dan bukan pada model komputer riba. Nama yang mengandungi nombor siri peranti pengguna ialah masalah sokongan yang menunggu penggantian perkakasan pertama.

Langkah 3: sahkan permintaan sebelum menandatanganinya

Pengeluar mengesahkan dua perkara berbeza, dan mencampurkannya ialah kesilapan klasik. Pertama, bahawa permintaan itu konsisten secara dalaman: tandatangan disahkan terhadap kunci awam yang dibawanya. Kedua, bahawa pemohon berhak atas apa yang diminta oleh permintaan, dan tiada pemeriksaan kriptografi boleh menjawabnya.

Bahagian mekanikal ialah satu arahan, dan ia sepatutnya mencetak hasil pengesahan 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 lulus pengesahan hanya menunjukkan bahawa pengirim memegang kunci peribadi yang sepadan pada masa penyerahan; ia tidak membuktikan pengirim ialah orang yang dinamakan dalam subjek, dan ia tidak membenarkan akses kumpulan atau laluan yang diminta. Semakan pendaftaran ialah pintu berasingan, dan permintaan untuk kumpulan yang tiada siapa meluluskannya patut ditolak dan bukan diedit secara senyap.

Langkah 4: benarkan, kemudian tandatangan dengan sambungan eksplisit

Penandatanganan ialah tempat CA memutuskan dasar dan bukannya menerima permintaan secara literal. Kesahan, penggunaan kunci dan sambungan peranan tergolong dalam fail sambungan, bukan dalam nilai lalai yang anda tidak akan ingat enam bulan kemudian. Sijil klien untuk pengesahan VPN memerlukan pengesahan 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 fail siri sedia ada jika satu sudah digunakan, dan simpan kunci CA di luar talian atau dalam stor terlindung yang dinamakan oleh dasar anda. Nombor siri sijil mesti unik bagi setiap pengeluar; mencipta semula fail siri dari awal berisiko perlanggaran yang menjadikan pembatalan kabur.

Rekod apa yang dikeluarkan: nombor siri, subjek, identiti yang diminta, orang yang meluluskan dan tamat tempoh. Rekod itulah yang menjadi asas keputusan pembatalan kemudian, dan ia tidak boleh dibina semula daripada sijil sahaja jika jejak pendaftaran hanya hidup dalam peti mel.

Langkah 5: pasang di sebelah kunci yang sepadan dan buktikan pasangan itu

Klien menerima sijil dan rantaian pengeluar, tidak pernah kunci. Sebelum menyambung, sahkan bahawa sijil benar-benar berpasangan dengan kunci yang sudah ada di cakera, kerana pasangan yang tidak sepadan menghasilkan kegagalan jabat tangan yang mengelirukan 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-dua digest mesti sepadan. Kemudian sambung dan sahkan bahawa identiti yang direkodkan pelayan ialah yang anda benarkan, bukan sekadar bahawa terowong naik. Jika kunci hilang atau peranti diganti, jawapannya ialah pembatalan serta permintaan baharu daripada peranti baharu; meminta pentadbir menghantar balik kunci dari tempat lain tidak memulihkan yang asal dan secara senyap memecahkan model yang menjadikan permintaan itu selamat.