Que comproba o teu cliente VPN antes de confiar nun certificado

O teu cliente VPN di que o certificado non se puido verificar, e o diálogo remata aí. O ficheiro está, o servidor funciona, e o mesmo perfil funcionou noutro portátil o mes pasado. Baixo ese aviso dunha liña, o cliente pasou o certificado do par por catro portas: unha autoridade de certificación que configuras avala a ruta de sinatura, esa ruta chega á autoridade, o nome do par é o que pediches, e o certificado é utilizábel agora para este propósito. Atopa a porta que se pechou e a reparación adoita ser un ficheiro; salta ese paso e reimportarás paquetes toda a tarde.

Le o diálogo antes de editar o perfil

Os erros de certificado redáctaos a biblioteca de abaixo, non o produto VPN que instalaches, así que a cadea exacta é a túa primeira proba. «Non se pode obter o certificado do emisor local» apunta á ruta ou á áncora de confianza. «O certificado caducou ou aínda non é válido» apunta ao tempo. «Propósito do certificado non admitido» apunta ao uso estendido da chave. Un desaxuste de nome diche que nome quería. Ningún dos catro se repara reinstalando o cliente.

Sube o nivel de rexistro antes de cambiar nada. OpenVPN informa do fallo de verificación arredor do aperto de mans cando o executas con --verb 4, e strongSwan escribe as súas decisións de identidade e cadea no rexistro charon. Despois confirma que certificado estás inspeccionando, porque a xente adoita probar o ficheiro do disco mentres o perfil incrusta unha copia máis antiga. Cando o perfil incrusta bloques PEM, o certificado incrustado é o que se proba.

Unha autoridade de certificación asina identidades, non permisos

A autoridade garda un nome e unha chave de sinatura. Emite certificados que vinculan unha chave pública a ese nome segundo a súa propia política, cunha xanela de validez e restricións de uso adxuntas. O teu cliente só precisa o certificado da autoridade para recoñecer o emisor; nunca precisa a chave de sinatura, e enviar esa chave aos clientes daríalles a capacidade de acuñar calquera identidade na que confíe o despregamento.

Confiar nunha autoridade converte en candidato todo certificado que asinou, non no par correcto. Un certificado de servidor web da mesma CA interna tamén é candidato. Por iso existen as portas de nome e propósito, e por iso unha chave de CA comprometida importa máis que calquera servidor individual: alcanza cada identidade que a autoridade emitiu algunha vez. Entrega certificados de cliente por dispositivo, para que un portátil perdido sexa unha revocación e non unha rexeneración de chaves en todo o despregamento.

Reconstrúe a ruta que o cliente intenta construír

A ruta vai do certificado do par, a través de cero ou máis intermedios, ata unha raíz no teu almacén de confianza. Un intermedio ausente é o fallo de cadea máis común, e desde o lado do cliente vese idéntico a unha raíz non confiábel. Le primeiro a folla e despois deixa que OpenSSL constrúa a ruta co material que pensas enviar.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Un estado de saída cero significa que a ruta se construíu con eses ficheiros; un fallo nomea o certificado que non puido alcanzar. Se openssl verify ten éxito mentres o cliente segue negándose, a diferenza está no que o servidor envía realmente ou en que ficheiro de confianza carga o perfil. En OpenVPN, os intermedios poden viaxar co ficheiro do certificado do servidor ou entregarse por separado con --extra-certs, e un paquete con dúas raíces escritas baixo o mesmo nome de suxeito enviará a un dos teus clientes pola rama equivocada.

O nome e o propósito son portas separadas

A construción da cadea nunca pregunta se o nome é teu. OpenVPN só o comproba cando o perfil define --verify-x509-name, e o vello costume de cotejar só o nome común rompe con certificados cuxas identidades viven en subjectAltName. Os despregamentos IKEv2 cotejan a identidade configurada coas entradas SAN ou co nome distinguido, segundo o cliente, e un valor comodín ou %any desactiva en silencio a comparación que crías ter.

Despois veñen o tempo e o propósito. Un portátil cuxo reloxo vai unhas horas adiantado rexeita un certificado que aínda non é válido, e un intermedio caducado fai fallar a ruta mentres a folla está vixente. Os fallos de propósito veñen dun certificado sen serverAuth no uso estendido da chave, ou cun keyUsage que non permite a sinatura do aperto de mans, o que OpenSSL informa como propósito de certificado non admitido. Reemite desde o modelo correcto; nada nesa mensaxe é motivo para desactivar a verificación.

A revocación só funciona se alguén a configurou

Unha CRL ou unha resposta OCSP non se consultan automaticamente. Nun servidor OpenVPN, os certificados de cliente compróbanse contra unha lista só cando --crl-verify apunta a unha. A comprobación do certificado do servidor por parte do cliente depende da implementación e a miúdo non existe. strongSwan necesita o seu complemento de revocación e unha política antes de mirar unha CRL para un par.

Iso explica o ticket que acabarás recibindo: un certificado de cliente revogado segue conectándose, e todos conclúen que a revocación está rota. Nada estaba comprobando. Publica e refresca a CRL, ou mantén os certificados de cliente tan efémeros que unha revocación obsoleta importe pouco tempo, e ensaia a ruta de revocación cun certificado de laboratorio antes de necesitala durante un incidente.

Unha orde de reparación que mantén a verificación activa

Ordena por síntoma antes de tocar ficheiros, porque cada fila da táboa che envía a un obxecto distinto.

Percorre a lista nunha pasada: confirma o ficheiro que carga o perfil, constrúe a ruta ti mesmo, comproba que o servidor envía o intermedio, compara o reloxo, le o SAN, le o EKU, e despois reconecta e observa como desaparece a mesma liña de rexistro. Se a un dispositivo non se lle pode dar ningunha CA, o pinning é a alternativa honesta, porque OpenVPN 2.6 acepta --peer-fingerprint e reduce a confianza a unha chave en lugar de eliminar a comprobación. RFC 5280 é a referencia de que significa cada un deses campos.