Sut i gynhyrchu allwedd cleient VPN a chyflwyno CSR i'w lofnodi

Yn hwyr neu'n hwyrach, bydd defnyddiwr VPN yn cynnig anfon allwedd breifat drwy e-bost fel y gall y gweinyddwr wneud tystysgrif, a'r cynnig hwnnw yw'r peth i'w wrthod. Mae'r llif sy'n gweithio yn cadw'r allwedd ar y cleient o'r gorchymyn cyntaf: mae'r cleient yn ei chynhyrchu, yn anfon cais llofnodi tystysgrif, mae'r dyroddwr yn ei ddilysu ac yn ei awdurdodi, ac mae'r dystysgrif lofnodedig yn dychwelyd i eistedd wrth ymyl yr allwedd a'i creodd. Mae'r rhestr wirio isod yn methu ar gau ar bob cam, a dyna'r pwynt, oherwydd dau o'r pum cam yw'r rhai y mae pobl yn eu hepgor pan fyddant ar frys.

Cam 1: cynhyrchwch yr allwedd lle bydd yn byw

Cynhyrchwch ar y peiriant a fydd yn dal yr allwedd, a'i gadw yno. Mae allwedd meddalwedd yn mynd i ffeil â chaniatâd caeth; nid yw allwedd a gefnogir gan galedwedd neu mewn storfa reoledig byth yn dod yn ffeil, ac mae ei llwybr cofrestru fel arfer yn offeryn ar wahân yn hytrach na gorchymyn OpenSSL. Naill ffordd neu'r llall, nid oes angen i neb weld yr hanner preifat.

Mae'r llif meddalwedd yn edrych fel hyn, gyda'r allwedd a'r cais yn cael eu creu mewn un sesiwn:

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"

Mae'r llinell umask yn bwysicach nag y mae'n ymddangos. Hebddi, mae'r allwedd yn cael ei hysgrifennu'n ddarllenadwy i bawb ar system sy'n caniatáu'n ddiofyn, ac mae copïo'r ffeil o gwmpas yn ddiweddarach yn lledaenu hynny. Mae ailddefnyddio allwedd bresennol yn gyfreithlon pan fydd eisoes yn cael ei diogelu ac yn cyd-fynd â'ch polisi; mae cynhyrchu un newydd fesul dyfais yn haws i'w hesbonio.

Cam 2: rhowch y hunaniaeth yn y cais, nid yn yr e-bost

Penderfynwch beth mae'r VPN yn ei ddilysu mewn gwirionedd cyn i'r cais gael ei greu, oherwydd mae'r ateb hwnnw'n perthyn y tu mewn i'r CSR. OpenVPN yn draddodiadol yn cysylltu hunaniaeth y cleient â'r enw cyffredin ar y dystysgrif, ac mae offer fel strongSwan yn paru llinyn hunaniaeth â'r pwnc neu enw amgen y pwnc. Nid yw e-bost sy'n dweud mai fy enw yw alice yn dystiolaeth, ac mae cais y mae ei bwnc yn dweud yr un peth ychydig yn well yn unig.

Ychwanegwch enw amgen pwnc pan fydd eich dilyswr yn gwirio un, gan fod paru modern yn aml yn anwybyddu'r CN blaenorol:

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

Cadwch y CN yn fyr, yn sefydlog ac yn gysylltiedig â'r cyfrif yn hytrach nag â model gliniadur. Mae enw sy'n cynnwys rhif cyfresol dyfais y defnyddiwr yn broblem cymorth sy'n aros am y disodliad caledwedd cyntaf.

Cam 3: dilyswch y cais cyn i chi ei lofnodi

Mae'r dyroddwr yn dilysu dau beth gwahanol, ac mae eu cymysgu yn gamgymeriad clasurol. Yn gyntaf, bod y cais yn fewnol gyson: mae'r llofnod yn dilysu yn erbyn yr allwedd gyhoeddus y mae'n ei chario. Yn ail, bod gan y ceisydd hawl i'r hyn y mae'r cais yn gofyn amdano, ac ni all unrhyw wiriad cryptograffig ateb hynny.

Mae'r rhan fecanyddol yn un gorchymyn, ac fe ddylai argraffu canlyniad dilysu ynghyd â'r pwnc:

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

Sylwch beth mae hynny'n ei brofi. Mae cais sy'n dilysu ond yn dangos bod yr anfonwr wedi dal yr allwedd breifat gyfatebol ar adeg cyflwyno; nid yw'n profi mai'r anfonwr yw'r person a enwir yn y pwnc, ac nid yw'n awdurdodi'r mynediad at y grŵp neu'r llwybr sy'n cael ei ofyn. Mae adolygiad cofrestru yn giât ar wahân, a dylid gwrthod cais sy'n gofyn am grŵp na chymeradwyodd neb yn hytrach na'i olygu'n dawel.

Cam 4: awdurdodwch, yna llofnodwch ag estyniadau penodol

Llofnodi yw lle mae'r CA yn penderfynu polisi yn hytrach na derbyn y cais yn llythrennol. Mae dilysrwydd, defnydd allwedd a'r estyniad rôl yn perthyn i ffeil estyniadau, nid i osodiadau diofyn na allwch eu cofio chwe mis yn ddiweddarach. Mae angen dilysu cleient fel pwrpas ar dystysgrif cleient ar gyfer dilysu VPN.

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

Defnyddiwch -CAserial gyda'r ffeil gyfresol bresennol os yw un eisoes yn cael ei defnyddio, a chadwch allwedd y CA all-lein neu yn y storfa warchodedig a enwir gan eich polisi. Rhaid i rifau cyfresol tystysgrifau fod yn unigryw fesul dyroddwr; mae ail-greu'r ffeil gyfresol o'r dechrau yn peryglu gwrthdrawiadau sy'n gwneud dirymu'n amwys.

Cofnodwch beth a ddyroddwyd: rhif cyfresol, pwnc, hunaniaeth a ofynnwyd, person a gymeradwyodd a dyddiad dod i ben. Y cofnod hwnnw yw'r hyn y mae penderfyniad dirymu yn dibynnu arno yn ddiweddarach, ac ni ellir ei ailadeiladu o'r dystysgrif yn unig os yw'r trywydd cofrestru yn byw mewn blwch post yn unig.

Cam 5: gosodwch ef wrth ymyl yr allwedd gyfatebol a phrofwch y pâr

Mae'r cleient yn derbyn y dystysgrif a chadwyn y dyroddwr, byth allwedd. Cyn cysylltu, cadarnhewch fod y dystysgrif mewn gwirionedd yn paru â'r allwedd sydd eisoes ar ddisg, oherwydd mae pâr anghywir yn cynhyrchu methiant ysgwyd llaw dryslyd lawer yn ddiweddarach:

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

Rhaid i'r ddau grynodeb gyd-fynd. Yna cysylltwch a chadarnhau mai'r hunaniaeth y mae'r gweinydd yn ei chofnodi yw'r un a awdurdodwyd gennych, nid yn unig fod y twnnel wedi codi. Os collir yr allwedd neu os disodlir y ddyfais, yr ateb yw dirymu ynghyd â chais newydd o'r ddyfais newydd; nid yw gofyn i'r gweinyddwr anfon allwedd yn ôl o rywle arall yn adfer yr un gwreiddiol ac mae'n torri'n dawel y model a oedd yn gwneud y cais yn ddiogel.