Mac VPN-certificaat: waarom de identiteitskiezer leeg blijft

Je hebt het certificaat geïnstalleerd, het verschijnt in Keychain Access met een vriendelijke naam, en de identiteitskiezer van de VPN-client blijft leeg. De client zoekt geen certificaat. Hij zoekt een identiteit: een certificaat dat aan de privésleutel is gekoppeld en het bezit kan bewijzen, opgeslagen waar de client het mag lezen.

Wat de client vraagt, is een identiteit

Het beveiligingsframework van Apple behandelt een certificaat en een identiteit als verschillende objecten. Een certificaat is openbare data. Een identiteit is dat certificaat plus de privésleutel, en alleen de identiteit kan een uitdaging voltooien. Een vertrouwd CA-certificaat laat een client daarentegen een uitgever beoordelen; het maakt de machine niet de houder van een uitgegeven klantreferentie.

Daarom levert het importeren van een .cer-bestand nooit een bruikbare klantidentiteit op. Het bestand bevat alleen openbaar materiaal, en geen enkele hernoeming of vertrouwensverklaring maakt er een sleutelpaar van.

Drie redenen waarom de kiezer leeg blijft

De eerste is een ontbrekende privésleutel, wat betekent dat het registratie- of importproces er geen heeft geleverd. De tweede is een opslag die de client niet raadpleegt: een profiel met gebruikersbereik kijkt in de sleutelhanger van de gebruiker, en een item in een systeemopslag kan voor hem onzichtbaar zijn. De derde is een mismatch in doel of beleid, waarbij het certificaat bestaat maar niet geldig is voor clientauthenticatie volgens de regels van de uitrol.

security find-identity -v -p ssl-client

Dit vermeldt de identiteiten die het systeem geldig acht voor clientauthenticatie. Als het aantal nul is, ligt het probleem vóór de VPN-client en geen profielbewerking lost dat op. Als de identiteit hier wel verschijnt maar niet in de client, zit het verschil in de opslag of het bereik van de client.

Waar de privésleutel woont, en wie hem mag gebruiken

Wanneer je een identiteit via Keychain Access importeert, biedt de importdialoog een doelsleutelhanger aan. Welk doel juist is, hangt af van de client en van of het profiel een gebruikers- of apparaatbereik heeft. Een oud antwoord dat de systeemsleutelhanger aanraadt, is geen universele regel, en items tussen opslagen kopiëren is geen reparatie.

System Roots is een vertrouwensverzameling. Een certificaat daar plaatsen verandert welke uitgevers het systeem vertrouwt; het maakt geen privésleutel aan en het is geen identiteitsopslag. Onverwante certificaten verplaatsen om een kiezer te vullen is het soort reparatie dat een machine achterlaat met een permanent verbrede vertrouwensset.

Toegang tot de privésleutel is een aparte controle. Elke applicatie toestemming geven om de sleutel te gebruiken lost het selectieprobleem van één client op en geeft dezelfde mogelijkheid aan al het andere op de machine. Geef het aan de client die het nodig heeft, en controleer of de sleutel hardwaresupported is of als niet-exporteerbaar is gemarkeerd; als dat zo is, moet de ondersteunde provider worden gebruikt in plaats van een geëxporteerde kopie.

Hoe het profiel naar de referentie verwijst

In een beheerde native IKEv2-configuratie verwijst het profiel via PayloadCertificateUUID naar de referentiepayload. De identiteit waarnaar wordt verwezen en de manier waarop die is ingericht, zijn wat telt; een weergavenaam in het profiel bewerken herstelt geen verwijzing die naar de verkeerde payload of naar een payload wijst die nooit een sleutel heeft geleverd.

Een externe provider kan een heel ander selectiemechanisme gebruiken, zoals zijn eigen opslag of een systeemprompt. Lees de documentatie van die provider in plaats van aannames van native profielen over te dragen, en verifieer de verwijzing in het profiel dat daadwerkelijk is geïnstalleerd, niet in de versie in de beheerconsole.

Selectie en acceptatie zijn aparte mijlpalen

Een gevulde kiezer betekent dat de client een identiteit kan vinden en gebruiken. Het zegt niets over of de gateway die accepteert. De server controleert nog steeds de uitgever, het geldigheidsvenster, de intrekkingsstatus en de koppeling van die referentie aan een account.

Test beide fasen expliciet, in die volgorde. Bevestig dat de identiteit wordt aangeboden, maak verbinding en vraag dan de eigenaar van de gateway te bevestigen welke referentie is gepresenteerd en welke koppelingsregel die heeft gebruikt. Als de client een identiteit aanbiedt en de server die weigert, ligt het resterende werk aan de serverkant. Het certificaat opnieuw installeren op de Mac verandert dat resultaat niet, hoe vaak het ook wordt herhaald.