Mac VPN-atestilo: kial la identeca elektilo restas malplena
La kliento bezonas atestilon kun sia privata ŝlosilo, en konservejo, kiun ĝi legas. Kontrolu unue la identecon, poste ĉu la pordego akceptas ĝin.
Vi instalas la atestilon, ĝi aperas en Keychain Access kun amika nomo, kaj la identeca elektilo de la VPN-kliento restas malplena. La kliento ne serĉas atestilon. Ĝi serĉas identecon: atestilon parigitan kun la privata ŝlosilo, kiu povas pruvi posedon, konservitan tie, kie la kliento rajtas legi ĝin.
Kion la kliento petas, estas identeco
La sekureca kadro de Apple traktas atestilon kaj identecon kiel malsamajn objektojn. Atestilo estas publika dateno. Identeco estas tiu atestilo plus ĝia privata ŝlosilo, kaj nur la identeco povas plenumi defion. Fidinda CA-atestilo, aliflanke, permesas al kliento taksi eldonanton; ĝi ne faras la maŝinon posedanto de eldonita klienta legitimilo.
| 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 |
Tial importado de dosiero .cer neniam produktas uzeblan klientan identecon. La dosiero portas nur publikan materialon, kaj neniu kvanto da renomado aŭ fido igas ĝin ŝlosilparo.
Tri kialoj, kial la elektilo restas malplena
La unua estas mankanta privata ŝlosilo, kio signifas, ke la registra aŭ importa procezo ne liveris unu. La dua estas konservejo, kiun la kliento ne konsultas: profilo je uzanto-nivelo serĉas en la ŝlosilaro de la uzanto, kaj ero metita en sistemkonservejon povas esti nevidebla por ĝi. La tria estas malkongruo de celo aŭ politiko, kie la atestilo ekzistas sed ne validas por klienta aŭtentikigo laŭ la reguloj de la deplojo.
security find-identity -v -p ssl-clientĈi tio listigas identecojn, kiujn la sistemo konsideras validaj por klienta aŭtentikigo. Se la nombro estas nulo, la problemo estas antaŭ la VPN-kliento kaj neniu profilredakto riparos ĝin. Se la identeco aperas ĉi tie sed ne en la kliento, la diferenco estas la konservejo aŭ la amplekso de la kliento.
Kie loĝas la privata ŝlosilo kaj kiu rajtas uzi ĝin
Kiam vi importas identecon per Keychain Access, la importa dialogo proponas celan ŝlosilaron. Kiu celo estas ĝusta dependas de la kliento kaj de tio, ĉu la profilo estas je uzanto- aŭ je aparat-nivelo. Malnova respondo, kiu rekomendas la susteman ŝlosilaron, ne estas universala regulo, kaj kopiado de eroj inter konservejoj ne estas riparo.
System Roots estas fida kolekto. Meti atestilon tie ŝanĝas, kiujn eldonantojn la sistemo fidas; ĝi ne kreas privatan ŝlosilon, kaj ĝi ne estas identeca konservejo. Movi nerilatajn atestilojn por plenigi elektilon estas la speco de riparo, kiu lasas maŝinon kun konstante vastigita fida aro.
Aliro al la privata ŝlosilo estas aparta kontrolo. Doni al ĉiu aplikaĵo permeson uzi la ŝlosilon solvas la elektan problemon de unu kliento kaj transdonas la saman kapablon al ĉio alia en la maŝino. Donu ĝin al la kliento, kiu bezonas ĝin, kaj kontrolu, ĉu la ŝlosilo estas aparate subtenata aŭ markita kiel ne-eksportebla; se jes, la subtenata provizanto devas esti uzata anstataŭ eksportita kopio.
Kiel la profilo montras al la legitimilo
En administrata indiĝena IKEv2-agordo, la profilo referencas sian legitimilan ŝarĝon per PayloadCertificateUUID. La referencata identeco kaj la maniero, kiel ĝi estis provizita, estas tio, kio gravas; redakti montran nomon en la profilo ne riparas referencon, kiu montras al la malĝusta ŝarĝo aŭ al tiu, kiu neniam liveris ŝlosilon.
Tria provizanto povas uzi tute alian elektan mekanismon, kiel propran konservejon aŭ sisteman inviton. Legu la dokumentaron de tiu provizanto anstataŭ transdoni supozojn pri indiĝena profilo, kaj kontrolu la referencon en la profilo, kiu estas efektive instalita, ne en tiu de la malneto en la administra konzolo.
Elektado kaj akcepto estas apartaj mejloŝtonoj
Plenigita elektilo signifas, ke la kliento povas trovi kaj uzi identecon. Ĝi diras nenion pri tio, ĉu la pordego akceptos ĝin. La servilo ankoraŭ kontrolas la eldonanton, la validecan fenestron, la revokan staton kaj la mapadon de tiu legitimilo al konto.
Testu ambaŭ stadiojn eksplicite, en tiu ordo. Konfirmu, ke la identeco estas proponita, konektu, kaj poste petu la posedanton de la pordego konfirmi, kiu legitimilo estis prezentita kaj kiu mapada regulo konsumis ĝin. Se la kliento proponas identecon kaj la servilo malakceptas ĝin, la restanta laboro estas ĉe la servila flanko. Reinstali la atestilon en la Mac ne ŝanĝos tiun rezulton, kiom ajn da fojoj ĝi ripetiĝos.