Mac IKEv2 ECDSA: hvilken sertifikattype tilhører klienten?
På en Mac beskriver ECDSA256 i IKEv2-innstillingene det lokale identitetssertifikatet, ikke gatewayen eller utstederens signatur. Les hver rolle før du velger.
På macOS svarer ECDSA-valget i en IKEv2-klientinnstilling på et smalt spørsmål: hvilket sertifikat beviser Macens identitet. Det beskriver ikke gateway-sertifikatet, signaturen som utstedte klientsertifikatet, eller krypteringsforslaget for tunnelen. Å behandle disse fire rollene som ett kompatibilitetsspørsmål er måten en korrekt lokal innstilling blir beskyldt for et avvik på serversiden. Beslutningen er liten, men bevisene som brukes for å ta den må være presise.
Feltet navngir ett sertifikat: den lokale identiteten
Apples Network Extension API eksponerer en sertifikattype for klientens legitimasjon, inkludert NEVPNIKEv2CertificateType.ECDSA256, dokumentert som sertifikattypen ECDSA p-256. Egenskapen gjelder sertifikatet som leveres via identityReference eller identityData.
Det betyr at beslutningen gjelder sertifikatet Macen presenterer, plus den private nøkkelen som hører til. Velg typen som samsvarer med løvsertifikatets offentlige nøkkel, og lever identiteten via den støttede mekanismen. Hvis Macen ikke har en brukbar privat nøkkel for identiteten, kan typevalget ikke redde forbindelsen.
Administrerte profiler tar samme beslutning via IKEv2-nyttelastens CertificateType, sammen med en sertifikatreferanse som PayloadCertificateUUID. Disse feltene har forutsetninger og et skjema for mål-OS-versjonen; en naken typeverdi kopiert inn i en profil kan ikke installeres, og et innstillingsvindu viser kanskje ikke alle API-alternativer. Kontroller nyttelastens forutsetninger for den versjonen før utrulling.
Avgjør etter rolle, ikke etter sertifikatets etikett
Les feltet du er i ferd med å endre, og spør hvilket sertifikat det peker på. Etikettene i et sertifikatvindu blander subjekt, utsteder og signaturalgoritme, og bare én av dem hører til valget 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 |
Hvis sertifikatviseren viser en ECDSA-signatur fra CAen, beskriver det utstederens signeringsnøkkel. Klientens egen nøkkel kan fortsatt være RSA, og typefeltet bør følge klientnøkkelen framfor signaturlinjen. Denne ene forvekslingen forklarer mange rapporter om "ECDSA er konfigurert, men forbindelsen feiler". Sammenlign nøkkeltypen i løvet med typen som er valgt i profilen, før du endrer noe.
Beslutningen blir enklere når løvet er identifisert: ECDSA256 for en p-256-klientnøkkel, en annen støttet type for en annen nøkkel. Hvis klientsertifikatet og nøkkelen ikke samsvarer, må du rette opp paret før du endrer VPN-profilen.
Gateway-sertifikatet er en egen beslutning
Gatewayen presenterer sitt eget sertifikat, og Macen validerer det mot et tillitsanker og et forventet navn. Om sertifikatet bruker ECDSA, RSA eller en annen nøkkeltype, er en egenskap ved serveren, ikke ved innstillingen for klientidentitet.
Lokal støtte for et ECDSA-klientsertifikat beviser ikke at hvert gateway-sertifikat, hver kurve eller hver serverautentiseringskonfigurasjon vil samvirke. Kontroller serverens identitet, kjeden og IKE-autentiseringsmetoden som separate innganger, og test med profilen som faktisk skal rulles ut.
Hvis gateway-sertifikatet er problemet, oppstår symptomet vanligvis under validering av motparten, ikke ved identitetsvalget. Les feilsteget før du endrer klienttypen, fordi en tillitsfeil og et avvik i klientnøkkelen ikke deler samme løsning.
Utstederens signatur og nøkkelavtalegruppen er ikke klienttypen
X.509 holder subjektets offentlige nøkkel og utstederens signatur i forskjellige felt. Subjektets offentlige nøkkelinformasjon beskriver nøkkelen i sertifikatet; signaturalgoritmen beskriver CAens nøkkel og signeringsoperasjonen. Bare det første samsvarer med innstillingen for sertifikattype.
IKE- og Child SA-forslagene er en annen akse. En ECDSA-sertifikattype er ikke et ESP-krypteringsvalg, og endring av nøkkelavtalegruppen velger ikke en sertifikattype. En profil kan ha gyldige forslag og feil identitetstype, eller riktig identitetstype og et forslag som motparten avviser.
Hold de tre linjene atskilt i endringsloggen: identitetssertifikat og nøkkel, gatewayens tillitsinnganger og forslagenes algoritmer. Å slå dem sammen i ett notat om "kryptoinneinstillinger" gjør den neste feilen umulig å tilskrive.
Bekreft beslutningen med feltene du konfigurerte
Kontroller identiteten profilen faktisk refererer til, og bekreft deretter at sertifikatet på den referansen har forventet offentlig nøkkel og en brukbar privat nøkkel. Typen som vises i grensesnittet, det refererte sertifikatet og nøkkelen på enheten må stemme overens.
Bekreft deretter gateway-inngangene: forventet servernavn, tillitsankeret og IKE-autentiseringsmetoden. Til slutt kobler du til og leser hvor håndtrykket stopper. En feil før identitetsutvekslingen peker bort fra denne innstillingen; en feil ved validering av motparten peker mot gateway-siden.
Noter den valgte typen, identitetsreferansen og gateway-sertifikatets subjekt i utrullingsnotatene. Den neste profiloppdateringen kan endre hvilken som helst av dem, og tre navngitte verdier er raskere å sammenligne enn et skjermbilde av et innstillingspanel.