IKEv2-sertifikat på iPhone: manuell eller administrert registrering

Å velge RSA fordi gatewayens sertifikatverktøy bruker det som standard, er en beslutning som tas før spørsmålet som betyr noe: hvordan skal disse iPhone-telefonene registreres? En tilkobling brukeren skriver inn selv, og en konfigurasjonsprofil levert av administrasjonen, viser ulike innstillinger, og noen sertifikatvalg finnes bare på én av disse veiene. Får du rekkefølgen riktig, blir sertifikatplanen kort; får du den feil, utsteder du legitimasjon telefonen ikke vil bruke. Behandle trinnene nedenfor som en sekvens, fordi hvert trinn begrenser valgene som er tilgjengelige for det neste.

Trinn én: velg registreringsveien

Manuell oppsett betyr at brukeren skriver inn serveradressen, velger autentiseringsmetoden og oppgir legitimasjon som grensesnittet tillater. Administrert registrering betyr at en profil bærer adressen, identifikatorene og en referanse til en nyttelast med legitimasjon. Den administrerte veien kan uttrykke kombinasjoner som den manuelle skjermen ikke kan, og derfor må sertifikatbeslutningen komme etter dette valget, ikke før.

Begge veiene kan autentisere en telefon. De skiller seg i hva du kan konfigurere og hvem som eier identiteten, så velg én bevisst i stedet for å blande en administrert profil med manuell innskriving av legitimasjon.

Trinn to: velg algoritmer for veien du valgte

For manuelt konfigurerte iPhone anbefaler strongSwans iOS-samhandlingsnotater et RSA-serversertifikat, fordi den manuelle klienten kanskje ikke godtar et ECDSA-serversertifikat; de samme notatene behandler macOS separat. Les dette som veiledning for det støttede klientutvalget, ikke som en varig lov om Apple-enheter. En administrert profil har mer plass: den kan velge sertifikattype eksplisitt, inkludert en ECDSA-klientidentitet, når nyttelasten og gatewayen begge støtter det.

Valider iOS-versjonene du faktisk støtter før du ruller ut noe. En laboratorietelefon på nyeste versjon beskriver ikke en flåte som omfatter eldre enheter, og en algoritme som fungerer i laboratoriet, kan fortsatt feile på den eldste telefonen i felt. Hent versjonsområdet fra enhetsadministrasjonen og ikke fra hukommelsen. Hvis flåten spenner over flere versjoner, test den eldste først, fordi det er der det manuelle grensesnittet er mest begrensende.

Trinn tre: les profilfeltene som separate ting

Flere nøkler med lignende navn beskriver ulike objekter. Fjernadressen er verten telefonen ringer. Fjernidentifikatoren er IKE-identiteten den forventer at gatewayen presenterer. Sertifikatreferansen i nyttelasten peker på klientlegitimasjon, og feltet for sertifikattype velger typen som brukes til IKEv2-maskinautentisering. Ingen av disse er CA-ens signaturalgoritme, selv om ordene overlapper.

Apples IKEv2-nyttelastreferanse lister RSA som standard sertifikattype med eksplisitte ECDSA-varianter, og den knytter utstedernavnnøkkelen til bestemte autentiseringsinnstillinger. Les disse sammenhengene i referansen for metoden du valgte, i stedet for å kopiere én nøkkel fra en fungerende utrulling.

Trinn fire: få gatewayens identitet til å samsvare med sertifikatet

Bruk et eksplisitt gatewaynavn, for eksempel vpn.example.com og sett et samsvarende alternativt subjektnavn i serversertifikatet. strongSwans Apple-veiledning forventer også utvidet nøkkelbruk for serverautentisering. Valget av RSA eller ECDSA endrer ingenting av dette: en algoritme kan ikke reparere et navneavvik, en manglende EKU eller en ufullstendig kjede.

Distribusjon av tillitsankeret er en egen oppgave fra å hevde identiteten. Telefonen trenger en sertifikatkjede den kan validere, og den må konfigureres til å forvente navnet du faktisk satte i sertifikatet.

At en annen plattform kobler til med hell, er bevis om den plattformens valideringsregler, ikke tillatelse til å lempe telefonens. Hold kontrollene identiske på tvers av klienter med mindre du har en dokumentert grunn til å avvike.

Trinn fem: skill klientidentiteten fra CA-tilliten

Et klientsertifikat og dens private nøkkel er ikke samme objekt som CA-sertifikatet telefonen stoler på. Å pakke et CA-sertifikat inn i en PKCS#12-identitet installerer det ikke automatisk som tillitsanker på hver støttet enhet, så behandle distribusjon av tillit som et eget trinn med egen verifisering.

Hvis designet i stedet bruker passordbasert EAP, trenger telefonen den tiltenkte kontoautentiseringen pluss servervalidering. Den veien rettferdiggjør ikke å sende én delt privat klientnøkkel til hele flåten, noe som er et annet design med en langt verre feilmodus.

Avslutt planen med fornyelse og tilbakekalling i tankene: hvem som utsteder klientlegitimasjonen på nytt, hvordan profilen oppdateres, og hvordan en mistet telefon stenges ute. Registrer profilversjonen og enhetsversjonene du validerte mot, fordi den registreringen er det som gjør neste sertifikatutskifting til en rutineendring.