Opsætning af IKEv2-certifikat på iPhone: manuel kontra administreret tilmelding

At vælge RSA, fordi gatewayens certifikatværktøj bruger det som standard, er en beslutning, der træffes før det spørgsmål, der betyder noget: hvordan bliver disse iPhones tilmeldt? En forbindelse, som brugeren selv indtaster, og en konfigurationsprofil, som administrationen leverer, viser forskellige indstillinger, og nogle certifikatvalg findes kun på en af disse veje. Får du rækkefølgen rigtig, bliver certifikatplanen kort; får du den forkert, udsteder du en legitimationsoplysning, som telefonen ikke vil bruge. Behandl trinnene nedenfor som en sekvens, fordi hvert trin indsnævrer de valg, der er tilgængelige for det næste.

Trin et: vælg tilmeldingsvejen

Manuel opsætning betyder, at brugeren indtaster serveradressen, vælger godkendelsesmetoden og angiver de legitimationsoplysninger, som grænsefladen tillader. Administreret tilmelding betyder, at en profil bærer adressen, identifikatorerne og en reference til en nyttelast med legitimationsoplysninger. Den administrerede vej kan udtrykke kombinationer, som den manuelle skærm ikke kan, og derfor skal certifikatbeslutningen komme efter dette valg og ikke før det.

Begge veje kan godkende en telefon. De adskiller sig i, hvad du kan konfigurere, og i hvem der ejer identiteten, så vælg den ene bevidst i stedet for at blande en administreret profil med manuel indtastning af legitimationsoplysninger.

Trin to: vælg algoritmer til den vej, du valgte

Til manuelt konfigurerede iPhones anbefaler strongSwans iOS-interoperabilitetsnoter et RSA-servercertifikat, fordi den manuelle klient muligvis ikke accepterer et ECDSA-servercertifikat; de samme noter behandler macOS separat. Læs det som vejledning for det understøttede klientudvalg, ikke som en varig lov om Apple-enheder. En administreret profil har mere plads: den kan vælge en certifikattype eksplicit, inklusive en ECDSA-klientidentitet, når nyttelasten og gatewayen begge understøtter det.

Valider de iOS-versioner, du faktisk understøtter, før du udruller noget. En laboratorietelefon på den nyeste version beskriver ikke en flåde, der omfatter ældre enheder, og en algoritme, der virker i laboratoriet, kan stadig fejle på den ældste telefon i marken. Hent versionsintervallet fra enhedsadministrationen i stedet for fra hukommelsen. Hvis flåden spænder over flere versioner, skal du teste den ældste først, fordi det er der, den manuelle grænseflade er mest begrænsende.

Trin tre: læs profilfelterne som separate ting

Flere enslydende nøgler beskriver forskellige objekter. Fjernadressen er den vært, som telefonen ringer op. Fjernidentifikatoren er den IKE-identitet, som den forventer, at gatewayen præsenterer. Certifikatreferencen i nyttelasten peger på en klientlegitimationsoplysning, og feltet for certifikattype vælger den type, der bruges til IKEv2-maskingodkendelse. Ingen af disse er CA'ens signaturalgoritme, selvom ordene overlapper.

Apples IKEv2-nyttelastreference angiver RSA som standardcertifikattype med eksplicitte ECDSA-varianter og knytter udstederens navnenøgle til bestemte godkendelsesindstillinger. Læs disse sammenhænge i referencen for den metode, du valgte, i stedet for at kopiere én nøgle fra en fungerende udrulning.

Trin fire: få gatewayens identitet til at matche dens certifikat

Brug et eksplicit gatewaynavn, for eksempel vpn.example.com og sæt et matchende alternativt emnenavn i servercertifikatet. strongSwans Apple-vejledning forventer også den udvidede nøgleanvendelse til servergodkendelse. Valget af RSA eller ECDSA ændrer intet af dette: en algoritme kan ikke reparere et navnemismatch, en manglende EKU eller en ufuldstændig kæde.

Distribution af tillidsankeret er en separat opgave fra at hævde identiteten. Telefonen har brug for en certifikatkæde, den kan validere, og den skal konfigureres til at forvente det navn, du faktisk satte i certifikatet.

At en anden platform forbinder med succes, er bevis for den platformens valideringsregler, ikke tilladelse til at lempe telefonens. Hold kontrollerne identiske på tværs af klienter, medmindre du har en dokumenteret grund til at afvige.

Trin fem: adskil klientidentiteten fra CA-tilliden

Et klientcertifikat og dets private nøgle er ikke det samme objekt som det CA-certifikat, som telefonen stoler på. At pakke et CA-certifikat ind i en PKCS#12-identitet installerer det ikke automatisk som tillidsanker på hver understøttet enhed, så behandl distribution af tillid som et selvstændigt trin med sin egen verifikation.

Hvis designet i stedet bruger adgangskodebaseret EAP, har telefonen brug for den tilsigtede kontogodkendelse plus servervalidering. Den vej retfærdiggør ikke at sende én delt privat klientnøgle til hele flåden, hvilket er et andet design med en langt værre fejltilstand.

Afslut planen med fornyelse og tilbagekaldelse in mente: hvem genudsteder klientlegitimationsoplysningen, hvordan profilen opdateres, og hvordan en mistet telefon afskæres. Registrér profilversionen og de enhedsversioner, du validerede imod, fordi den registrering er det, der gør den næste certifikatudskiftning til en rutineændring.