Mac VPN sertifikāts: kāpēc identitātes atlasītājs paliek tukšs
Klientam vajag sertifikātu ar tā privāto atslēgu, tādā krātuvē, ko tas lasa. Vispirms pārbaudiet identitāti, pēc tam, vai vārteja to pieņem.
Jūs instalējāt sertifikātu, tas parādās Keychain Access ar draudzīgu nosaukumu, un VPN klienta identitātes atlasītājs joprojām ir tukšs. Klients nemeklē sertifikātu. Tas meklē identitāti: sertifikātu, kas savienots pārī ar privāto atslēgu un spēj pierādīt valdījumu, saglabātu tur, kur klientam ir atļauts to lasīt.
Tas, ko klients prasa, ir identitāte
Apple drošības sistēma sertifikātu un identitāti uzskata par dažādiem objektiem. Sertifikāts ir publiski dati. Identitāte ir šis sertifikāts kopā ar tā privāto atslēgu, un tikai identitāte var pabeigt izaicinājumu. Savukārt uzticams CA sertifikāts ļauj klientam novērtēt izdevēju; tas nepadara mašīnu par izsniegto klienta akreditācijas datu turētāju.
| 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 |
Tāpēc .cer faila importēšana nekad nerada lietojamu klienta identitāti. Fails satur tikai publisku materiālu, un nekāda pārdēvēšana vai uzticēšanās to nepārvērš atslēgu pārī.
Trīs iemesli, kāpēc atlasītājs paliek tukšs
Pirmais ir trūkstoša privātā atslēga, kas nozīmē, ka reģistrācijas vai importēšanas process to nav piegādājis. Otrais ir krātuve, kuru klients neaplūko: lietotāja līmeņa profils skatās lietotāja atslēgu saišķī, un sistēmas krātuvē ievietots elements tam var būt neredzams. Trešais ir mērķa vai politikas neatbilstība, kad sertifikāts pastāv, bet saskaņā ar izvietošanas noteikumiem nav derīgs klienta autentifikācijai.
security find-identity -v -p ssl-clientŠis uzskaita identitātes, ko sistēma uzskata par derīgām klienta autentifikācijai. Ja skaits ir nulle, problēma ir pirms VPN klienta, un neviens profila labojums to nesalabos. Ja identitāte parādās šeit, bet ne klientā, atšķirība ir klienta krātuvē vai tvērumā.
Kur dzīvo privātā atslēga un kas to drīkst lietot
Kad importējat identitāti, izmantojot Keychain Access, importēšanas dialogs piedāvā mērķa atslēgu saišķi. Kura vietne ir pareiza, atkarīgs no klienta un no tā, vai profils ir lietotāja vai ierīces tvērumā. Sena atbilde, kas iesaka sistēmas atslēgu saišķi, nav universāls noteikums, un elementu kopēšana starp krātuvēm nav labojums.
System Roots ir uzticības kolekcija. Sertifikāta ievietošana tur maina, kuriem izdevējiem sistēma uzticas; tas nerada privāto atslēgu, un tā nav identitāšu krātuve. Nesaistītu sertifikātu pārvietošana, lai aizpildītu atlasītāju, ir tāda veida labojums, pēc kura mašīna paliek ar pastāvīgi paplašinātu uzticības kopu.
Piekļuve privātajai atslēgai ir atsevišķa kontrole. Katram lietojumam piešķirt atļauju lietot atslēgu atrisina viena klienta atlases problēmu un piešķir tās pašas spējas visam pārējam mašīnā. Piešķiriet to klientam, kuram tā nepieciešama, un pārbaudiet, vai atslēga ir aparatūras atbalstīta vai atzīmēta kā neeksportējama; ja tā, jāizmanto atbalstītais nodrošinātājs, nevis eksportēta kopija.
Kā profils norāda uz akreditācijas datiem
Pārvaldītā vietējā IKEv2 konfigurācijā profils atsaucas uz savu akreditācijas datu kravu, izmantojot PayloadCertificateUUID. Svarīga ir atsauktā identitāte un veids, kā tā tika nodrošināta; profila parādāmā nosaukuma rediģēšana nesalabo atsauci, kas norāda uz nepareizu kravu vai tādu, kas nekad nav piegādājusi atslēgu.
Trešās puses nodrošinātājs var izmantot pilnīgi citu atlases mehānismu, piemēram, savu krātuvi vai sistēmas uzvedni. Lasiet šī nodrošinātāja dokumentāciju, nevis pārnesiet vietējā profila pieņēmumus, un pārbaudiet atsauci profilā, kas faktiski ir instalēts, nevis pārvaldības konsoles melnrakstā.
Atlase un pieņemšana ir atsevišķi etapi
Aizpildīts atlasītājs nozīmē, ka klients spēj atrast identitāti un to izmantot. Tas neko nepasaka par to, vai vārteja to pieņems. Serveris joprojām pārbauda izdevēju, derīguma logu, atsaukšanas statusu un šo akreditācijas datu kartējumu uz kontu.
Pārbaudiet abus etapus skaidri, šajā secībā. Apstipriniet, ka identitāte tiek piedāvāta, izveidojiet savienojumu, pēc tam lūdziet vārtejas īpašniekam apstiprināt, kuri akreditācijas dati tika uzrādīti un kurš kartēšanas noteikums tos izmantoja. Ja klients piedāvā identitāti un serveris to noraida, atlikušais darbs ir servera pusē. Sertifikāta atkārtota instalēšana Mac datorā šo rezultātu nemainīs, lai cik reižu to atkārtotu.