IKEv2-sertifikaat-SAN: waarom identiteitskontrole misluk

Jou sertifikaat ketting na 'n vertroude CA, die datums is reg, en die eweknie weier steeds om fase 1 met 'n identiteitsfout te voltooi. Bereikbaarheid en 'n geldige handtekening is net die helfte van wat 'n IKEv2-kliënt nagaan. Die ander helfte is of die identiteit wat dit verwag in die regte veld in die sertifikaat verskyn, en daardie verwagting word deur die profiel bepaal, nie deur die sertifikaat se lêernaam nie.

Die simptoom is altyd dieselfde

'n Verbindingsprofiel word van 'n gasheernaam na 'n IP-adres verander, of vernuwe van 'n sertifikaat met 'n DNS-naam na een wat net adresse dra, en die tonnel hou op onderhandel. Niks in die netwerkpad het verander nie. Die kliënt bereik die eweknie, ontvang 'n sertifikaat en verwerp die eweknie se identiteit omdat die identifiseerder wat hy verwag het nie in 'n veld verskyn wat hy aanvaar nie. Vernuwings is die gewone sneller, want die vervangingsertifikaat kom dikwels uit 'n ander sjabloon as die een wat dit vervang.

Beide kante teken dan iets onbehulpsaams aan, en daarom word die fout gewoonlik as 'n sertifikaatprobleem gerapporteer. Die kliëntlog noem miskien die identiteit wat dit wou hê, en daardie naam is die leidraad wat jy soek, nie die vervaldatum nie.

Pas die identifiseerder se tipe, nie net die waarde nie

'n dNSName-SAN en 'n iPAddress-SAN is verskillende velde met verskillende passingreëls, so 'n sertifikaat wat 203.0.113.10 as 'n DNS-string dra, bevredig nie 'n kliënt wat 'n IP-identiteit verwag nie. Moderne valideerders ignoreer grotendeels die algemene naam, so die vriendelike etiket in die sertifikaatbesonderhede bewys niks oor wat gaan pas nie. As 'n gasheernaam tydens foutopsporing deur 'n adres vervang is, aanvaar dat die verwagte identiteit saamgeskuif het totdat jy dit nagegaan het. Vergelyk die string in die profiel met die string in die SAN karakter vir karakter, want 'n punt aan die einde of 'n oortollige spasie is genoeg.

Jokertekens is net vir DNS gerieflik en volg hul eie passingreëls, wat nog 'n rede is waarom 'n IP-gebaseerde profiel nooit daarop moet staatmaak nie.

Vind waar elke kliënt die verwagting stoor

In strongSwan kom die waarde wat teen die sertifikaat vergelyk word uit die eweknie-identiteitsinstelling: rightid in die klassieke konfigurasie, of die id van 'n remote-verbindingafdeling in swanctl. Die dokumentasie oor Apple IKEv2-interoperabiliteit is hier nuttig, want dit spel die identiteitskonvensies uit wat 'n profielgedrewe kliënt gebruik, en daardie konvensies verduidelik 'n klas mispassings wat op die draad willekeurig lyk.

Apple-konfigurasieprofiele dra 'n veld vir die remote-identifiseerder, en die waarde daar is wat die kliënt nagaan, nie die bedieneradres in die verbindingsinstellings nie. Windows- en toestelkliënte het elkeen sy eie veld met sy eie verstek, en die verstek volg dikwels die adres wat jy getik het. Waar twee velde verskil, wen die een wat die kliënt werklik lees, en dit is selde die een wat jy geredigeer het.

Herstel die profiel of die sertifikaat, doelbewus

Inspekteer die eweknie-sertifikaat met goedgekeurde gereedskap en lys die SAN-inskrywings met hul tipes voordat jy enigiets verander. Daardie inspeksie het geen private sleutel en geen oplaai nodig nie, en dit besleg die vraag in sekondes. As die ontplooiing een DNS-identiteit bedoel, moet die sertifikaat dit as 'n dNSName-inskrywing dra, en as die ontplooiing 'n adres bedoel, het die sertifikaat 'n iPAddress-inskrywing vir presies daardie adres nodig.

Wanneer die sertifikaat verkeerd is, vra 'n reggestelde een by die operateur aan met die spesifieke verwagte identifiseerder. Wanneer die profiel verkeerd is, herstel die profiel en laat die sertifikaat staan. Om identiteitskontrole af te skakel laat die fout verdwyn en verwyder die kontrole dat die tonnel met die eweknie praat wat jy bedoel het.

Dokumenteer die verwagte identiteit per kliëntplatform, want 'n waarde wat een kliënt outomaties aflei, moet dalk op 'n ander een eksplisiet wees.

Gee die vernuwingsversoek vier feite

Skryf die verwagte identifiseerder en sy tipe neer, die SAN-inskrywings wat die huidige sertifikaat werklik het, die kliënt en weergawe wat die kontrole doen, en die presiese foutteks. 'n Vernuwingsversoek wat uit daardie vier reëls gebou is, kry die eerste keer die regte sertifikaat, in plaas van nog een met dieselfde bekende lêernaam.