Slik importerer du et VPN-sertifikat på Android og verifiserer nøkkelen

Å importere et VPN-klientssertifikat på Android tar et par minutter. Å kontrollere at det havnet på riktig sted tar lengre tid, og det er den delen folk flest hopper over når installasjonsdialogen melder suksess. En suksessmelding betyr bare at filen ble parset. Den sier ingenting om hvilken tilbyder som holder den private nøkkelen, eller om det fortsatt ligger en kopi i Downloads-mappen din.

Trinn 1: Les P12 før den forlater maskinen din

Start med selve filen. Hvis du ikke kan navngi subjektet, utstederen og utløpsdatoen i den, importerer du noe du ikke vil kunne verifisere senere.

En PKCS#12-pakke inneholder vanligvis et klientssertifikat, den private nøkkelen og utstederkjeden. openssl pkcs12 -in client.p12 -info -noout skriver ut MAC og krypteringsalgoritmene uten å dumpe nøkkelmateriale, så du ser om pakken er passordbeskyttet og med hvilken chiffre. Følg opp med keytool -list -v -keystore client.p12 -storetype PKCS12 for å få alias, SHA-256-fingeravtrykket og gyldighetsvinduet du skal sammenligne med telefonen.

Send passordet via en annen kanal enn filen, eller overlever filen i en styrt distribusjonsflyt som ikke etterlater en kopi. Et passord som limes inn i samme chatmelding som arkivet, gjør to kontroller til én.

Trinn 2: Installer det i sporet VPN-appen faktisk leser

På vanlig Android 11 til 14 går veien gjennom Innstillinger, Sikkerhet, Kryptering og påloggingsinformasjon, Installer et sertifikat, deretter VPN og appbrukersertifikat. Ordlyden og innstikkingen flytter seg mellom utgivelser og leverandørskall, så følg etiketten for påloggingsinformasjonstypen i stedet for en innlært menyplassering. I en arbeidsprofil installerer du fra innsiden av arbeidssiden, fordi påloggingsinformasjon ikke krysser profilgrensen.

Ikke legg en klientidentitet i CA-sertifikatsporet. Det sporet mater brukerens tillitslager, og siden Android 7 har apper ignorert brukertilførte CA-er med mindre nettverkssikkerhetskonfigurasjonen deres tillater det, så et klientsertifikat som parkeres der, dukker aldri opp i VPN-nøkkelvelgeren.

Noen VPN-klienter rører aldri systemlageret og importerer P12 i sin egen appkatalog i stedet. Det er en legitim design, men den endrer hvert senere trinn: nøkkelen lever nå under appens sandkasse og er nøyaktig så sterk som den appen håndterer sitt eget lager. Sjekk klientdokumentasjonen før du antar at KeyChain er i spill.

Trinn 3: Bevis hvilken tilbyder som holder nøkkelen

En import bekrefter parsing, ikke maskinvarestøtte. På Android 12 og nyere rapporterer KeyInfo.getSecurityLevel() om en nøkkel sitter i det klarerte kjøremiljøet, i StrongBox eller i programvare, og det erstatter det eldre isInsideSecureHardware()-kallet. Hvis VPN-klienten ikke viser den verdien, er fingeravtrykket fra trinn 1 din reserve. Et sertifikat som kodes på nytt under import, vil ikke samsvare byte for byte, men den offentlige nøkkelen og subjektet vil fortsatt gjøre det.

Ikke-eksporterbar er ikke det samme som ubrukelig. En nøkkel som ikke kan forlate enheten, kan fortsatt brukes av enhver app brukeren gir tillatelse til å velge det aliaset, og derfor er alias-spørringen en reell kontroll og ikke en formalitet. Android Keystore-dokumentasjonen er verdt en gjennomlesing hvis du tar den designbeslutningen.

Regn så med kopiene du lagde. P12 på den bærbare, den i sakvedlegget og den i forrige måneds sikkerhetskopi er alle fortsatt gyldige identiteter til utstederen tilbakekaller dem. Maskinvarbeskyttelsen av forekomsten på telefonen gjør ingenting for dem.

Trinn 4: Finn ut hvem som eier kravet om skjermlås

Tre hemmeligheter blandes sammen her: enhetens opplåsings-PIN, passfrasen for den private nøkkelen og passordet for VPN-kontoen. En forespørsel om én er aldri en anmodning om å tilbakestille de andre, og å tilbakestille feil er måten folk låser seg ute av en profil som fungerte fint.

Når en enhetsadministrator eller en policy for administrert profil krever en lås, tilhører kravet den policyen, ikke sertifikatet. adb shell dumpsys device_policy lister de aktive administratorene og passordkvaliteten de håndhever, som er den raskeste måten å se om en MDM-agent er grunnen til at PIN-reglene dine endret seg. Å fjerne sertifikatet lemper ikke policyen, og å fjerne policyen er en administrativ beslutning snarere enn en innstillingsjustering.

Forvent også et kompromiss med brukervennligheten. Hvis nøkkelen krever brukergodkjenning, kan tunnelen ikke komme opp før første opplåsing, så planlagte synkroniseringer og fjernoppvåkninger feiler per design. Bestem det før utrulling, ikke etter.

Unngå snarveien med å redigere locksettings.db eller spille av en gammel omvei for et glemt mønster. Disse rutinene ble skrevet for bestemte builds, de kan etterlate påloggingslageret i en tilstand som rammeverket ikke lenger forventer, og de endrer aldri policyen som ba om låsen i utgangspunktet.

Trinn 5: Avvikle identiteten og verifiser avvisningen

Avvikling har tre deler, og bare den første er lokal. Fjern VPN-profilen, slett brukersertifikatet under Innstillinger, Sikkerhet, Kryptering og påloggingsinformasjon, Brukerpåloggingsinformasjon, og la deretter utstederen tilbakekalle serienummeret til sertifikatet. Den lokale slettingen alene etterlater en påloggingsinformasjon som serveren fortsatt godtar hvis noen beholdt P12.

Verifiser resultatet i stedet for å anta det. Prøv en tilkobling med den avviklede profilen og bekreft at serveren avviser den. En tunnel som fortsatt kommer opp, betyr at du tilbakekalte feil serienummer, eller at klienten stille falt tilbake til en annen installert identitet.

Hvis du ruller tilbake en mislykket import, importer på nytt fra den opprinnelige krypterte pakken og sjekk fingeravtrykket igjen i stedet for å gjenbruke en dekryptert nøkkelfil du lot ligge på disken.