Mac-VPN-sertifikaataanmelding: identiteit, sleutelgebruik of poortvertroue?
Drie besluite sit agter 'n sertifikaataanmelding: watter identiteit gekies word, of die VPN-komponent sy sleutel mag gebruik, en of die poort vertrou word.
Sertifikaatgebaseerde VPN-aanmeldings vra die Mac om iets nouer as 'n wagwoord: gebruik hierdie spesifieke private sleutel, in hierdie uitvoeringskonteks, om 'n identiteit aan daardie poort te bewys. Wanneer dit misluk, beskryf die boodskap gewoonlik net die laaste ding wat verkeerd geloop het, wat selde die ding is wat dit veroorsaak het. Om die drie besluite te volg in die volgorde waarin die stelsel hulle neem, hou die diagnose eerlik, en dit verhoed dat 'n plaaslike toestemmingsprobleem as 'n kettingvalideringsfout behandel word.
Volg die aanmelding in die volgorde wat die Mac gebruik
Eers kies die kliënt 'n identiteit: 'n sertifikaat wat met 'n bruikbare private sleutel gepaar is, beskikbaar deur die ondersteunde stoor of geloofwaardigheidsverskaffer. Dan vra die VPN-komponent om 'n kriptografiese bewerking met daardie sleutel uit te voer, en die plaaslike magtigingsmodel antwoord. Eers nadat albei slaag, vind die afgeleë handdruk plaas, waar die Mac die poort evalueer en die poort die kliënt se bewys evalueer.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
Lees die tabel van bo na onder en stop by die eerste ry wat misluk. Alles onder 'n mislukking is onbewys, en daarom is “die sertifikaat is nie vertrou nie” so 'n algemene en so 'n onbetroubare gevolgtrekking.
Wat die plaaslike toestemming werklik dek
In die macOS-sleutelringmodel dra beskermde items bewerking-spesifieke toegangsreëls en 'n lys vertroude programme. Om met 'n private sleutel te onderteken is een van daardie bewerkings, en die reëls geld vir die uitvoerbare lêer wat dit doen, nie vir die sertifikaat as dokument nie. Apple se verwysing vir toegangsbeheer trek ook 'n grens tussen hierdie model en die iCloud-sleutelring en toegangsgroepreëlings, so advies wat vir die een geskryf is, dra nie oor na die ander nie.
Twee gevolge volg. Dat 'n openbare sertifikaat in 'n lys sigbaar is, bewys nie dat die VPN se agtergrondkomponent daardie sleutel hoegenaamd kan bereik nie. En toestemming wat aan 'n front-end-toepassing gegee is, sê niks oor 'n aparte helper of netwerkuitbreiding nie, want hulle is verskillende kode met verskillende identiteite.
Identifiseer die werklike implementering en sy ondersteunde meganisme vir die deel van geloofwaardighede, eerder as om 'n uitvoerbare pad uit 'n ou kliënt te kopieer. Bevestig watter identiteit die stelsel in die eerste plek sal bied:
security find-identity -v -p ssl-clientLees van errSecInteractionNotAllowed
Daardie status rapporteer verbode interaksie met die Security Server, en dit sê niks oor sertifikaatkettings nie. Lees dit saam met die bewerking wat dit veroorsaak het: 'n ondertekenversoek wat uit 'n konteks kom wat nie 'n opdrag kan vertoon nie, sal op hierdie manier misluk, selfs wanneer die sleutel en die sertifikaat albei heeltemal geldig is. Die bewerking wat dit aangeteken het, nie die sertifikaatstoor nie, is die plek om te begin. Enigiets wat jy aan vertrouensankers verander, sal die fout presies laat waar dit was.
Behandel dus die kode as 'n rede om die uitvoeringskonteks en magtiging te ondersoek. Om dit as bewys te behandel dat die poort se CA nie vertrou word nie, stuur jou na die verkeerde helfte van die probleem, en die verandering wat jy daar maak, sal die fout hoegenaamd nie beïnvloed nie.
Herstel eng, nie breed nie
Begin met die verbindingseienaar se inskrywings- of invoerinstruksies. Teken die kliëntweergawe, die profielomvang, die identiteit wat gekies is en die eerste relevante plaaslike fout aan, want daardie vier feite is wat 'n ondersteuningsoorhandiging nodig het en waarvan 'n latere vergelyking afhang. 'n Bestuurde profiel of 'n hardewaregesteunde identiteit kan vereis dat die administrateur of die verskaffer die oorhandiging herstel, en geen hoeveelheid plaaslike klikwerk vervang dit nie.
Waar die produk 'n gebruiker se goedkeuring verwag, bevestig watter komponent vra en keur slegs daardie toegang deur die ondersteunde vloei goed. Waar die komponent geen manier het om 'n opdrag in die konteks waarin dit loop te laat ontstaan nie, moet die voorsiening die roete volg wat die verskaffer dokumenteer, nie 'n dialoog wat uit een of ander ander terminaalvenster gelok is nie.
Twee veranderinge word in ouer advies saamgevoeg, en albei is te breed. Om elke toepassing toegang tot die private sleutel te gee, verbreed plaaslike sleutelgebruik ver verby die vereiste, en om die sertifikaat op Always Trust te stel, verander sertifikaatevaluering vir alles op die masjien. Nie een van dié twee druk “hierdie goedgekeurde VPN-implementering, met hierdie beoogde identiteit” uit nie.
Kontroleer plaaslik voordat jy die poort lees
Ná 'n herstel, bevestig dat die plaaslike bewerking slaag voordat jy enige antwoord van die ander kant interpreteer. As onderteken nou werk, is 'n daaropvolgende verwerping van die naam, ketting of kliënttoelating 'n nuwe resultaat eerder as 'n herhaling, en dit hoort by 'n ander besluit met 'n ander eienaar.
'n Nuttige oorhandiging noem watter van die drie besluite misluk het en stop daar. Dit sluit nooit die private sleutel in nie, en dit stel nooit onverwante sleutelringitems terug in die hoop dat 'n skoon bladsy sal help nie. Vestig daardie twee gewoontes voor die voorval eerder as tydens dit, wanneer die versoeking om alles tegelyk te probeer die sterkste is. 'n Kaartjie wat sê “die sleutelring herbou” vertel die volgende leser byna niks oor die oorspronklike fout nie.