It kiezen fan RSA om't it sertifikaatark fan 'e poarte it standert brûkt, is in beslút dat nommen wurdt foar de fraach dy't der ta docht: hoe wurde dizze iPhones oanmeld? In ferbining dy't de brûker sels yntypet en in konfiguraasjeprofyl dat troch behear levere wurdt, biede ferskate ynstellings, en guon sertifikaatkarren besteane allinne op ien fan dy paden. Set de oarder goed en it sertifikaatplan wurdt koart; dochst it ferkeard en dan joust in bewiis út dat de telefoan net brûke sil. Behannelje de stappen hjirûnder as in searje, want elk ferkoarte de karren dy't foar de folgjende beskikber binne.

Stap ien: kies it oanmeldpaad

Hânmjittige opset betsjut dat de brûker it tsjinneradres yntypet, de autentikaasjemetoade kiest en elk bewiis leveret dat de ynterface tastiet. Beheard oanmelden betsjut dat in profyl it adres, de identifikaasjes en in ferwizing nei in bewiislading draacht. It behearde paad kin kombinaasjes útdrukke dy't it hânmjittige skerm net kin, en dêrom moat it sertifikaatbeslút nei dizze kar komme en net derfoar.

Beide paden kinne in telefoan autentisearje. Se ferskille yn wat jo konfigurearje kinne en wa't de identiteit besit, dus kies ien bewust ynstee fan in beheard profyl mei hânmjittige bewiisynfier te mingen.

Stap twa: kies algoritmen foar it paad dat jo keazen hawwe

Foar hânmjittich konfigurearre iPhones riede de iOS-ynteroperaasjebegripen fan strongSwan in RSA-tsjinnersertifikaat oan, om't de hânmjittige klant in ECDSA-tsjinnersertifikaat miskien net akseptearret; deselde begripen behannelje macOS apart. Lês dat as rjochtline foar de stipe klanteset, net as in permaninte wet oer Apple-apparaten. In beheard profyl hat mear romte: it kin in sertifikaattype eksplisyt kieze, ynklusyf in ECDSA-klantidentiteit, as de lading en de poarte dat beide stypje.

Falidearje de iOS-ferzjes dy't jo echt stypje foardat jo wat útrôlje. In laboratoariumtelefoan op 'e nijste ferzje beskriuwt gjin float dy't âldere apparaten omfettet, en in algoritme dat yn it laboratoarium wurket, kin noch altyd mislearje op 'e âldste telefoan yn it fjild. Helje it ferzjeberik út apparaatbehear, net út it ûnthâld. As de float oer ferskate ferzjes rint, testje dan earst de âldste, want dêr is de hânmjittige ynterface it meast beheinend.

Stap trije: lês de profylfjilden as aparte dingen

Ferskate nammen fan itselde soarte beskriuwe ferskate objekten. It adres fan fierôf is de host dy't de telefoan skillet. De identifikaasje fan fierôf is de IKE-identiteit dy't er fan 'e poarte ferwachtet. De sertifikaatferwizing yn 'e lading wiist nei in klantbewiis, en it fjild foar sertifikaattype kiest it type dat brûkt wurdt foar IKEv2-masjine-autentikaasje. Net ien fan dy is it ûndertekeningsalgoritme fan 'e CA, ek al oerlaapje de wurden.

De IKEv2-ladingsreferinsje fan Apple neamt RSA as it standert sertifikaattype mei eksplisite ECDSA-farianten, en ferbynt de kaai fan 'e útjouwersnamme oan bepaalde autentikaasje-ynstellings. Lês dy ferhâldings yn 'e referinsje foar de metoade dy't jo keazen hawwe, ynstee fan ien kaai út in wurkjende útrôl te kopiearjen.

Stap fjouwer: meitsje de identiteit fan 'e poarte lyk oan har sertifikaat

Brûk in eksplisite poartenamme, bygelyks vpn.example.com en set in oerienkommende alternatyf ûnderwerpnnamme yn it tsjinnersertifikaat. De Apple-rjochtline fan strongSwan ferwachtet ek it útwreide kaaiberik foar tsjinnerautentikaasje. RSA of ECDSA kieze feroaret dêr neat oan: in algoritme kin in nammemiskiping, in ûntbrekkende EKU of in ûnfolsleine keatling net reparearje.

It fersprieden fan it fertrouwensanker is in aparte taak fan it befêstigjen fan 'e identiteit. De telefoan hat in sertifikaatkeatling nedich dy't er falidearje kin, en hy moat konfigurearre wurde om de namme te ferwachtsjen dy't jo echt yn it sertifikaat set hawwe.

Dat in oar platfoarm mei súkses ferbynt, is bewiis oer de falidaasjeregels fan dat platfoarm, net tastimming om dy fan 'e telefoan te fersêftsjen. Hâld de kontrôles itselde oer klanten, útsein as jo in dokumintearre reden hawwe om te ferskillen.

Stap fiif: skied de klantidentiteit fan it CA-fertrouwen

In klantsertifikaat en syn priveekaai binne net itselde objekt as it CA-sertifikaat dêr't de telefoan op fertrout. It ynpakken fan in CA-sertifikaat yn in PKCS#12-identiteit ynstallearret it net automatysk as fertrouwensanker op elk stipe apparaat, dus behannelje fertrouwensfersprieding as in eigen stap mei eigen ferifikaasje.

As it ûntwerp ynstee wachtwurd-basearre EAP brûkt, hat de telefoan de bedoelde akkountautentikaasje plus tsjinnerfalidaasje nedich. Dat paad rjochtfeardiget it ferstjoeren fan ien dielde priveekaai foar de klant nei de hiele float net, wat in oar ûntwerp is mei in folle minner mislearringsmodel.

Meitsje it plan ôf mei fernijing en werropping yn 't each: wa't it klantbewiis opnij útjout, hoe't it profyl bywurke wurdt en hoe't in ferlerne telefoan ôfsnien wurdt. Registrearje de profylferzje en de apparaatferzjes dêr't jo tsjin falidearre hawwe, want dy registraasje makket de folgjende sertifikaatwiksel in routineferoaring.

Relatearre artikelen