Mac IKEv2 ECDSA: vilken certifikattyp hör till klienten?
På en Mac beskriver ECDSA256 i IKEv2-inställningarna det lokala identitetscertifikatet, inte gatewayen eller utgivarens signatur. Läs varje roll innan du väljer.
På macOS besvarar ECDSA-valet i en IKEv2-klientinställning en smal fråga: vilket certifikat bevisar Macens identitet. Det beskriver inte gateway-certifikatet, signaturen som utfärdade klientcertifikatet eller krypteringsförslaget för tunneln. Att behandla dessa fyra roller som en enda kompatibilitetsfråga är hur en korrekt lokal inställning får skulden för en avvikelse på serversidan. Beslutet är litet, men bevisen som används för att fatta det måste vara exakta.
Fältet namnger ett certifikat: den lokala identiteten
Apples Network Extension API exponerar en certifikattyp för klientens autentiseringsuppgift, inklusive NEVPNIKEv2CertificateType.ECDSA256, dokumenterad som certifikattypen ECDSA p-256. Egenskapen gäller certifikatet som levereras via identityReference eller identityData.
Det betyder att beslutet gäller certifikatet som Macen presenterar, plus den privata nyckel som hör till. Välj den typ som matchar löv certifikatets publika nyckel och leverera identiteten via den stödda mekanismen. Om Macen inte har en användbar privat nyckel för identiteten kan typvalet inte rädda anslutningen.
Hanterade profiler fattar samma beslut via IKEv2-nyttolastens CertificateType, tillsammans med en certifikatreferens som PayloadCertificateUUID. Dessa fält har förutsättningar och ett schema för mål-OS-versionen; ett naket typvärde som kopieras in i en profil går inte att installera, och ett inställningsfönster kanske inte visar alla API-alternativ. Kontrollera nyttolastens förutsättningar för den versionen före utrullning.
Avgör efter roll, inte efter certifikatets etikett
Läs fältet du ska ändra och fråga vilket certifikat det pekar på. Etiketterna i en certifikatvisare blandar subjekt, utgivare och signaturalgoritm, och bara en av dem hör till 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 |
Om certifikatvisaren visar en ECDSA-signatur från CA:n beskriver det utgivarens signeringsnyckel. Klientens egen nyckel kan fortfarande vara RSA, och typfältet bör följa klientnyckeln snarare än signaturraden. Denna enda förväxling förklarar många rapporter om "ECDSA är konfigurerat men anslutningen misslyckas". Jämför nyckeltypen i lövet med typen som valts i profilen innan du ändrar något.
Beslutet blir enklare när lövet är identifierat: ECDSA256 för en p-256-klientnyckel, en annan stödd typ för en annan nyckel. Om klientcertifikatet och dess nyckel inte matchar, åtgärda paret innan du ändrar VPN-profilen.
Gateway-certifikatet är ett eget beslut
Gatewayen presenterar sitt eget certifikat och Macen validerar det mot ett förtroendeankare och ett förväntat namn. Om certifikatet använder ECDSA, RSA eller en annan nyckeltyp är en egenskap hos servern, inte hos inställningen för klientidentitet.
Lokalt stöd för ett ECDSA-klientcertifikat bevisar inte att varje gateway-certifikat, kurva eller serverautentiseringskonfiguration kommer att samverka. Kontrollera serverns identitet, dess kedja och dess IKE-autentiseringsmetod som separata indata, och testa med profilen som faktiskt ska rullas ut.
Om gateway-certifikatet är problemet, visar sig symtomet oftast vid validering av motparten och inte vid identitetsvalet. Läs felsteget innan du ändrar klienttypen, eftersom ett förtroendefel och en avvikelse i klientnyckeln inte delar samma åtgärd.
Utgivarens signatur och nyckelavtalsgruppen är inte klienttypen
X.509 håller subjektets publika nyckel och utgivarens signatur i olika fält. Subjektets publika nyckelinformation beskriver nyckeln i certifikatet; signaturalgoritmen beskriver CA:ns nyckel och signeringsoperationen. Bara det första matchar inställningen för certifikattyp.
IKE- och Child SA-förslagen är en annan axel. En ECDSA-certifikattyp är inte ett ESP-krypteringsval, och att ändra nyckelavtalsgruppen väljer inte en certifikattyp. En profil kan ha giltiga förslag och fel identitetstyp, eller rätt identitetstyp och ett förslag som motparten avvisar.
Håll de tre raderna åtskilda i ändringsloggen: identitetscertifikat och nyckel, gatewayens förtroendeindata och förslagens algoritmer. Att slå ihop dem i en anteckning om "kryptoinställningar" gör nästa fel omöjligt att tillskriva.
Verifiera beslutet med fälten du konfigurerade
Kontrollera identiteten som profilen faktiskt refererar till, och bekräfta sedan att certifikatet på den referensen har den förväntade publika nyckeln och en användbar privat nyckel. Typen som visas i gränssnittet, det refererade certifikatet och nyckeln på enheten måste stämma överens.
Bekräfta sedan gatewayens indata: det förväntade servernamnet, förtroendeankaret och IKE-autentiseringsmetoden. Anslut till sist och läs var handskakningen stannar. Ett fel före identitetsutbytet pekar bort från denna inställning; ett fel vid validering av motparten pekar mot gateway-sidan.
Anteckna den valda typen, identitetsreferensen och gateway-certifikatets subjekt i utrullningsanteckningarna. Nästa profiluppdatering kan ändra vilken som helst av dem, och tre namngivna värden är snabbare att jämföra än en skärmbild av en inställningspanel.