IKEv2-certifikat og SAN: hvorfor identitetstjekket fejler
Et gyldigt IKEv2-certifikat fejler stadig, når den forventede identitet og SAN-typen ikke stemmer overens. Match DNS mod DNS, IP mod IP, og kontroller profilen først.
Dit certifikat kæder til en betroet CA, datoerne er fine, og peer'en nægter stadig at fuldføre fase 1 med en identitetsfejl. Rækkevidde og en gyldig signatur er kun halvdelen af det, en IKEv2-klient kontrollerer. Den anden halvdel er, om den identitet, den forventer, vises i certifikatet i det rigtige felt, og den forventning sættes af profilen, ikke af certifikatets filnavn.
Symptomet har altid samme form
En forbindelsesprofil ændres fra et værtsnavn til en IP-adresse, eller fornyes fra et certifikat med et DNS-navn til et, der kun bærer adresser, og tunnelen holder op med at forhandle. Intet på netværksstien er ændret. Klienten når peer'en, modtager et certifikat og afviser peer'ens identitet, fordi den identifikator, den fik besked om at forvente, ikke er repræsenteret i et felt, den accepterer. Fornyelser er den sædvanlige udløser, da erstatningscertifikatet ofte kommer fra en anden skabelon end det, det erstatter.
Begge sider logger så noget ubrugeligt, og derfor rapporteres fejlen normalt som et certifikatproblem. Klientloggen kan nævne den identitet, den ville have, og det navn er det spor, du vil have, ikke udløbsdatoen.
Match identifikatortypen, ikke kun værdien
Et dNSName-SAN og et iPAddress-SAN er forskellige felter med forskellige matchregler, så et certifikat, der bærer 203.0.113.10 som DNS-streng, opfylder ikke en klient, der forventer en IP-identitet. Moderne validatorer ignorerer i vid udstrækning det fælles navn, så den venlige etiket i certifikatoplysningerne beviser intet om, hvad der vil matche. Hvis et værtsnavn blev erstattet af en adresse under fejlfinding, antag at den forventede identitet flyttede med, indtil du har kontrolleret det. Sammenlign strengen i profilen med strengen i SAN tegn for tegn, fordi en punktum til sidst eller et overflødigt mellemrum er nok.
Jokertegn er en bekvemmelighed kun for DNS og følger deres egne matchregler, hvilket er en anden grund til, at en IP-baseret profil aldrig bør stole på dem.
Find ud af, hvor hver klient gemmer forventningen
I strongSwan kommer den værdi, der sammenlignes med certifikatet, fra indstillingen for peer-identitet: rightid i den klassiske konfiguration eller id i en fjernforbindelsessektion i swanctl. Dokumentationen om Apple IKEv2-interoperabilitet er nyttig her, fordi den beskriver de identitetskonventioner, en profil styret klient bruger, og disse konventioner forklarer en klasse af uoverensstemmelser, der ser tilfældige ud på nettet.
Apples konfigurationsprofiler bærer et felt for fjernidentifikator, og værdien der er det, klienten kontrollerer, ikke serveradressen i forbindelsesindstillingerne. Windows- og appliance-klienter har hver deres felt med deres egen standard, og standarden følger ofte den adresse, du indtastede. Når to felter er uenige, vinder det, klienten faktisk læser, og det er sjældent det, du redigerede.
Reparer profilen eller certifikatet med vilje
Inspicér peer-certifikatet med godkendte værktøjer, og list SAN-posterne med deres typer, før du ændrer noget. Den inspektion kræver ingen privat nøgle og ingen upload, og den afgør spørgsmålet på sekunder. Hvis implementeringen sigter mod én DNS-identitet, skal certifikatet bære den som en dNSName-post, og hvis den sigter mod en adresse, har certifikatet brug for en iPAddress-post til præcis den adresse.
Når certifikatet er forkert, bed operatøren om et rettet et med den specifikke forventede identifikator. Når profilen er forkert, ret profilen og lad certifikatet være. Deaktivering af identitetsvalidering får fejlen til at forsvinde og fjerner den kontrol, at tunnelen taler med den peer, du havde til hensigt.
Dokumentér den forventede identitet pr. klientplatform, fordi en værdi, som én klient udleder automatisk, måske skal være eksplicit på en anden.
Giv fornyelsesanmodningen fire fakta
Skriv den forventede identifikator og dens type ned, de SAN-poster, det aktuelle certifikat faktisk har, den klient og version, der udfører kontrollen, og den præcise fejltekst. En fornyelsesanmodning bygget på de fire linjer får det rigtige certifikat første gang i stedet for endnu et med det samme velkendte filnavn.