strongSwan send_cert: hvornår IKE-certifikatet sendes

Gateways logger certifikatrelaterede godkendelsesfejl, og den første indskydelse er at tilføje endnu en CA til modtageren. Det forudsætter, at certifikatet ankom og blev afvist. Den anden mulighed er, at det aldrig blev sendt, og det afgør afsenderens forbindelsespolitik. Find ud af, hvilken af de to der skete, før du ændrer tilliden.

Hvad send_cert egentlig styrer

Certifikatgodkendelse kræver, at peerens slutentitetscertifikat når den anden side gennem IKE-udvekslingen eller gennem forudgående udrulning. I swanctl styrer forbindelsesindstillingen send_cert, om dette endepunkt medsender sin certifikatnyttelast: aldrig, altid eller ifasked. Standarden ifasked sender det som svar på en certifikatanmodning fra peeren. At anmode om et certifikat er en separat indstilling, for at bede den anden side om dens certifikat er ikke det samme som at tilbyde sit eget.

Ældre ipsec.conf-installationer brugte leftsendcert og rightsendcert, og disse navne knytter sig til lokale og fjernede roller snarere end direkte til swanctl.

Læs ét forsøg, før du ændrer forbindelsen

Diagnostiser ud fra ét kontrolleret forsøg, ikke ud fra det generelle indtryk, at certifikater er involveret. Både politikken og den aktive association kan inspiceres.

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

Forbindelseslisten viser den konfigurerede værdi af send_cert, og SA-listen viser, hvilke forbindelser der faktisk kom op. Loggen tilføjer forhandlingsdetaljer: om der blev modtaget en certifikatanmodning, og om der blev sendt en certifikatnyttelast. En generisk godkendelsesfejl identificerer ikke et leveringsproblem, så led efter den konkrete udveksling, før du konkluderer noget. Noter forsøgets tidsstempel, så logvinduet dækker hele handshaket.

Modtagerens tillid er en separat beslutning

Levering og tillid er forskellige egenskaber, og det ene løser ikke det andet. En modtager skal have det tilsigtede tillidsanker, modtage en brugbar kæde og matche den forventede peer-identitet. Et slutentitetscertifikat, der ankommer uden sit mellemliggende certifikat, fejler stadig en streng kædekontrol. Omvendt tvinger installationen af en CA ikke en peer til at sende sit certifikat overhovedet.

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

Inspektionen viser, hvilken udsteder der signerede certifikatet, og hvornår det udløber, og det er hvad modtagerens anker skal svare til. Stol på den udstedende CA, som installationen ejer, ikke på hvert mellemliggende certifikat i kæden, for at forfremme hvert mellemliggende certifikat til root udvider tilliden langt ud over én peer. Hold identitetsbekræftelse aktiv, for en forbindelse, der kun lykkes med deaktiveret validering, er ikke en løsning. Hvor kæden er ufuldstændig, reparer udrulningen i stedet for afsenderens politik.

Ændr kun afsenderen med bevis

Når loggen viser, at certifikatet aldrig blev sendt, og modtageren faktisk anmodede om et, er send_cert på always en berettiget ændring for den forbindelse. Anvend den i swanctl-konfigurationen, genindlæs forbindelserne og opret en ny session i stedet for at genbruge den eksisterende SA. Bekræft, at certifikatnyttelasten nu vises, og at modtageren accepterer den mod det tilsigtede anker. Ændrer intet sig, lå fejlen alligevel på tillidssiden, og afsenderindstillingen var ikke årsagen.

Skriv den observerede udveksling, ankeret og den resulterende verifikation ind i ændringsprotokollen. En certifikatrettelse, der ikke kan beskrives i de termer, er et tilfælde.