IKEv2-tanúsítvány SAN: miért vall kudarcot az identitásellenőrzés

A tanúsítvány egy megbízható CA-hoz láncolódik, a dátumok rendben vannak, a partner mégis megtagadja az 1. fázis befejezését identitáshiba miatt. Az elérhetőség és az érvényes aláírás csak a fele annak, amit egy IKEv2-kliens ellenőriz. A másik fele az, hogy a várt identitás megjelenik-e a tanúsítványban a megfelelő mezőben, és ezt az elvárást a profil állítja be, nem a tanúsítvány fájlneve.

A tünet mindig ugyanolyan alakú

Egy kapcsolati profil hosztnévről IP-címre vált, vagy olyan tanúsítványról újítják meg, amely DNS-nevet hordozott, egy olyanra, amely csak címeket hordoz, ésaz alagút leáll az egyeztetéssel. A hálózati útvonalon semmi sem változott. A kliens eléri a partnert, tanúsítványt kap, és elutasítja a partner identitását, mert az az azonosító, amelyre számítania kellett, nem szerepel egy általa elfogadott mezőben. Az újítások a szokásos kiváltó okok, mivel a csere-tanúsítvány gyakran más sablonból származik, mint amelyet helyettesít.

Mindkét oldal ekkor használhatatlan naplóbejegyzést ír, ezért a hibát általában tanúsítványproblémaként jelentik. A kliens naplója megnevezheti a kívánt identitást, és ez a név a nyom, amire szüksége van, nem a lejárati dátum.

Az azonosító típusát egyeztesse, ne csak az értékét

A dNSName SAN és az iPAddress SAN különböző mezők, különböző egyeztetési szabályokkal, ezért egy 203.0.113.10-et DNS-karakterláncként hordozó tanúsítvány nem elégíti ki az IP-identitást váró klienst. A modern ellenőrzők nagyrészt figyelmen kívül hagyják a köznapi nevet, ezért a tanúsítvány részleteiben látható barátságos címke semmit sem bizonyít arról, mi fog egyezni. Ha a hibaelhárítás során a hosztnevet címre cserélték, feltételezze, hogy a várt identitás vele együtt mozdult, amíg nem ellenőrizte. Hasonlítsa össze a profilban lévő karakterláncot a SAN-ban lévővel karakterről karakterre, mert egy záró pont vagy egy felesleges szóköz is elég.

A helyettesítő karakterek csak DNS-kényelmi eszközök, saját egyeztetési szabályaik vannak, ami további ok arra, hogy egy IP-alapú profil soha ne támaszkodjon rájuk.

Keresse meg, hol tárolja az elvárást az egyes kliensek

A strongSwanban a tanúsítvánnyal összevetett érték a partneridentitás-beállításból származik: rightid a klasszikus konfigurációban, vagy a id egy távoli kapcsolatszakasz swanctl-beli azonosítójából. Az Apple IKEv2 interoperabilitásról szóló dokumentációja itt hasznos, mert kifejti azokat az identitáskonvenciókat, amelyeket a profilvezérelt kliens használ, és ezek a konvenciók megmagyaráznak egy olyan eltéréstípust, amely a hálózaton véletlenszerűnek tűnik.

Az Apple konfigurációs profilok távoli azonosító mezőt tartalmaznak, és az ott lévő értéket ellenőrzi a kliens, nem a kapcsolatbeállításokban szereplő kiszolgálócímet. A Windows és az eszközkliensek mindegyikének saját mezője és saját alapértelmezése van, és az alapértelmezés gyakran a beírt címet követi. Ahol két mező ellentmond, az győz, amelyet a kliens valóban olvas, és ez ritkán az, amelyet szerkesztett.

Javítsa a profilt vagy a tanúsítványt, szándékosan

Vizsgálja meg a partner tanúsítványát jóváhagyott eszközökkel, és sorolja fel a SAN-bejegyzéseket típusaikkal együtt, mielőtt bármit módosítana. A vizsgálathoz nem kell privát kulcs és feltöltés, és másodpercek alatt eldönti a kérdést. Ha a telepítés egyetlen DNS-identitást szándékol, a tanúsítványnak dNSName-bejegyzésként kell hordoznia; ha a telepítés egy címet szándékol, a tanúsítványnak iPAddress-bejegyzésre van szüksége pontosan ahhoz a címhez.

Ha a tanúsítvány hibás, kérjen javítottat az üzemeltetőtől a konkrét várt azonosítóval. Ha a profil hibás, javítsa a profilt, és hagyja békén a tanúsítványt. Az identitásellenőrzés kikapcsolása eltünteti a hibát, és megszünteti annak ellenőrzését, hogy az alagút a szándékolt partnerrel beszél.

Dokumentálja az elvárt identitást kliensplatformonként, mert egy kliens által automatikusan levezetett értéket egy másikon kifejezetten meg kell adni.

Négy tényt adjon a megújítási kérelemhez

Írja le a várt azonosítót és annak típusát, a jelenlegi tanúsítványban ténylegesen meglévő SAN-bejegyzéseket, az ellenőrzést végző klienst és verziót, valamint a pontos hibaüzenetet. Az ebből a négy sorból felépített megújítási kérelem elsőre a megfelelő tanúsítványt kapja, nem pedig egy újat ugyanazzal az ismerős fájlnévvel.