Mac IKEv2 ECDSA: kva sertifikattype høyrer til klienten?
På ein Mac skildrar ECDSA256 i IKEv2-innstillingane det lokale identitetssertifikatet, ikkje gatewayen eller signaturen til utstedaren. Les kvar rolle før du vel.
På macOS svarar ECDSA-valet i ei IKEv2-klientinnstilling på eit smalt spørsmål: kva sertifikat provar identiteten til Macen. Det skildrar ikkje gateway-sertifikatet, signaturen som gav ut klientsertifikatet, eller krypteringsframlegget for tunnelen. Å handsame desse fire rollene som eitt kompatibilitetsspørsmål er måten ei korrekt lokal innstilling blir skulda for eit avvik på serversida. Avgjerda er lita, men prova som blir brukt for å ta ho må vere presise.
Feltet namngir eitt sertifikat: den lokale identiteten
Network Extension API frå Apple eksponerer ein sertifikattype for klientlegitimasjonen, inkludert NEVPNIKEv2CertificateType.ECDSA256, dokumentert som sertifikattypen ECDSA p-256. Eigenskapen gjeld sertifikatet som blir levert via identityReference eller identityData.
Det tyder at avgjerda gjeld sertifikatet Macen legg fram, plus den private nøkkelen som høyrer til. Vel typen som svarar til den offentlege nøkkelen til lauvsertifikatet, og lever identiteten via den støtta mekanismen. Viss Macen ikkje har ein brukbar privat nøkkel for identiteten, kan typevalet ikkje redde sambandet.
Administrerte profilar tar same avgjerd via CertificateType i IKEv2-nyttelasta, saman med ein sertifikatreferanse som PayloadCertificateUUID. Desse felta har føresetnader og eit skjema for målversjonen av operativsystemet; ein naken typeverdi kopiert inn i ein profil kan ikkje installerast, og eit innstillingvindauge viser kanskje ikkje alle API-alternativ. Kontroller føresetnadene til nyttelasta for den versjonen før utrulling.
Avgjer etter rolle, ikkje etter etiketten på sertifikatet
Les feltet du er i ferd med å endre, og spør kva sertifikat det peikar på. Etikettene i ein sertifikatvisar blandar subjekt, utstedar og signaturealgoritme, og berre éin av dei høyrer til valet av klientidentitet.
| 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 |
Viss sertifikatvisaren viser ein ECDSA-signatur frå CAen, skildrar det signeringsnøkkelen til utstedaren. Klienten sin eigen nøkkel kan framleis vere RSA, og typefeltet bør følgje klientnøkkelen framfor signaturlina. Denne eine forvekslinga forklarer mange rapportar om "ECDSA er konfigurert, men sambandet feilar". Samanlikn nøkkeltypen i lauvet med typen som er vald i profilen, før du endrar noko.
Avgjerda blir enklare når lauvet er identifisert: ECDSA256 for ein p-256-klientnøkkel, ein annan støtta type for ein annan nøkkel. Viss klientsertifikatet og nøkkelen ikkje passar, må du rette opp paret før du endrar VPN-profilen.
Gateway-sertifikatet er ei eiga avgjerd
Gatewayen legg fram sitt eige sertifikat, og Macen validerer det mot eit tillitsanker og eit forventa namn. Om sertifikatet brukar ECDSA, RSA eller ein annan nøkkeltype, er ein eigenskap ved serveren, ikkje ved innstillinga for klientidentitet.
Lokal støtte for eit ECDSA-klientsertifikat provar ikkje at kvart gateway-sertifikat, kvar kurve eller kvar serverautentiseringskonfigurasjon vil samverke. Kontroller identiteten til serveren, kjeda og IKE-autentiseringsmetoden som separate inngangar, og test med profilen som faktisk skal rullast ut.
Viss gateway-sertifikatet er problemet, oppstår symptomet vanlegvis under validering av motparten, ikkje ved identitetsvalet. Les feilsteget før du endrar klienttypen, fordi ein tillitsfeil og eit avvik i klientnøkkelen ikkje deler same løysing.
Signaturen til utstedaren og nøkkelavtalegruppa er ikkje klienttypen
X.509 held den offentlege nøkkelen til subjektet og signaturen til utstedaren i ulike felt. Informasjonen om offentleg nøkkel til subjektet skildrar nøkkelen i sertifikatet; signaturealgoritmen skildrar nøkkelen til CAen og signeringsoperasjonen. Berre det første svarar til innstillinga for sertifikattype.
IKE- og Child SA-framlegga er ein annan akse. Ein ECDSA-sertifikattype er ikkje eit ESP-krypteringsval, og endring av nøkkelavtalegruppa vel ikkje ein sertifikattype. Ein profil kan ha gyldige framlegg og feil identitetstype, eller rett identitetstype og eit framlegg som motparten avviser.
Hald dei tre linjene skilde i endringsloggen: identitetssertifikat og nøkkel, tillitsinngangar til gatewayen og algoritmane til framlegga. Å slå dei saman i eitt notat om "kryptinnstillingar" gjer den neste feilen umogleg å tilskrive.
Stadfest avgjerda med felta du sette opp
Kontroller identiteten profilen faktisk viser til, og stadfest deretter at sertifikatet på den referansen har forventa offentleg nøkkel og ein brukbar privat nøkkel. Typen som blir vist i grensesnittet, det refererte sertifikatet og nøkkelen på eininga må stemme overeins.
Stadfest deretter inngangane til gatewayen: forventa servernamn, tillitsankeret og IKE-autentiseringsmetoden. Til slutt koplar du til og les kvar handtrykket stoppar. Ein feil før identitetsutvekslinga peikar bort frå denne innstillinga; ein feil ved validering av motparten peikar mot gateway-sida.
Noter den valde typen, identitetsreferansen og subjektet til gateway-sertifikatet i utrullingsnotata. Den neste profiloppdatering kan endre kva som helst av dei, og tre namngjetne verdiar er raskare å samanlikne enn eit skjermbilete av eit innstillingspanel.