strongSwan send_cert: når IKE-sertifikatet vert sendt

Gateways loggar sertifikatrelaterte autentiseringsfeil, og den første innskytelsen er å leggje til endå ein CA hos mottakaren. Det føreset at sertifikatet kom fram og vart avvist. Den andre moglegheita er at det aldri vart sendt, og det avgjer tilkoplingspolicyen til avsendaren. Finn ut kva av dei to som hende før du endrar tillita.

Kva send_cert faktisk styrer

Sertifikatautentisering krev at sluttentitetssertifikatet til peeren når den andre sida gjennom IKE-utvekslinga eller gjennom tidlegare utrulling. I swanctl styrer tilkoplingsinnstillinga send_cert om dette endepunktet tek med sertifikatnyttelasta si: aldri, alltid eller ifasked. Standarden ifasked sender det som svar på ein sertifikatførespurnad frå peeren. Å be om eit sertifikat er ei eiga innstilling, for å be den andre sida om sertifikatet er ikkje det same som å tilby sitt eige.

Eldre ipsec.conf-installasjonar brukte leftsendcert og rightsendcert, og desse namna knyter seg til lokale og eksterne roller snarare enn direkte til swanctl.

Les eitt forsøk før du endrar tilkoplinga

Diagnostiser ut frå eitt kontrollert forsøk, ikkje ut frå det generelle inntrykket at sertifikat er involverte. Både policyen og den aktive assosiasjonen kan inspiserast.

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

Tilkoplingslista viser den konfigurerte verdien av send_cert, og SA-lista viser kva tilkoplingar som faktisk kom opp. Loggen tilfører forhandlingsdetaljar: om ein sertifikatførespurnad vart motteken og om ei sertifikatnyttelast gjekk ut. Ein generisk autentiseringsfeil peikar ikkje på eit leveringsproblem, så leit etter den konkrete utvekslinga før du konkluderer noko. Noter tidsstempelet til forsøket slik at loggvindauget dekkjer heile handtrykket.

Tillita til mottakaren er ei eiga avgjerd

Levering og tillit er ulike eigenskapar, og å rette den eine rettar ikkje den andre. Ein mottakar må ha det tiltenkte tillitsankeret, ta imot ei brukbar kjede og matche den forventa peeridentiteten. Eit sluttentitetssertifikat som kjem utan sitt mellomliggjande sertifikat, feilar framleis ein streng kjedekontroll. Omvendt tvingar installasjonen av ein CA ikkje ein peer til å sende sertifikatet sitt i det heile.

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

Inspeksjonen viser kva utferdar som signerte sertifikatet og når det går ut, og det er det ankeret til mottakaren må svare til. Stol på den utferdande CA-en som installasjonen eig, ikkje på kvart mellomliggjande sertifikat i kjeda, for å fremje kvart mellomliggjande sertifikat til root utvidar tillita langt utover ein einaste peer. Hald identitetsbekreftinga aktiv, for ei tilkopling som berre lykkast med deaktivert validering er inga løysing. Der kjeda er ufullstendig, reparer utrullinga i staden for policyen til avsendaren.

Endre avsendaren berre med prov

Når loggen viser at sertifikatet aldri vart sendt og mottakaren faktisk bad om eitt, er send_cert på always ei grunngjeven endring for den tilkoplinga. Bruk ho i swanctl-konfigurasjonen, last tilkoplingane på nytt og etabler ein ny sesjon i staden for å bruke den eksisterande SA-en om att. Stadfest at sertifikatnyttelasta no viser seg og at mottakaren godtek ho mot det tiltenkte ankeret. Endrar ingenting seg, låg feilen likevel på tillitssida og avsendarinnstillinga var ikkje årsaka.

Skriv den observerte utvekslinga, ankeret og den resulterande verifiseringa inn i endringsprotokollen. Ei sertifikatretting som ikkje kan skildrast i dei termane, er eit samantreff.