VPN-aanmelding met certificaat op de Mac: identiteit, sleutelgebruik of vertrouwen in de gateway?
Drie beslissingen liggen achter een aanmelding met certificaat: welke identiteit wordt gekozen, of de VPN-component zijn sleutel mag gebruiken en of de gateway vertrouwd is.
VPN-aanmeldingen met certificaat vragen de Mac iets engers dan een wachtwoord: gebruik deze specifieke persoonlijke sleutel, in deze uitvoeringscontext, om een identiteit aan die gateway te bewijzen. Als het mislukt, beschrijft de melding meestal alleen het laatste dat misging, en dat is zelden de oorzaak. De drie beslissingen in de volgorde lopen waarin het systeem ze neemt, houdt de diagnose eerlijk en voorkomt dat een lokaal rechtenprobleem als een ketenvalidatiefout wordt behandeld.
Doorloop de aanmelding in de volgorde die de Mac hanteert
Eerst kiest de client een identiteit: een certificaat met een bruikbare persoonlijke sleutel, beschikbaar via het ondersteunde archief of de referentieprovider. Daarna vraagt de VPN-component om een cryptografische bewerking met die sleutel uit te voeren, en het lokale autorisatiemodel antwoordt. Pas als beide slagen, vindt de handshake op afstand plaats, waarbij de Mac de gateway beoordeelt en de gateway het bewijs van de client.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
Lees de tabel van boven naar beneden en stop bij de eerste rij die mislukt. Alles onder een fout is onbewezen, en daarom is „het certificaat is niet vertrouwd” zo’n gangbare en zo’n onbetrouwbare conclusie.
Wat de lokale toestemming werkelijk dekt
In het sleutelhanger-model van macOS dragen beschermde items bewerkingsspecifieke toegangsregels en een lijst met vertrouwde apps. Ondertekenen met een persoonlijke sleutel is een van die bewerkingen, en de regels gelden voor het uitvoerbare bestand dat dit doet, niet voor het certificaat als document. Apples referentie over toegangsbeheer trekt ook een grens tussen dit model en de iCloud-sleutelhanger en regelingen met toegangsgroepen, dus advies dat voor het ene is geschreven, gaat niet over naar het andere.
Daaruit volgen twee gevolgen. Dat een openbaar certificaat in een lijst zichtbaar is, bewijst niet dat de achtergrondcomponent van de VPN die sleutel überhaupt kan bereiken. En toestemming voor een front-end-app zegt niets over een aparte helper of netwerkextensie, want dat is andere code met andere identiteiten.
Stel de werkelijke implementatie vast en het ondersteunde mechanisme voor het delen van referenties, in plaats van een pad naar een uitvoerbaar bestand uit een oude client te kopiëren. Bevestig eerst welke identiteit het systeem zal aanbieden:
security find-identity -v -p ssl-clienterrSecInteractionNotAllowed lezen
Die status meldt een niet-toegestane interactie met de Security Server en zegt niets over certificaatketens. Lees hem samen met de bewerking die hem veroorzaakte: een ondertekeningsverzoek uit een context die geen melding kan tonen, mislukt op deze manier zelfs wanneer de sleutel en het certificaat beide volledig geldig zijn. Het beginpunt is de bewerking die hem heeft gelogd, niet het certificaatarchief. Alles wat je aan vertrouwensankers verandert, laat de fout precies staan waar hij was.
Behandel de code dus als reden om de uitvoeringscontext en de autorisatie te onderzoeken. Hem behandelen als bewijs dat de CA van de gateway niet vertrouwd is, stuurt je naar de verkeerde helft van het probleem, en de wijziging die je daar aanbrengt, heeft helemaal geen invloed op de fout.
Repareer smal, niet breed
Begin bij de inschrijf- of importinstructies van de eigenaar van de verbinding. Noteer de clientversie, de reikwijdte van het profiel, de gekozen identiteit en de eerste relevante lokale fout, want die vier feiten heeft een overdracht aan support nodig en daar hangt een latere vergelijking van af. Een beheerd profiel of een identiteit met hardwareondersteuning kan vereisen dat de beheerder of de provider de overdracht repareert, en geen enkele hoeveelheid lokaal klikken vervangt dat.
Waar het product een goedkeuring van de gebruiker verwacht, stel vast welke component daarom vraagt en keur alleen die toegang goed via de ondersteunde stroom. Waar de component geen manier heeft om een melding op te roepen in de context waarin hij draait, moet de inrichting de route volgen die de leverancier documenteert, niet een dialoog die uit een ander terminalvenster wordt gelokt.
Twee wijzigingen worden in ouder advies samengevoegd, en beide zijn te breed. Elke app toegang geven tot de persoonlijke sleutel verbreedt het lokale sleutelgebruik ver voorbij de eis, en het certificaat op Always Trust zetten verandert de certificaatbeoordeling voor alles op de machine. Geen van beide drukt uit „deze goedgekeurde VPN-implementatie, met deze bedoelde identiteit”.
Controleer lokaal voordat je de gateway leest
Bevestig na een reparatie dat de lokale bewerking slaagt voordat je enig antwoord van de andere kant interpreteert. Als ondertekenen nu werkt, is een latere afwijzing van naam, keten of clienttoelating een nieuw resultaat en geen terugval, en die hoort bij een andere beslissing met een andere eigenaar.
Een bruikbare overdracht benoemt welke van de drie beslissingen mislukte en stopt daar. Ze bevat nooit de persoonlijke sleutel, en ze reset nooit ongerelateerde sleutelhangeritems in de hoop dat een schone lei helpt. Stel die twee gewoonten in vóór het incident en niet tijdens, wanneer de verleiding om alles tegelijk te proberen het sterkst is. Een ticket met „sleutelhanger opnieuw opgebouwd” vertelt de volgende lezer vrijwel niets over de oorspronkelijke fout.