SAN certifikátu IKEv2: prečo overenie identity zlyháva

Váš certifikát sa reťazí k dôveryhodnej CA, dátumy sú v poriadku a partner aj tak odmieta dokončiť fázu 1 s chybou identity. Dostupnosť a platný podpis sú len polovica toho, čo klient IKEv2 kontroluje. Druhá polovica je, či sa očakávaná identita nachádza v certifikáte v správnom poli, a túto očakávanie nastavuje profil, nie názov súboru certifikátu.

Príznak má vždy rovnaký tvar

Profil pripojenia sa zmení z názvu hostiteľa na IP adresu alebo sa obnoví z certifikátu, ktorý niesol DNS názov, na certifikát, ktorý nesie iba adresy, atunel prestane vyjednávať. V sieťovej ceste sa nič nezmenilo. Klient dosiahne partnera, dostane certifikát a odmietne identitu partnera, pretože identifikátor, ktorý mal očakávať, nie je zastúpený v poli, ktoré akceptuje. Obnovy sú zvyčajným spúšťačom, keďže náhradný certifikát často pochádza z inej šablóny ako ten, ktorý nahradzuje.

Obe strany potom zapíšu niečo nepoužiteľné, a preto sa zlyhanie zvyčajne hlási ako problém s certifikátom. Záznam klienta môže uviesť požadovanú identitu a ten názov je stopa, ktorú potrebujete, nie dátum expirácie.

Priraďte typ identifikátora, nielen hodnotu

SAN typu dNSName a SAN typu iPAddress sú rôzne polia s rôznymi pravidlami párovania, takže certifikát s 203.0.113.10 ako reťazcom DNS neuspokojí klienta, ktorý očakáva identitu IP. Moderné validátory do veľkej miery ignorujú bežný názov, takže priateľský štítok v podrobnostiach certifikátu nič nedokazuje o tom, čo sa bude zhodovať. Ak bol počas riešenia problémov názov hostiteľa nahradený adresou, predpokladajte, že sa očakávaná identita presunula spolu s ním, kým ste to neoverili. Porovnajte reťazec v profile s reťazcom v SAN znak po znaku, pretože koncová bodka alebo nadbytočná medzera stačí.

Zástupné znaky sú len pohodlím DNS a riadia sa vlastnými pravidlami párovania, čo je ďalší dôvod, prečo by sa profil založený na IP nikdy nemal spoliehať na ne.

Nájdite, kde každý klient uchováva očakávanie

V strongSwane hodnota porovnávaná s certifikátom pochádza z nastavenia identity partnera: rightid v klasickej konfigurácii alebo id sekcie vzdialeného pripojenia v swanctl. Jeho dokumentácia o interoperabilite s Apple IKEv2 je tu užitočná, pretože vysvetľuje konvencie identity, ktoré používa klient riadený profilom, a tieto konvencie vysvetľujú triedu nezhôd, ktoré na linke pôsobia náhodne.

Konfiguračné profily Apple obsahujú pole vzdialeného identifikátora a práve túto hodnotu klient kontroluje, nie adresu servera v nastaveniach pripojenia. Klienti Windows a zariadení majú každý svoje pole s vlastnou predvolenou hodnotou a predvolená hodnota často nasleduje adresu, ktorú ste zadali. Keď sa dve polia nezhodujú, vyhráva to, ktoré klient skutočne číta, a to je zriedka to, ktoré ste upravili.

Opravte profil alebo certifikát, zámerne

Pred akoukoľvek zmenou skontrolujte certifikát partnera schválenými nástrojmi a vymenujte položky SAN s ich typmi. Táto kontrola nevyžaduje súkromný kľúč ani nahrávanie a vyrieši otázku v priebehu sekúnd. Ak nasadenie zamýšľa jednu identitu DNS, certifikát ju musí obsahovať ako položku dNSName, a ak nasadenie zamýšľa adresu, certifikát potrebuje položku iPAddress presne pre túto adresu.

Keď je certifikát nesprávny, požiadajte operátora o opravený s konkrétnym očakávaným identifikátorom. Keď je profil nesprávny, opravte profil a nechajte certifikát na pokoji. Vypnutie overovania identity odstráni chybu a odstráni aj kontrolu, že tunel komunikuje so zamýšľaným partnerom.

Zdokumentujte očakávanú identitu pre každú klientsku platformu, pretože hodnota, ktorú jeden klient odvodzuje automaticky, môže byť na inom potrebné uviesť explicitne.

Dajte žiadosti o obnovu štyri fakty

Zapíšte očakávaný identifikátor a jeho typ, položky SAN, ktoré aktuálny certifikát skutočne má, klienta a verziu vykonávajúce kontrolu a presný text chyby. Žiadosť o obnovu zostavená z týchto štyroch riadkov získa na prvý raz správny certifikát namiesto ďalšieho s rovnakým známym názvom súboru.