Mac VPN-certifikat: varför identitetsväljaren förblir tom
Klienten behöver ett certifikat med sin privata nyckel, i ett arkiv som den läser. Kontrollera identiteten först och sedan om gatewayen accepterar den.
Du installerade certifikatet, det visas i Keychain Access med ett vänligt namn, och identitetsväljaren i VPN-klienten är fortfarande tom. Klienten söker inte ett certifikat. Den söker en identitet: ett certifikat kopplat till den privata nyckeln som kan bevisa innehav, lagrat där klienten får läsa det.
Det klienten begär är en identitet
Apples säkerhetsramverk behandlar ett certifikat och en identitet som olika objekt. Ett certifikat är offentliga data. En identitet är det certifikatet plus dess privata nyckel, och bara identiteten kan slutföra en utmaning. Ett betrott CA-certifikat låter däremot en klient utvärdera en utfärdare; det gör inte maskinen till innehavare av en utfärdad klientlegitimation.
| 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 |
Därför ger import av en .cer-fil aldrig en användbar klientidentitet. Filen innehåller bara offentligt material, och ingen namnändring eller tillit gör den till ett nyckelpar.
Tre skäl till att väljaren förblir tom
Det första är en saknad privat nyckel, vilket betyder att registrerings- eller importprocessen inte levererade någon. Det andra är ett arkiv som klienten inte undersöker: en profil med användaromfång tittar i användarens nyckelring, och ett objekt i ett systemarkiv kan vara osynligt för den. Det tredje är en bristande överensstämmelse i syfte eller policy, där certifikatet finns men inte är giltigt för klientautentisering enligt distributionens regler.
security find-identity -v -p ssl-clientDetta listar de identiteter som systemet anser giltiga för klientautentisering. Om antalet är noll ligger problemet före VPN-klienten och ingen profiländring åtgärdar det. Om identiteten visas här men inte i klienten är skillnaden arkivet eller klientens omfång.
Var den privata nyckeln bor och vem som får använda den
När du importerar en identitet via Keychain Access erbjuder importdialogen en målnyckelring. Vilket mål som är rätt beror på klienten och på om profilen har användar- eller enhetsomfång. Ett gammalt svar som rekommenderar systemnyckelringen är ingen universell regel, och kopiering av objekt mellan arkiv är ingen reparation.
System Roots är en tillitssamling. Att placera ett certifikat där ändrar vilka utfärdare systemet litar på; det skapar ingen privat nyckel och är inget identitetsarkiv. Att flytta orelaterade certifikat för att fylla en väljare är den typ av åtgärd som lämnar en maskin med en permanent utökad tillitsmängd.
Åtkomst till den privata nyckeln är en separat kontroll. Att ge varje program tillstånd att använda nyckeln löser valproblemet för en klient och ger samma förmåga till allt annat på maskinen. Ge den till klienten som behöver den, och kontrollera om nyckeln är hårdvarubaserad eller markerad som icke-exporterbar; om så är fallet måste den supporterade leverantören användas i stället för en exporterad kopia.
Hur profilen pekar på legitimationen
I en hanterad inbyggd IKEv2-konfiguration refererar profilen till sin legitimationsnyttolast via PayloadCertificateUUID. Det är identiteten som refereras och sättet den tillhandahölls på som spelar roll; att redigera ett visningsnamn i profilen reparerar inte en referens som pekar på fel nyttolast eller på en som aldrig levererade en nyckel.
En tredjepartsleverantör kan använda en helt annan urvalsmekanism, som sitt eget arkiv eller en systemförfrågan. Läs den leverantörens dokumentation i stället för att föra över antaganden från inbyggda profiler, och verifiera referensen i profilen som faktiskt är installerad, inte i utkastet i administratörskonsolen.
Val och accepterande är separata milstolpar
En fylld väljare betyder att klienten kan hitta och använda en identitet. Det säger ingenting om gatewayen accepterar den. Servern kontrollerar fortfarande utfärdaren, giltighetsfönstret, återkallningsstatusen och mappningen från den legitimationen till ett konto.
Testa båda stegen uttryckligen, i den ordningen. Bekräfta att identiteten erbjuds, anslut och be sedan gatewayens ägare bekräfta vilken legitimation som presenterades och vilken mappningsregel som använde den. Om klienten erbjuder en identitet och servern avvisar den ligger det återstående arbetet på serversidan. Att installera om certifikatet på Macen ändrar inte det resultatet, hur många gånger det än upprepas.