Hogyan hozzunk létre VPN-kliens kulcsot és nyújtsunk be CSR-t aláírásra

Tartsa a privát kulcsot az ügyfélnél, és csak a kérést küldje el. Ellenőrizze a CSR-t, hagyja jóvá az identitást, írja alá kifejezett kiterjesztésekkel, majd igazolja a párt.

Előbb vagy utóbb egy VPN-felhasználó felajánlja, hogy e-mailben elküldi a privát kulcsot, hogy a rendszergazda tanúsítványt készíthessen, és éppen ezt az ajánlatot kell elutasítani. A működő folyamat az első parancstól az ügyfélnél tartja a kulcsot: az ügyfél létrehozza, tanúsítvány-aláírási kérelmet küld, a kibocsátó ellenőrzi és engedélyezi, és az aláírt tanúsítvány visszatér, hogy a létrehozó kulcs mellé kerüljön. Az alábbi ellenőrzőlista minden lépésnél zártan hibázik, és ez a lényeg, mert az öt lépésből kettő éppen az, amelyet az emberek sietve kihagynak.

Lépés 1: ott hozza létre a kulcsot, ahol élni fog

Azon a gépen hozza létre, amelyik a kulcsot fogja tartani, és hagyja ott. A szoftveres kulcs szigorú jogosultságú fájlba kerül; a hardveresen támogatott vagy kezelt tárolóban lévő kulcs soha nem lesz fájl, és a regisztrációs útvonala általában külön eszköz, nem OpenSSL-parancs. Akárhogy is, senkinek nem kell látnia a privát felét.

A szoftveres folyamat így néz ki, a kulcs és a kérés egy munkamenetben jön létre:

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"

A umask sor fontosabb, mint látszik. Nélküle a kulcs az alapértelmezés szerint engedékeny rendszeren mindenki számára olvashatóan íródik, és a fájl későbbi másolgatása ezt terjeszti. A meglévő kulcs újrafelhasználása akkor jogszerű, ha már védett, és megfelel a szabályzatának; eszközönként újat létrehozni könnyebben indokolható.

Lépés 2: tegye az identitást a kérésbe, ne az e-mailbe

Döntse el, mit hitelesít valójában a VPN, mielőtt a kérés létrejön, mert az a válasz a CSR belsejébe tartozik. OpenVPN hagyományosan a tanúsítvány közös nevéhez köti az ügyfél identitását, és az olyan eszközök, mint a strongSwan, identitásláncot egyeztetnek a tárggyal vagy a tárgy alternatív nevével. Egy e-mail, amely azt mondja, hogy a nevem alice, nem bizonyíték, és egy kérés, amelynek tárgya ugyanezt mondja, csak kicsit jobb.

Adjon hozzá tárgy-alternatív nevet, amikor az ellenőrzője ilyet vizsgál, mert a modern egyeztetés gyakran figyelmen kívül hagyja a régi CN-t:

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

Tartsa a CN-t rövidnek, stabilnak és a fiókhoz kötöttnek, ne egy laptopmodellhez. A felhasználó eszközének sorozatszámát tartalmazó név olyan támogatási probléma, amely az első hardvercserére vár.

Lépés 3: ellenőrizze a kérést, mielőtt aláírja

A kibocsátó két különböző dolgot ellenőriz, és ezek összekeverése a klasszikus hiba. Először, hogy a kérés belsőleg konzisztens: az aláírás az általa hordozott nyilvános kulccsal ellenőrizhető. Másodszor, hogy a kérelmező jogosult arra, amit a kérés kér, és erre egyetlen kriptográfiai ellenőrzés sem tud válaszolni.

A mechanikus rész egyetlen parancs, és az ellenőrzés eredményét a tárggyal együtt kell kiírnia:

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

Figyelje meg, mit bizonyít ez. Az ellenőrzést teljesítő kérés csak azt mutatja, hogy a küldő a beküldés időpontjában birtokolta a megfelelő privát kulcsot; nem bizonyítja, hogy a küldő a tárgyban megnevezett személy, és nem engedélyezi a kért csoport- vagy útvonalhozzáférést. A regisztráció felülvizsgálata külön kapu, és az olyan csoportra vonatkozó kérést, amelyet senki nem hagyott jóvá, el kell utasítani, nem pedig csendben szerkeszteni.

Lépés 4: engedélyezzen, majd írjon alá kifejezett kiterjesztésekkel

Az aláírás az a pont, ahol a CA szabályzatot dönt, ahelyett hogy szó szerint elfogadná a kérést. Az érvényesség, a kulcshasználat és a szerepkiterjesztés kiterjesztésfájlba tartozik, nem olyan alapértékekbe, amelyekre hat hónap múlva nem emlékszik. A VPN-hitelesítéshez használt ügyféltanúsítványnak ügyfél-hitelesítésre van szüksége célként.

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

Használja a -CAserial kapcsolót a meglévő sorozatszám-fájllal, ha már van használatban, és tartsa a CA-kulcsot offline vagy a szabályzata által megnevezett védett tárolóban. A tanúsítványok sorozatszámának kibocsátónként egyedinek kell lennie; a sorozatszám-fájl nulláról való újraépítése olyan ütközéseket kockáztat, amelyek kétértelművé teszik a visszavonást.

Jegyezze fel, mi került kiadásra: sorozatszám, tárgy, kért identitás, jóváhagyó személy és lejárat. Ez a nyilvántartás az, amire egy visszavonási döntés később támaszkodik, és nem állítható helyre pusztán a tanúsítványból, ha a regisztráció nyoma csak egy postaládában él.

Lépés 5: telepítse a megfelelő kulcs mellé, és igazolja a párt

Az ügyfél megkapja a tanúsítványt és a kibocsátó láncát, soha nem kulcsot. Csatlakozás előtt igazolja, hogy a tanúsítvány valóban párt alkot a lemezen már meglévő kulccsal, mert a nem illeszkedő pár sokkal később zavaró kézfogási hibát okoz:

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

A két kivonatnak meg kell egyeznie. Ezután csatlakozzon, és igazolja, hogy a kiszolgáló által naplózott identitás az Ön által engedélyezett, nem csupán az, hogy az alagút felállt. Ha a kulcs elveszik vagy az eszközt lecserélik, a válasz a visszavonás plusz egy új kérés az új eszközről; ha a rendszergazdától máshonnan kért kulcsot, az nem állítja helyre az eredetit, és csendben megtöri a modellt, amely a kérést biztonságossá tette.

Kapcsolódó cikkek