¿Certificado de cliente autofirmado? O servidor VPN ségueno rexeitando

O operador envía un enderezo e un nome de usuario, e o cliente pide un ficheiro de CA, un certificado e unha chave. Xerar eses tres localmente parece o seguinte paso obvio. Prodúcese un certificado no que só cre a súa propia máquina. A confianza do servidor está ancorada nunha CA que vostede non controla, así que o aperto de mans remata antes de comezar.

A confianza vive no servidor, non no seu perfil

A autenticación con certificado é unha comparación. O cliente presenta un certificado; a pasarela comproba se o asinou algunha das CA da súa configuración.

O seu perfil nomea o ficheiro de CA que o cliente debe usar para verificar o servidor. Non pode nomear unha CA que o servidor deba usar para verificalo a vostede. Esa metade da configuración non é súa.

Un certificado feito por vostede falla esta comparación mesmo cando é tecnicamente perfecto. Ten unha sinatura válida, un suxeito e datas, pero o emisor é unha CA da que a pasarela nunca oíu falar. O erro aparece durante o aperto de mans, despois de que o servidor xa pedise un certificado. Nada no perfil do cliente pode cambiar a resposta.

Por que un certificado autofirmado non pode substituílo

Un certificado autofirmado está asinado coa súa propia chave. A sinatura verifícase contra o mesmo ficheiro, o que o fai autoconsistente e inútil como credencial para a pasarela doutro.

A pasarela non pregunta se o certificado é coherente internamente. Pregunta se o asinou un emisor de confianza.

Por iso as mensaxes de erro confunden. O cliente pode informar dun fallo de verificación que soa a problema do servidor, mentres o servidor rexistra un emisor descoñecido. Ambos describen o mesmo desaxuste desde extremos opostos.

A vía da CSR conserva a súa chave privada

Aínda pode facer a maior parte do traballo localmente. Xere un par de chaves, constrúa unha solicitude de sinatura de certificado arredor da metade pública e envíe esa solicitude ao operador. Só a solicitude sae da súa máquina. A metade privada queda onde a xerou.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

O operador asina a solicitude coa súa CA e devolve un certificado. A súa chave privada nunca viaxou, e o resultado encadea coa áncora na que confía a pasarela.

Os servizos xestionados adoitan saltarse a CSR e emitir o paquete completo. É un intercambio razoable cando o mesmo provedor xa remata o túnel e ten a CA. A custodia da chave non mellora por conservala, porque o provedor podería acuñar outra en calquera momento.

Os paquetes impórtanse, non se instalan

Os paquetes de provedores con nomes que soan a seguridade adoitan ser perfís de OpenVPN. Conteñen configuración e ás veces certificados, e non instalan nada. Importe o ficheiro nun cliente que fale o protocolo, e a conexión queda configurada.

A regra de manexo dedúcese do contido. Se o perfil incorpora unha chave privada, é unha credencial e merece o mesmo coidado que un contrasinal: nada de correo, nada de repositorio, nada de cartafol de descargas compartido. Cando o operador entrega ca.crt, client.crt e client.key por separado, gárdeos xuntos con permisos restritivos e apunte o perfil cara a eles.

Engada as comprobacións que o operador poida ter omitido

Un perfil xerado polo router ás veces carece de verificación do par. remote-cert-tls server esixe que o certificado do par leve o propósito de autenticación de servidor, de xeito que un certificado de cliente non se poida reproducir como servidor. Esa liña é un cambio pequeno cunha xustificación clara.

verify-x509-name vai máis aló cando o operador pode nomear o suxeito ou o SAN esperados. Ambas son adicións pequenas a un perfil, e ambas son defendibles. Inspeccione o que recibiu antes de importalo.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

A configuración de verificación non é unha reparación dunha cadea rota. Se o emisor é incorrecto, a resposta é un certificado da CA correcta, non un indicador que desactive a comprobación. Desactivar a verificación converte un fallo de autenticación nun non detectado.

Pida un só paquete: o certificado da autoridade en PEM, un certificado de cliente asinado por esa autoridade, unha chave que xerase vostede ou que chegase por unha canle na que confíe, e o nome exacto do servidor que o certificado debe presentar. Anote a data de caducidade na mesma mensaxe, porque un certificado caducado parece unha avaría de rede meses despois.