Hvernig á að búa til VPN-biðlauslykil og senda CSR til undirritunar

Fyrr eða síðar býðst VPN-notandi til að senda einkalykil í tölvupósti svo stjórnandinn geti búið til vottorð, og einmitt það tilboð á að hafna. Virka ferlið heldur lyklinum hjá biðlaranum frá fyrstu skipun: biðlarinn býr hann til, sendir beiðni um undirritun vottorðs, útgefandinn staðfestir og heimilar hana, og undirritaða vottorðið kemur aftur og stendur við hlið lykilsins sem bjó það til. Gátlistinn hér að neðan bregst lokað á hverju þrepi, og það er málið, því tvö af fimm þrepum eru einmitt þau sem fólk sleppir þegar það er flýtt.

Þrep 1: búðu til lykilinn þar sem hann mun búa

Búðu hann til á vélinni sem á að halda lyklinum og láttu hann þar vera. Hugbúnaðarlykill fer í skrá með ströngum heimildum; lykill sem er studdur af vélbúnaði eða í stýrðu hlaði verður aldrei skrá, og skráningarslóð hans er venjulega sérstakt tól frekar en OpenSSL-skipun. Hvort sem er, þarf enginn að sjá einkahlutann.

Hugbúnaðarferlið lítur svona út, lykillinn og beiðnin eru búin til í einni lotu:

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"

Línan umask skiptir meira máli en hún virðist. Án hennar er lykillinn skrifaður lesanlegur öllum á kerfi sem er leyfisglatt sjálfgefið, og að afrita skrána síðar dreifir því. Að endurnýta fyrirliggjandi lykil er lögmætt þegar hann er þegar varinn og passar við stefnu þína; að búa til nýjan fyrir hvert tæki er auðveldara að rökstyðja.

Þrep 2: settu auðkennið í beiðnina, ekki í tölvupóstinn

Ákveddu hvað VPN auðkennir í raun áður en beiðnin er búin til, því það svar á heima inni í CSR. OpenVPN tengir auðkenni biðlarans venjulega við almenna nafn vottorðsins, og tól eins og strongSwan passa auðkennisstreng við viðfangið eða annað nafn viðfangs. Tölvupóstur sem segir að ég heiti alice er ekki sönnun, og beiðni þar sem viðfangið segir það sama er aðeins örlítið betri.

Bættu við öðru nafni viðfangs þegar staðfestingaraðilinn þinn athugar slíkt, því nútíma samanburður hunsar oft gamla CN:

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

Haltu CN stuttu, stöðugu og bundnu við reikninginn frekar en fartölvumódel. Nafn sem inniheldur raðnúmer tækis notandans er stuðningsvandamál sem bíður fyrstu vélbúnaðarskipta.

Þrep 3: staðfestu beiðnina áður en þú skrifar undir hana

Útgefandinn staðfestir tvennt ólíkt, og að rugla því saman er klassíska mistökin. Fyrst, að beiðnin sé innbyrðis samkvæm: undirskriftin er staðfest gagnvart opinbera lyklinum sem hún ber. Síðan, að beiðandinn eigi rétt á því sem beiðnin biður um, og því getur engin dulritunarathugun svarað.

Vélræni hlutinn er ein skipun, og hún ætti að prenta staðfestingarniðurstöðu ásamt viðfanginu:

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

Taktu eftir hvað það sannar. Beiðni sem staðfestist sýnir aðeins að sendandinn hafi haft samsvarandi einkalykil á afhendingartímanum; hún sannar ekki að sendandinn sé manneskjan sem nefnd er í viðfanginu, og hún heimilar ekki aðgang að hópnum eða leiðinni sem beðið er um. Skráningaryfirferð er sérstakt hlið, og beiðni um hóp sem enginn samþykkti ætti að hafna frekar en að breyta henni hljóðlega.

Þrep 4: heimilaðu, skrifaðu svo undir með skýrum viðaukum

Undirritun er þar sem CA ákveður stefnu í stað þess að samþykkja beiðnina bókstaflega. Gildistími, lyklanotkun og hlutverksviðauki eiga heima í viðauksskrá, ekki í sjálfgefnum gildum sem þú manst ekki eftir hálfu ári síðar. Biðlara-vottorð fyrir VPN-auðkenningu þarf biðlaraauðkenningu sem tilgang.

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

Notaðu -CAserial með fyrirliggjandi raðnúmeraskrá ef ein er þegar í notkun, og haltu CA-lyklinum ótengdum eða í því varða hlaði sem stefna þín nefnir. Raðnúmer vottorða verða að vera einstök fyrir hvern útgefanda; að endurskapa raðnúmeraskrána frá grunni hættir á árekstrum sem gera afturköllun tvíræða.

Skráðu hvað var gefið út: raðnúmer, viðfang, umbeðið auðkenni, samþykkjanda og gildislok. Það skjal er það sem afturköllunarákvörðun byggir á síðar, og ekki er hægt að endurbyggja það eingöngu úr vottorðinu ef skráningarslóðin lifir aðeins í pósthólfi.

Þrep 5: settu það upp við hlið samsvarandi lykils og sannaðu parið

Biðlarinn fær vottorðið og keðju útgefandans, aldrei lykil. Áður en þú tengist, staðfestu að vottorðið myndi í raun par við lykilinn sem þegar er á diski, því misræmt par framleiðir ruglingslegt handabandsvillu miklu síðar:

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

Tveir þéttarinnir verða að stemma. Tengstu svo og staðfestu að auðkennið sem þjónninn skráir sé það sem þú heimilaðir, ekki bara að göngin hafi risið. Ef lykillinn glatast eða tækinu er skipt, er svarið afturköllun ásamt nýrri beiðni frá nýja tækinu; að biðja stjórnandann að senda lykil til baka annars staðar frá endurheimtir ekki upprunalega og brýtur hljóðlega líkanið sem gerði beiðnina örugga.