Mac VPN-sertifikat: hvorfor identitetsvelgeren forblir tom
Klienten trenger et sertifikat med sin private nøkkel, i et lager den leser. Sjekk identiteten først, deretter om gatewayen godtar den.
Du installerte sertifikatet, det vises i Keychain Access med et vennlig navn, og identitetsvelgeren til VPN-klienten er fortsatt tom. Klienten leter ikke etter et sertifikat. Den leter etter en identitet: et sertifikat koblet til den private nøkkelen som kan bevise eierskap, lagret der klienten har lov til å lese det.
Det klienten ber om, er en identitet
Apples sikkerhetsrammeverk behandler et sertifikat og en identitet som forskjellige objekter. Et sertifikat er offentlige data. En identitet er det sertifikatet pluss den private nøkkelen, og bare identiteten kan fullføre en utfordring. Et klarert CA-sertifikat lar på sin side en klient vurdere en utsteder; det gjør ikke maskinen til innehaver av en utstedt klientlegitimasjon.
| Item | What it can do | What it cannot do |
|---|---|---|
| CA or server certificate | Validate the gateway's chain | Authenticate this client |
| Client certificate without key | Nothing for authentication | Prove possession of anything |
| Identity (cert plus key) | Answer the authentication challenge | Guarantee the gateway accepts it |
Derfor gir import av en .cer-fil aldri en brukbar klientidentitet. Filen inneholder bare offentlig materiale, og ingen omdøping eller tillit gjør den til et nøkkelpar.
Tre grunner til at velgeren forblir tom
Den første er en manglende privat nøkkel, som betyr at registrerings- eller importprosessen ikke leverte en. Den andre er et lager klienten ikke undersøker: en profil med brukeromfang ser i brukerens nøkkelring, og et element plassert i et systemlager kan være usynlig for den. Den tredje er et misforhold i formål eller policy, der sertifikatet finnes, men ikke er gyldig for klientautentisering etter distribusjonens regler.
security find-identity -v -p ssl-clientDette lister identitetene systemet anser som gyldige for klientautentisering. Hvis antallet er null, ligger problemet før VPN-klienten, og ingen profilendring vil rette det. Hvis identiteten vises her men ikke i klienten, er forskjellen lageret eller omfanget til klienten.
Hvor den private nøkkelen bor, og hvem som kan bruke den
Når du importerer en identitet via Keychain Access, tilbyr importdialogen en målnøkkelring. Hvilket mål som er riktig avhenger av klienten og av om profilen har bruker- eller enhetsomfang. Et gammelt svar som anbefaler systemnøkkelringen er ikke en universell regel, og kopiering av elementer mellom lagre er ikke en reparasjon.
System Roots er en tillitssamling. Å sette et sertifikat der endrer hvilke utstedere systemet stoler på; det oppretter ikke en privat nøkkel, og det er ikke et identitetslager. Å flytte urelaterte sertifikater rundt for å fylle en velger er den typen rettelse som etterlater en maskin med et permanent utvidet tillitssett.
Tilgang til den private nøkkelen er en egen kontroll. Å gi hver applikasjon tillatelse til å bruke nøkkelen løser valgproblemet til én klient og gir den samme evnen til alt annet på maskinen. Gi den til klienten som trenger den, og sjekk om nøkkelen er maskinvarebasert eller merket ikke-eksporterbar; hvis den er det, må den støttede leverandøren brukes i stedet for en eksportert kopi.
Hvordan profilen peker på legitimasjonen
I en administrert innebygd IKEv2-konfigurasjon refererer profilen til sin legitimasjonsnyttelast via PayloadCertificateUUID. Det er identiteten som refereres og måten den ble klargjort på som betyr noe; å redigere et visningsnavn i profilen reparerer ikke en referanse som peker på feil nyttelast eller på en som aldri leverte en nøkkel.
En tredjepartsleverandør kan bruke en helt annen valgmekanisme, som sitt eget lager eller en systemforespørsel. Les dokumentasjonen til den leverandøren i stedet for å overføre antakelser fra innebygde profiler, og verifiser referansen i profilen som faktisk er installert, ikke i utkastet i administrasjonskonsollen.
Valg og aksept er separate milepæler
En fylt velger betyr at klienten kan finne og bruke en identitet. Det sier ingenting om hvorvidt gatewayen godtar den. Serveren sjekker fortsatt utstederen, gyldighetsvinduet, tilbaketrekkingsstatusen og koblingen fra den legitimasjonen til en konto.
Test begge stadiene eksplisitt, i den rekkefølgen. Bekreft at identiteten tilbys, koble til, og be deretter eieren av gatewayen bekrefte hvilken legitimasjon som ble presentert og hvilken koblingsregel som brukte den. Hvis klienten tilbyr en identitet og serveren avviser den, ligger det resterende arbeidet på serversiden. Å installere sertifikatet på nytt på Macen vil ikke endre det resultatet, uansett hvor mange ganger det gjentas.