Jaga CA akar VPN Anda tetap offline dan tetap terbitkan sertifikat

VPN Anda menjawab koneksi pada pukul 3 pagi sementara mesin yang menandatangani sertifikatnya mati di dalam laci. Klien yang memvalidasi sertifikat server tidak pernah menghubungi CA Anda, jadi CA tidak perlu dapat dijangkau untuk koneksi apa pun. Bagian yang memerlukan perencanaan adalah hari ketika sertifikat harus diterbitkan, diperbarui, atau dicabut sementara kunci akar tetap terkunci.

Apa yang sebenarnya divalidasi oleh koneksi

Saat klien OpenVPN terhubung, ia menelusuri rantai tanda tangan dari sertifikat daun server ke atas hingga sertifikat CA yang sudah dipercayainya, memeriksa jendela masa berlaku, dan, jika profil mengatakannya, melihat daftar pencabutan. Ia tidak pernah mencari CA akar Anda. Server melakukan tindakan cermin untuk sertifikat klien. Pada saat koneksi hanya ada daun, perantara, dan bundel kepercayaan yang Anda bagikan sebelumnya.

Yang sebenarnya gagal adalah salah satu dari tiga hal: kunci penandatangan tidak tersedia saat penerbitan, daftar pencabutan sudah kedaluwarsa, atau bundel kepercayaan klien lebih tua daripada rantai yang disajikan server. Yang pertama adalah masalah proses; dua lainnya adalah masalah distribusi. Tidak satu pun dari ini memerlukan kunci akar online, dan layanan VPN terkelola yang menuntut sertifikat privat untuk autentikasi terowongan hanya memindahkan otoritas penandatangan ke penyedia. Azure point-to-site bekerja sebaliknya: Anda mengunggah sertifikat akar dan sertifikat yang ditandatangani di bawahnya dipercaya, jadi tanyakan siapa yang menandatangani, siapa yang memvalidasi, dan bagaimana sertifikat ditarik lebih awal.

Bangun akar di host yang tidak pernah mendapat alamat

Akar offline jarang dipakai: untuk menandatangani sertifikat CA perantara, dan nanti untuk memperbarui atau mencabutnya. Semua hal lain terjadi satu tingkat di bawahnya. Lakukan pekerjaan akar pada mesin yang dijauhkan dari jaringan, jika mungkin dari sistem live, dan catat siapa yang ada di ruangan. Perintahnya mengasumsikan OpenSSL 1.1.1 atau lebih baru, karena -addext tidak tersedia di build lama.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key
openssl req -x509 -new -key root.key -sha256 -days 7300 \
  -subj "/CN=Example VPN Root CA" -out root.crt \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

Buat perantara di host penandatangan dan bawa hanya permintaannya ke mesin offline. Akar menandatangani permintaan itu dengan panjang jalur nol, sehingga CA perantara boleh menandatangani sertifikat titik akhir tetapi tidak boleh membuat CA lain di bawahnya. Ekstensi tunggal itu mencegah host penandatangan yang disusupi mencetak otoritas setara akar. Gunakan ECDSA hanya jika setiap klien menjalankan OpenVPN 2.4 atau lebih baru; jika tidak, buat kunci RSA dan pertahankan alurnya sama.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out intermediate.key
openssl req -new -key intermediate.key -subj "/CN=Example VPN Intermediate CA" -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \
  -CAcreateserial -days 3650 -sha256 -extfile intermediate.ext -out intermediate.crt

intermediate.ext berisi basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign, dan authorityKeyIdentifier=keyid:always. Kembalikan kunci akar ke brankasnya sebelum host penandatangan terhubung lagi. Jika akar harus dapat mencabut perantara, tanda tangani dengan openssl ca -config root.cnf -extensions intermediate_ca terhadap index.txt tingkat akar alih-alih openssl x509 -req, agar nomor seri tercatat; lalu kirim daftar akar yang dihasilkan di dalam profil klien, tempat crl-verify berbasis file membacanya saat mulai. Kirim kepada klien bundel berisi kedua sertifikat CA; satu daun saja tidak akan tervalidasi terhadap akar.

Terbitkan daun dari perantara, dengan basis data

