Kā ģenerēt VPN klienta atslēgu un iesniegt CSR parakstīšanai

Agrāk vai vēlāk VPN lietotājs piedāvā nosūtīt privāto atslēgu pa e-pastu, lai administrators varētu izveidot sertifikātu, un tieši šis piedāvājums ir jānoraida. Strādājošā plūsma tur atslēgu klientā no pirmās komandas: klients to ģenerē, nosūta sertifikāta parakstīšanas pieprasījumu, izdevējs to pārbauda un atļauj, un parakstītais sertifikāts atgriežas, lai stāvētu blakus atslēgai, kas to radīja. Zemāk redzamais kontrollists katrā solī neizdodas slēgti, un tā ir būtība, jo divi no pieciem soļiem ir tie, ko cilvēki izlaiž, kad steidzas.

Solis 1: ģenerējiet atslēgu tur, kur tā dzīvos

Ģenerējiet mašīnā, kas turēs atslēgu, un atstājiet to tur. Programmatūras atslēga nonāk failā ar stingrām atļaujām; aparatūras atbalstīta vai pārvaldītā krātuvē esoša atslēga nekad nekļūst par failu, un tās reģistrācijas ceļš parasti ir atsevišķs rīks, nevis OpenSSL komanda. Lai kā būtu, nevienam nav jāredz privātā puse.

Programmatūras plūsma izskatās šādi, atslēga un pieprasījums tiek izveidoti vienā sesijā:

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 rinda ir svarīgāka, nekā izskatās. Bez tās atslēga tiek ierakstīta visiem lasāmā veidā sistēmā, kas pēc noklusējuma ir atļaujoša, un faila vēlāka kopēšana to izplata. Esošas atslēgas atkārtota izmantošana ir likumīga, ja tā jau ir aizsargāta un atbilst jūsu politikai; jaunas ģenerēšana katram ierīcei ir vieglāk pamatojama.

Solis 2: ievietojiet identitāti pieprasījumā, nevis e-pastā

Izlemiet, ko VPN faktiski autentificē, pirms pieprasījums tiek izveidots, jo šī atbilde pieder CSR iekšpusei. OpenVPN tradicionāli saista klienta identitāti ar sertifikāta kopīgo nosaukumu, un tādi rīki kā strongSwan saskaņo identitātes virkni ar subjektu vai subjekta alternatīvo nosaukumu. E-pasts, kas saka, ka mani sauc alice, nav pierādījums, un pieprasījums, kura subjekts saka to pašu, ir tikai nedaudz labāks.

Pievienojiet subjekta alternatīvo nosaukumu, kad jūsu pārbaudītājs tādu pārbauda, jo mūsdienu saskaņošana bieži ignorē veco CN:

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

Turiet CN īsu, stabilu un piesaistītu kontam, nevis portatīvā datora modelim. Nosaukums, kas satur lietotāja ierīces sērijas numuru, ir atbalsta problēma, kas gaida pirmo aparatūras nomaiņu.

Solis 3: pārbaudiet pieprasījumu pirms parakstīšanas

Izdevējs pārbauda divas dažādas lietas, un to sajaukšana ir klasiskā kļūda. Pirmkārt, ka pieprasījums ir iekšēji konsekvents: paraksts tiek pārbaudīts pret tajā esošo publisko atslēgu. Otrkārt, ka pieprasītājam ir tiesības uz to, ko pieprasījums prasa, un uz to nevar atbildēt neviena kriptogrāfiska pārbaude.

Mehāniskā daļa ir viena komanda, un tai vajadzētu izdrukāt pārbaudes rezultātu kopā ar subjektu:

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

Pievērsiet uzmanību, ko tas pierāda. Pārbaudīts pieprasījums parāda tikai to, ka sūtītājam iesniegšanas brīdī bija atbilstošā privātā atslēga; tas nepierāda, ka sūtītājs ir subjektā nosauktais cilvēks, un tas nepiešķir atļauju pieprasītajai grupas vai maršruta piekļuvei. Reģistrācijas pārskatīšana ir atsevišķi vārti, un pieprasījums par grupu, kuru neviens nav apstiprinājis, ir jānoraida, nevis klusi jālabo.

Solis 4: atļaujiet, tad parakstiet ar skaidriem paplašinājumiem

Parakstīšana ir vieta, kur CA izlemj politiku, nevis pieņem pieprasījumu burtiski. Derīgums, atslēgas lietojums un lomas paplašinājums pieder paplašinājumu failam, nevis noklusējuma vērtībām, kuras pēc pusgada neatcerēsities. VPN autentifikācijas klienta sertifikātam kā mērķis ir nepieciešama klienta autentifikācija.

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

Izmantojiet -CAserial ar esošo sērijas numuru failu, ja tāds jau tiek lietots, un turiet CA atslēgu bezsaistē vai jebkurā aizsargātā krātuvē, ko nosauc jūsu politika. Sertifikātu sērijas numuriem jābūt unikāliem katram izdevējam; sērijas numuru faila atjaunošana no nulles riskē ar sadursmēm, kas padara atsaukšanu neviennozīmīgu.

Pierakstiet, kas tika izsniegts: sērijas numurs, subjekts, pieprasītā identitāte, apstiprinātājs un derīguma termiņš. Tieši šis ieraksts ir tas, uz ko vēlāk balstās atsaukšanas lēmums, un to nevar atjaunot tikai no sertifikāta, ja reģistrācijas pēdas dzīvo tikai pastkastē.

Solis 5: instalējiet to blakus atbilstošajai atslēgai un pierādiet pāri

Klients saņem sertifikātu un izdevēja ķēdi, nekad atslēgu. Pirms savienošanas apstipriniet, ka sertifikāts tiešām veido pāri ar atslēgu, kas jau ir diskā, jo nesaskanīgs pāris daudz vēlāk rada mulsinošu rokasspiediena kļūdu:

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

Abiem kopsavilkumiem jāsakrīt. Pēc tam savienojieties un apstipriniet, ka identitāte, ko serveris reģistrē, ir tā, kuru atļāvāt, nevis tikai tas, ka tunelis pacēlās. Ja atslēga tiek pazaudēta vai ierīce tiek nomainīta, atbilde ir atsaukšana plus jauns pieprasījums no jaunās ierīces; lūgums administratoram atsūtīt atslēgu atpakaļ no citurienes neatjauno oriģinālu un klusi salauž modeli, kas padarīja pieprasījumu drošu.