IKEv2-varmenteen käyttöönotto iPhonessa: manuaalinen vai hallittu rekisteröinti

RSA:n valitseminen siksi, että yhdyskäytävän varmennetyökalu käyttää sitä oletuksena, on päätös, joka tehdään ennen tärkeää kysymystä: miten nämä iPhonet rekisteröidään? Käyttäjän itse kirjoittama yhteys ja hallinnon toimittama kokoonpanoprofiili tarjoavat eri asetukset, ja jotkin varmennevalinnat ovat olemassa vain toisella näistä poluista. Järjestys oikein ja varmennesuunnitelmasta tulee lyhyt; väärin ja myönnät tunnistetiedot, joita puhelin ei käytä. Käsittele alla olevia vaiheita sarjana, sillä jokainen kaventaa seuraavan käytettävissä olevia valintoja.

Vaihe yksi: valitse rekisteröintipolku

Manuaalinen käyttöönotto tarkoittaa, että käyttäjä syöttää palvelimen osoitteen, valitsee todennusmenetelmän ja toimittaa kaikki tunnistetiedot, jotka käyttöliittymä sallii. Hallittu rekisteröinti tarkoittaa, että profiili kuljettaa osoitteen, tunnisteet ja viittauksen tunnistetietojen hyötykuormaan. Hallittu polku voi ilmaista yhdistelmiä, joihin manuaalinen näyttö ei pysty, minkä vuoksi varmennepäätöksen on tultava tämän valinnan jälkeen eikä ennen sitä.

Molemmat polut voivat todentaa puhelimen. Ne eroavat siinä, mitä voit määrittää ja kenelle identiteetti kuuluu, joten valitse toinen tietoisesti sen sijaan, että sekoittaisit hallitun profiilin manuaaliseen tunnistetietojen syöttöön.

Vaihe kaksi: valitse algoritmit valitsemallesi polulle

Manuaalisesti määritetyille iPhoneille strongSwanin iOS-yhteensopivuusmuistiinpanot suosittelevat RSA-palvelinvarmennetta, koska manuaalinen asiakasohjelma ei ehkä hyväksy ECDSA-palvelinvarmennetta; samat muistiinpanot käsittelevät macOS:ää erikseen. Lue tämä ohjeena tuetulle asiakasohjelmajoukolle, älä pysyvänä lakina Apple-laitteista. Hallitulla profiililla on enemmän tilaa: se voi valita varmennetyypin nimenomaisesti, mukaan lukien ECDSA-asiakasidentiteetin, kun hyötykuorma ja yhdyskäytävä tukevat sitä molemmat.

Validoi ne iOS-versiot, joita todella tuet, ennen kuin otat mitään käyttöön. Uusimman version laboratoriopuhelin ei kuvaa laitekantaa, johon kuuluu vanhempia laitteita, ja laboratoriossa toimiva algoritmi voi silti epäonnistua kentän vanhimmassa puhelimessa. Ota versioväli laitehallinnasta, älä muistista. Jos laitekanta kattaa useita versioita, testaa ensin vanhin, sillä siellä manuaalinen käyttöliittymä on rajoittavin.

Vaihe kolme: lue profiilin kentät erillisinä asioina

Useat samannimiset avaimet kuvaavat eri objekteja. Etäosoite on isäntä, johon puhelin soittaa. Etätunniste on IKE-identiteetti, jonka se odottaa yhdyskäytävän esittävän. Hyötykuorman varmenneviittaus osoittaa asiakasohjelman tunnistetietoihin, ja varmennetyyppikenttä valitsee tyypin, jota käytetään IKEv2-konetodennukseen. Mikään näistä ei ole CA:n allekirjoitusalgoritmi, vaikka sanat menevät päällekkäin.

Applen IKEv2-hyötykuurmaviite luettelee RSA:n oletusvarmennetyypiksi ja nimeää eksplisiittiset ECDSA-muunnelmat, ja se sitoo myöntäjän nimen avaimen tiettyihin todennusasetuksiin. Lue nämä suhteet valitsemasi menetelmän viitteestä sen sijaan, että kopioisit yhden avaimen toimivasta käyttöönotosta.

Vaihe neljä: sovita yhdyskäytävän identiteetti sen varmenteeseen

Käytä nimenomaista yhdyskäytävän nimeä, esimerkiksi vpn.example.com ja laita vastaava vaihtoehtoinen subjektin nimi palvelinvarmenteeseen. strongSwanin Apple-ohje odottaa myös laajennettua avaimen käyttöä palvelintodennukseen. RSA:n tai ECDSA:n valinta ei muuta mitään tästä: algoritmi ei voi korjata nimen ristiriitaa, puuttuvaa EKU:ta tai puutteellista ketjua.

Luottamusankkurin jakelu on erillinen tehtävä identiteetin väittämisestä. Puhelin tarvitsee varmenneketjun, jonka se voi validoida, ja se on määritettävä odottamaan nimeä, jonka todella laitoit varmenteeseen.

Toisen alustan onnistunut yhdistäminen on todiste kyseisen alustan validointisäännöistä, ei lupa löysentää puhelimen sääntöjä. Pidä tarkistukset samoina asiakasohjelmien välillä, ellet voi dokumentoida syytä poiketa.

Vaihe viisi: erota asiakasidentiteetti CA-luottamuksesta

Asiakasvarmenne ja sen yksityinen avain eivät ole sama objekti kuin CA-varmenne, johon puhelin luottaa. CA-varmenteen pakkaaminen PKCS#12-identiteetin sisään ei asenna sitä automaattisesti luottamusankkuriksi jokaiseen tuettuun laitteeseen, joten käsittele luottamuksen jakelua omana vaiheenaan omine tarkistuksineen.

Jos suunnittelu käyttää sen sijaan salasanaan perustuvaa EAP:ta, puhelin tarvitsee aiottuun tilin todentamisen sekä palvelimen validoinnin. Tämä polku ei oikeuta toimittamaan yhtä jaettua asiakasohjelman yksityistä avainta koko laitekannalle, mikä on erilainen suunnittelu ja paljon huonommalla vikatilalla.

Viimeistele suunnitelma uusiminen ja peruutus mielessä: kuka myöntää asiakasohjelman tunnistetiedot uudelleen, miten profiilia päivitetään ja miten kadonnut puhelin katkaistaan. Kirjaa profiilin versio ja laiteversiot, joita vasten validoit, sillä juuri se kirjaus tekee seuraavasta varmennevaihdosta rutiinimuutoksen.