VPN-innlogging med sertifikat på Mac: identitet, nøkkelbruk eller tillit til gatewayen?

VPN-innlogginger med sertifikat ber Macen om noe snevrere enn et passord: bruk denne bestemte private nøkkelen, i denne kjørekonteksten, for å bevise en identitet overfor den gatewayen. Når det feiler, beskriver meldingen vanligvis bare det siste som gikk galt, og det er sjelden det som forårsaket det. Å gå gjennom de tre avgjørelsene i den rekkefølgen systemet tar dem holder diagnosen ærlig, og det hindrer at et lokalt tillatelsesproblem blir behandlet som en feil i kjedevalideringen.

Gå gjennom innloggingen i den rekkefølgen Macen gjør det

Først velger klienten en identitet: et sertifikat paret med en brukbar privat nøkkel, tilgjengelig gjennom det støttede lageret eller legitimasjonsleverandøren. Deretter ber VPN-komponenten om å utføre en kryptografisk operasjon med den nøkkelen, og den lokale autorisasjonsmodellen svarer. Først når begge lykkes, skjer håndtrykket eksternt, der Macen vurderer gatewayen og gatewayen vurderer klientbeviset.

Les tabellen ovenfra og ned og stopp ved den første raden som feiler. Alt under en feil er ubevist, og det er derfor «sertifikatet er ikke betrodd» er en så vanlig og så lite pålitelig konklusjon.

Hva den lokale tillatelsen faktisk dekker

I macOS-nøkkelringmodellen har beskyttede elementer operasjonsspesifikke tilgangsregler og en liste over betrodde programmer. Signering med en privat nøkkel er en slik operasjon, og reglene gjelder for den kjørbare filen som utfører den, ikke for sertifikatet som dokument. Apples referanse for tilgangskontroll trekker også en linje mellom denne modellen og iCloud-nøkkelringen og ordninger med tilgangsgrupper, så råd skrevet for det ene overføres ikke til det andre.

To konsekvenser følger. At et offentlig sertifikat er synlig i en liste beviser ikke at bakgrunnskomponenten i VPN-en i det hele tatt kan nå den nøkkelen. Og en tillatelse gitt til et forgrunnsprogram sier ingenting om en egen hjelper eller nettverksutvidelse, fordi de er annen kode med andre identiteter.

Identifiser den faktiske implementasjonen og dens støttede mekanisme for deling av legitimasjon i stedet for å kopiere en kjørbar filbane fra en gammel klient. Bekreft først hvilken identitet systemet vil tilby:

security find-identity -v -p ssl-client

Å lese errSecInteractionNotAllowed

Den statusen rapporterer ikke tillatt samhandling med Security Server, og den sier ingenting om sertifikatkjeder. Les den sammen med operasjonen som produserte den: en signeringsforespørsel sendt fra en kontekst som ikke kan vise en forespørsel vil feile slik selv når nøkkelen og sertifikatet begge er fullstendig gyldige. Operasjonen som logget den, ikke sertifikatlageret, er stedet å begynne. Alt du endrer med tillitsankere vil la feilen bli stående nøyaktig der den var.

Så behandle koden som en grunn til å undersøke kjørekontekst og autorisasjon. Å behandle den som bevis på at gatewayens CA ikke er betrodd sender deg til den gale halvdelen av problemet, og endringen du gjør der vil ikke påvirke feilen i det hele tatt.

Reparer snevert, ikke bredt

Start med registrerings- eller importinstruksjonene til eieren av tilkoblingen. Noter klientversjonen, profilens omfang, identiteten som ble valgt og den første relevante lokale feilen, fordi de fire fakta er det en overlevering til støtte trenger og det en senere sammenligning avhenger av. En administrert profil eller en identitet med maskinvarestøtte kan kreve at administratoren eller leverandøren reparerer overleveringen, og ingen mengde lokale klikk erstatter det.

Der produktet forventer en brukergodkjenning, bekreft hvilken komponent som spør og godkjenn bare den tilgangen gjennom den støttede flyten. Der komponenten ikke har noen måte å reise en forespørsel i konteksten den kjører i, må klargjøringen følge ruten leverandøren dokumenterer, ikke en dialog lokket ut av et annet terminalvindu.

To endringer blir slått sammen i eldre råd, og begge er for brede. Å gi hvert program tilgang til den private nøkkelen utvider den lokale nøkkelbruken langt utover kravet, og å sette sertifikatet til Always Trust endrer sertifikatvurderingen for alt på maskinen. Ingen av dem uttrykker «denne godkjente VPN-implementasjonen, med denne tiltenkte identiteten».

Sjekk lokalt før du leser gatewayen

Etter en reparasjon, bekreft at den lokale operasjonen lykkes før du tolker noen respons fra den andre siden. Hvis signeringen nå virker, er en senere avvisning av navn, kjede eller klientopptak et nytt resultat og ikke en gjentakelse, og det hører til en annen avgjørelse med en annen eier.

En nyttig overlevering navngir hvilken av de tre avgjørelsene som feilet og stopper der. Den inkluderer aldri den private nøkkelen, og den tilbakestiller aldri urelaterte nøkkelringselementer i håp om at et rent bord skal hjelpe. Sett de to vanene før hendelsen og ikke under den, når fristelsen til å prøve alt på en gang er sterkest. En sak som sier «nøkkelringen er bygget på nytt» forteller neste leser nesten ingenting om den opprinnelige feilen.