Certifikát IKEv2 a SAN: proč kontrola totožnosti selhává

Řetěz vašeho certifikátu vede k důvěryhodné CA, data jsou v pořádku, a přesto protějšek odmítá dokončit fázi 1 s chybou identity. Dostupnost a platný podpis jsou jen polovina toho, co klient IKEv2 kontroluje. Druhá polovina je, zda se očekávaná identita objevuje v certifikátu ve správném poli, a toto očekávání určuje profil, ne název souboru certifikátu.

Příznak má vždy stejný tvar

Profil připojení se změní z názvu hostitele na IP adresu nebo se obnoví z certifikátu s DNS názvem na certifikát, který nese jen adresy, a tunel přestane vyjednávat. V síťové cestě se nic nezměnilo. Klient dosáhne protějšku, obdrží certifikát a odmítne identitu protějšku, protože identifikátor, který měl očekávat, není zastoupen v poli, které přijímá. Obnovy jsou obvyklým spouštěčem, protože náhradní certifikát často pochází z jiné šablony než ten, který nahrazuje.

Obě strany pak zalogují něco neužitečného, a proto se selhání obvykle hlásí jako problém s certifikátem. Klientský log může uvést identitu, kterou chtěl, a to je vodítko, které hledáte, ne datum vypršení.

Slaďte typ identifikátoru, ne jen hodnotu

SAN dNSName a SAN iPAddress jsou různá pole s různými pravidly shody, takže certifikát nesoucí 203.0.113.10 jako DNS řetězec neuspokojí klienta, který očekává IP identitu. Moderní validátory většinou ignorují obecný název, takže přátelský štítek v podrobnostech certifikátu nic nedokazuje o tom, co bude odpovídat. Pokud byl během řešení potíží název hostitele nahrazen adresou, předpokládejte, že se očekávaná identita posunula s ním, dokud to neověříte. Porovnejte řetězec v profilu s řetězcem v SAN znak po znaku, protože tečka na konci nebo přebytečná mezera stačí.

Zástupné znaky jsou pohodlí jen pro DNS a řídí se vlastními pravidly shody, což je další důvod, proč se na ně profil založený na IP nikdy nesmí spoléhat.

Najděte, kde který klient ukládá očekávání

V strongSwanu pochází hodnota porovnávaná s certifikátem z nastavení identity protějšku: rightid v klasické konfiguraci nebo id sekce vzdáleného připojení ve swanctl. Dokumentace k interoperabilitě s Apple IKEv2 je zde užitečná, protože popisuje konvence identity, které klient řízený profilem používá, a tyto konvence vysvětlují třídu neshod, která v síti vypadá náhodně.

Konfigurační profily Apple nesou pole vzdáleného identifikátoru a hodnota tam je to, co klient kontroluje, ne adresa serveru v nastavení připojení. Klienti Windows a zařízení mají každý své pole se svou výchozí hodnotou a výchozí hodnota často sleduje adresu, kterou jste zadali. Když se dvě pole rozcházejí, vyhraje to, které klient skutečně čte, a to je jen zřídka to, které jste upravili.

Opravte profil nebo certifikát záměrně

Prohlédněte certifikát protějšku schválenými nástroji a vypište položky SAN s jejich typy, než cokoli změníte. Tato prohlídka nevyžaduje soukromý klíč ani nahrání a rozhodne otázku během sekund. Pokud nasazení zamýšlí jednu DNS identitu, certifikát ji musí nést jako položku dNSName, a pokud zamýšlí adresu, certifikát potřebuje položku iPAddress přesně pro tuto adresu.

Když je certifikát špatný, požádejte operátora o opravený s konkrétním očekávaným identifikátorem. Když je špatný profil, opravte profil a certifikát nechte být. Vypnutí validace identity způsobí, že chyba zmizí, a odstraní kontrolu, že tunel mluví s protějškem, kterého jste zamýšleli.

Zdokumentujte očekávanou identitu pro každou klientskou platformu, protože hodnota, kterou jeden klient odvozuje automaticky, může být na jiném potřeba uvést výslovně.

Dejte žádosti o obnovu čtyři fakta

Zapište očekávaný identifikátor a jeho typ, položky SAN, které aktuální certifikát skutečně má, klienta a verzi provádějící kontrolu a přesný text chyby. Žádost o obnovu postavená z těchto čtyř řádků získá správný certifikát napoprvé, místo dalšího se stejným známým názvem souboru.