Por que OpenConnect rexeita a pasarela tras un cambio de certificado?
Un fallo de verificación tras un cambio de certificado na pasarela é unha decisión de confianza, non un túnel roto. Escolla entre a CA emisora e a fixación dunha soa chave.
As pasarelas substitúen certificados, e un cliente que onte se conectaba comeza a deterse no primeiro intercambio TLS. A mensaxe nomea un motivo de verificación e non un fallo de rede, e a máquina en si non cambiou, que é a pista útil. O que se rompeu é a relación entre o certificado que agora se presenta e as raíces que o cliente está disposto a considerar. Reparalo é unha decisión de confianza, así que tome esa decisión antes de escribir unha opción.
Lea o fallo antes de cambiar calquera axuste de confianza
Un erro do tipo asinante ausente significa que a cadea remata en algo que o cliente non acepta. Pode ser un certificado renovado dunha autoridade interna, unha substitución dunha pública, ou un dispositivo no medio que presenta o seu propio certificado. Só a redacción non pode distinguir eses casos, así que mire o emisor antes de decidir.
Execute a conexión unha vez en primeiro plano e déixea fallar, porque a saída interactiva leva o nome do servidor, a cadea de emisores e a impresión dixital que o cliente calculou. Compare ese emisor cunha autoridade que a súa organización opere de verdade. Se a impresión cambiou mentres o emisor non, tráteo como sospeitoso ata que se confirme unha renovación por unha canle na que xa confía. Adiviñar neste punto é como unha persoa acaba fixando a chave dun interceptor.
Anote a versión do cliente na mesma nota. Boa parte dos fallos que parecen problemas de confianza veñen dun cliente máis antigo que atopa un intercambio de pasarela máis novo.
Escolla entre confiar no emisor e fixar unha chave
Ambas as opcións fan que a conexión funcione. Rómpense despois de maneiras opostas, así que a escolla pertence ao fallo que poida tolerar.
| Approach | Good fit | What breaks it |
|---|---|---|
Trust the issuing CA with --cafile | Internal PKI you can obtain over an already trusted channel | CA rotation, or a client that still falls back to public roots |
Pin one key with --servercert | No CA relationship, or exactly one key should ever be accepted | Any reissue that generates a new key pair |
Recorra ao ficheiro de CA cando o certificado veña dunha autoridade que poida verificar de forma independente, porque as renovacións seguen funcionando sen tocar os argumentos do cliente. Compáreo co interruptor que desactiva as raíces do sistema, doutro xeito unha autoridade pública pode satisfacer a comprobación no seu nome. Fixe unha chave no seu lugar cando a pasarela non teña unha CA que poida obter ou cando a excepción máis estreita posible sexa o obxectivo. Ningún camiño é máis seguro en abstracto: a CA escala ao longo das renovacións, a fixación é máis fácil de revisar.
Escolla o que escolla, o valor de confianza ten que chegar por unha canle que fose de confianza antes de que ocorrese o cambio. Un administrador, unha sesión de consola na pasarela ou unha copia tomada con antelación cumpren. Copiar a impresión que mostre o aviso é cómodo e é exactamente o que un interceptor espera.
Poña o valor na orde que realmente lanza
A fixación viaxa nunha opción de certificado de servidor, e o seu prefixo decide a codificación: resumos hexadecimais de chave pública baixo sha1 ou sha256, e a fixación de chave en base64 baixo pin-sha256. Subministrala tamén desactiva a confianza do sistema para esa execución, así que a chave fixada convértese en toda a decisión.
sudo openconnect --protocol=gp vpn.example.com --user alice \
--servercert pin-sha256:AbCdEf... # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trustO cliente coincide cun resumo truncado, aceptando tan só catro caracteres tras o prefixo, o que é unha trampa e non unha comodidade. Un valor acurtado pasa localmente e segue sen identificar a pasarela que pretendía. Copie a cadea completa que o cliente imprimiu no primeiro intento en lugar de reescribila desde unha mensaxe. Logo mova a opción terminada ao script envoltorio, ao ficheiro de unidade ou ao perfil que lanza a conexión, para que a decisión de confianza sexa revisable e as edicións posteriores sexan deliberadas.
Os lanzadores de escritorio e o complemento de NetworkManager gardan a súa propia copia dos argumentos de conexión. Un script editado no disco non chega a un perfil importado antes, así que o valor almacenado segue gañando.
Xestione unha rotación sen quedarse fóra
A opción pode darse máis dunha vez, así que un cambio planificado pode aceptar as chaves saínte e entrante á vez. Engada a nova fixación antes de que a pasarela cambie, manteña ambas na lista mentres migran as sesións, e retire a xubilada cando a chave vella xa non estea. Esa ventá necesita un responsable, xa que unha dobre fixación esquecida deixa unha chave confiada sen ninguén que a vixie. Unha reconstrución que produce un par de chaves novo rompe unha fixación pura, e a recuperación é o mesmo procedemento na outra dirección.
Escriba a data do cambio xunto á fixación. Unha fixación sen data de revisión é unha caída futura que leva unha mensaxe de erro confusa.
Descarte a versión do cliente antes de editar a confianza
Un cliente antigo pode fallar mentres analiza unha resposta de autenticación que a pasarela alterou desde entón, e a mensaxe superficial segue falando da conexión e non do analizador. Compare a versión instalada co que documenta a pasarela, e probe un paquete actual nun perfil refugable antes de cambiar calquera axuste de confianza.
openconnect --versionDespois da reparación, verifique dúas cousas en lugar dunha: o portal carga a través do túnel e un enderezo interno corrente responde. Un aperto de mans completado só demostra que a decisión de confianza foi aceptada.