Mac IKEv2 ECDSA: ce tip de certificat aparține clientului?
Pe un Mac, ECDSA256 din setările IKEv2 descrie certificatul de identitate local, nu poarta de acces sau semnătura emitentului. Citește fiecare rol înainte de a alege.
Pe macOS, alegerea ECDSA într-o setare de client IKEv2 răspunde unei întrebări înguste: care certificat dovedește identitatea Mac-ului. Nu descrie certificatul porții de acces, semnătura care a emis certificatul clientului sau propunerea de criptare a tunelului. Tratarea acestor patru roluri ca o singură întrebare de compatibilitate este modul în care o setare locală corectă ajunge învinuită pentru o nepotrivire din partea serverului. Decizia este mică, dar dovezile folosite pentru ea trebuie să fie precise.
Câmpul numește un singur certificat: identitatea locală
API-ul Network Extension al Apple expune un tip de certificat pentru acreditările clientului, inclusiv NEVPNIKEv2CertificateType.ECDSA256, documentat ca tipul de certificat ECDSA p-256. Proprietatea se aplică certificatului furnizat prin identityReference sau identityData.
Asta înseamnă că decizia privește certificatul pe care Mac-ul îl prezintă, împreună cu cheia privată aferentă. Alege tipul care corespunde cheii publice a acelui certificat frunză și furnizează identitatea prin mecanismul acceptat. Dacă Mac-ul nu are o cheie privată utilizabilă pentru identitate, alegerea tipului nu poate salva conexiunea.
Profilurile administrate iau aceeași decizie prin CertificateType al încărcăturii IKEv2, împreună cu o referință de certificat precum PayloadCertificateUUID. Aceste câmpuri au precondiții și o schemă pentru versiunea de sistem de operare țintă; o valoare de tip goală copiată într-un profil nu este instalabilă, iar fereastra de setări poate să nu expună fiecare opțiune API. Verifică precondițiile încărcăturii pentru acea versiune înainte de implementare.
Decide după rol, nu după eticheta certificatului
Citește câmpul pe care urmează să îl schimbi și întreabă la ce certificat indică. Etichetele dintr-un vizualizator de certificate amestecă subiectul, emitentul și algoritmul de semnare, iar doar una dintre ele ține de alegerea identității clientului.
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
Dacă vizualizatorul de certificate arată o semnătură ECDSA de la CA, aceasta descrie cheia de semnare a emitentului. Cheia clientului poate fi încă RSA, iar câmpul de tip ar trebui să urmeze cheia clientului, nu linia semnăturii. Această singură confuzie explică multe rapoarte de tipul "ECDSA este configurat, dar conexiunea eșuează". Compară tipul cheii din frunză cu tipul selectat în profil înainte de a schimba ceva.
Decizia devine mai simplă odată ce frunza este identificată: ECDSA256 pentru o cheie de client p-256, alt tip acceptat pentru o cheie diferită. Dacă certificatul clientului și cheia sa nu corespund, corectează acea pereche înainte de a schimba profilul VPN.
Certificatul porții de acces este o decizie separată
Poarta de acces prezintă propriul certificat, iar Mac-ul îl validează față de o ancoră de încredere și un nume așteptat. Dacă acel certificat folosește ECDSA, RSA sau alt tip de cheie este o proprietate a serverului, nu a setării de identitate a clientului.
Suportul local pentru un certificat de client ECDSA nu dovedește că fiecare certificat de poartă, curbă sau configurație de autentificare a serverului va interopera. Verifică identitatea serverului, lanțul său și metoda de autentificare IKE ca intrări separate și testează cu profilul care va fi implementat efectiv.
Dacă certificatul porții de acces este problema, simptomul apare de obicei în timpul validării partenerului, nu la selectarea identității. Citește etapa eșecului înainte de a schimba tipul clientului, pentru că o eroare de încredere și o nepotrivire a cheii clientului nu împărtășesc aceeași soluție.
Semnătura emitentului și grupul de acord al cheilor nu sunt tipul clientului
X.509 ține cheia publică a subiectului și semnătura emitentului în câmpuri diferite. Informațiile despre cheia publică a subiectului descriu cheia din certificat; algoritmul de semnare descrie cheia CA și operația de semnare. Doar prima corespunde setării tipului de certificat.
Propunerile IKE și Child SA sunt o altă axă. Un tip de certificat ECDSA nu este o alegere de criptare ESP, iar schimbarea grupului de acord al cheilor nu selectează un tip de certificat. Un profil poate avea propuneri valide și tipul de identitate greșit, sau tipul de identitate corect și o propunere pe care partenerul o respinge.
Păstrează cele trei linii separate în jurnalul modificărilor: certificat și cheie de identitate, intrări de încredere ale porții de acces și algoritmii propunerilor. Combinarea lor într-o singură notă "setări cripto" face imposibilă atribuirea următorului eșec.
Verifică decizia cu câmpurile pe care le-ai configurat
Verifică identitatea la care profilul face referire efectiv, apoi confirmă că certificatul de la acea referință are cheia publică așteptată și o cheie privată utilizabilă. Tipul afișat în interfață, certificatul referit și cheia de pe dispozitiv trebuie să coincidă.
Apoi confirmă intrările porții de acces: numele de server așteptat, ancora de încredere și metoda de autentificare IKE. În final, conectează-te și citește unde se oprește handshake-ul. Un eșec înainte de schimbul de identitate indică în afara acestei setări; un eșec la validarea partenerului indică spre partea porții de acces.
Notează tipul ales, referința de identitate și subiectul certificatului porții de acces în notițele de implementare. Următoarea actualizare a profilului poate schimba oricare dintre ele, iar trei valori numite se compară mai repede decât o captură de ecran a unui panou de setări.