Så importerar du ett VPN-certifikat på Android och verifierar nyckeln

Att importera ett VPN-klientcertifikat på Android tar ett par minuter. Att kontrollera att det landade på rätt ställe tar längre tid, och det är den delen de flesta hoppar över när installationsdialogen säger att det lyckades. Ett lyckat meddelande betyder bara att filen parsades. Det säger ingenting om vilken leverantör som håller den privata nyckeln eller om en kopia fortfarande ligger i din Downloads-mapp.

Steg 1: Läs P12 innan den lämnar din maskin

Börja med själva filen. Om du inte kan namnge subjektet, utgivaren och utgångsdatumet i den, importerar du något du inte kommer att kunna verifiera senare.

Ett PKCS#12-paket innehåller vanligtvis ett klientcertifikat, dess privata nyckel och utgivarkedjan. openssl pkcs12 -in client.p12 -info -noout skriver ut MAC och krypteringsalgoritmerna utan att dumpa nyckelmaterial, så du ser om paketet är lösenordsskyddat och med vilket chiffer. Följ upp med keytool -list -v -keystore client.p12 -storetype PKCS12 för att få alias, SHA-256-fingeravtrycket och giltighetsfönstret du ska jämföra med telefonen.

Skicka lösenordet via en annan kanal än filen, eller överlämna filen i ett hanterat distributionsflöde som inte lämnar någon kopia. Ett lösenord som klistras in i samma chattmeddelande som arkivet gör två kontroller till en.

Steg 2: Installera det i spåret som VPN-appen faktiskt läser

På vanlig Android 11 till 14 går vägen genom Inställningar, Säkerhet, Kryptering och inloggningsuppgifter, Installera ett certifikat, sedan VPN och appens användarcertifikat. Formuleringen och nästlingen flyttar sig mellan utgåvor och tillverkarskal, så följ etiketten för inloggningsuppgiftstypen i stället för en inlärd menyplacering. I en arbetsprofil installerar du inifrån arbetssidan, eftersom inloggningsuppgifter inte korsar profilgränsen.

Lägg inte en klientidentitet i CA-certifikatspåret. Det spåret matar användarens förtroendelager, och sedan Android 7 har appar ignorerat användartillagda CA:n om inte deras nätverkssäkerhetskonfiguration tillåter det, så ett klientcertifikat som parkeras där dyker aldrig upp i VPN:ns nyckelväljare.

Vissa VPN-klienter rör aldrig systemlagret och importerar P12 till sin egen appkatalog i stället. Det är en legitim design, men den ändrar varje senare steg: nyckeln lever nu under appens sandlåda och är exakt så stark som den appen hanterar sin egen lagring. Kontrollera klientens dokumentation innan du antar att KeyChain är inblandat.

Steg 3: Bevisa vilken leverantör som håller nyckeln

En import bekräftar parsning, inte hårdvarustöd. På Android 12 och senare rapporterar KeyInfo.getSecurityLevel() om en nyckel sitter i den betrodda körningsmiljön, i StrongBox eller i programvara, och det ersätter det äldre isInsideSecureHardware()-anropet. Om VPN-klienten inte visar det värdet är fingeravtrycket från steg 1 din reserv. Ett certifikat som kodas om under importen matchar inte byte för byte, men den publika nyckeln och subjektet gör det fortfarande.

Icke-exporterbar är inte detsamma som oanvändbar. En nyckel som inte kan lämna enheten kan fortfarande användas av vilken app som helst som användaren ger tillstånd att välja det aliaset, och det är därför aliasfrågan är en verklig kontroll och inte en formalitet. Android Keystore-dokumentationen är värd en genomläsning om du fattar det designbeslutet.

Räkna sedan med kopiorna du gjorde. P12 på din bärbara dator, den i ärendebilagan och den i förra månadens säkerhetskopia är alla fortfarande giltiga identiteter tills utgivaren återkallar dem. Hårdvaruskyddet för instansen på telefonen gör ingenting för dem.

Steg 4: Ta reda på vem som äger kravet på skärmlås

Tre hemligheter blandas ihop här: enhetens upplåsnings-PIN, lösenfrasen för den privata nyckeln och lösenordet för VPN-kontot. En fråga om en är aldrig en begäran att återställa de andra, och att återställa fel är hur folk låser sig ute från en profil som fungerade bra.

När en enhetsadministratör eller en policy för hanterad profil kräver ett lås tillhör kravet den policyn, inte certifikatet. adb shell dumpsys device_policy listar de aktiva administratörerna och den lösenordskvalitet de upprätthåller, vilket är det snabbaste sättet att se om en MDM-agent är anledningen till att dina PIN-regler ändrades. Att ta bort certifikatet lättar inte på policyn, och att ta bort policyn är ett administrativt beslut snarare än en inställningsjustering.

Förvänta dig också en kompromiss med användbarheten. Om nyckeln kräver användargodkännande kan tunneln inte komma upp före första upplåsningen, så schemalagda synkroniseringar och fjärrväckningar misslyckas enligt design. Bestäm det före utrullningen, inte efter.

Undvik genvägen att redigera locksettings.db eller spela upp en gammal kringgående lösning för ett glömt mönster. Dessa rutiner skrevs för specifika builds, de kan lämna inloggningsuppgiftslagret i ett tillstånd som ramverket inte längre förväntar sig, och de ändrar aldrig policyn som bad om låset från början.

Steg 5: Avveckla identiteten och verifiera avvisningen

Avvecklingen har tre delar och bara den första är lokal. Ta bort VPN-profilen, radera användarcertifikatet under Inställningar, Säkerhet, Kryptering och inloggningsuppgifter, Användarinloggningsuppgifter, och låt sedan utgivaren återkalla certifikatets serienummer. Enbart den lokala raderingen lämnar en inloggningsuppgift som servern fortfarande accepterar om någon behöll P12.

Verifiera resultatet i stället för att anta det. Prova en anslutning med den avvecklade profilen och bekräfta att servern avvisar den. En tunnel som fortfarande kommer upp betyder att du återkallade fel serienummer eller att klienten tyst föll tillbaka på en annan installerad identitet.

Om du rullar tillbaka en misslyckad import, importera igen från det ursprungliga krypterade paketet och kontrollera fingeravtrycket igen i stället för att återanvända en dekrypterad nyckelfil som du lämnat på disken.