Mac IKEv2 ECDSA: welk certificaattype hoort bij de client?

Op macOS beantwoordt de ECDSA-keuze in een IKEv2-clientinstelling een smalle vraag: welk certificaat bewijst de identiteit van de Mac. Het beschrijft niet het gatewaycertificaat, de handtekening die het clientcertificaat heeft uitgegeven, of het versleutelingsvoorstel voor de tunnel. Die vier rollen als één compatibiliteitsvraag behandelen is de manier waarop een correcte lokale instelling de schuld krijgt van een afwijking aan de serverkant. De beslissing is klein, maar het bewijs dat ervoor wordt gebruikt moet precies zijn.

Het veld benoemt één certificaat: de lokale identiteit

De Network Extension API van Apple biedt een certificaattype voor de clientreferentie, waaronder NEVPNIKEv2CertificateType.ECDSA256, gedocumenteerd als het certificaattype ECDSA p-256. De eigenschap geldt voor het certificaat dat via identityReference of identityData wordt geleverd.

Dat betekent dat de beslissing gaat over het certificaat dat de Mac presenteert, plus de bijbehorende persoonlijke sleutel. Kies het type dat past bij de openbare sleutel van dat bladcertificaat en lever de identiteit via het ondersteunde mechanisme. Als de Mac geen bruikbare persoonlijke sleutel voor de identiteit heeft, kan de typekeuze de verbinding niet redden.

Beheerde profielen nemen dezelfde beslissing via CertificateType van de IKEv2-payload, samen met een certificaatverwijzing zoals PayloadCertificateUUID. Die velden hebben voorwaarden en een schema voor de doelversie van het besturingssysteem; een kale typewaarde die in een profiel wordt gekopieerd is niet installeerbaar, en een instellingenvenster toont mogelijk niet elke API-optie. Controleer de voorwaarden van de payload voor die versie vóór de uitrol.

Beslis op rol, niet op het label van het certificaat

Lees het veld dat u gaat wijzigen en vraag op welk certificaat het wijst. De labels in een certificaatviewer mengen het onderwerp, de uitgever en het handtekeningalgoritme, en slechts één daarvan hoort bij de keuze van de clientidentiteit.

Als de certificaatviewer een ECDSA-handtekening van de CA toont, beschrijft dat de ondertekeningssleutel van de uitgever. De eigen sleutel van de client kan nog steeds RSA zijn, en het typeveld moet de clientsleutel volgen, niet de handtekeningsregel. Deze ene verwarring verklaart veel meldingen van "ECDSA is ingesteld, maar de verbinding mislukt". Vergelijk het sleuteltype in het blad met het type dat in het profiel is gekozen voordat u iets wijzigt.

De beslissing wordt eenvoudiger zodra het blad is geïdentificeerd: ECDSA256 voor een p-256-clientsleutel, een ander ondersteund type voor een andere sleutel. Als het clientcertificaat en de sleutel niet bij elkaar passen, herstel dat paar voordat u het VPN-profiel wijzigt.

Het gatewaycertificaat is een aparte beslissing

De gateway presenteert zijn eigen certificaat en de Mac valideert het tegen een vertrouwensanker en een verwachte naam. Of dat certificaat ECDSA, RSA of een ander sleuteltype gebruikt, is een eigenschap van de server, niet van de instelling voor clientidentiteit.

Lokale ondersteuning voor een ECDSA-clientcertificaat bewijst niet dat elk gatewaycertificaat, elke curve of elke serverauthenticatieconfiguratie zal samenwerken. Controleer de identiteit van de server, de keten en de IKE-authenticatiemethode als afzonderlijke invoer, en test met het profiel dat werkelijk wordt uitgerold.

Als het gatewaycertificaat het probleem is, verschijnt het symptoom meestal tijdens de validatie van de peer en niet bij de identiteitskeuze. Lees de faalfase voordat u het clienttype wijzigt, want een vertrouwensfout en een afwijking in de clientsleutel delen niet dezelfde oplossing.

De handtekening van de uitgever en de sleutelovereenkomtgroep zijn niet het clienttype

X.509 houdt de openbare sleutel van het onderwerp en de handtekening van de uitgever in verschillende velden. De openbare-sleutelinformatie van het onderwerp beschrijft de sleutel in het certificaat; het handtekeningalgoritme beschrijft de sleutel van de CA en de ondertekeningsbewerking. Alleen het eerste past bij de instelling voor het certificaattype.

De IKE- en Child SA-voorstellen zijn een andere as. Een ECDSA-certificaattype is geen ESP-versleutelingskeuze, en het wijzigen van de sleutelovereenkomstgroep selecteert geen certificaattype. Een profiel kan geldige voorstellen en het verkeerde identiteitstype hebben, of het juiste identiteitstype en een voorstel dat de peer weigert.

Houd de drie regels gescheiden in het wijzigingslogboek: identiteitscertificaat en sleutel, vertrouwensinvoer van de gateway en algoritmen van de voorstellen. Ze samenvoegen in één notitie over "cryptinstellingen" maakt de volgende fout niet meer toe te schrijven.

Controleer de beslissing met de velden die u hebt ingesteld

Controleer de identiteit waarnaar het profiel werkelijk verwijst, en bevestig dan dat het certificaat bij die verwijzing de verwachte openbare sleutel en een bruikbare persoonlijke sleutel heeft. Het getoonde type in de interface, het gerefereerde certificaat en de sleutel op het apparaat moeten overeenkomen.

Bevestig daarna de invoer van de gateway: de verwachte servernaam, het vertrouwensanker en de IKE-authenticatiemethode. Maak ten slotte verbinding en lees waar de handshake stopt. Een fout vóór de identiteitsuitwisseling wijst weg van deze instelling; een fout bij de validatie van de peer wijst naar de gatewaykant.

Noteer het gekozen type, de identiteitsverwijzing en het onderwerp van het gatewaycertificaat in de uitrolnotities. De volgende profielupdate kan elk daarvan wijzigen, en drie benoemde waarden zijn sneller te vergelijken dan een schermafbeelding van een instellingenpaneel.