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

VPN-innloggingar med sertifikat ber Macen om noko trongare enn eit passord: bruk denne bestemte private nøkkelen, i denne køyringskonteksten, for å prove ein identitet overfor den gatewayen. Når det sviktar, skildrar meldinga vanlegvis berre det siste som gjekk gale, og det er sjeldan det som førte til det. Å gå gjennom dei tre avgjerdene i den rekkjefølgja systemet tek dei, held diagnosen ærleg, og det hindrar at eit lokalt løyveproblem blir handsama som ein feil i valideringa av kjeda.

Gå gjennom innlogginga i den rekkjefølgja Macen gjer det

Fyrst vel klienten ein identitet: eit sertifikat para med ein brukande privat nøkkel, tilgjengeleg gjennom det støtta lageret eller legitimasjonsleverandøren. Deretter ber VPN-komponenten om å utføre ein kryptografisk operasjon med den nøkkelen, og den lokale autorisasjonsmodellen svarar. Fyrst når båe lukkast, skjer handtrykket eksternt, der Macen vurderer gatewayen og gatewayen vurderer klientbeviset.

Les tabellen ovanfrå og ned og stopp ved den fyrste rada som sviktar. Alt under ein feil er ubevist, og difor er «sertifikatet er ikkje tiltrua» ei så vanleg og så lite påliteleg slutning.

Kva det lokale løyvet faktisk dekkjer

I macOS-nøkkelringmodellen har verna element operasjonsspesifikke tilgangsreglar og ei liste over tiltrudde program. Signering med ein privat nøkkel er ein slik operasjon, og reglane gjeld for den køyrbare fila som gjer det, ikkje for sertifikatet som dokument. Apples referanse for tilgangskontroll dreg òg ei line mellom denne modellen og iCloud-nøkkelringa og ordningar med tilgangsgrupper, så råd skrivne for det eine blir ikkje overførte til det andre.

To ting følgjer av dette. At eit offentleg sertifikat er synleg i ei liste, beviser ikkje at bakgrunnskomponenten i VPN-en i det heile kan nå den nøkkelen. Og eit løyve gjeve til eit forgrunnsprogram seier ingenting om ein eigen hjelpar eller nettverksutviding, fordi dei er annan kode med andre identitetar.

Identifiser den faktiske implementasjonen og den støtta mekanismen hans for deling av legitimasjon i staden for å kopiere ei køyrbar filstig frå ein gammal klient. Stadfest fyrst kva identitet systemet vil by på:

security find-identity -v -p ssl-client

Å lese errSecInteractionNotAllowed

Den statusen rapporterer om ein ikkje-tillaten samhandel med Security Server, og han seier ingenting om sertifikatkjeder. Les han saman med operasjonen som skapte han: ein signeringsførespurnad send frå ein kontekst som ikkje kan vise ei melding, vil svikte slik jamvel når nøkkelen og sertifikatet båe er fullt gyldige. Operasjonen som logga han, ikkje sertifikatlageret, er staden å byrje. Alt du endrar med tillitsanker, vil la feilen bli ståande nøyaktig der han var.

Så handsam koden som ein grunn til å granske køyringskontekst og autorisasjon. Å handsame han som prov på at CA-en til gatewayen ikkje er tiltrua, sender deg til den gale halvdelen av problemet, og endringa du gjer der vil ikkje påverke feilen i det heile.

Reparer trongt, ikkje breitt

Byrj med registrerings- eller importinstruksjonane til eigaren av sambandet. Noter klientversjonen, omfanget av profilen, identiteten som vart vald og den fyrste relevante lokale feilen, fordi dei fire fakta er det ei overlevering til støtte treng og det ei seinare samanlikning heng på. Ein styrt profil eller ein identitet med maskinvarestøtte kan krevje at administratoren eller leverandøren reparerer overleveringa, og inga mengd lokale klikk erstattar det.

Der produktet ventar ei godkjenning frå brukaren, stadfest kva komponent som spør og godkjenn berre den tilgangen gjennom den støtta flyten. Der komponenten ikkje har nokon måte å reise ei melding i konteksten han køyrer i, må klargjeringa følgje ruta leverandøren dokumenterer, ikkje ein dialog lokka ut av eit anna terminalvindauge.

To endringar blir slegne saman i eldre råd, og båe er for breie. Å gje kvart program tilgang til den private nøkkelen utvidar den lokale nøkkelbruken langt utover kravet, og å setje sertifikatet til Always Trust endrar sertifikatvurderinga for alt på maskina. Ingen av dei uttrykkjer «denne godkjende VPN-implementasjonen, med denne tiltenkte identiteten».

Sjekk lokalt før du les gatewayen

Etter ein reparasjon, stadfest at den lokale operasjonen lukkast før du tolkar noko svar frå den andre sida. Viss signeringa no verkar, er ei seinare avvising av namn, kjede eller klientopptak eit nytt resultat og ikkje eit tilbakefall, og det høyrer til ei anna avgjerd med ein annan eigar.

Ei nyttig overlevering namngjev kva av dei tre avgjerdene som svikta og stoppar der. Ho inneheld aldri den private nøkkelen, og ho nullstiller aldri nøkkelringselement som ikkje er relaterte, i håp om at eit reint bord skal hjelpe. Set dei to vanane før hendinga og ikkje under henne, når freistinga til å prøve alt på ein gong er sterkast. Ei sak som seier «nøkkelringa er bygd opp att» fortel neste lesar nesten ingenting om den opphavlege feilen.