IKEv2-certificaat op iPhone: handmatige of beheerde inschrijving

RSA kiezen omdat de certificaattool van de gateway het standaard gebruikt, is een beslissing die wordt genomen vóór de vraag die ertoe doet: hoe worden deze iPhones ingeschreven? Een verbinding die de gebruiker zelf intypt en een configuratieprofiel dat door beheer wordt geleverd, bieden verschillende instellingen, en sommige certificaatkeuzes bestaan alleen op een van die paden. Zet de volgorde goed en het certificaatplan wordt kort; zet je hem fout, dan geef je een referentie uit die de telefoon niet zal gebruiken. Behandel de stappen hieronder als een reeks, want elke stap vernauwt de keuzes die voor de volgende beschikbaar zijn.

Stap één: kies het inschrijvingspad

Handmatige configuratie betekent dat de gebruiker het serveradres invoert, de authenticatiemethode kiest en alle referenties opgeeft die de interface toestaat. Beheerde inschrijving betekent dat een profiel het adres, de identificaties en een verwijzing naar een referentielading draagt. Het beheerde pad kan combinaties uitdrukken die het handmatige scherm niet kan, daarom moet de certificaatbeslissing na deze keuze komen en niet ervoor.

Beide paden kunnen een telefoon authenticeren. Ze verschillen in wat je kunt configureren en wie de identiteit bezit, dus kies er bewust één in plaats van een beheerd profiel te mengen met handmatige invoer van referenties.

Stap twee: kies algoritmen voor het pad dat je hebt gekozen

Voor handmatig geconfigureerde iPhones bevelen de iOS-interoperabiliteitsnotities van strongSwan een RSA-servercertificaat aan, omdat de handmatige client een ECDSA-servercertificaat mogelijk niet accepteert; dezelfde notities behandelen macOS apart. Lees dit als richtlijn voor de ondersteunde clientset, niet als een permanente wet over Apple-apparaten. Een beheerd profiel heeft meer ruimte: het kan een certificaattype expliciet kiezen, inclusief een ECDSA-clientidentiteit, wanneer de lading en de gateway beide dat ondersteunen.

Valideer de iOS-versies die je echt ondersteunt voordat je iets uitrolt. Een laboratoriumtelefoon op de nieuwste versie beschrijft geen vloot die oudere apparaten bevat, en een algoritme dat in het laboratorium werkt, kan alsnog falen op de oudste telefoon in het veld. Haal het versiebereik uit apparaatbeheer en niet uit je geheugen. Als de vloot meerdere versies omvat, test dan eerst de oudste, want daar is de handmatige interface het meest beperkend.

Stap drie: lees de profielvelden als afzonderlijke dingen

Verschillende sleutels met vergelijkbare namen beschrijven verschillende objecten. Het externe adres is de host die de telefoon belt. De externe identificatie is de IKE-identiteit die hij van de gateway verwacht. De certificaatverwijzing in de lading wijst naar een clientreferentie, en het veld voor het certificaattype kiest het type dat voor IKEv2-machineauthenticatie wordt gebruikt. Geen daarvan is het handtekeningalgoritme van de CA, ook al overlappen de woorden.

Apple's IKEv2-ladingreferentie vermeldt RSA als het standaard certificaattype met expliciete ECDSA-varianten, en koppelt de sleutel van de uitgeversnaam aan bepaalde authenticatie-instellingen. Lees die relaties in de referentie voor de methode die je koos in plaats van één sleutel uit een werkende uitrol te kopiëren.

Stap vier: laat de identiteit van de gateway overeenkomen met het certificaat

Gebruik een expliciete gateway-naam, bijvoorbeeld vpn.example.com en zet een overeenkomende alternatieve subjectnaam in het servercertificaat. De Apple-richtlijn van strongSwan verwacht ook het uitgebreide sleutelgebruik voor serverauthenticatie. RSA of ECDSA kiezen verandert daar niets aan: een algoritme kan een naamverschil, een ontbrekende EKU of een onvolledige keten niet repareren.

Het distribueren van de vertrouwensanker is een aparte taak van het bevestigen van de identiteit. De telefoon heeft een certificaatketen nodig die hij kan valideren, en hij moet zo worden geconfigureerd dat hij de naam verwacht die je werkelijk in het certificaat hebt gezet.

Dat een ander platform met succes verbindt, is bewijs over de validatieregels van dat platform, geen toestemming om die van de telefoon te versoepelen. Houd de controles identiek over clients, tenzij je een gedocumenteerde reden hebt om af te wijken.

Stap vijf: scheid de clientidentiteit van het CA-vertrouwen

Een clientcertificaat en de bijbehorende privésleutel zijn niet hetzelfde object als het CA-certificaat dat de telefoon vertrouwt. Een CA-certificaat in een PKCS#12-identiteit bundelen installeert het niet automatisch als vertrouwensanker op elk ondersteund apparaat, dus behandel vertrouwensdistributie als een eigen stap met eigen verificatie.

Als het ontwerp in plaats daarvan wachtwoordgebaseerde EAP gebruikt, heeft de telefoon de bedoelde accountauthenticatie plus servervalidatie nodig. Dat pad rechtvaardigt niet het versturen van één gedeelde privésleutel van de client naar de hele vloot, wat een ander ontwerp is met een veel slechtere faalmodus.

Rond het plan af met vernieuwing en intrekking in gedachten: wie de clientreferentie opnieuw uitgeeft, hoe het profiel wordt bijgewerkt en hoe een verloren telefoon wordt afgesneden. Registreer de profielversie en de apparaatversies waartegen je hebt gevalideerd, want die registratie maakt de volgende certificaatwissel een routinematige wijziging.