SAN for IKEv2-sertifikat: kvifor identitetskontrollen feilar

Sertifikatet ditt er lenka til ein klarert CA, datoane er i orden, og motparten nektar framleis å fullføre fase 1 med ein identitetsfeil. Rekkevidd og ein gyldig signatur er berre halvparten av det ein IKEv2-klient kontrollerer. Den andre halvparten er om identiteten han ventar visest i sertifikatet i rett felt, og den ventinga blir sett av profilen, ikkje av filnamnet til sertifikatet.

Symptomet har alltid same forma

Ein tilkoplingsprofil blir endra frå eit vertsnamn til ei IP-adresse, eller fornya frå eit sertifikat som bar eit DNS-namn til eitt som ber berre adresser, ogtunnelen sluttar å forhandle. Ingenting i nettverksbanen er endra. Klienten når motparten, tek imot eit sertifikat og avviser identiteten til motparten fordi identifikatoren han vart beden om å vente på ikkje er representert i eit felt han godtek. Fornyingar er den vanlege utløysaren, sidan erstatningssertifikatet ofte kjem frå ein annan mal enn det det erstattar.

Begge sider loggar så noko ubrukeleg, og difor blir feilen vanlegvis rapportert som eit sertifikatproblem. Klientloggen kan nemne identiteten han ville ha, og det namnet er leiartråden du vil ha, ikkje utløpsdatoen.

Match identifikatortypen, ikkje berre verdien

Ein dNSName-SAN og ein iPAddress-SAN er ulike felt med ulike matchreglar, så eit sertifikat som ber 203.0.113.10 som ein DNS-streng tilfredsstiller ikkje ein klient som ventar ein IP-identitet. Moderne validatarar ignorerer i stor grad det vanlege namnet, så den venlege etiketten i sertifikatdetaljane beviser ingenting om kva som vil matche. Viss eit vertsnamn vart erstatta av ei adresse under feilsøking, rekn med at den venta identiteten flytta med henne til du har kontrollert. Samanlikn strengen i profilen med strengen i SAN teikn for teikn, fordi eit punktum til slutt eller ein ekstra plass er nok.

Jokerteikn er berre ei DNS-bekvemmelegheit og følgjer sine eigne matchreglar, som er ein annan grunn til at ein IP-basert profil aldri bør stole på dei.

Finn ut kvar kvar klient lagrar ventinga

I strongSwan kjem verdien som blir samanlikna med sertifikatet frå innstillinga for identiteten til motparten: rightid i den klassiske konfigurasjonen, eller id i ein ekstern tilkoplingsseksjon i swanctl. Dokumentasjonen deira om Apple IKEv2-interoperabilitet er nyttig her fordi han forklarer identitetskonvensjonane som ein profilbasert klient brukar, og desse konvensjonane forklarer ein klasse av avvik som ser tilfeldige ut på leidninga.

Apples konfigurasjonsprofilar har eit felt for ekstern identifikator, og verdien der er det klienten kontrollerer, ikkje tenaradressa i tilkoplingsinnstillingane. Windows- og apparatklientar har kvar sitt felt med kvar sin standardverdi, og standardverdien følgjer ofte adressa du skreiv inn. Der to felt er usamde, vinn det klienten faktisk les, og det er sjeldan det du redigerte.

Reparer profilen eller sertifikatet, med vilje

Inspiser sertifikatet til motparten med godkjende verktøy og list SAN-oppføringane med typane deira før du endrar noko. Den inspeksjonen treng ingen privat nøkkel og inga opplasting, og han avgjer spørsmålet på sekundar. Viss utrullinga har til hensikt éin DNS-identitet, må sertifikatet bere han som ein dNSName-oppføring, og viss utrullinga har til hensikt ei adresse, treng sertifikatet ein iPAddress-oppføring for nøyaktig den adressa.

Når sertifikatet er feil, be operatøren om eit retta eit med den spesifikke venta identifikatoren. Når profilen er feil, rett profilen og lat sertifikatet vere. Å slå av identitetsvalidering gjer at feilen forsvinn og fjernar kontrollen av at tunnelen snakkar med motparten du meinte.

Dokumenter den venta identiteten per klientplattform, fordi ein verdi som éin klient leier ut automatisk kan måtte angivast eksplisitt på ein annan.

Gi fornyingsførespurnaden fire fakta

Skriv ned den venta identifikatoren og typen, SAN-oppføringane det noverande sertifikatet faktisk har, klienten og versjonen som utfører kontrollen, og den nøyaktige feilteksten. Ein fornyingsførespurnad bygd frå desse fire linjene får det rette sertifikatet første gong, i staden for eit nytt med same kjende filnamn.