Kiel generi klientan ŝlosilon de VPN kaj sendi CSR por subskribo

Pli frue aŭ pli malfrue VPN-uzanto proponas sendi privatan ŝlosilon per retpoŝto, por ke la administranto povu fari atestilon, kaj ĝuste tiun proponon oni devas rifuzi. La funkcianta fluo tenas la ŝlosilon ĉe la kliento de la unua komando: la kliento generas ĝin, sendas peton pri atestila subskribo, la eldonanto kontrolas kaj rajtigas ĝin, kaj la subskribita atestilo revenas por stari apud la ŝlosilo, kiu ĝin kreis. La kontrol-listo sube malsukcesas fermite ĉe ĉiu paŝo, kaj tio estas la senco, ĉar du el la kvin paŝoj estas ĝuste tiuj, kiujn homoj saltas, kiam ili hastas.

Paŝo 1: generu la ŝlosilon tie, kie ĝi loĝos

Generu sur la maŝino, kiu tenos la ŝlosilon, kaj lasu ĝin tie. Programara ŝlosilo iras en dosieron kun striktaj permesoj; aparate subtenata ŝlosilo aŭ ŝlosilo en administrata stokejo neniam fariĝas dosiero, kaj ĝia registriĝa vojo kutime estas aparta ilo anstataŭ komando OpenSSL. Ĉiel ajn, neniu bezonas vidi la privatan duonon.

La programara fluo aspektas tiel, kun la ŝlosilo kaj la peto kreitaj en unu seanco:

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"

La linio umask gravas pli, ol ĝi aspektas. Sen ĝi la ŝlosilo skribiĝas monde legebla sur sistemo kun implicaj permesoj, kaj kopiado de la dosiero poste disvastigas tion. Reuzi ekzistantan ŝlosilon estas legitime, kiam ĝi jam estas protektita kaj kongruas kun via politiko; generi novan por ĉiu aparato estas pli facile pravigebla.

Paŝo 2: metu la identecon en la peton, ne en la retpoŝton

Decidu, kion la VPN fakte aŭtentikigas, antaŭ ol la peto kreiĝas, ĉar tiu respondo apartenas ene de la CSR. OpenVPN tradicie ligas klientan identecon al la komuna nomo de la atestilo, kaj iloj kiel strongSwan kongruigas identecan ĉenon kun la subjekto aŭ subjekta alternativa nomo. Retpoŝto, kiu diras, ke mia nomo estas alice, ne estas pruvo, kaj peto, kies subjekto diras la samon, estas nur iomete pli bona.

Aldonu subjektan alternativan nomon, kiam via kontrolilo kontrolas unu, ĉar moderna kongruigo ofte ignoras la malnovan CN:

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

Tenu la CN mallonga, stabila kaj ligita al la konto anstataŭ al tekkomputila modelo. Nomo enhavanta la serian numeron de la uzanta aparato estas subtena problemo atendanta la unuan aparatan anstataŭigon.

Paŝo 3: kontrolu la peton antaŭ ol vi subskribos ĝin

La eldonanto kontrolas du malsamajn aferojn, kaj kunfandi ilin estas la klasika eraro. Unue, ke la peto estas interne konsekvenca: la subskribo kontroliĝas kontraŭ la publika ŝlosilo, kiun ĝi portas. Due, ke la petanto rajtas al tio, kion la peto postulas, kaj al tio neniu kriptografia kontrolo povas respondi.

La mekanika parto estas unu komando, kaj ĝi devus presi kontrolrezulton kune kun la subjekto:

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

Rimarku, kion tio pruvas. Peto, kiu kontroliĝas, montras nur, ke la sendinto posedis la kongruan privatan ŝlosilon en la momento de sendado; ĝi ne pruvas, ke la sendinto estas la persono nomita en la subjekto, kaj ĝi ne rajtigas la grupan aŭ vojan aliron, kiun oni petas. Registriĝa revizio estas aparta pordego, kaj peto pri grupo, kiun neniu aprobis, devus esti malakceptita anstataŭ silente redaktita.

Paŝo 4: rajtigu, poste subskribu kun eksplicitaj etendaĵoj

Subskribado estas kie la CA decidas politikon anstataŭ akcepti la peton laŭvorte. Valideco, ŝlosila uzo kaj la rola etendaĵo apartenas al etendaĵa dosiero, ne al implicaj valoroj, kiujn vi ne memoros ses monatojn poste. Klienta atestilo por VPN-aŭtentikigo bezonas klientan aŭtentikigon kiel sian celon.

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

Uzu -CAserial kun la ekzistanta seria dosiero, se unu jam estas uzata, kaj tenu la CA-ŝlosilon eksterrete aŭ en kiu ajn protektita stokejo via politiko nomas. Atestilaj seriaj numeroj devas esti unikaj por eldonanto; rekrei la serian dosieron de nulo riskas koliziojn, kiuj igas revokon ambigua.

Registru, kion oni eldonis: seria numero, subjekto, petita identeco, aprobinta persono kaj findato. Tiu registro estas tio, sur kio poste dependas revoka decido, kaj ĝi ne povas esti rekonstruita nur el la atestilo, se la registriĝa spuro vivas nur en poŝtkesto.

Paŝo 5: instalu ĝin apud la kongrua ŝlosilo kaj pruvu la paron

La kliento ricevas la atestilon kaj la eldonan ĉenon, neniam ŝlosilon. Antaŭ konekti, konfirmu, ke la atestilo vere pariĝas kun la ŝlosilo jam surdiske, ĉar miskongrua paro produktas konfuzan manpreman fiaskon multe pli poste:

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

La du resumoj devas kongrui. Poste konektu kaj konfirmu, ke la identeco, kiun la servilo protokolas, estas tiu, kiun vi rajtigis, ne nur ke la tunelo leviĝis. Se la ŝlosilo perdiĝas aŭ la aparato anstataŭiĝas, la respondo estas revoko plus nova peto de la nova aparato; peti la administranton resendi ŝlosilon de aliloke ne rekuperas la originalon kaj silente rompas la modelon, kiu igis la peton sekura.