IKEv2-certifikat på iPhone: manuell eller hanterad registrering

Att välja RSA för att gatewayens certifikatverktyg använder det som standard är ett beslut som fattas före frågan som spelar roll: hur ska dessa iPhone registreras? En anslutning som användaren skriver in själv och en konfigurationsprofil som levereras av hanteringen visar olika inställningar, och vissa certifikatval finns bara på en av dessa vägar. Får du ordningen rätt blir certifikatplanen kort; får du den fel utfärdar du autentiseringsuppgifter som telefonen inte kommer att använda. Behandla stegen nedan som en sekvens, eftersom varje steg begränsar de val som är tillgängliga för nästa.

Steg ett: välj registreringsvägen

Manuell konfiguration innebär att användaren anger serverns adress, väljer autentiseringsmetod och tillhandahåller alla autentiseringsuppgifter som gränssnittet tillåter. Hanterad registrering innebär att en profil bär adressen, identifierarna och en referens till en nyttolast med autentiseringsuppgifter. Den hanterade vägen kan uttrycka kombinationer som den manuella skärmen inte kan, därför måste certifikatbeslutet komma efter detta val, inte före.

Båda vägarna kan autentisera en telefon. De skiljer sig i vad som kan konfigureras och vem som äger identiteten, så välj en medvetet i stället för att blanda en hanterad profil med manuell inmatning av autentiseringsuppgifter.

Steg två: välj algoritmer för den väg du valde

För manuellt konfigurerade iPhone rekommenderar strongSwans iOS-interoperabilitetsanteckningar ett RSA-servercertifikat, eftersom den manuella klienten kanske inte accepterar ett ECDSA-servercertifikat; samma anteckningar behandlar macOS separat. Läs detta som vägledning för den stödda klientgruppen, inte som en permanent lag om Apple-enheter. En hanterad profil har mer utrymme: den kan välja certifikattyp explicit, inklusive en ECDSA-klientidentitet, när nyttolasten och gatewayen båda stöder det.

Validera de iOS-versioner du faktiskt stöder innan du rullar ut något. En laboratorietelefon på den senaste versionen beskriver inte en flotta som omfattar äldre enheter, och en algoritm som fungerar i laboratoriet kan ändå misslyckas på den äldsta telefonen i fält. Hämta versionsintervallet från enhetshanteringen och inte från minnet. Om flottan spänner över flera versioner, testa den äldsta först, eftersom det är där det manuella gränssnittet är mest begränsande.

Steg tre: läs profilfälten som separata saker

Flera nycklar med liknande namn beskriver olika objekt. Fjärradressen är värden som telefonen ringer. Fjärridentiteten är den IKE-identitet som den förväntar sig att gatewayen presenterar. Certifikatreferensen i nyttolasten pekar på klientautentiseringsuppgifter, och fältet för certifikattyp väljer den typ som används för IKEv2-maskinautentisering. Ingen av dessa är CA:ns signaturalgoritm, även om orden överlappar.

Apples IKEv2-nyttolastreferens listar RSA som standardcertifikattyp med explicita ECDSA-varianter, och den kopplar utfärdarnamnnyckeln till särskilda autentiseringsinställningar. Läs dessa relationer i referensen för den metod du valde i stället för att kopiera en nyckel från en fungerande driftsättning.

Steg fyra: få gatewayens identitet att matcha dess certifikat

Använd ett explicit gatewaynamn, till exempel vpn.example.com och placera ett matchande alternativt subjektnamn i servercertifikatet. strongSwans Apple-vägledning förväntar sig också den utökade nyckelanvändningen för serverautentisering. Valet av RSA eller ECDSA ändrar inget av detta: en algoritm kan inte reparera en namnavvikelse, en saknad EKU eller en ofullständig kedja.

Distribution av förtroendeankaret är en separat uppgift från att hävda identiteten. Telefonen behöver en certifikatkedja som den kan validera, och den måste konfigureras att förvänta sig det namn du faktiskt satte i certifikatet.

Att en annan plattform ansluter framgångsrikt är bevis om den plattformens valideringsregler, inte tillstånd att lätta på telefonens. Håll kontrollerna identiska mellan klienter om du inte har en dokumenterad anledning att avvika.

Steg fem: skilj klientidentiteten från CA-förtroendet

Ett klientcertifikat och dess privata nyckel är inte samma objekt som det CA-certifikat telefonen litar på. Att paketera ett CA-certifikat i en PKCS#12-identitet installerar det inte automatiskt som förtroendeankare på varje stödd enhet, så behandla distribution av förtroende som ett eget steg med egen verifiering.

Om designen i stället använder lösenordsbaserad EAP behöver telefonen den avsedda kontoautentiseringen plus servervalidering. Den vägen motiverar inte att skicka en delad privat klientnyckel till hela flottan, vilket är en annan design med ett mycket sämre felbeteende.

Avsluta planen med förnyelse och återkallelse i åtanke: vem som återutfärdar klientautentiseringsuppgifterna, hur profilen uppdateras och hur en förlorad telefon stängs av. Registrera profilversionen och de enhetsversioner du validerade mot, eftersom den registreringen är det som gör nästa certifikatbyte till en rutinändring.