Android IKEv2: användarcertifikatet och CA:n har olika uppgifter
Ett fält bevisar vem telefonen är, det andra avgör vilken gateway som ska litas på. Androids IKEv2-profil håller dem åtskilda eftersom handskakningen gör det.
En Android IKEv2-skärm som ber om både ett användarcertifikat och ett CA-certifikat ser ut att vilja ha samma sak två gånger. Det gör den inte. IKEv2 autentiserar båda parterna, i båda riktningarna, inom samma utbyte, och telefonen spelar en annan roll i varje riktning: den måste bevisa vem den är och den måste avgöra vilken gateway den tror på. Ett användarcertifikat svarar på den första frågan, en betrodd CA på den andra, och ingendera kan ersätta den andra.
Två riktningar av autentisering i ett utbyte
IKEv2 upprättar en kontrollkanal i två faser. Det första utbytet förhandlar algoritmer och nycklar; det andra, IKE_AUTH, bär en AUTH-nyttolast från varje sida tillsammans med varje sidas identitet. Nyttolasten är en signatur eller MAC beräknad över utbytet och verifieras mot något som mottagaren redan litar på.
Gatewayen bevisar sin identitet med sitt eget certifikat, och telefonen validerar certifikatets kedja upp till en rot som den är beredd att lita på och kontrollerar sedan att identiteten i certifikatet matchar den gateway den avsåg att nå. Telefonen bevisar sin identitet med sin egen autentiseringsuppgift, och gatewayen verifierar den mot den CA som utfärdade klientcertifikatet.
Det är hela mekanismen bakom de två fälten. Användarcertifikatet är ett påstående telefonen gör om sig själv; CA-fältet är ett påstående om vem telefonen kommer att tro på. En profil som har det ena men inte det andra kan inte slutföra ömsesidig autentisering, och inget antal nya försök ändrar det. De två felen ser till och med olika ut: en saknad användarnyckel hindrar telefonen från att alls skapa en signatur, medan ett saknat betrott ankare hindrar den från att acceptera gatewayens certifikat.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Vad profilbyggaren i Android frågar efter
Googles IKEv2-profilbyggare exponerar varje autentiseringsmetod separat i stället för som ett enda certifikatläge. Metoden för digital signatur tar ett användarcertifikat, en privat nyckel och en rot-CA för servern. De andra metoderna tar ett användarnamn och lösenord, eller en i förväg delad nyckel.
Läs den signaturen noga, för den kodar mekanismen ovan. Det finns inget fält för användarens privata nyckel i metoden med användarnamn och lösenord, och inget fält för gatewayens betrodda ankare i PSK-metoden, av det enkla skälet att dessa metoder bevisar olika saker. Att blanda dem genom att klistra in ett lösenord i ett certifikatfält ger en profil som misslyckas vid IKE_AUTH med ett meddelande som inte namnger någon av dem.
Den dokumenterade nyckeltypen för metoden med digital signatur är RSA. En meny märkt IPsec eller certifikat innebär inte stöd för ECDSA, och en profil som satts ihop med antagandet att det finns kommer att misslyckas i plattformens API innan nätverket ens är inblandat.
Varför ett offentligt användarcertifikat inte räcker
AUTH-nyttolasten är en signatur över utbytet, gjord med klientens privata nyckel. Att ha det offentliga certifikatet låter gatewayen kontrollera en signatur; för telefonen gör det ingenting, eftersom den behöver nyckeln för att skapa en. Att bara importera .crt och lämna nyckeln kvar är den vanligaste varianten av detta fel.
Androids nyckelinfrastruktur speglar det. Att välja en klientidentitet går via KeyChain, som kräver åtkomst till motsvarande privata nyckel, inte bara en certifikatpost. Ett registreringspaket eller ett arbetsflöde för enhetshantering som installerar paret tillsammans är det normala sättet att få en användbar identitet; att kopiera en certifikatfil för hand är det oftast inte.
De två posterna i profilen är alltså inte ett certifikatpaket och en dubblett av det. Den ena är ett nyckelpar som plattformen måste kunna signera med, den andra är ett betrott ankare som plattformen jämför mot. Kontrollera dem som två separata fakta: kan den här profilen signera, och vet den vem den ska lita på?
Betrodda ankare tillhör en applikation, inte telefonen
Att installera ett rotcertifikat i användarlagret gör inte att varje Android-applikation litar på det: sedan Android 7 måste en app välja in det via sin nätverkssäkerhetskonfiguration, och före den versionen accepterades användarinstallerade CA:er mycket bredare. Applikationers förtroendekonfiguration kan skilja sig, och en VPN-klient som hanterar sitt eget förtroendematerial kanske aldrig tittar i användarlagret. Det är därför samma CA-fil kan fungera i en klient och verka ignoreras i en annan.
Två ägarmodeller följer. En systemhanterad VPN-profil använder enhetens certifikatinstallation eller administratörens registreringsflöde, och profilen refererar sedan den avsedda CA:n. En apphanterad VPN behåller sitt eget förtroendematerial och använder sin egen dokumenterade import, som kan vara helt separat från Android-inställningarna. Det är också där du reparerar en bruten kedja: i CA-lagret och profilvalet för det systemhanterade fallet, i klientens egen importskärm för det apphanterade.
Bestäm vilken modell du är i innan du importerar något och bekräfta sedan den aktiva profilens förtroendeval. Om operatörens instruktioner och klientens meny inte stämmer överens gäller klientens dokumenterade beteende för den installationen, men CA:n måste ändå komma från operatören via en kanal du kan verifiera. En fils namn är inte bevis på vem som utfärdade den.
Välj läget, sedan filerna
Certifikatläget behöver ett klientnyckelpar, den utfärdande CA:n på gatewayens sida, ett betrott ankare för gatewayens certifikat och en förväntan om vilken identitet certifikatet måste bära. Läget med användarnamn och lösenord ersätter klientnyckelparet med autentiseringsuppgifter men behåller kravet på gatewayförtroende intakt. PSK-läget ersätter båda med en delad hemlighet och ändrar förtroendemodellen i stället för att förenkla den.
Vilket du än väljer, håll normal validering påslagen. Ett alternativ som inte verifiera, där en klient erbjuder det, tar bort den kontroll som CA-fältet finns för att utföra; det åtgärdar inte ett saknat betrott ankare. Samma sak gäller att acceptera vilket servercertifikat som helst för att anslutningen fungerar utan det.
Verifiera sedan på rätt ställe: importera materialet, anslut en gång och bekräfta i klientens anslutningsdetaljer att gatewayens identitet är den du förväntade dig och att profilen rapporterar den autentiseringsmetod du avsåg att använda. En lyckad anslutning med fel metod vald är en konfiguration du ännu inte förstår, och den kommer att misslyckas nästa gång operatören skärper en policy.