strongSwan send_cert: quan s’envia el certificat IKE

Les passarel·les registren errors d’autenticació relacionats amb certificats, i el primer impuls és afegir una altra CA al receptor. Això pressuposa que el certificat va arribar i va ser rebutjat. L’altra possibilitat és que no s’enviés mai, i això ho decideix la política de connexió de l’emissor. Determineu quin dels dos casos va passar abans de tocar la confiança.

Què controla realment send_cert

L’autenticació amb certificat necessita que el certificat d’entitat final del peer arribi a l’altra banda mitjançant l’intercanvi IKE o un aprovisionament previ. A swanctl, el paràmetre de connexió send_cert determina si aquest extrem inclou la seva càrrega de certificat: mai, sempre o ifasked. El valor predeterminat ifasked l’envia com a resposta a una sol·licitud de certificat del peer. Demanar un certificat és un paràmetre a part, perquè demanar a l’altra banda el seu certificat no és el mateix que oferir el propi.

Els desplegaments antics d’ipsec.conf feien servir leftsendcert i rightsendcert, i aquests noms corresponen als rols local i remot, no directament a swanctl.

Llegiu un intent abans de modificar la connexió

Diagnostiqueu a partir d’un sol intent controlat, no de la impressió general que hi ha certificats implicats. Tant la política com l’associació activa es poden inspeccionar.

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

El llistat de connexions mostra el valor configurat de send_cert, i el llistat de SA mostra quines connexions es van establir realment. El registre afegeix detalls de la negociació: si es va rebre una sol·licitud de certificat i si va sortir una càrrega de certificat. Una fallada d’autenticació genèrica no identifica un problema de lliurament, així que busqueu l’intercanvi concret abans de concloure res. Anoteu la marca de temps de l’intent perquè la finestra del registre cobreixi tot el handshake.

La confiança del receptor és una decisió a part

El lliurament i la confiança són propietats diferents, i arreglar-ne una no arregla l’altra. Un receptor ha de posseir l’àncora de confiança prevista, rebre una cadena utilitzable i coincidir amb la identitat esperada del peer. Un certificat d’entitat final que arriba sense el seu intermedi continua fallant una comprovació estricta de cadena. A la inversa, instal·lar una CA no obliga gens un peer a enviar el seu certificat.

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

La inspecció mostra quin emissor va signar el certificat i quan caduca, i a això ha de correspondre l’àncora del receptor. Confieu en la CA emissora que posseeix el desplegament, no en cada intermedi de la cadena, perquè promoure cada intermedi a arrel amplia la confiança molt més enllà d’un sol peer. Mantingueu activa la verificació d’identitat, ja que una connexió que només funciona amb la validació desactivada no és cap solució. On la cadena és incompleta, repareu l’aprovisionament en lloc de la política de l’emissor.

Canvieu l’emissor només amb proves

Quan el registre mostra que el certificat no es va enviar mai i que el receptor sí que el va sol·licitar, posar send_cert a always és un canvi justificat per a aquesta connexió. Apliqueu-lo a la configuració de swanctl, recarregueu les connexions i establiu una sessió nova en lloc de reutilitzar la SA existent. Confirmeu que la càrrega del certificat apareix ara i que el receptor l’accepta contra l’àncora prevista. Si no canvia res, la fallada era del costat de la confiança i el paràmetre de l’emissor no n’era la causa.

Escriviu l’intercanvi observat, l’àncora i la verificació resultant al registre de canvis. Una correcció de certificat que no es pugui descriure en aquests termes és una casualitat.