Du installerede certifikatet, det vises i Keychain Access med et venligt navn, og VPN-klientens identitetsvælger er stadig tom. Klienten leder ikke efter et certifikat. Den leder efter en identitet: et certifikat parret med den private nøgle, der kan bevise besiddelse, gemt hvor klienten har tilladelse til at læse.

Det, klienten beder om, er en identitet

Apples sikkerhedsrammeværk behandler et certifikat og en identitet som forskellige objekter. Et certifikat er offentlige data. En identitet er det certifikat plus dets private nøgle, og kun identiteten kan gennemføre en udfordring. Et betroet CA-certifikat lader derimod en klient vurdere en udsteder; det gør ikke maskinen til indehaver af en udstedt klientlegitimation.

ItemWhat it can doWhat it cannot do
CA or server certificateValidate the gateway's chainAuthenticate this client
Client certificate without keyNothing for authenticationProve possession of anything
Identity (cert plus key)Answer the authentication challengeGuarantee the gateway accepts it

Derfor giver import af en .cer fil aldrig en brugbar klientidentitet. Filen indeholder kun offentligt materiale, og ingen omdøbning eller tillid gør den til et nøglepar.

Tre grunde til, at vælgeren forbliver tom

Den første er en manglende privat nøgle, hvilket betyder, at registrerings- eller importprocessen ikke leverede en. Den anden er et lager, som klienten ikke konsulterer: en brugerbaseret profil kigger i brugerens nøglering, og et element, der er placeret i et systemlager, kan være usynligt for den. Den tredje er en uoverensstemmelse i formål eller politik, hvor certifikatet findes, men ikke er gyldigt til klientgodkendelse under implementeringens regler.

security find-identity -v -p ssl-client

Dette viser de identiteter, som systemet anser for gyldige til klientgodkendelse. Hvis antallet er nul, ligger problemet oven for VPN-klienten, og ingen profilredigering vil løse det. Hvis identiteten vises her, men ikke i klienten, er forskellen klientens lager eller omfang.

Hvor den private nøgle bor, og hvem der må bruge den

Når du importerer en identitet via Keychain Access, tilbyder importdialogen en målnøglering. Hvilken destination der er korrekt, afhænger af klienten og af, om profilen er bruger- eller enhedsbaseret. Et gammelt svar, der anbefaler systemnøgleringen, er ikke en universel regel, og at kopiere elementer mellem lagre er ikke en reparation.

System Roots er en tillidssamling. At lægge et certifikat der ændrer, hvilke udstedere systemet har tillid til; det opretter ikke en privat nøgle, og det er ikke et identitetslager. At flytte urelaterede certifikater rundt for at fylde en vælger er den slags reparation, der efterlader en maskine med et permanent udvidet tillidssæt.

Adgang til den private nøgle er en separat kontrol. At give hver applikation tilladelse til at bruge nøglen løser én klients udvalgsproblem og giver den samme mulighed til alt andet på maskinen. Giv den til den klient, der har brug for den, og kontroller, om nøglen er hardwarebaseret eller markeret som ikke-eksporterbar; hvis den er det, skal den understøttede udbyder bruges i stedet for en eksporteret kopi.

Hvordan profilen peger på legitimationsoplysningen

I en administreret oprindelig IKEv2-konfiguration refererer profilen til sin legitimationsnyttelast gennem PayloadCertificateUUID. Det er den refererede identitet og måden, den blev klargjort på, der betyder noget; at redigere et visningsnavn i profilen reparerer ikke en reference, der peger på den forkerte nyttelast eller på en, der aldrig leverede en nøgle.

En tredjepartsudbyder kan bruge en helt anden udvælgelsesmekanisme, såsom sit eget lager eller en systemprompt. Læs den udbyders dokumentation i stedet for at overføre antagelser om den oprindelige profil, og bekræft referencen i den profil, der faktisk er installeret, frem for i kladden i administrationskonsollen.

Udvalg og accept er separate milepæle

En fyldt vælger betyder, at klienten kan finde og bruge en identitet. Det siger intet om, hvorvidt gatewayen accepterer den. Serveren kontrollerer stadig udstederen, gyldighedsvinduet, tilbagekaldelsesstatus og tilknytningen af den legitimationsoplysning til en konto.

Test begge faser eksplicit, i den rækkefølge. Bekræft, at identiteten tilbydes, opret forbindelse, og lad derefter gatewayens ejer bekræfte, hvilken legitimationsoplysning der blev præsenteret, og hvilken tilknytningsregel der forbrugte den. Hvis klienten tilbyder en identitet, og serveren afviser den, er det resterende arbejde på serversiden. Geninstallation af certifikatet på Macen ændrer ikke det resultat, uanset hvor mange gange det gentages.

Relaterede artikler