Како генерисати кључ VPN клијента и послати CSR на потписивање

Држите приватни кључ на клијенту и шаљите само захтев. Верификујте CSR, одобрите идентитет, потпишите са експлицитним екстензијама и затим потврдите пар.

Пре или касније, корисник VPN-а понуди да пошаље приватни кључ е-поштом како би администратор могао да направи сертификат, и управо ту понуду треба одбити. Радни ток држи кључ на клијенту од прве команде: клијент га генерише, шаље захтев за потписивање сертификата, издавалац га верификује и овлашћује, а потписани сертификат се враћа и стоји поред кључа који га је створио. Контролна листа испод не успева затворено на сваком кораку, и то је поента, јер су два од пет корака управо они које људи прескачу када журе.

Корак 1: генеришите кључ тамо где ће живети

Генеришите га на машини која ће држати кључ и оставите га тамо. Софтверски кључ завршава у датотеци са строгим дозволама; кључ подржан хардвером или у управљивом складишту никада не постаје датотека, а његова путања регистрације је обично одвојена алатка, а не команда OpenSSL. Како год, нико не треба да види приватну половину.

Софтверски ток изгледа овако, кључ и захтев се стварају у једној сесији:

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 је важнији него што изгледа. Без њега кључ се уписује читљив за све на систему који подразумевано дозвољава, а касније копирање датотеке то шири. Поновна употреба постојећег кључа је легитимна када је већ заштићен и одговара вашој политици; генерисање новог за сваки уређај лакше је оправдати.

Корак 2: ставите идентитет у захтев, не у е-пошту

Одлучите шта VPN заиста аутентификује пре него што захтев настане, јер тај одговор припада унутар CSR-а. OpenVPN традиционално везује идентитет клијента за заједничко име сертификата, а алати као што је strongSwan пореде ниску идентитета са субјектом или алтернативним именом субјекта. Е-пошта која каже да се зовем alice није доказ, а захтев чији субјекат каже исто је само мало бољи.

Додајте алтернативно име субјекта када га ваш верификатор проверава, јер модерно подударање често игнорише стари CN:

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

Држите CN кратак, стабилан и везан за налог, а не за модел преносног рачунара. Име које садржи серијски број корисниковог уређаја је проблем подршке који чека прву замену хардвера.

Корак 3: верификујте захтев пре него што га потпишете

Издавалац верификује две различите ствари, а њихово мешање је класична грешка. Прво, да је захтев унутрашње конзистентан: потпис се верификује према јавном кључу који носи. Друго, да подносилац има право на оно што захтев тражи, а на то не може да одговори ниједна криптографска провера.

Механички део је једна команда, и она би требало да испише резултат верификације заједно са субјектом:

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

Обратите пажњу шта то доказује. Захтев који прође верификацију показује само да је пошиљалац имао одговарајући приватни кључ у тренутку подношења; он не доказује да је пошиљалац особа наведена у субјекту, и не овлашћује приступ траженој групи или рути. Преглед регистрације је одвојена капија, и захтев за групу коју нико није одобрио треба одбити, а не тихо уредити.

Корак 4: овластите, затим потпишите са експлицитним екстензијама

Потписивање је место где CA одлучује о политици уместо да захтев прихвати дословно. Важност, коришћење кључа и екстензија улоге припадају датотеци екстензија, а не подразумеваним вредностима које нећете памтити шест месеци касније. Клијентски сертификат за аутентификацију VPN-а захтева клијентску аутентификацију као своју намену.

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

Користите -CAserial са постојећом датотеком серијских бројева ако се нека већ користи, и држите кључ CA ван мреже или у заштићеном складишту које наводи ваша политика. Серијски бројеви сертификата морају бити јединствени за сваког издаваоца; поновно стварање датотеке серијских бројева од нуле ризикује сударе који отповику чине двосмисленим.

Забележите шта је издато: серијски број, субјекат, тражени идентитет, лице које је одобрило и рок. Управо тај запис је оно на шта се касније ослања одлука о отповику, и не може се обновити само из сертификата ако траг регистрације живи само у поштанском сандучету.

Корак 5: инсталирајте га поред одговарајућег кључа и докажите пар

Клијент прима сертификат и ланац издаваоца, никада кључ. Пре повезивања потврдите да се сертификат заиста спарује са кључем који је већ на диску, јер неодговарајући пар ствара збуњујући неуспех руковања много касније:

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

Два сажетка морају да се поклопе. Затим се повежите и потврдите да је идентитет који сервер бележи онај који сте овластили, а не само то да се тунел подигао. Ако се кључ изгуби или уређај замени, одговор је отповикување плус нови захтев са новог уређаја; захтев администратору да пошаље кључ са другог места не враћа оригинал и тихо крши модел који је захтев чинио безбедним.

Повезани чланци