Postavljanje IKEv2 sertifikata na iPhone: ručna naspram upravljane prijave
Put prijave određuje koje opcije sertifikata postoje. Prvo izaberite ručnu ili upravljanu, zatim uskladite identitet servera, klijentske akreditive i algoritam.
Biranje RSA zato što alat za sertifikate na mrežnom prolazu koristi njega kao podrazumijevano je odluka donesena prije pitanja koje je važno: kako će ovi iPhone uređaji biti prijavljeni? Veza koju korisnik sam unese i konfiguracijski profil koji dostavi uprava izlažu različite postavke, a neke opcije sertifikata postoje samo na jednom od tih puteva. Postavite redoslijed ispravno i plan sertifikata postaje kratak; pogriješite i izdat ćete akreditiv koji telefon neće koristiti. Tretirajte korake ispod kao niz, jer svaki sužava izbore dostupne sljedećem.
Prvi korak: izaberite put prijave
Ručno postavljanje znači da korisnik unosi adresu servera, bira metodu autentifikacije i dostavlja sve akreditive koje interfejs dozvoljava. Upravljana prijava znači da profil nosi adresu, identifikatore i referencu na korisni teret s akreditivima. Upravljani put može izraziti kombinacije koje ručni ekran ne može, zbog čega odluka o sertifikatu mora doći poslije ovog izbora, a ne prije njega.
Oba puta mogu autentifikovati telefon. Razlikuju se u tome šta možete konfigurisati i kome pripada identitet, pa svjesno izaberite jedan umjesto miješanja upravljanog profila s ručnim unosom akreditiva.
Drugi korak: izaberite algoritme za put koji ste odabrali
Za ručno konfigurisane iPhone uređaje, strongSwanove napomene o interoperabilnosti s iOS-om preporučuju RSA sertifikat servera, jer ručni klijent možda neće prihvatiti ECDSA sertifikat servera; iste napomene macOS tretiraju odvojeno. Čitajte to kao smjernicu za podržani skup klijenata, a ne kao trajni zakon o Apple uređajima. Upravljani profil ima više prostora: može eksplicitno izabrati tip sertifikata, uključujući ECDSA identitet klijenta, kada to i korisni teret i mrežni prolaz podržavaju.
Provjerite verzije iOS-a koje zaista podržavate prije nego bilo šta pustite u rad. Telefon iz laboratorije na najnovijem izdanju ne opisuje flotu koja uključuje starije uređaje, a algoritam koji radi u laboratoriji i dalje može zakazati na najstarijem telefonu na terenu. Uzmite raspon verzija iz upravljanja uređajima, a ne iz sjećanja. Ako flota obuhvata više izdanja, prvo testirajte najstarije, jer je upravo tu ručni interfejs najrestriktivniji.
Treći korak: čitajte polja profila kao odvojene stvari
Nekoliko ključeva sličnih imena opisuje različite objekte. Udaljena adresa je host koji telefon bira. Udaljeni identifikator je IKE identitet koji očekuje da mrežni prolaz predstavi. Referenca na sertifikat u korisnom teretu pokazuje na klijentske akreditive, a polje tipa sertifikata bira tip koji se koristi za mašinsku autentifikaciju putem IKEv2. Nijedno od toga nije algoritam potpisa CA, iako se riječi preklapaju.
Appleova referenca za IKEv2 korisni teret navodi RSA kao podrazumijevani tip sertifikata s eksplicitnim ECDSA varijantama i povezuje ključ imena izdavaoca s određenim postavkama autentifikacije. Čitajte te veze iz reference za metodu koju ste izabrali, umjesto da kopirate jedan ključ iz radnog postavljanja.
Četvrti korak: uskladite identitet mrežnog prolaza s njegovim sertifikatom
Koristite eksplicitno ime mrežnog prolaza, na primjer vpn.example.com i stavite odgovarajuće alternativno ime subjekta u sertifikat servera. strongSwanove Apple smjernice takođe očekuju proširenu upotrebu ključa za autentifikaciju servera. Izbor RSA ili ECDSA ne mijenja ništa od toga: algoritam ne može popraviti neslaganje imena, nedostajući EKU ili nepotpun lanac.
Distribucija sidra povjerenja odvojen je zadatak od tvrdnje identiteta. Telefonu je potreban lanac sertifikata koji može validirati i mora biti konfigurisan da očekuje ime koje ste zaista stavili u sertifikat.
Uspješno povezivanje druge platforme dokaz je o pravilima validacije te platforme, a ne dozvola da ublažite pravila telefona. Držite provjere identičnim među klijentima, osim ako imate dokumentovan razlog da se razlikuju.
Peti korak: odvojite identitet klijenta od povjerenja u CA
Klijentski sertifikat i njegov privatni ključ nisu isti objekat kao CA sertifikat kojem telefon vjeruje. Pakovanje CA sertifikata unutar PKCS#12 identiteta ne instalira ga automatski kao sidro povjerenja na svakom podržanom uređaju, pa tretirajte distribuciju povjerenja kao zaseban korak sa sopstvenom provjerom.
Ako dizajn umjesto toga koristi EAP zasnovan na lozinci, telefonu su potrebni predviđena autentifikacija računa i validacija servera. Taj put ne opravdava slanje jednog zajedničkog privatnog ključa klijenta cijeloj floti, što je drugačiji dizajn s mnogo gorim načinom otkaza.
Završite plan imajući na umu obnovu i opoziv: ko ponovo izdaje klijentske akreditive, kako se profil ažurira i kako se izgubljeni telefon odsijeca. Zabilježite verziju profila i verzije uređaja prema kojima ste validirali, jer taj zapis čini sljedeću zamjenu sertifikata rutinskom promjenom.