¿Por qué OpenConnect rechaza la puerta de enlace tras un cambio de certificado?

Las puertas de enlace sustituyen certificados, y un cliente que ayer se conectaba empieza a detenerse en el primer intercambio TLS. El mensaje nombra un motivo de verificación y no un fallo de red, y la máquina en sí no ha cambiado, que es la pista útil. Lo que se rompió es la relación entre el certificado que ahora se presenta y las raíces que el cliente está dispuesto a considerar. Repararlo es una decisión de confianza, así que tómela antes de escribir una opción.

Lea el fallo antes de cambiar cualquier ajuste de confianza

Un error del tipo firmante ausente significa que la cadena termina en algo que el cliente no acepta. Puede ser un certificado renovado de una autoridad interna, una sustitución de una pública, o un dispositivo en medio que presenta su propio certificado. Solo la redacción no puede distinguir esos casos, así que mire al emisor antes de decidir.

Ejecute la conexión una vez en primer plano y déjela fallar, porque la salida interactiva lleva el nombre del servidor, la cadena de emisores y la huella que calculó el cliente. Compare ese emisor con una autoridad que su organización opere de verdad. Si la huella cambió mientras el emisor no, trátelo como sospechoso hasta que se confirme una renovación por un canal en el que ya confía. Adivinar en este punto es como una persona acaba fijando la clave de un interceptor.

Anote la versión del cliente en la misma nota. Buena parte de los fallos que parecen problemas de confianza vienen de un cliente más antiguo que se encuentra con un intercambio de puerta más nuevo.

Elija entre confiar en el emisor y fijar una clave

Ambas opciones hacen que la conexión funcione. Se rompen después de maneras opuestas, así que la elección pertenece al fallo que pueda tolerar.

Recurra al archivo de CA cuando el certificado venga de una autoridad que pueda verificar de forma independiente, porque las renovaciones siguen funcionando sin tocar los argumentos del cliente. Compárelo con el interruptor que desactiva las raíces del sistema, de lo contrario una autoridad pública puede satisfacer la comprobación en su nombre. Fije una clave en su lugar cuando la puerta no tenga una CA que pueda obtener o cuando la excepción más estrecha posible sea el objetivo. Ningún camino es más seguro en abstracto: la CA escala a lo largo de las renovaciones, la fijación es más fácil de revisar.

Elija lo que elija, el valor de confianza tiene que llegar por un canal que fuera de confianza antes de que ocurriera el cambio. Un administrador, una sesión de consola en la puerta o una copia tomada con antelación cumplen. Copiar la huella que muestre el aviso es cómodo y es exactamente lo que un interceptor espera.

Ponga el valor en el comando que realmente lanza

La fijación viaja en una opción de certificado de servidor, y su prefijo decide la codificación: resúmenes hexadecimales de clave pública bajo sha1 o sha256, y la fijación de clave en base64 bajo pin-sha256. Suministrarla también desactiva la confianza del sistema para esa ejecución, así que la clave fijada se convierte en toda la 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-trust

El cliente coincide con un resumen truncado, aceptando tan solo cuatro caracteres tras el prefijo, lo que es una trampa y no una comodidad. Un valor acortado pasa localmente y sigue sin identificar la puerta que pretendía. Copie la cadena completa que el cliente imprimió en el primer intento en lugar de reescribirla desde un mensaje. Luego mueva la opción terminada al script envoltorio, al archivo de unidad o al perfil que lanza la conexión, para que la decisión de confianza sea revisable y las ediciones posteriores sean deliberadas.

Los lanzadores de escritorio y el complemento de NetworkManager guardan su propia copia de los argumentos de conexión. Un script editado en disco no llega a un perfil importado antes, así que el valor almacenado sigue ganando.

Gestione una rotación sin quedarse fuera

La opción puede darse más de una vez, así que un cambio planificado puede aceptar las claves saliente y entrante a la vez. Añada la nueva fijación antes de que la puerta cambie, mantenga ambas en la lista mientras migran las sesiones, y retire la jubilada cuando la clave vieja ya no esté. Esa ventana necesita un responsable, ya que una doble fijación olvidada deja una clave confiada sin nadie que la vigile. Una reconstrucción que produce un par de claves nuevo rompe una fijación pura, y la recuperación es el mismo procedimiento en la otra dirección.

Escriba la fecha del cambio junto a la fijación. Una fijación sin fecha de revisión es una caída futura que lleva un mensaje de error confuso.

Descarte la versión del cliente antes de editar la confianza

Un cliente antiguo puede fallar mientras analiza una respuesta de autenticación que la puerta ha alterado desde entonces, y el mensaje superficial sigue hablando de la conexión y no del analizador. Compare la versión instalada con lo que documenta la puerta, y pruebe un paquete actual en un perfil desechable antes de cambiar cualquier ajuste de confianza.

openconnect --version

Después de la reparación, verifique dos cosas en lugar de una: el portal se carga a través del túnel y una dirección interna corriente responde. Un apretón de manos completado solo demuestra que la decisión de confianza fue aceptada.