strongSwan send_cert: cando se envía o certificado IKE

As pasarelas rexistran fallos de autenticación relacionados con certificados, e o primeiro impulso é engadir outra CA ao receptor. Iso presupón que o certificado chegou e foi rexeitado. A outra posibilidade é que nunca se enviase, e iso decídeo a política de conexión do emisor. Determine cal dos dous casos ocorreu antes de tocar a confianza.

Que controla send_cert en realidade

A autenticación con certificado necesita que o certificado de entidade final do peer chegue ao outro lado mediante o intercambio IKE ou un aprovisionamento previo. En swanctl, o axuste de conexión send_cert determina se este extremo inclúe a súa carga de certificado: nunca, sempre ou ifasked. O valor predeterminado ifasked envíao como resposta a unha solicitude de certificado do peer. Pedir un certificado é un axuste á parte, porque pedirlle á outra parte o seu certificado non é o mesmo que ofrecer o propio.

Os despregamentos antigos de ipsec.conf usaban leftsendcert e rightsendcert, e eses nomes corresponden aos roles local e remoto, non directamente a swanctl.

Lea un intento antes de modificar a conexión

Diagnostique a partir dun único intento controlado, non da impresión xeral de que hai certificados implicados. Tanto a política como a asociación activa poden inspeccionarse.

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

A listaxe de conexións mostra o valor configurado de send_cert, e a listaxe de SA mostra que conexións chegaron a establecerse. O rexistro engade detalles da negociación: se se recibiu unha solicitude de certificado e se saíu unha carga de certificado. Un fallo de autenticación xenérico non identifica un problema de entrega, así que busque o intercambio concreto antes de concluír nada. Anote a marca de tempo do intento para que a xanela do rexistro cubra todo o handshake.

A confianza do receptor é unha decisión á parte

A entrega e a confianza son propiedades distintas, e arranxar unha non arranxa a outra. Un receptor debe posuír a áncora de confianza prevista, recibir unha cadea utilizábel e coincidir coa identidade esperada do peer. Un certificado de entidade final que chega sen o seu intermedio segue fallando unha comprobación estrita de cadea. Á inversa, instalar unha CA non obriga en absoluto un peer a enviar o seu certificado.

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

A inspección mostra que emisor asinou o certificado e cando caduca, e a iso debe corresponder a áncora do receptor. Confíe na CA emisora que posúe o despregamento, non en cada intermedio da cadea, porque promover cada intermedio a raíz amplía a confianza moito máis alá dun só peer. Manteña activa a verificación de identidade, xa que unha conexión que só funciona coa validación desactivada non é unha solución. Onde a cadea está incompleta, repare o aprovisionamento en lugar da política do emisor.

Cambie o emisor só con probas

Cando o rexistro mostra que o certificado nunca se enviou e que o receptor si o solicitou, poñer send_cert en always é un cambio xustificado para esa conexión. Aplíqueo na configuración de swanctl, recargue as conexións e estableza unha sesión nova en lugar de reutilizar a SA existente. Confirme que a carga do certificado aparece agora e que o receptor a acepta contra a áncora prevista. Se non cambia nada, o fallo estaba do lado da confianza e o axuste do emisor non era a causa.

Escriba o intercambio observado, a áncora e a verificación resultante no rexistro de cambios. Unha corrección de certificado que non se poida describir neses termos é unha casualidade.