strongSwan send_cert: kdy se certifikát IKE odesílá

send_cert určuje, zda peer odešle svůj certifikát, zatímco send_certreq žádá druhou stranu o jeho zaslání. Než změníte důvěru příjemce, projděte logy.

Brány logují chyby ověřování související s certifikáty a prvním impulsem je přidat příjemci další CA. To předpokládá, že certifikát dorazil a byl odmítnut. Druhou možností je, že nebyl nikdy odeslán, a to určuje politika připojení odesílatele. Než změníte důvěru, zjistěte, který z obou případů nastal.

Co send_cert skutečně řídí

Ověřování certifikátem vyžaduje, aby se certifikát koncového subjektu protistrany dostal na druhou stranu přes výměnu IKE nebo přes dřívější zřízení. V swanctl nastavení připojení send_cert určuje, zda tento koncový bod přikládá svůj certifikátový obsah: nikdy, vždy nebo ifasked. Výchozí ifasked jej odešle jako odpověď na žádost o certifikát od protistrany. Žádost o certifikát je samostatné nastavení, protože požádat druhou stranu o její certifikát není totéž jako nabídnout ten svůj.

Starší nasazení ipsec.conf používala leftsendcert a rightsendcert a tyto názvy odpovídají místním a vzdáleným rolím, nikoli přímo swanctl.

Přečtěte si jeden pokus, než změníte připojení

Diagnostikujte z jednoho řízeného pokusu, ne z obecného dojmu, že jde o certifikáty. Prohlédnout lze jak politiku, tak aktivní asociaci.

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

Seznam připojení ukazuje nakonfigurovanou hodnotu send_cert a seznam SA ukazuje, která připojení skutečně vznikla. Log doplňuje podrobnosti vyjednávání: zda dorazila žádost o certifikát a zda odešel certifikátový obsah. Obecná chyba ověřování neukazuje na problém s doručením, proto před jakýmkoli závěrem najděte konkrétní výměnu. Zaznamenejte časové razítko pokusu, aby okno logu pokrylo celé navazování.

Důvěra příjemce je samostatné rozhodnutí

Doručení a důvěra jsou různé vlastnosti a oprava jedné neopraví druhou. Příjemce musí mít zamýšlený kořen důvěry, obdržet použitelný řetězec a odpovídat očekávané identitě protistrany. Certifikát koncového subjektu, který dorazí bez svého zprostředkujícího certifikátu, stále neprojde přísnou kontrolou řetězce. Naopak instalace CA protistranu vůbec nenutí svůj certifikát odeslat.

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

Kontrola ukazuje, který vydavatel certifikát podepsal a kdy vyprší, a tomu musí odpovídat kořen důvěry příjemce. Důvěřujte vydávající CA, kterou nasazení vlastní, ne každému zprostředkujícímu certifikátu v řetězci, protože povýšení každého zprostředkujícího certifikátu na kořen rozšiřuje důvěru daleko za jednu protistranu. Ponechte ověřování identity aktivní, protože připojení, které uspěje jen s vypnutou validací, není oprava. Kde je řetězec neúplný, opravte zřízení, ne politiku odesílatele.

Měňte odesílatele jen s důkazy

Když log ukáže, že certifikát nebyl nikdy odeslán a příjemce o něj skutečně požádal, je send_cert na always oprávněnou změnou pro to připojení. Použijte ji v konfiguraci swanctl, znovu načtěte připojení a vytvořte novou relaci, místo abyste znovu použili stávající SA. Potvrďte, že se certifikátový obsah nyní objeví a že jej příjemce přijme vůči zamýšlenému kořeni. Pokud se nic nezmění, chyba byla nakonec na straně důvěry a nastavení odesílatele nebylo příčinou.

Zapište pozorovanou výměnu, kořen a výsledné ověření do záznamu změn. Oprava certifikátu, kterou nelze popsat těmito pojmy, je náhoda.

Související články