Jinsi ya kuzalisha ufunguo wa mteja wa VPN na kuwasilisha CSR kwa kusainiwa

Mapema au baadaye, mtumiaji wa VPN hujitolea kutuma ufunguo wa faragha kwa barua pepe ili msimamizi aweze kutengeneza cheti, na ofa hiyo ndiyo inayopaswa kukataliwa. Mtiririko unaofanya kazi huweka ufunguo kwa mteja tangu amri ya kwanza: mteja huuzalisha, hutuma ombi la kusaini cheti, mtoaji huthibitisha na kuidhinisha, na cheti kilichosainiwa hurudi kukaa kando ya ufunguo uliouunda. Orodha ya ukaguzi hapa chini hushindwa kwa kufungwa katika kila hatua, na hilo ndilo lengo, kwa sababu hatua mbili kati ya tano ni zile ambazo watu huruka wanapokuwa na haraka.

Hatua 1: zalisha ufunguo mahali utakapoishi

Zalisha kwenye mashine itakayoshikilia ufunguo, na uache hapo. Ufunguo wa programu huenda kwenye faili yenye ruhusa kali; ufunguo unaoungwa mkono na maunzi au katika hifadhi inayosimamiwa kamwe haufanyiki faili, na njia yake ya usajili kwa kawaida ni chombo tofauti na si amri ya OpenSSL. Vyovyote vile, hakuna anayehitaji kuona nusu ya faragha.

Mtiririko wa programu unaonekana hivi, ufunguo na ombi huundwa katika kikao kimoja:

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"

Mstari wa umask ni muhimu zaidi kuliko unavyoonekana. Bila hiyo ufunguo huandikwa ukisomeka kwa kila mtu kwenye mfumo unaoruhusu kwa chaguo-msingi, na kunakili faili baadaye huenea hilo. Kutumia tena ufunguo uliopo ni halali wakati tayari umelindwa na unalingana na sera yako; kuzalisha mpya kwa kila kifaa ni rahisi kuhalalisha.

Hatua 2: weka utambulisho kwenye ombi, si kwenye barua pepe

Amua VPN inathibitisha nini kwa kweli kabla ombi kuundwa, kwa sababu jibu hilo ni la ndani ya CSR. OpenVPN kwa kawaida huunganisha utambulisho wa mteja na jina la kawaida la cheti, na zana kama strongSwan hulinganisha mfuatano wa utambulisho na somo au jina mbadala la somo. Barua pepe inayosema jina langu ni alice si ushahidi, na ombi ambalo somo lake linasema hivyo hivyo ni bora kidogo tu.

Ongeza jina mbadala la somo wakati kithibitishaji chako kinakagua moja, kwa kuwa ulinganishaji wa kisasa mara nyingi hupuuza CN ya zamani:

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

Weka CN fupi, thabiti na iliyofungwa na akaunti badala ya muundo wa kompyuta ya mkononi. Jina lililo na nambari ya mfululizo ya kifaa cha mtumiaji ni tatizo la usaidizi linalosubiri ubadilishaji wa kwanza wa maunzi.

Hatua 3: thibitisha ombi kabla ya kulisaini

Mtoaji huthibitisha mambo mawili tofauti, na kuyachanganya ni kosa la kawaida. Kwanza, kwamba ombi lina mshikamano wa ndani: saini huthibitishwa dhidi ya ufunguo wa umma unaobebwa nalo. Pili, kwamba mwombaji ana haki ya kile ombi linataka, na hilo hakuna ukaguzi wa kriptografia unaoweza kulijibu.

Sehemu ya kiufundi ni amri moja, na inapaswa kuchapisha matokeo ya uthibitishaji pamoja na somo:

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

Angalia kile hilo linathibitisha. Ombi linalothibitishwa linaonyesha tu kwamba mtumaji alikuwa na ufunguo wa faragha unaolingana wakati wa kuwasilisha; halithibitishi kwamba mtumaji ni mtu aliyetajwa kwenye somo, na haliruhusu ufikiaji wa kundi au njia inayoomba. Ukaguzi wa usajili ni lango tofauti, na ombi la kundi ambalo hakuna aliyelidhinisha linapaswa kukataliwa badala ya kuhaririwa kwa utulivu.

Hatua 4: idhinisha, kisha saini kwa viendelezi dhahiri

Kusaini ni mahali ambapo CA huamua sera badala ya kukubali ombi kama lilivyo. Uhalali, matumizi ya ufunguo na kiendelezi cha jukumu ni vya faili ya viendelezi, si vya chaguo-msingi ambavyo hutakumbuka baada ya miezi sita. Cheti cha mteja kwa uthibitishaji wa VPN kinahitaji uthibitishaji wa mteja kama madhumuni yake.

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

Tumia -CAserial na faili ya mfululizo iliyopo ikiwa moja tayari inatumika, na weka ufunguo wa CA nje ya mtandao au katika hifadhi iliyolindwa ambayo sera yako inaitaja. Nambari za mfululizo za vyeti lazima ziwe za kipekee kwa kila mtoaji; kuunda upya faili ya mfululizo kutoka mwanzo huhatarisha mgongano unaofanya ubatilishaji kuwa wenye utata.

Rekodi kilichotolewa: nambari ya mfululizo, somo, utambulisho ulioombwa, mtu aliyedhinisha na mwisho. Rekodi hiyo ndiyo ambayo uamuzi wa ubatilishaji hutegemea baadaye, na hauwezi kujengwa upya kutoka kwa cheti pekee ikiwa alama ya usajili inaishi katika sanduku la barua pepe pekee.

Hatua 5: isakinishe kando ya ufunguo unaolingana na uthibitishe jozi

Mteja hupokea cheti na mnyororo wa mtoaji, kamwe si ufunguo. Kabla ya kuunganisha, thibitisha kwamba cheti kinaoana kwa kweli na ufunguo ulio tayari kwenye diski, kwa sababu jozi isiyolingana huzalisha hitilafu ya kupeana mikono yenye kuchanganya baadaye sana:

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

Digest mbili lazima zioane. Kisha unganisha na uthibitishe kwamba utambulisho ambao seva inarekodi ni ule ulioidhinisha, na si tu kwamba handaki ilipanda. Ikiwa ufunguo unapotea au kifaa kinabadilishwa, jibu ni ubatilishaji pamoja na ombi jipya kutoka kwa kifaa kipya; kumwomba msimamizi arudishe ufunguo kutoka mahali pengine hakurejeshi asili na huvunja kwa utulivu mtindo uliofanya ombi kuwa salama.