SAN for IKEv2-sertifikat: hvorfor identitetskontrollen feiler

Sertifikatet ditt er lenket til en klarert CA, datoene er i orden, og motparten nekter fortsatt å fullføre fase 1 med en identitetsfeil. Rekkevidde og en gyldig signatur er bare halvparten av det en IKEv2-klient kontrollerer. Den andre halvparten er om identiteten den forventer vises i sertifikatet i riktig felt, og den forventningen settes av profilen, ikke av sertifikatets filnavn.

Symptomet har alltid samme form

En tilkoblingsprofil endres fra et vertsnavn til en IP-adresse, eller fornyes fra et sertifikat som bar et DNS-navn til ett som bare bærer adresser, ogtunnelen slutter å forhandle. Ingenting i nettverksbanen er endret. Klienten når motparten, mottar et sertifikat og avviser motpartens identitet fordi identifikatoren den ble bedt om å forvente ikke er representert i et felt den godtar. Fornyelser er den vanlige utløseren, siden erstatningssertifikatet ofte kommer fra en annen mal enn det det erstatter.

Begge sider logger så noe ubrukelig, og derfor rapporteres feilen vanligvis som et sertifikatproblem. Klientloggen kan navngi identiteten den ønsket, og det navnet er ledetråden du vil ha, ikke utløpsdatoen.

Match identifikatortypen, ikke bare verdien

En dNSName-SAN og en iPAddress-SAN er forskjellige felt med forskjellige matchregler, så et sertifikat som bærer 203.0.113.10 som en DNS-streng tilfredsstiller ikke en klient som forventer en IP-identitet. Moderne validatorer ignorerer i stor grad det vanlige navnet, så den vennlige etiketten i sertifikatdetaljene beviser ingenting om hva som vil matche. Hvis et vertsnavn ble erstattet av en adresse under feilsøking, anta at den forventede identiteten flyttet med den til du har kontrollert. Sammenlign strengen i profilen med strengen i SAN tegn for tegn, fordi et punktum til slutt eller en ekstra plass er nok.

Jokertegn er bare en DNS-bekvemmelighet og følger sine egne matchregler, som er en annen grunn til at en IP-basert profil aldri bør stole på dem.

Finn ut hvor hver klient lagrer forventningen

I strongSwan kommer verdien som sammenlignes med sertifikatet fra innstillingen for motpartens identitet: rightid i den klassiske konfigurasjonen, eller id i en ekstern tilkoblingsseksjon i swanctl. Dokumentasjonen deres om Apple IKEv2-interoperabilitet er nyttig her fordi den forklarer identitetskonvensjonene som en profilbasert klient bruker, og disse konvensjonene forklarer en klasse av avvik som ser tilfeldig ut på ledningen.

Apples konfigurasjonsprofiler har et felt for ekstern identifikator, og verdien der er det klienten kontrollerer, ikke serveradressen i tilkoblingsinnstillingene. Windows- og apparatklienter har hvert sitt felt med hver sin standardverdi, og standardverdien følger ofte adressen du skrev inn. Der to felt er uenige, vinner det klienten faktisk leser, og det er sjelden det du redigerte.

Reparer profilen eller sertifikatet, med vilje

Inspiser motpartens sertifikat med godkjente verktøy og list SAN-oppføringene med typene deres før du endrer noe. Den inspeksjonen trenger ingen privat nøkkel og ingen opplasting, og den avgjør spørsmålet på sekunder. Hvis utrullingen har til hensikt én DNS-identitet, må sertifikatet bære den som en dNSName-oppføring, og hvis utrullingen har til hensikt en adresse, trenger sertifikatet en iPAddress-oppføring for nøyaktig den adressen.

Når sertifikatet er feil, be operatøren om et rettet ett med den spesifikke forventede identifikatoren. Når profilen er feil, rett profilen og la sertifikatet være. Å slå av identitetsvalidering gjør at feilen forsvinner og fjerner kontrollen av at tunnelen snakker med motparten du mente.

Dokumenter den forventede identiteten per klientplattform, fordi en verdi som én klient utleder automatisk kan måtte angis eksplisitt på en annen.

Gi fornyelsesforespørselen fire fakta

Skriv ned den forventede identifikatoren og typen, SAN-oppføringene det nåværende sertifikatet faktisk har, klienten og versjonen som utfører kontrollen, og den nøyaktige feilteksten. En fornyelsesforespørsel bygget fra disse fire linjene får det riktige sertifikatet første gang, i stedet for et nytt med samme kjente filnavn.