Kako ustvarite ključ odjemalca VPN in vložite CSR v podpis

Prej ali slej uporabnik VPN ponudi, da bo zasebni ključ poslal po e-pošti, da bi lahko skrbnik izdelal potrdilo, in prav to ponudbo je treba zavrniti. Delujoč tok hrani ključ pri odjemalcu od prvega ukaza: odjemalec ga ustvari, pošlje zahtevo za podpis potrdila, izdajatelj jo preveri in odobri, podpisano potrdilo pa se vrne in leži ob ključu, ki ga je ustvaril. Spodnji kontrolni seznam odpove zaprto na vsakem koraku in to je bistvo, ker sta dva od petih korakov prav tista, ki ju ljudje v naglici izpustijo.

Korak 1: ustvarite ključ tam, kjer bo živel

Ustvarite ga na stroju, ki bo hranil ključ, in ga pustite tam. Programski ključ konča v datoteki s strogimi dovoljenji; ključ, podprt s strojno opremo ali v upravljanem shrambi, nikoli ne postane datoteka, njegova pot registracije pa je običajno ločeno orodje in ne ukaz OpenSSL. Kakor koli, nihče ne potrebuje videti zasebne polovice.

Programski tok je videti takole, ključ in zahteva nastaneta v eni seji:

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"

Vrstica umask je pomembnejša, kot se zdi. Brez nje se ključ zapiše kot berljiv vsem na sistemu s privzeto dovoljujočimi pravicami, poznejše kopiranje datoteke pa to razširi. Ponovna uporaba obstoječega ključa je legitimna, ko je že zaščiten in ustreza vaši politiki; ustvarjanje novega za vsako napravo je lažje utemeljiti.

Korak 2: identiteto vstavite v zahtevo, ne v e-pošto

Odločite, kaj VPN dejansko preverja, preden zahteva nastane, ker ta odgovor spada v notranjost CSR. OpenVPN tradicionalno veže identiteto odjemalca na skupno ime potrdila, orodja, kot je strongSwan, pa ujemajo niz identitete s subjektom ali alternativnim imenom subjekta. E-pošta, ki pravi, da mi je ime alice, ni dokaz, zahteva, katere subjekt pravi isto, pa je le malo boljša.

Dodajte alternativno ime subjekta, ko ga vaš preverjevalec preverja, saj sodobno ujemanje pogosto prezre stari CN:

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

CN naj bo kratek, stabilen in vezan na račun, ne na model prenosnika. Ime s serijsko številko uporabnikove naprave je težava podpore, ki čaka na prvo zamenjavo strojne opreme.

Korak 3: preverite zahtevo, preden jo podpišete

Izdajatelj preverja dve različni stvari in njuno mešanje je klasična napaka. Prvič, da je zahteva notranje skladna: podpis se preveri glede na javni ključ, ki ga nosi. Drugič, da je prosilec upravičen do tega, kar zahteva zahteva, in na to ne more odgovoriti nobeno kriptografsko preverjanje.

Mehanski del je en ukaz in izpisati bi moral rezultat preverjanja skupaj s subjektom:

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

Opazite, kaj to dokazuje. Zahteva, ki se preveri, pokaže le, da je pošiljatelj imel ustrezen zasebni ključ v trenutku oddaje; ne dokazuje, da je pošiljatelj oseba, navedena v subjektu, in ne dovoljuje dostopa do zahtevane skupine ali poti. Pregled registracije so ločena vrata in zahtevo za skupino, ki je nihče ni odobril, je treba zavrniti, ne pa tiho urediti.

Korak 4: odobrite, nato podpišite z izrecnimi razširitvami

Podpisovanje je kraj, kjer CA odloča o politiki, namesto da bi zahtevo sprejela dobesedno. Veljavnost, uporaba ključa in razširitev vloge spadajo v datoteko razširitev, ne v privzete vrednosti, ki se jih ne boste spomnili pol leta pozneje. Potrdilo odjemalca za preverjanje VPN potrebuje kot namen preverjanje odjemalca.

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

Uporabite -CAserial z obstoječo datoteko serijskih številk, če se ena že uporablja, in ključ CA hranite brez povezave ali v zaščiteni shrambi, ki jo navaja vaša politika. Serijske številke potrdil morajo biti edinstvene za vsakega izdajatelja; ponovno ustvarjanje datoteke serijskih številk od začetka tvega kolizije, zaradi katerih je preklic dvoumen.

Zabeležite, kaj je bilo izdano: serijsko številko, subjekt, zahtevano identiteto, osebo, ki je odobrila, in veljavnost. Ta zapis je tisto, na čemer pozneje temelji odločitev o preklicu, in ga ni mogoče obnoviti samo iz potrdila, če sled registracije živi le v poštnem predalu.

Korak 5: namestite ga ob ustrezen ključ in dokažite par

Odjemalec prejme potrdilo in verigo izdajatelja, nikoli ključa. Pred povezavo potrdite, da potrdilo res tvori par s ključem, ki je že na disku, ker neustrezen par povzroči zmedeno napako rokovanja veliko pozneje:

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

Oba povzetka se morata ujemati. Nato se povežite in potrdite, da je identiteta, ki jo strežnik zabeleži, tista, ki ste jo odobrili, in ne le to, da se je tunel dvignil. Če se ključ izgubi ali naprava zamenja, je odgovor preklic in nova zahteva z nove naprave; prošnja skrbniku, naj pošlje ključ od drugod, ne obnovi izvirnika in tiho zlomi model, ki je zahtevo naredil varno.