Com generar una clau de client VPN i enviar una CSR per signar

Tard o d'hora, un usuari de VPN ofereix d'enviar per correu una clau privada perquè l'administrador pugui fer un certificat, i aquesta oferta és la que cal rebutjar. El flux que funciona manté la clau al client des de la primera ordre: el client la genera, envia una sol·licitud de signatura de certificat, l'emissor la verifica i l'autoritza, i el certificat signat torna per seure al costat de la clau que el va crear. La llista de comprovació següent falla tancada a cada pas, i aquest és el punt, perquè dos dels cinc passos són els que la gent s'estalvia quan té pressa.

Pas 1: genereu la clau on viurà

Genereu a la màquina que tindrà la clau i deixeu-la allà. Una clau de programari va a un fitxer amb permisos restrictius; una clau recolzada per maquinari o en un magatzem gestionat no es converteix mai en un fitxer, i el seu camí d'inscripció sol ser una eina separada i no una ordre OpenSSL. De qualsevol manera, ningú no ha de veure la meitat privada.

El flux de programari és així, amb la clau i la sol·licitud creades en una sola sessió:

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 línia umask importa més del que sembla. Sense ella, la clau s'escriu llegible per tothom en un sistema permissiu per defecte, i copiar el fitxer més tard ho escampa. Reutilitzar una clau existent és legítim quan ja està protegida i coincideix amb la vostra política; generar-ne una de nova per dispositiu és més fàcil de justificar.

Pas 2: poseu la identitat a la sol·licitud, no al correu

Decidiu què autentica realment la VPN abans de crear la sol·licitud, perquè aquesta resposta pertany dins de la CSR. OpenVPN tradicionalment lliga la identitat del client al nom comú del certificat, i eines com strongSwan fan coincidir una cadena d'identitat amb el subjecte o un nom alternatiu del subjecte. Un correu que diu que em dic alice no és una prova, i una sol·licitud el subjecte de la qual diu el mateix només és una mica millor.

Afegiu un nom alternatiu del subjecte quan el vostre verificador en comprovi un, ja que la concordança moderna sovint ignora el CN antic:

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

Mantingueu el CN curt, estable i lligat al compte i no a un model de portàtil. Un nom que contingui el número de sèrie del dispositiu de l'usuari és un problema de suport esperant la primera substitució de maquinari.

Pas 3: verifiqueu la sol·licitud abans de signar-la

L'emissor verifica dues coses diferents, i confondre-les és l'error clàssic. Primer, que la sol·licitud sigui internament coherent: la signatura es verifica contra la clau pública que porta. Segon, que el sol·licitant tingui dret al que demana la sol·licitud, cosa que cap comprovació criptogràfica pot respondre.

La part mecànica és una ordre, i hauria d'imprimir un resultat de verificació juntament amb el subjecte:

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

Fixeu-vos en què demostra això. Una sol·licitud que es verifica només mostra que el remitent tenia la clau privada corresponent en el moment de l'enviament; no demostra que el remitent sigui la persona nomenada al subjecte, ni autoritza l'accés al grup o a la ruta que es demana. La revisió d'inscripció és una porta separada, i una sol·licitud que demana un grup que ningú no ha aprovat s'hauria de rebutjar en lloc d'editar-se en silenci.

Pas 4: autoritzeu i després signeu amb extensions explícites

La signatura és on la CA decideix la política en lloc d'acceptar la sol·licitud al peu de la lletra. La validesa, l'ús de la clau i l'extensió de rol pertanyen a un fitxer d'extensions, no a valors per defecte que no recordareu sis mesos després. Un certificat de client per a l'autenticació VPN necessita l'autenticació de client com a propòsit.

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

Utilitzeu -CAserial amb el fitxer de sèrie existent si ja se n'usa un, i manteniu la clau de la CA fora de línia o en el magatzem protegit que indiqui la vostra política. Els números de sèrie dels certificats han de ser únics per emissor; refer el fitxer de sèrie des de zero arrisca col·lisions que fan ambigua la revocació.

Registreu què s'ha emès: sèrie, subjecte, identitat sol·licitada, persona aprovadora i caducitat. Aquest registre és del que depèn més tard una decisió de revocació, i no es pot reconstruir només amb el certificat si el rastre d'inscripció viu únicament en una bústia de correu.

Pas 5: instal·leu-lo al costat de la clau corresponent i demostreu la parella

El client rep el certificat i la cadena de l'emissor, mai una clau. Abans de connectar, confirmeu que el certificat s'aparella realment amb la clau que ja hi ha al disc, perquè una parella que no coincideix produeix un error d'apretada de mans confús molt més tard:

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

Els dos resums han de coincidir. Després connecteu i confirmeu que la identitat que registra el servidor és la que heu autoritzat, i no només que el túnel s'ha aixecat. Si es perd la clau o es substitueix el dispositiu, la resposta és revocació més una sol·licitud nova des del dispositiu nou; demanar a l'administrador que torni a enviar una clau d'un altre lloc no recupera l'original i trenca en silenci el model que feia segura la sol·licitud.