IKEv2-sertifikat på iPhone: manuell eller styrt registrering

Å velje RSA fordi sertifikatverktøyet til gatewayen brukar det som standard, er eit val som blir teke før spørsmålet som betyr noko: korleis skal desse iPhone-telefonane registrerast? Ei tilkopling brukaren skriv inn sjølv, og ein konfigurasjonsprofil levert av styringa, viser ulike innstillingar, og nokre sertifikatval finst berre på ein av desse vegane. Får du rekkjefølgja rett, blir sertifikatplanen kort; får du han feil, gjev du ut legitimasjon telefonen ikkje vil bruke. Handsama trinna nedanfor som ein sekvens, fordi kvart trinn avgrensar vala som er tilgjengelege for det neste.

Trinn éin: vel registreringsvegen

Manuell oppsett tyder at brukaren skriv inn serveradressa, vel autentiseringsmetoden og oppgjev legitimasjon som grensesnittet tillèt. Styrt registrering tyder at ein profil ber adressa, identifikatorane og ei tilvising til ein nyttelast med legitimasjon. Den styrte vegen kan uttrykke kombinasjonar som den manuelle skjermen ikkje kan, og difor må sertifikatavgjerda kome etter dette valet, ikkje før.

Begge vegane kan autentisere ein telefon. Dei skil seg i kva du kan konfigurere og kven som eig identiteten, så vel éin medvite i staden for å blande ein styrt profil med manuell innskriving av legitimasjon.

Trinn to: vel algoritmar for vegen du valde

For manuelt konfigurerte iPhone tilrår iOS-samhandlingsnotata til strongSwan eit RSA-serversertifikat, fordi den manuelle klienten kanskje ikkje godtek eit ECDSA-serversertifikat; dei same notata handsamar macOS separat. Les dette som rettleiing for det støtta klientutvalet, ikkje som ei varig lov om Apple-einingar. Ein styrt profil har meir plass: han kan velje sertifikattype eksplisitt, inkludert ein ECDSA-klientidentitet, når nyttelasten og gatewayen begge støttar det.

Valider iOS-versjonane du faktisk støttar før du rullar ut noko. Ein laboratorietelefon på nyaste versjon skildrar ikkje ein flåte som omfattar eldre einingar, og ein algoritme som fungerer i laboratoriet, kan framleis feile på den eldste telefonen i felt. Hent versjonsområdet frå einingstyringa og ikkje frå minnet. Viss flåten spenner over fleire versjonar, test den eldste først, fordi det er der det manuelle grensesnittet er mest avgrensande.

Trinn tre: les profilfelta som separate ting

Fleire nøklar med liknande namn skildrar ulike objekt. Fjernadressa er verten telefonen ringjer. Fjernidentifikatoren er IKE-identiteten han ventar at gatewayen presenterer. Sertifikattilvisinga i nyttelasten peikar på klientlegitimasjon, og feltet for sertifikattype vel typen som blir brukt til IKEv2-maskinautentisering. Ingen av desse er signaturalgoritmen til CA-en, sjølv om orda overlappar.

Apple sin IKEv2-nyttelastreferanse listar RSA som standard sertifikattype med eksplisitte ECDSA-variantar, og han knyter utgivarnamnnøkkelen til bestemte autentiseringsinnstillingar. Les desse samanhengane i referansen for metoden du valde, i staden for å kopiere éin nøkkel frå ein fungerande utrulling.

Trinn fire: få identiteten til gatewayen til å samsvare med sertifikatet

Bruk eit eksplisitt gatewaynamn, til dømes vpn.example.com og set eit samsvarande alternativt subjektnamn i serversertifikatet. Apple-rettleiinga til strongSwan ventar også utvida nøkkelbruk for serverautentisering. Valet av RSA eller ECDSA endrar ingenting av dette: ein algoritme kan ikkje reparere eit namneavvik, ein manglande EKU eller ei ufullstendig kjede.

Distribusjon av tillitsankeret er ei eiga oppgåve frå å hevde identiteten. Telefonen treng ei sertifikatkjede han kan validere, og han må konfigurerast til å vente på namnet du faktisk sette i sertifikatet.

At ein annan plattform koplar til med hell, er prov om valideringsreglane til den plattforma, ikkje løyve til å lempe på telefonen sine. Hald kontrollane identiske på tvers av klientar med mindre du har ein dokumentert grunn til å avvike.

Trinn fem: skil klientidentiteten frå CA-tilliten

Eit klientsertifikat og den private nøkkelen hans er ikkje same objekt som CA-sertifikatet telefonen stolar på. Å pakke eit CA-sertifikat inn i ein PKCS#12-identitet installerer det ikkje automatisk som tillitsanker på kvar støtta eining, så handsama distribusjon av tillit som eit eige trinn med eigen verifisering.

Viss designet i staden brukar passordbasert EAP, treng telefonen den tiltenkte kontoautentiseringa pluss servervalidering. Den vegen rettferdiggjer ikkje å sende éin delt privat klientnøkkel til heile flåten, noko som er eit anna design med ein langt verre feilmodus.

Avslutt planen med fornying og tilbakekalling i tankane: kven som gjev ut klientlegitimasjonen på nytt, korleis profilen blir oppdatert, og korleis ein mist telefon blir stengd ute. Registrer profilversjonen og einingsversjonane du validerte mot, fordi den registreringa er det som gjer neste sertifikatutskifting til ei rutineendring.