strongSwan send_cert: mikor küldi el az IKE-tanúsítványt

A send_cert szabályozza, hogy egy peer elküldi-e a tanúsítványát, a send_certreq pedig a másik féltől kéri azt. A fogadó bizalmának módosítása előtt ellenőrizze a naplókat.

Az átjárók naplózzák a tanúsítványokhoz kapcsolódó hitelesítési hibákat, és az első ötlet egy újabb CA hozzáadása a fogadóhoz. Ez feltételezi, hogy a tanúsítvány megérkezett és elutasították. A másik lehetőség, hogy soha nem küldték el, és erről a küldő kapcsolatpolitikája dönt. A bizalom módosítása előtt állapítsa meg, melyik történt meg.

Mit is szabályoz valójában a send_cert

A tanúsítványos hitelesítéshez a peer végponti tanúsítványának el kell jutnia a másik félhez az IKE-cserén vagy egy korábbi előkészítésen keresztül. A swanctlben a kapcsolat beállítása send_cert határozza meg, hogy ez a végpont belefoglalja-e a tanúsítvány-terhelését: soha, mindig vagy ifasked. Az alapértelmezett ifasked a peer tanúsítványkérésére válaszul küldi el. A tanúsítvány kérése külön beállítás, mert a másik féltől a saját tanúsítványát kérni nem ugyanaz, mint a sajátunkat felajánlani.

A régebbi ipsec.conf-telepítések a leftsendcert és a rightsendcert beállítást használták, és ezek a nevek a helyi és a távoli szerepkörhöz kapcsolódnak, nem közvetlenül a swanctlhez.

Olvasson el egy kísérletet a kapcsolat módosítása előtt

Egyetlen ellenőrzött kísérlet alapján diagnosztizáljon, ne abból az általános benyomásból, hogy tanúsítványok vannak a dologban. Mind a politika, mind az aktív társítás megvizsgálható.

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

A kapcsolatlista a beállított send_cert értéket mutatja, az SA-lista pedig azt, hogy mely kapcsolatok jöttek létre valóban. A napló hozzáadja a tárgyalás részleteit: érkezett-e tanúsítványkérés, és kiment-e tanúsítvány-terhelés. Az általános hitelesítési hiba nem jelöl meg szállítási problémát, ezért keresse meg a konkrét cserét, mielőtt bármit megállapít. Jegyezze fel a kísérlet időbélyegét, hogy a naplóablak lefedje a teljes kézfogást.

A fogadó bizalma külön döntés

A szállítás és a bizalom különböző tulajdonságok, és az egyik javítása nem javítja a másikat. A fogadónak rendelkeznie kell a szándékolt bizalmi horgonnyal, használható láncot kell kapnia, és meg kell felelnie a várt peer-identitásnak. A köztes tanúsítványa nélkül érkező végponti tanúsítvány továbbra is elbukik egy szigorú láncellenőrzésen. Fordítva, egy CA telepítése egyáltalán nem kényszeríti a peert arra, hogy elküldje a tanúsítványát.

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

Az ellenőrzés megmutatja, melyik kibocsátó írta alá a tanúsítványt és mikor jár le, és a fogadó horgonyának ehhez kell illeszkednie. Bízzon a telepítés tulajdonában lévő kibocsátó CA-ban, ne a lánc minden köztes tanúsítványában, mert minden köztes tanúsítvány gyökérré emelése a bizalmat messze egyetlen peeren túlra tágítja. Tartsa aktívan az identitásellenőrzést, mert az a kapcsolat, amely csak kikapcsolt érvényesítéssel működik, nem javítás. Ahol a lánc hiányos, az előkészítést javítsa, ne a küldő politikáját.

Csak bizonyítékokkal módosítsa a küldőt

Amikor a napló azt mutatja, hogy a tanúsítványt soha nem küldték el, a fogadó viszont kérte, a send_cert always értékre állítása indokolt változtatás ahhoz a kapcsolathoz. Alkalmazza a swanctl konfigurációjában, töltse újra a kapcsolatokat, és hozzon létre új munkamenetet a meglévő SA újrafelhasználása helyett. Erősítse meg, hogy a tanúsítvány-terhelés most megjelenik, és a fogadó elfogadja a szándékolt horgonyhoz képest. Ha semmi sem változik, a hiba mégis a bizalmi oldalon volt, és a küldő beállítása nem volt az ok.

Írja be a megfigyelt cserét, a horgonyt és az abból eredő ellenőrzést a változásnaplóba. Az a tanúsítvány-javítás, amely nem írható le ezekkel a kifejezésekkel, véletlen.

Kapcsolódó cikkek