Sådan importerer du et VPN-certifikat på Android og verificerer nøglen

Import af et VPN-klientcertifikat på Android tager et par minutter. At kontrollere, at det landede det rigtige sted, tager længere tid, og det er den del, de fleste springer over, når installationsdialogen melder succes. En succesmeddelelse betyder kun, at filen blev parset. Den siger intet om, hvilken udbyder der har den private nøgle, eller om der stadig ligger en kopi i din Downloads-mappe.

Trin 1: Læs P12, før den forlader din maskine

Start med selve filen. Hvis du ikke kan navngive subjektet, udstederen og udløbsdatoen i den, importerer du noget, du ikke kan verificere senere.

En PKCS#12-pakke indeholder normalt et klientcertifikat, dets private nøgle og udstederkæden. openssl pkcs12 -in client.p12 -info -noout udskriver MAC og krypteringsalgoritmerne uden at dumpe nøglemateriale, så du kan se, om pakken er adgangskodebeskyttet, og med hvilken cipher. Følg op med keytool -list -v -keystore client.p12 -storetype PKCS12 for at få alias, SHA-256-fingeraftrykket og gyldighedsvinduet, som du vil sammenligne med telefonen.

Send adgangskoden ad en anden kanal end filen, eller overdrag filen i et styret distributionsflow, der ikke efterlader en kopi. En adgangskode, der indsættes i samme chatbesked som arkivet, gør to kontroller til én.

Trin 2: Installer den i det slot, VPN-appen faktisk læser

På standard Android 11 til 14 går vejen gennem Indstillinger, Sikkerhed, Kryptering og legitimationsoplysninger, Installer et certifikat, derefter VPN og appbrugercertifikat. Ordlyden og indlejringen flytter sig mellem udgivelser og producenters skins, så følg etiketten for legitimationsoplysningstypen i stedet for en husket menuplacering. I en arbejdsprofil skal du installere indefra arbejdssiden, fordi legitimationsoplysninger ikke krydser profilgrænsen.

Sæt ikke en klientidentitet i CA-certifikatsporet. Det spor fodrer brugerens tillidslager, og siden Android 7 har apps ignoreret brugeroplevede CA'er, medmindre deres netværkssikkerhedskonfiguration tillader det, så et klientcertifikat, der parkeres der, vises aldrig i VPN-nøglevælgeren.

Nogle VPN-klienter rører aldrig systemlageret og importerer i stedet P12 i deres egen appmappe. Det er et legitimt design, men det ændrer alle senere trin: nøglen lever nu under appens sandkasse og er præcis så stærk, som appen håndterer sit eget lager. Læs klientens dokumentation, før du antager, at KeyChain er i spil.

Trin 3: Bevis, hvilken udbyder der har nøglen

En import bekræfter parsning, ikke hardwareunderstøttelse. På Android 12 og nyere rapporterer KeyInfo.getSecurityLevel(), om en nøgle sidder i Trusted Execution Environment, i StrongBox eller i software, og det erstatter det ældre isInsideSecureHardware()-kald. Hvis VPN-klienten ikke viser den værdi, er fingeraftrykket fra trin 1 dit reservevalg. Et certifikat, der genkodes under import, matcher ikke byte for byte, men den offentlige nøgle og subjektet gør stadig.

Ikke-eksporterbar er ikke det samme som ubrugelig. En nøgle, der ikke kan forlade enheden, kan stadig bruges af enhver app, som brugeren giver lov til at vælge det alias, og derfor er aliasprompten en reel kontrol og ikke en formalitet. Android Keystore-dokumentationen er værd at læse en gang, hvis du træffer den designbeslutning.

Tag så højde for de kopier, du lavede. P12 på din bærbare, den i billetvedhæftningen og den i sidste måneds backup er alle stadig gyldige identiteter, indtil udstederen tilbagekalder dem. Hardwarebeskyttelse af forekomsten på telefonen gør intet for dem.

Trin 4: Find ud af, hvem der ejer kravet om skærmlås

Tre hemmeligheder blandes sammen her: enhedens oplåsnings-PIN, den private nøgles adgangssætning og VPN-kontoens adgangskode. En prompt for én er aldrig en anmodning om at nulstille de andre, og at nulstille den forkerte er måden, hvorpå folk låser sig ude af en profil, der fungerede fint.

Når en enhedsadministrator eller en politik for en administreret profil kræver en lås, tilhører kravet den politik, ikke certifikatet. adb shell dumpsys device_policy lister de aktive administratorer og den adgangskodekvalitet, de håndhæver, hvilket er den hurtigste måde at se, om en MDM-agent er grunden til, at dine PIN-regler blev ændret. Fjernelse af certifikatet lemper ikke politikken, og fjernelse af politikken er en administrativ beslutning snarere end en indstillingsjustering.

Forvent også et kompromis med brugervenligheden. Hvis nøglen kræver brugergodkendelse, kan tunnelen ikke komme op før første oplåsning, så planlagte synkroniseringer og fjernopvågninger fejler per design. Beslut det før udrulning, ikke efter.

Undgå genvejen med at redigere locksettings.db eller genafspille en gammel omvej til et glemt mønster. Disse rutiner blev skrevet til bestemte builds, de kan efterlade legitimationslageret i en tilstand, som frameworket ikke længere forventer, og de ændrer aldrig den politik, der bad om låsen i første omgang.

Trin 5: Udfas identiteten og verificer afvisningen

Udfasning har tre dele, og kun den første er lokal. Fjern VPN-profilen, slet brugercertifikatet under Indstillinger, Sikkerhed, Kryptering og legitimationsoplysninger, Brugerlegitimationsoplysninger, og få derefter udstederen til at tilbagekalde certifikatets serienummer. Den lokale sletning alene efterlader en legitimation, som serveren stadig accepterer, hvis nogen har beholdt P12.

Verificer resultatet i stedet for at antage det. Prøv en forbindelse med den udfasede profil, og bekræft, at serveren afviser den. En tunnel, der stadig kommer op, betyder, at du tilbagekaldte det forkerte serienummer, eller at klienten i stilhed faldt tilbage til en anden installeret identitet.

Hvis du ruller en mislykket import tilbage, skal du importere igen fra den oprindelige krypterede pakke og tjekke fingeraftrykket igen i stedet for at genbruge en dekrypteret nøglefil, du har efterladt på disken.