strongSwan send_cert: cuándo se envía el certificado IKE

Las pasarelas registran fallos de autenticación relacionados con certificados, y el primer impulso es añadir otra CA al receptor. Eso presupone que el certificado llegó y fue rechazado. La otra posibilidad es que nunca se enviara, y eso lo decide la política de conexión del emisor. Determine cuál de los dos casos ocurrió antes de tocar la confianza.

Qué controla send_cert en realidad

La autenticación con certificado necesita que el certificado de entidad final del peer llegue al otro lado mediante el intercambio IKE o mediante un aprovisionamiento previo. En swanctl, el ajuste de conexión send_cert determina si este extremo incluye su carga de certificado: nunca, siempre o ifasked. El valor predeterminado ifasked lo envía en respuesta a una solicitud de certificado del peer. Solicitar un certificado es un ajuste aparte, porque pedir a la otra parte su certificado no es lo mismo que ofrecer el propio.

Los despliegues antiguos de ipsec.conf usaban leftsendcert y rightsendcert, y esos nombres corresponden a los roles local y remoto, no directamente a swanctl.

Lea un intento antes de modificar la conexión

Diagnostique a partir de un único intento controlado, no de la impresión general de que hay certificados implicados. Tanto la política como la asociación activa se pueden inspeccionar.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

El listado de conexiones muestra el valor configurado de send_cert, y el listado de SA muestra qué conexiones llegaron a establecerse. El registro añade detalles de la negociación: si se recibió una solicitud de certificado y si salió una carga de certificado. Un fallo de autenticación genérico no identifica un problema de entrega, así que busque el intercambio concreto antes de concluir nada. Anote la marca de tiempo del intento para que la ventana del registro cubra todo el handshake.

La confianza del receptor es una decisión aparte

La entrega y la confianza son propiedades distintas, y arreglar una no arregla la otra. Un receptor debe poseer el ancla de confianza prevista, recibir una cadena utilizable y coincidir con la identidad esperada del peer. Un certificado de entidad final que llega sin su intermedio sigue fallando una comprobación estricta de cadena. A la inversa, instalar una CA no obliga en absoluto a un peer a enviar su certificado.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

La inspección muestra qué emisor firmó el certificado y cuándo caduca, y a eso debe corresponder el ancla del receptor. Confíe en la CA emisora que posee el despliegue, no en cada intermedio de la cadena, porque promover cada intermedio a raíz amplía la confianza mucho más allá de un solo peer. Mantenga activa la verificación de identidad, ya que una conexión que solo funciona con la validación desactivada no es una solución. Donde la cadena está incompleta, repare el aprovisionamiento en lugar de la política del emisor.

Cambie el emisor solo con pruebas

Cuando el registro muestra que el certificado nunca se envió y que el receptor sí lo solicitó, poner send_cert en always es un cambio justificado para esa conexión. Aplíquelo en la configuración de swanctl, recargue las conexiones y establezca una sesión nueva en lugar de reutilizar la SA existente. Confirme que la carga del certificado aparece ahora y que el receptor la acepta contra el ancla prevista. Si nada cambia, el fallo estaba en el lado de la confianza y el ajuste del emisor no era la causa.

Escriba el intercambio observado, el ancla y la verificación resultante en el registro de cambios. Una corrección de certificado que no pueda describirse en esos términos es una casualidad.