VPN müştəri açarını necə yaratmaq və imzalanmaq üçün CSR necə təqdim etmək olar

Tez-tez və ya gec, bir VPN istifadəçisi administratorun sertifikat yarada bilməsi üçün şəxsi açarı e-poçtla göndərməyi təklif edir və rədd edilməli olan məhz həmin təklifdir. İşlək axın açarı ilk əmrdən etibarən müştəridə saxlayır: müştəri onu yaradır, sertifikat imzalama sorğusu göndərir, buraxan onu yoxlayır və icazə verir, imzalanmış sertifikat isə onu yaradan açarın yanına qayıdır. Aşağıdakı yoxlama siyahısı hər addımda qapalı rejimdə uğursuz olur və məqsəd də budur, çünki beş addımdan ikisi insanların tələsdikləri zaman atladıqları addımlardır.

Addım 1: açarı yaşayacağı yerdə yaradın

Açarı saxlayacaq maşında yaradın və orada saxlayın. Proqram açarı məhdud icazələri olan fayla yazılır; aparat dəstəkli və ya idarə olunan anbarda saxlanan açar heç vaxt fayl olmur və onun qeydiyyat yolu adətən OpenSSL əmri deyil, ayrı bir alətdir. Hər halda, şəxsi yarısını görməyə heç kimin ehtiyacı yoxdur.

Proqram axını belə görünür, açar və sorğu bir sessiyada yaradılır:

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"

umask sətri göründüyündən daha vacibdir. Onsuz açar standart olaraq icazəli sistemdə hamının oxuya bildiyi şəkildə yazılır və faylı sonra kopyalamaq bunu yayır. Mövcud açarın təkrar istifadəsi, artıq qorunursa və siyasətinizə uyğundursa, qanunidir; hər cihaz üçün yenisini yaratmaq barədə düşünmək daha asandır.

Addım 2: şəxsiyyəti sorğuya qoyun, e-poçta yox

Sorğu yaradılmadan əvvəl VPN-in həqiqətən nəyi autentifikasiya etdiyinə qərar verin, çünki bu cavab CSR-in içində yer alır. OpenVPN ənənəvi olaraq müştəri şəxsiyyətini sertifikatın ümumi adına bağlayır və strongSwan kimi alətlər şəxsiyyət sətrini subyektə və ya subyektin alternativ adına uyğunlaşdırır. Adım alice olduğunu deyən e-poçt sübut deyil və subyekti eyni şeyi deyən sorğu yalnız bir az daha yaxşıdır.

Yoxlayıcınız birini yoxlayırsa, subyektin alternativ adını əlavə edin, çünki müasir uyğunlaşdırma köhnə CN-i çox vaxt nəzərə almır:

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

CN-i qısa, sabit və noutbuk modelinə deyil, hesaba bağlı saxlayın. İstifadəçi cihazının seriya nömrəsini ehtiva edən ad ilk aparat dəyişikliyini gözləyən dəstək problemidir.

Addım 3: sorğunu imzalamadan əvvəl yoxlayın

Buraxan iki fərqli şeyi yoxlayır və onları qarışdırmaq klassik səhvdir. Birincisi, sorğunun daxilən ardıcıl olması: imza onun daşıdığı açıq açarla yoxlanılır. İkincisi, sorğu sahibinin sorğunun istədiyinə haqqı olması, buna heç bir kriptoqrafik yoxlama cavab verə bilməz.

Mexaniki hissə bir əmrdir və subyektlə birlikdə yoxlama nəticəsi çap etməlidir:

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

Bunun nəyi sübut etdiyinə diqqət yetirin. Yoxlanılan sorğu yalnız göndərənin təqdimetmə anında uyğun şəxsi açarı saxladığını göstərir; göndərənin subyektdə adlandırılan şəxs olduğunu sübut etmir və tələb olunan qrup və ya marşrut girişinə icazə vermir. Qeydiyyat baxışı ayrı bir keçiddir və heç kimin təsdiqləmədiyi qrupu istəyən sorğu səssizcə redaktə edilmək əvəzinə rədd edilməlidir.

Addım 4: icazə verin, sonra açıq genişləndirmələrlə imzalayın

İmzalama, CA-nın sorğunu hərfi qəbul etmək əvəzinə siyasət qərar verdiyi yerdir. Etibarlılıq, açar istifadəsi və rol genişləndirməsi altı ay sonra xatırlaya bilməyəcəyiniz defoltlarda deyil, genişləndirmə faylında olmalıdır. VPN autentifikasiyası üçün müştəri sertifikatına məqsəd kimi müştəri autentifikasiyası lazımdır.

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

Artıq istifadədədirsə, mövcud seriya faylı ilə -CAserial istifadə edin və CA açarını oflayn və ya siyasətinizin adlandırdığı qorunan anbarda saxlayın. Sertifikat seriya nömrələri hər buraxan üçün unikal olmalıdır; seriya faylını sıfırdan yenidən yaratmaq ləğvi qeyri-müəyyən edən toqquşmalara səbəb olur.

Nəyin verildiyini qeyd edin: seriya, subyekt, tələb olunan şəxsiyyət, təsdiqləyən şəxs və bitmə tarixi. Sonradan ləğv qərarı məhz bu qeydə əsaslanır və qeydiyyat izi yalnız poçt qutusunda yaşayırsa, o, təkcə sertifikatdan bərpa edilə bilməz.

Addım 5: onu uyğun açarın yanına quraşdırın və cütlüyü sübut edin

Müştəri sertifikatı və buraxan zəncirini alır, heç vaxt açarı yox. Qoşulmadan əvvəl sertifikatın diskdəki açarla həqiqətən cütləşdiyini təsdiqləyin, çünki uyğunsuz cüt çox sonra çaşdırıcı əl sıxma uğursuzluğu yaradır:

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

İki həzm bir-birinə uyğun olmalıdır. Sonra qoşulun və serverin qeyd etdiyi şəxsiyyətin icazə verdiyiniz şəxs olduğunu təsdiqləyin, sadəcə tunelin qalxdığını yox. Açar itirsə və ya cihaz dəyişdirilirsə, cavab ləğvetmə və yeni cihazdan yeni sorğudur; administratora başqa yerdən açar göndərməyi xahiş etmək orijinalı bərpa etmir və sorğunu təhlükəsiz edən modeli səssizcə pozur.