SAN van IKEv2-certificaat: waarom de identiteitscontrole mislukt

Je certificaat is geketend aan een vertrouwde CA, de datums zijn in orde, en de peer weigert nog steeds fase 1 te voltooien met een identiteitsfout. Bereikbaarheid en een geldige handtekening zijn slechts de helft van wat een IKEv2-client controleert. De andere helft is of de identiteit die hij verwacht in het juiste veld in het certificaat staat, en die verwachting wordt bepaald door het profiel, niet door de bestandsnaam van het certificaat.

Het symptoom heeft altijd dezelfde vorm

Een verbindingsprofiel wordt gewijzigd van een hostnaam naar een IP-adres, of vernieuwd van een certificaat met een DNS-naam naar een certificaat dat alleen adressen bevat, ende tunnel stopt met onderhandelen. Niets in het netwerkpad is veranderd. De client bereikt de peer, ontvangt een certificaat en wijst de identiteit van de peer af omdat de id die hij moest verwachten niet is vertegenwoordigd in een veld dat hij accepteert. Vernieuwingen zijn de gebruikelijke trigger, omdat het vervangende certificaat vaak uit een andere sjabloon komt dan het certificaat dat het vervangt.

Beide kanten loggen dan iets onbruikbaars, waardoor de fout meestal als een certificaatprobleem wordt gemeld. Het clientlog kan de gewenste identiteit noemen, en die naam is de aanwijzing die je wilt, niet de vervaldatum.

Koppel het type id, niet alleen de waarde

Een dNSName-SAN en een iPAddress-SAN zijn verschillende velden met verschillende overeenkomstenregels, dus een certificaat met 203.0.113.10 als DNS-string voldoet niet aan een client die een IP-identiteit verwacht. Moderne validators negeren grotendeels de common name, dus het vriendelijke label in de certificaatdetails bewijst niets over wat er zal matchen. Als een hostnaam tijdens het oplossen van problemen is vervangen door een adres, ga er dan van uit dat de verwachte identiteit mee is verhuisd tot je het hebt gecontroleerd. Vergelijk de string in het profiel met de string in de SAN teken voor teken, want een punt aan het eind of een losse spatie is genoeg.

Wildcards zijn alleen een DNS-gemak en volgen hun eigen overeenkomstenregels, wat een andere reden is waarom een op IP gebaseerd profiel er nooit op zou moeten vertrouwen.

Zoek op waar elke client de verwachting opslaat

In strongSwan komt de waarde die met het certificaat wordt vergeleken uit de peer-identity-instelling: rightid in de klassieke configuratie, of de id van een remote connection-sectie in swanctl. De documentatie over Apple IKEv2-interoperabiliteit is hier nuttig omdat die de identiteitsconventies uitlegt die een profielgestuurde client gebruikt, en die conventies verklaren een klasse van mismatches die op de draad willekeurig lijken.

Apple-configuratieprofielen bevatten een remote identifier-veld, en de waarde daar is wat de client controleert, niet het serveradres in de verbindingsinstellingen. Windows- en apparaatclients hebben elk hun eigen veld met hun eigen standaard, en de standaard volgt vaak het adres dat je hebt getypt. Waar twee velden het oneens zijn, wint degene die de client daadwerkelijk leest, en dat is zelden degene die je hebt bewerkt.

Repareer het profiel of het certificaat, bewust

Inspecteer het peercertificaat met goedgekeurde hulpmiddelen en lijst de SAN-vermeldingen met hun typen op voordat je iets wijzigt. Die inspectie vereist geen privésleutel en geen upload, en beslecht de vraag binnen enkele seconden. Als de uitrol één DNS-identiteit bedoelt, moet het certificaat die als dNSName-vermelding bevatten, en als de uitrol een adres bedoelt, heeft het certificaat een iPAddress-vermelding nodig voor precies dat adres.

Als het certificaat verkeerd is, vraag de operator dan om een gecorrigeerd certificaat met de specifieke verwachte id. Als het profiel verkeerd is, repareer het profiel en laat het certificaat met rust. Identiteitsvalidatie uitschakelen laat de fout verdwijnen en haalt de controle weg dat de tunnel met de bedoelde peer praat.

Documenteer de verwachte identiteit per clientplatform, omdat een waarde die de ene client automatisch afleidt op een andere expliciet kan moeten zijn.

Geef de vernieuwingsaanvraag vier feiten

Noteer de verwachte id en het type, de SAN-vermeldingen die het huidige certificaat werkelijk heeft, de client en versie die de controle uitvoeren, en de exacte fouttekst. Een vernieuwingsaanvraag die uit deze vier regels is opgebouwd, krijgt de eerste keer het juiste certificaat, in plaats van nog een met dezelfde bekende bestandsnaam.