SAN för IKEv2-certifikat: varför identitetskontrollen misslyckas

Ditt certifikat kedjas till en betrodd CA, datumen är korrekta och motparten vägrar ändå slutföra fas 1 med ett identitetsfel. Nåbarhet och en giltig signatur är bara hälften av vad en IKEv2-klient kontrollerar. Den andra hälften är om identiteten den förväntar sig finns i certifikatet i rätt fält, och den förväntan sätts av profilen, inte av certifikatets filnamn.

Symtomet har alltid samma form

En anslutningsprofil ändras från ett värdnamn till en IP-adress, eller förnyas från ett certifikat som bar ett DNS-namn till ett som bara bär adresser, ochtunneln slutar förhandla. Inget i nätverksvägen har ändrats. Klienten når motparten, tar emot ett certifikat och avvisar motpartens identitet eftersom identifieraren den blev tillsagd att förvänta sig inte representeras i ett fält den accepterar. Förnyelser är den vanliga utlösaren, eftersom ersättningscertifikatet ofta kommer från en annan mall än det det ersätter.

Båda sidor loggar sedan något oanvändbart, och därför rapporteras felet vanligtvis som ett certifikatproblem. Klientloggen kan namnge den identitet den ville ha, och det namnet är ledtråden du vill ha, inte utgångsdatumet.

Matcha identifierartypen, inte bara värdet

En dNSName-SAN och en iPAddress-SAN är olika fält med olika matchningsregler, så ett certifikat som bär 203.0.113.10 som en DNS-sträng uppfyller inte en klient som förväntar sig en IP-identitet. Moderna validerare ignorerar till stor del det vanliga namnet, så den vänliga etiketten i certifikatdetaljerna bevisar ingenting om vad som kommer att matcha. Om ett värdnamn ersattes av en adress under felsökningen, anta att den förväntade identiteten flyttade med den tills du har kontrollerat. Jämför strängen i profilen med strängen i SAN tecken för tecken, eftersom en punkt i slutet eller ett extra blanksteg räcker.

Jokertecken är bara en DNS-bekvämlighet och följer sina egna matchningsregler, vilket är en annan anledning till att en IP-baserad profil aldrig bör förlita sig på dem.

Ta reda på var varje klient lagrar förväntan

I strongSwan kommer värdet som jämförs med certifikatet från inställningen för motpartens identitet: rightid i den klassiska konfigurationen, eller id i ett avsnitt för fjärranslutning i swanctl. Deras dokumentation om Apple IKEv2-interoperabilitet är användbar här eftersom den förklarar de identitetskonventioner som en profilbaserad klient använder, och dessa konventioner förklarar en klass av avvikelser som ser slumpmässiga ut på tråden.

Apples konfigurationsprofiler har ett fält för fjärridentifierare, och värdet där är det klienten kontrollerar, inte serveradressen i anslutningsinställningarna. Windows- och enhetsklienter har var sitt fält med var sitt standardvärde, och standardvärdet följer ofta adressen du skrev in. När två fält inte stämmer överens vinner det klienten faktiskt läser, och det är sällan det du redigerade.

Reparera profilen eller certifikatet, med avsikt

Inspektera motpartens certifikat med godkända verktyg och lista SAN-posterna med deras typer innan du ändrar något. Den inspektionen kräver ingen privat nyckel och ingen uppladdning, och den avgör frågan på sekunder. Om driftsättningen avser en enda DNS-identitet måste certifikatet bära den som en dNSName-post, och om driftsättningen avser en adress behöver certifikatet en iPAddress-post för exakt den adressen.

När certifikatet är fel, be operatören om ett korrigerat med den specifika förväntade identifieraren. När profilen är fel, rätta profilen och låt certifikatet vara. Att stänga av identitetsvalideringen får felet att försvinna och tar bort kontrollen att tunneln talar med den motpart du avsåg.

Dokumentera den förväntade identiteten per klientplattform, eftersom ett värde som en klient härleder automatiskt kan behöva anges explicit på en annan.

Ge förnyelsebegäran fyra fakta

Skriv ned den förväntade identifieraren och dess typ, de SAN-poster som det nuvarande certifikatet faktiskt har, klienten och versionen som utför kontrollen, och den exakta feltexten. En förnyelsebegäran byggd från dessa fyra rader får rätt certifikat första gången, i stället för ännu ett med samma välbekanta filnamn.