strongSwan send_cert: när IKE-certifikatet skickas

Gateways loggar certifikatrelaterade autentiseringsfel, och den första impulsen är att lägga till ytterligare en CA hos mottagaren. Det förutsätter att certifikatet anlände och avvisades. Den andra möjligheten är att det aldrig skickades, och det avgör avsändarens anslutningspolicy. Ta reda på vilket av de två som inträffade innan du ändrar förtroendet.

Vad send_cert faktiskt styr

Certifikatautentisering kräver att peerens slutentitetscertifikat når den andra sidan via IKE-utbytet eller via tidigare etablering. I swanctl styr anslutningsinställningen send_cert om denna endpoint inkluderar sin certifikatnyttolast: aldrig, alltid eller ifasked. Standardvärdet ifasked skickar det som svar på en certifikatbegäran från peeren. Att begära ett certifikat är en separat inställning, för att be den andra sidan om dess certifikat är inte samma sak som att erbjuda sitt eget.

Äldre ipsec.conf-installationer använde leftsendcert och rightsendcert, och dessa namn motsvarar lokala och avlägsna roller snarare än swanctl direkt.

Läs ett försök innan du ändrar anslutningen

Diagnostisera utifrån ett enda kontrollerat försök, inte utifrån det allmänna intrycket att certifikat är inblandade. Både policyn och den aktiva associationen går att inspektera.

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

Anslutningslistan visar det konfigurerade värdet för send_cert, och SA-listan visar vilka anslutningar som faktiskt kom upp. Loggen tillför förhandlingsdetaljer: om en certifikatbegäran togs emot och om en certifikatnyttolast gick ut. Ett generiskt autentiseringsfel pekar inte ut ett leveransproblem, så leta efter det specifika utbytet innan du drar någon slutsats. Anteckna försökets tidsstämpel så att loggfönstret täcker hela handskakningen.

Mottagarens förtroende är ett separat beslut

Leverans och förtroende är olika egenskaper, och att åtgärda den ena åtgärdar inte den andra. En mottagare måste ha det avsedda förtroendeankaret, ta emot en användbar kedja och matcha den förväntade peeridentiteten. Ett slutentitetscertifikat som anländer utan sitt mellanliggande certifikat fallerar fortfarande en strikt kedjekontroll. Omvänt tvingar installationen av en CA inte en peer att skicka sitt certifikat överhuvudtaget.

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

Inspektionen visar vilken utfärdare som signerade certifikatet och när det löper ut, och det är vad mottagarens ankare måste motsvara. Lita på den utfärdande CA som installationen äger, inte på varje mellanliggande certifikat i kedjan, för att befordra varje mellanliggande certifikat till root vidgar förtroendet långt bortom en enda peer. Håll identitetsverifieringen aktiv, för en anslutning som bara lyckas med validering avstängd är ingen lösning. Där kedjan är ofullständig, reparera etableringen i stället för avsändarens policy.

Ändra avsändaren bara med bevis

När loggen visar att certifikatet aldrig skickades och mottagaren faktiskt begärde ett, är send_cert på always en motiverad ändring för den anslutningen. Tillämpa den i swanctl-konfigurationen, ladda om anslutningarna och upprätta en ny session i stället för att återanvända den befintliga SA. Bekräfta att certifikatnyttolasten nu visas och att mottagaren accepterar den mot det avsedda ankaret. Ändras ingenting låg felet ändå på förtroendesidan och avsändarinställningen var inte orsaken.

Skriv det observerade utbytet, ankaret och den resulterande verifieringen i ändringsprotokollet. En certifikatåtgärd som inte kan beskrivas i de termerna är ett sammanträffande.