Menandatangani dengan openssl x509 -req berfungsi sampai Anda perlu mencabut, karena tidak ada yang mencatat nomor seri. Gunakan openssl ca sejak sertifikat pertama agar nomor seri, masa berlaku, dan status pencabutan hidup dalam satu basis data. Buat file basis data sekali, lalu arahkan konfigurasi ke sana:

mkdir -p /etc/vpn-ca/intermediate/newcerts
touch /etc/vpn-ca/intermediate/index.txt
echo 1000 > /etc/vpn-ca/intermediate/serial
echo 1000 > /etc/vpn-ca/intermediate/crlnumber

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/vpn-ca/intermediate
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
certificate = $dir/intermediate.crt
private_key = $dir/intermediate.key
default_md = sha256
default_days = 365
default_crl_days = 30
unique_subject = no
policy = policy_any
[ policy_any ]
commonName = supplied
[ server_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @server_names
[ client_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ server_names ]
DNS.1 = vpn.example.com

Baris penggunaan kunci mengasumsikan kunci ECDSA; tambahkan keyEncipherment untuk RSA. Beri setiap klien nama umumnya sendiri, karena OpenVPN mengidentifikasi koneksi dari bidang itu, dan dua laptop yang berbagi CN=vpn-client tidak dapat dibedakan di log, dalam aturan client-config-dir, atau dalam push per pengguna mana pun, dan Anda kehilangan atribusi yang membuat keputusan pencabutan dapat dipertahankan. Terbitkan dan validasi daun seperti ini:

openssl req -new -key alice.key -subj "/CN=alice-laptop" -out alice.csr
openssl ca -config intermediate.cnf -extensions client_cert -in alice.csr -out alice.crt -batch
openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt alice.crt

Simpan kunci penandatangan di balik batas kebijakan alih-alih menyalinnya ke host VPN: layanan kecil yang mengautentikasi permintaan, memeriksa nama umum terhadap daftar izin, dan hanya mengembalikan sertifikat. Catat setiap nomor seri; log adalah satu-satunya tautan antara sertifikat dan orang yang memintanya.

Terbitkan pencabutan tanpa membangunkan akar

Sertifikat klien dicabut oleh perantara, tidak pernah oleh akar. Daftar akar hanya penting ketika perantara dibakar. Arahkan server ke daftar perantara dengan crl-verify. CRL berbasis file dimuat saat layanan mulai, jadi muat ulang setelah setiap regenerasi; bentuk direktori membaca status saat koneksi dan memakan satu file per nomor seri.

Cabut dan regenerasi dengan dua perintah dari basis data yang sama:

openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem

Lalu perhatikan jam. CRL membawa bidang pembaruan berikutnya, dan begitu tanggal itu lewat, rekan yang memvalidasi menolak daftar alih-alih mengabaikannya. Regenerasi bulanan dengan default_crl_days = 30 menyisakan kelonggaran; tahunan tidak. Masa hidup daun yang lebih pendek adalah kontrol yang lebih andal, karena pencabutan hanya berlaku di tempat daftar dirujuk.

Uji rantai, lalu tuliskan upacaranya

Reproduksi empat kegagalan sebelum memercayai desain. Validasi rantai dengan openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Hubungkan dengan sertifikat klien kedaluwarsa dan pastikan server menolaknya. Cabut klien uji, muat ulang, dan pastikan daftar berlaku. Majukan jam host satu hari, karena jam yang salah dapat menerbitkan dan menolak sertifikat yang tampak valid di tempat lain.

Akar offline hanyalah kontrol jika dokumennya ada: dua orang bernama untuk upacara, catatan setiap nomor seri yang ditandatangani, cadangan terenkripsi yang disimpan terpisah dari mesin, dan uji pemulihan pada host terisolasi. Tandatangani perantara cadangan selama upacara yang sama agar host penandatangan yang mati tidak memaksa Anda membuka akar tengah malam.

Sebelum menyebutnya selesai, pastikan lima hal: kunci akar tidak ada di host berjaringan, kunci perantara hanya hidup di host penandatangan, bundel klien membawa kedua sertifikat CA, CRL memiliki pembaruan berikutnya di masa depan, dan seseorang memiliki entri kalender untuk setiap kedaluwarsa dalam rantai. Jika satu hilang, penyiapan yang tampak offline hanyalah tidak terdokumentasi.