strongSwan send_cert: når IKE-sertifikatet sendes

Gateways logger sertifikatrelaterte autentiseringsfeil, og den første innskytelsen er å legge til nok en CA hos mottakeren. Det forutsetter at sertifikatet kom frem og ble avvist. Den andre muligheten er at det aldri ble sendt, og det avgjør avsenderens tilkoblingspolicy. Finn ut hvilken av de to som skjedde før du endrer tilliten.

Hva send_cert faktisk styrer

Sertifikatautentisering krever at peerens sluttentitetssertifikat når den andre siden gjennom IKE-utvekslingen eller gjennom tidligere utrulling. I swanctl styrer tilkoblingsinnstillingen send_cert om dette endepunktet tar med sin sertifikatnyttelast: aldri, alltid eller ifasked. Standarden ifasked sender det som svar på en sertifikatforespørsel fra peeren. Å be om et sertifikat er en egen innstilling, for å be den andre siden om sertifikatet er ikke det samme som å tilby sitt eget.

Eldre ipsec.conf-installasjoner brukte leftsendcert og rightsendcert, og disse navnene knytter seg til lokale og eksterne roller snarere enn direkte til swanctl.

Les ett forsøk før du endrer tilkoblingen

Diagnostiser ut fra ett kontrollert forsøk, ikke ut fra det generelle inntrykket at sertifikater er involvert. Både policyen og den aktive assosiasjonen kan inspiseres.

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

Tilkoblingslisten viser den konfigurerte verdien av send_cert, og SA-listen viser hvilke tilkoblinger som faktisk kom opp. Loggen tilfører forhandlingsdetaljer: om en sertifikatforespørsel ble mottatt og om en sertifikatnyttelast gikk ut. En generisk autentiseringsfeil peker ikke på et leveringsproblem, så se etter den konkrete utvekslingen før du konkluderer noe. Noter forsøkets tidsstempel slik at loggvinduet dekker hele håndtrykket.

Mottakerens tillit er en egen beslutning

Levering og tillit er forskjellige egenskaper, og å rette den ene retter ikke den andre. En mottaker må ha det tiltenkte tillitsankeret, motta en brukbar kjede og matche den forventede peeridentiteten. Et sluttentitetssertifikat som ankommer uten sitt mellomliggende sertifikat, feiler fortsatt en streng kjedekontroll. Omvendt tvinger installasjonen av en CA ikke en peer til å sende sertifikatet sitt i det hele tatt.

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

Inspeksjonen viser hvilken utsteder som signerte sertifikatet og når det utløper, og det er hva mottakerens anker må svare til. Stol på den utstedende CA-en som installasjonen eier, ikke på hvert mellomliggende sertifikat i kjeden, for å forfremme hvert mellomliggende sertifikat til root utvider tilliten langt utover én peer. Hold identitetsbekreftelsen aktiv, for en tilkobling som bare lykkes med deaktivert validering er ingen løsning. Der kjeden er ufullstendig, reparer utrullingen i stedet for avsenderens policy.

Endre avsenderen bare med bevis

Når loggen viser at sertifikatet aldri ble sendt og mottakeren faktisk ba om ett, er send_cert på always en berettiget endring for den tilkoblingen. Bruk den i swanctl-konfigurasjonen, last tilkoblingene på nytt og etabler en ny sesjon i stedet for å gjenbruke den eksisterende SA-en. Bekreft at sertifikatnyttelasten nå vises og at mottakeren godtar den mot det tiltenkte ankeret. Endres ingenting, lå feilen likevel på tillitssiden og avsenderinnstillingen var ikke årsaken.

Skriv den observerte utvekslingen, ankeret og den resulterende verifiseringen inn i endringsprotokollen. En sertifikatrettelse som ikke kan beskrives i de termene, er et sammentreff.