Como xerar unha clave de cliente VPN e enviar unha CSR para asinar

Tarde ou cedo, un usuario de VPN ofrece enviar por correo unha clave privada para que o administrador poida facer un certificado, e é precisamente esa oferta a que hai que rexeitar. O fluxo que funciona mantén a clave no cliente desde o primeiro comando: o cliente xéraa, envía unha solicitude de sinatura de certificado, o emisor verifícaa e autorízaa, e o certificado asinado volve para quedar xunto á clave que o creou. A lista de comprobación seguinte falla pechada en cada paso, e ese é o punto, porque dous dos cinco pasos son os que a xente salta cando ten présa.

Paso 1: xere a clave onde vai vivir

Xere na máquina que vai ter a clave e déixea alí. Unha clave de software vai a un ficheiro con permisos restrinxidos; unha clave respaldada por hardware ou nun almacén xestionado nunca se converte en ficheiro, e a súa ruta de inscrición adoita ser unha ferramenta aparte e non un comando de OpenSSL. En calquera caso, ninguén necesita ver a metade privada.

O fluxo de software vese así, coa clave e a solicitude creadas nunha soa sesión:

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"

A liña umask importa máis do que parece. Sen ela a clave escríbese lexible por todos nun sistema permisivo por defecto, e copiar o ficheiro despois propágao. Reutilizar unha clave existente é lexítimo cando xa está protexida e encaixa coa súa política; xerar unha nova por dispositivo é máis doado de xustificar.

Paso 2: poña a identidade na solicitude, non no correo

Decida que autentica realmente a VPN antes de crear a solicitude, porque esa resposta pertence dentro da CSR. OpenVPN tradicionalmente vincula a identidade do cliente ao nome común do certificado, e ferramentas como strongSwan comparan unha cadea de identidade co suxeito ou un nome alternativo do suxeito. Un correo que di que me chamo alice non é unha proba, e unha solicitude cuxo suxeito di o mesmo é só un pouco mellor.

Engada un nome alternativo do suxeito cando o seu verificador comprobe un, xa que a coincidencia moderna adoita ignorar o CN antigo:

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

Manteña o CN curto, estable e ligado á conta en lugar de a un modelo de portátil. Un nome que conteña o número de serie do dispositivo do usuario é un problema de soporte esperando a primeira substitución de hardware.

Paso 3: verifique a solicitude antes de asinala

O emisor verifica dúas cousas distintas, e confundilas é o erro clásico. Primeiro, que a solicitude sexa internamente coherente: a sinatura verifícase contra a clave pública que leva. Segundo, que o solicitante teña dereito ao que pide a solicitude, e iso ningunha comprobación criptográfica pode respondelo.

A parte mecánica é un só comando, e debería imprimir un resultado de verificación xunto co suxeito:

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

Fíxese no que demostra iso. Unha solicitude que se verifica só mostra que o remitente tiña a clave privada correspondente no momento do envío; non demostra que o remitente sexa a persoa nomeada no suxeito, nin autoriza o acceso ao grupo ou á ruta que se solicita. A revisión de inscrición é unha porta aparte, e unha solicitude que pide un grupo que ninguén aprobou debería rexeitarse en lugar de editarse en silencio.

Paso 4: autorice e despois asine con extensións explícitas

A sinatura é onde a CA decide a política en lugar de aceptar a solicitude ao pé da letra. A validez, o uso da clave e a extensión de rol pertencen a un ficheiro de extensións, non a valores por defecto que non recordará seis meses despois. Un certificado de cliente para autenticación VPN necesita a autenticación de cliente como propósito.

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

Use -CAserial co ficheiro de serie existente se xa hai un en uso, e manteña a clave da CA fóra de liña ou no almacén protexido que indique a súa política. Os números de serie dos certificados deben ser únicos por emisor; recrear o ficheiro de serie desde cero arrisca colisións que fan ambigua a revocación.

Rexiste o que se emitiu: número de serie, suxeito, identidade solicitada, persoa que aprobou e caducidade. Ese rexistro é do que depende despois unha decisión de revocación, e non pode reconstruírse só a partir do certificado se o rastro de inscrición vive unicamente nunha caixa de correo.

Paso 5: instáleo xunto á clave correspondente e demostre o emparellamento

O cliente recibe o certificado e a cadea do emisor, nunca unha clave. Antes de conectar, confirme que o certificado se emparella de verdade coa clave que xa está no disco, porque un par que non coincide produce un fallo de aperta de mans confuso moito máis tarde:

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

Os dous resumos deben coincidir. Despois conecte e confirme que a identidade que rexistra o servidor é a que vostede autorizou, e non só que o túnel se levantou. Se se perde a clave ou se substitúe o dispositivo, a resposta é revocación máis unha solicitude nova desde o dispositivo novo; pedir ao administrador que devolva unha clave desde outro sitio non recupera o orixinal e rompe en silencio o modelo que facía segura a solicitude.