Nola sortu VPN bezeroaren gakoa eta CSR bat bidali sinatzeko

Lehenago edo geroago, VPN erabiltzaile batek gako pribatu bat posta elektronikoz bidaltzea eskainiko du administratzaileak ziurtagiri bat egin ahal izan dezan, eta eskaintza horixe da baztertu behar dena. Funtzionatzen duen fluxuak gakoa bezeroan mantentzen du lehen komandotik: bezeroak sortzen du, ziurtagiri sinatze eskari bat bidaltzen du, igorleak egiaztatzen eta baimetzen du, eta sinatutako ziurtagiria itzultzen da sortu zuen gakoaren ondoan egoteko. Beheko zerrendak huts egiten du itxita urrats bakoitzean, eta hori da kontua, bost urratsetatik bi presaka doazenean jendeak saltatzen dituenak direlako.

1 urratsa: sortu gakoa bizi izango den lekuan

Sortu gakoa edukiko duen makinan eta utzi han. Software gako bat baimen murritzak dituen fitxategi batean gordetzen da; hardwarez babestutako gakoa edo biltegi kudeatu bateko gakoa ez da inoiz fitxategi bihurtzen, eta haren izena emateko bidea OpenSSL komandoa baino tresna bereizi bat izaten da normalean. Nola edo hala, inork ez du erdia pribatua ikusi behar.

Software fluxua horrela ikusten da, gakoa eta eskaria saio bakarrean sortuta:

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"

umask lerroak uste baino garrantzi handiagoa du. Harekin gabe gakoa guztiek irakurtzeko eran idazten da lehenetsitako permisibitatea duen sisteman, eta fitxategia geroago kopiatzeak hori hedatzen du. Dagoen gako bat berrerabiltzea zilegia da jada babestuta badago eta zure politikarekin bat badator; gailu bakoitzeko gako berri bat sortzea errazagoa da justifikatzen.

2 urratsa: jarri identitatea eskarian, eta ez postan

Erabaki VPNak zer egiaztatzen duen benetan eskaria sortu aurretik, erantzun hori CSR-ren barruan sartzen delako. OpenVPN tradizionalki bezeroaren identitatea ziurtagiriaren izen komunarekin lotzen du, eta strongSwan bezalako tresnek identitate katea subjektuarekin edo subjektuaren izen alternatiboarekin parekatzen dute. Nire izena alice dela dioen posta ez da froga, eta subjektuak gauza bera dioen eskaria apenas da hobea.

Gehitu subjektuaren izen alternatiboa zure egiaztatzaileak bat egiaztatzen duenean, parekatze modernoak CN zaharra maiz baztertzen duelako:

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

Mantendu CN laburra, egonkorra eta kontuari lotuta, eta ez eramangarri baten modeloei. Erabiltzailearen gailuaren serie zenbakia duen izena lehen hardware ordezkapenaren zain dagoen laguntza arazoa da.

3 urratsa: egiaztatu eskaria sinatu aurretik

Igorleak bi gauza desberdin egiaztatzen ditu, eta horiek nahastea da akats klasikoa. Lehenik, eskaria barnetik koherentea dela: sinadura eramaten duen gako publikoaren aurka egiaztatzen da. Bigarrenik, eskatzaileak eskariak eskatzen duenerako eskubidea duela, eta horri ezin dio egiaztapen kriptografikok erantzun.

Zati mekanikoa komando bakarra da, eta egiaztatze emaitza bat inprimatu beharko luke subjektuarekin batera:

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

Ohartu zer frogatzen duen horrek. Egiaztatzen den eskari batek erakusten du bidaltzaileak dagokion gako pribatua zuela bidaltze unean soilik; ez du frogatzen bidaltzailea subjektuan izendatutako pertsona denik, eta ez du baimentzen eskatzen ari den talde edo bide sarbidea. Izena emateko berrikuspena ate bereizi bat da, eta inork onartu ez duen talde bat eskatzen duen eskaria baztertu egin behar litzateke isilka editatu beharrean.

4 urratsa: baimendu, eta gero sinatu luzapen esplizituekin

Sinatzea da CAk politika erabakitzen duen tokia, eskaria hitzez hitz onartu beharrean. Baliozkotasuna, gako erabilera eta rol luzapena luzapen fitxategi batean egon behar dute, eta ez sei hilabete geroago gogoratuko ez dituzun balio lehenetsietan. VPN egiaztapenerako bezero ziurtagiri batek bezero egiaztapena behar du helburu gisa.

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

Erabili -CAserial lehendik dagoen serie fitxategiarekin bat jada erabiltzen ari bada, eta mantendu CA gakoa lineaz kanpo edo zure politikak aipatzen duen biltegi babestuan. Ziurtagirien serie zenbakiek igorle bakoitzeko bakarrak izan behar dute; serie fitxategia hutsetik berriz sortzeak errebokazioa anbiguoa egiten duten talkak arriskatu ditzake.

Erregistratu zer jaulki zen: seriea, subjektua, eskatutako identitatea, onartu zuen pertsona eta iraungitzea. Erregistro hori da geroago errebokazio erabaki batek oinarritzat duena, eta ezin da ziurtagiritik soilik berreraiki izena emateko arrastoa postontzi batean soilik bizi bada.

5 urratsa: instalatu dagokion gakoaren ondoan eta frogatu bikotea

Bezeroak ziurtagiria eta igorlearen katea jasotzen ditu, inoiz ez gakoa. Konektatu aurretik, berretsi ziurtagiriak diskoan dagoen gakoarekin benetan bikotea osatzen duela, bikote desegoki batek askoz geroago uztarketa hutsegite nahasia sortzen duelako:

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

Bi laburpenek bat etorri behar dute. Gero konektatu eta berretsi zerbitzariak erregistratzen duen identitatea baimendu duzun hori dela, eta ez soilik tunela altxatu dela. Gakoa galdu edo gailua ordezkatzen bada, erantzuna errebokazioa gehi gailu berritik eskari berri bat da; administratzaileari beste nonbaitetik gakoa itzultzeko eskatzeak ez du jatorrizkoa berreskuratzen eta isilka hausten du eskaria seguru egin zuen eredua.