VPN-inloggning med certifikat på Mac: identitet, nyckelanvändning eller tillit till gatewayen?

VPN-inloggningar med certifikat ber Macen om något snävare än ett lösenord: använd den här specifika privata nyckeln, i den här körningskontexten, för att bevisa en identitet för den gatewayen. När det misslyckas beskriver meddelandet oftast bara det sista som gick fel, och det är sällan det som orsakade det. Att gå igenom de tre besluten i den ordning systemet fattar dem håller diagnosen ärlig och hindrar att ett lokalt behörighetsproblem behandlas som ett kedjevalideringsfel.

Gå igenom inloggningen i den ordning Macen gör det

Först väljer klienten en identitet: ett certifikat parat med en användbar privat nyckel, tillgängligt via det stödda förrådet eller leverantören av autentiseringsuppgifter. Sedan begär VPN-komponenten att en kryptografisk operation utförs med den nyckeln, och den lokala auktoriseringsmodellen svarar. Först när båda lyckas sker handskakningen på distans, där Macen utvärderar gatewayen och gatewayen utvärderar klientens bevis.

Läs tabellen uppifrån och ned och stanna vid första raden som misslyckas. Allt under ett misslyckande är obevisat, och det är därför ”certifikatet är inte betrott” är en så vanlig och så opålitlig slutsats.

Vad det lokala tillståndet faktiskt omfattar

I macOS nyckelring modell bär skyddade objekt operationsspecifika åtkomstregler och en lista över betrodda program. Signering med en privat nyckel är en av dessa operationer, och reglerna gäller för den körbara fil som utför den, inte för certifikatet som dokument. Apples referens för åtkomstkontroll drar också en gräns mellan den här modellen och iCloud-nyckelringen och upplägg med åtkomstgrupper, så råd skrivna för det ena överförs inte till det andra.

Två konsekvenser följer. Att ett offentligt certifikat syns i en lista bevisar inte att bakgrundskomponenten i VPN:en alls kan nå den nyckeln. Och ett tillstånd som ges till ett förgrundsprogram säger ingenting om en separat hjälpare eller nätverksutökning, eftersom de är annan kod med andra identiteter.

Identifiera den faktiska implementationen och dess stödda mekanism för delning av autentiseringsuppgifter i stället för att kopiera en sökväg till en körbar fil från en gammal klient. Bekräfta först vilken identitet systemet kommer att erbjuda:

security find-identity -v -p ssl-client

Att läsa errSecInteractionNotAllowed

Den statusen rapporterar otillåten interaktion med Security Server och säger ingenting om certifikatkedjor. Läs den tillsammans med operationen som producerade den: en signeringsbegäran som utfärdats från en kontext som inte kan visa en fråga misslyckas på det här sättet även när nyckeln och certifikatet båda är fullständigt giltiga. Platsen att börja på är operationen som loggade den, inte certifikatförrådet. Allt du ändrar kring tillitsankare lämnar felet precis där det var.

Behandla därför koden som en anledning att granska körningskontext och auktorisering. Att behandla den som bevis på att gatewayens CA inte är betrodd skickar dig till fel halva av problemet, och ändringen du gör där påverkar inte felet alls.

Reparera snävt, inte brett

Börja med registrerings- eller importinstruktionerna från ägaren av anslutningen. Notera klientversionen, profilens omfattning, den valda identiteten och det första relevanta lokala felet, eftersom de fyra fakta är vad en överlämning till support behöver och vad en senare jämförelse beror på. En hanterad profil eller en identitet med hårdvarustöd kan kräva att administratören eller leverantören reparerar överlämningen, och ingen mängd lokala klick ersätter det.

Där produkten förväntar sig ett användargodkännande, bekräfta vilken komponent som frågar och godkänn bara den åtkomsten genom det stödda flödet. Där komponenten inte har något sätt att resa en fråga i den kontext den körs i måste etableringen följa den väg leverantören dokumenterar, inte en dialog som lockas fram ur ett annat terminalfönster.

Två ändringar buntas ihop i äldre råd, och båda är för breda. Att ge varje program åtkomst till den privata nyckeln vidgar den lokala nyckelanvändningen långt utöver kravet, och att ställa certifikatet på Always Trust ändrar certifikatbedömningen för allt på maskinen. Ingen av dem uttrycker ”den här godkända VPN-implementationen, med den här avsedda identiteten”.

Kontrollera lokalt innan du läser gatewayen

Efter en reparation, bekräfta att den lokala operationen lyckas innan du tolkar något svar från den andra sidan. Om signeringen nu fungerar är ett senare avslag av namn, kedja eller klientupptag ett nytt resultat och inte ett återfall, och det hör till ett annat beslut med en annan ägare.

En användbar överlämning namnger vilket av de tre besluten som misslyckades och stannar där. Den innehåller aldrig den privata nyckeln, och den återställer aldrig orelaterade nyckelringsobjekt i hopp om att ett rent bord ska hjälpa. Sätt de två vanorna före incidenten och inte under den, när frestelsen att prova allt på en gång är som störst. Ett ärende som säger ”nyckelringen byggdes om” berättar nästan ingenting för nästa läsare om det ursprungliga felet.