Mac IKEv2 ECDSA: hvilken certificattype hører til klienten?
På en Mac beskriver ECDSA256 i IKEv2-indstillingerne det lokale identitetscertifikat, ikke gatewayen eller udstederens signatur. Læs hver rolle, før du vælger.
På macOS besvarer ECDSA-valget i en IKEv2-klientindstilling et snævert spørgsmål: hvilket certifikat beviser Mac'ens identitet. Det beskriver ikke gateway-certifikatet, signaturen der udstedte klientcertifikatet, eller krypteringsforslaget til tunnelen. At behandle de fire roller som ét kompatibilitetsspørgsmål er måden, hvorpå en korrekt lokal indstilling bliver bebrejdet en uoverensstemmelse på serversiden. Beslutningen er lille, men de beviser, der bruges til at træffe den, skal være præcise.
Feltet navngiver ét certifikat: den lokale identitet
Apples Network Extension API eksponerer en certifikattype til klientens legitimationsoplysninger, herunder NEVPNIKEv2CertificateType.ECDSA256, dokumenteret som certifikattypen ECDSA p-256. Egenskaben gælder for det certifikat, der leveres via identityReference eller identityData.
Det betyder, at beslutningen handler om det certifikat, Mac'en præsenterer, plus den private nøgle, der hører til. Vælg den type, der matcher dette løvcertifikats offentlige nøgle, og lever identiteten via den understøttede mekanisme. Hvis Mac'en ikke har en brugbar privat nøgle til identiteten, kan typevalget ikke redde forbindelsen.
Administrerede profiler træffer samme beslutning via IKEv2-nyttelastens CertificateType, parret med en certifikatreference som PayloadCertificateUUID. Disse felter har forudsætninger og et skema til mål-OS-versionen; en nøgen typeværdi kopieret ind i en profil kan ikke installeres, og et indstillingsvindue viser måske ikke alle API-muligheder. Kontroller nyttelastens forudsætninger for den version, før du udruller.
Beslut efter rolle, ikke efter certifikatets etiket
Læs det felt, du er ved at ændre, og spørg, hvilket certifikat det peger på. Etiketterne i en certifikatvisning blander emnet, udstederen og signaturalgoritmen, og kun én af dem hører til valget af 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 certifikatvisningen viser en ECDSA-signatur fra CA'en, beskriver det udstederens signeringsnøgle. Klientens egen nøgle kan stadig være RSA, og typefeltet bør følge klientnøglen frem for signaturlinjen. Denne ene forveksling forklarer mange rapporter om "ECDSA er konfigureret, men forbindelsen fejler". Sammenlign nøgletypen i løvet med den type, der er valgt i profilen, før du ændrer noget.
Beslutningen bliver enklere, når løvet er identificeret: ECDSA256 til en p-256-klientnøgle, en anden understøttet type til en anden nøgle. Hvis klientcertifikatet og dets nøgle ikke matcher, så ret det par, før du ændrer VPN-profilen.
Gateway-certifikatet er en særskilt beslutning
Gatewayen præsenterer sit eget certifikat, og Mac'en validerer det mod et tillidsanker og et forventet navn. Om det certifikat bruger ECDSA, RSA eller en anden nøgletype, er en egenskab ved serveren, ikke ved indstillingen for klientidentitet.
Lokal understøttelse af et ECDSA-klientcertifikat beviser ikke, at ethvert gateway-certifikat, enhver kurve eller servergodkendelseskonfiguration vil fungere sammen. Kontroller serverens identitet, dens kæde og dens IKE-godkendelsesmetode som separate input, og test med den profil, der faktisk udrulles.
Hvis gateway-certifikatet er problemet, opstår symptomet normalt under validering af modparten snarere end ved identitetsvalget. Læs fejlstadiet, før du ændrer klienttypen, fordi en tillidsfejl og en uoverensstemmelse i klientnøglen ikke har samme løsning.
Udstederens signatur og nøgleaftalegruppen er ikke klienttypen
X.509 holder emnets offentlige nøgle og udstederens signatur i forskellige felter. Emnets offentlige nøgleinformation beskriver nøglen i certifikatet; signaturalgoritmen beskriver CA'ens nøgle og signeringsoperation. Kun det første matcher indstillingen for certifikattype.
IKE- og Child SA-forslagene er en anden akse. En ECDSA-certifikattype er ikke et ESP-krypteringsvalg, og ændring af nøgleaftalegruppen vælger ikke en certifikattype. En profil kan have gyldige forslag og den forkerte identitetstype, eller den rigtige identitetstype og et forslag, som modparten afviser.
Hold de tre linjer adskilt i ændringsloggen: identitetscertifikat og nøgle, gatewayens tillidsinput og forslagsalgoritmer. At slå dem sammen i én note om "kryptoindstillinger" gør den næste fejl umulig at tilskrive.
Bekræft beslutningen med de felter, du har konfigureret
Kontroller den identitet, profilen faktisk refererer til, og bekræft derefter, at certifikatet på den reference har den forventede offentlige nøgle og en brugbar privat nøgle. Den viste type i brugerfladen, det refererede certifikat og nøglen på enheden skal stemme overens.
Bekræft derefter gateway-inputtet: det forventede servernavn, tillidsankeret og IKE-godkendelsesmetoden. Til sidst skal du oprette forbindelse og læse, hvor håndtrykket stopper. En fejl før identitetsudvekslingen peger væk fra denne indstilling; en fejl ved validering af modparten peger mod gateway-siden.
Notér den valgte type, identitetsreferencen og gateway-certifikatets emne i udrulningsnotaterne. Den næste profilopdatering kan ændre enhver af dem, og tre navngivne værdier er hurtigere at sammenligne end et skærmbillede af et indstillingspanel.