SAN-ul certificatului IKEv2: de ce eșuează verificarea identității

Certificatul dumneavoastră se înlănțuie la o CA de încredere, datele sunt corecte, iar partenerul refuză în continuare să finalizeze faza 1 cu o eroare de identitate. Accesibilitatea și o semnătură validă sunt doar jumătate din ce verifică un client IKEv2. Cealaltă jumătate este dacă identitatea așteptată apare în certificat în câmpul potrivit, iar această așteptare este stabilită de profil, nu de numele fișierului certificatului.

Simptomul are întotdeauna aceeași formă

Un profil de conexiune este schimbat dintr-un nume de gazdă într-o adresă IP sau reînnoit dintr-un certificat care purta un nume DNS într-unul care poartă doar adrese, șitunelul nu mai negociază. Nimic din calea rețelei nu s-a schimbat. Clientul ajunge la partener, primește un certificat și respinge identitatea partenerului pentru că identificatorul pe care i s-a spus să îl aștepte nu este reprezentat într-un câmp pe care îl acceptă. Reînnoirile sunt declanșatorul obișnuit, deoarece certificatul de înlocuire provine adesea dintr-un alt șablon decât cel pe care îl înlocuiește.

Ambele părți înregistrează apoi ceva inutil, motiv pentru care eșecul este de obicei raportat ca o problemă de certificat. Jurnalul clientului poate numi identitatea dorită, iar acel nume este indiciul de care aveți nevoie, nu data de expirare.

Potriviți tipul identificatorului, nu doar valoarea

Un SAN dNSName și un SAN iPAddress sunt câmpuri diferite cu reguli de potrivire diferite, așa că un certificat care conține 203.0.113.10 ca șir DNS nu satisface un client care așteaptă o identitate IP. Validatoarele moderne ignoră în mare măsură numele comun, așa că eticheta prietenoasă din detaliile certificatului nu dovedește nimic despre ce se va potrivi. Dacă un nume de gazdă a fost înlocuit cu o adresă în timpul depanării, presupuneți că identitatea așteptată s-a mutat cu el până când ați verificat. Comparați șirul din profil cu șirul din SAN caracter cu caracter, pentru că un punct final sau un spațiu în plus sunt suficiente.

Metacaracterele sunt doar o comozitate DNS și urmează propriile reguli de potrivire, ceea ce este un alt motiv pentru care un profil bazat pe IP nu ar trebui să se bazeze niciodată pe ele.

Găsiți unde fiecare client păstrează așteptarea

În strongSwan, valoarea comparată cu certificatul provine din setarea identității partenerului: rightid în configurația clasică, sau id unei secțiuni de conexiune la distanță din swanctl. Documentația sa despre interoperabilitatea Apple IKEv2 este utilă aici pentru că explică convențiile de identitate folosite de un client condus de profil, iar acele convenții explică o clasă de nepotriviri care par aleatorii pe fir.

Profilurile de configurare Apple conțin un câmp de identificator la distanță, iar valoarea de acolo este ce verifică clientul, nu adresa serverului din setările conexiunii. Clienții Windows și ai echipamentelor au fiecare propriul câmp cu propria valoare implicită, iar valoarea implicită urmează adesea adresa tastată. Acolo unde două câmpuri nu sunt de acord, câștigă cel pe care clientul îl citește efectiv, și rareori este cel pe care l-ați editat.

Reparați profilul sau certificatul, în mod deliberat

Înainte de a schimba ceva, inspectați certificatul partenerului cu instrumente aprobate și listați intrările SAN cu tipurile lor. Acea inspecție nu necesită cheie privată și nici încărcare, și rezolvă întrebarea în câteva secunde. Dacă implementarea intenționează o singură identitate DNS, certificatul trebuie să o conțină ca intrare dNSName, iar dacă implementarea intenționează o adresă, certificatul are nevoie de o intrare iPAddress exact pentru acea adresă.

Când certificatul este greșit, cereți operatorului unul corectat cu identificatorul așteptat specific. Când profilul este greșit, corectați profilul și lăsați certificatul în pace. Dezactivarea validării identității face eroarea să dispară și elimină verificarea că tunelul vorbește cu partenerul dorit.

Documentați identitatea așteptată pentru fiecare platformă de client, pentru că o valoare pe care un client o derivă automat poate trebui să fie explicită pe altul.

Dați cererii de reînnoire patru fapte

Notați identificatorul așteptat și tipul lui, intrările SAN pe care certificatul actual le are efectiv, clientul și versiunea care fac verificarea, și textul exact al erorii. O cerere de reînnoire construită din aceste patru linii obține certificatul corect din prima, în loc de încă unul cu același nume de fișier familiar.