Slik importerer du eit VPN-sertifikat på Android og stadfester nøkkelen
Importer ein P12 på Android, stadfest kva tilbydar som held nøkkelen, og finn ut kven som eigentleg eig kravet om skjermlås.
Å importere eit VPN-klientssertifikat på Android tek eit par minutt. Å kontrollere at det landa på rett stad tek lengre tid, og det er den delen folk flest hoppar over når installasjonsdialogen melder suksess. Ei suksessmelding betyr berre at fila vart parsa. Ho seier ingenting om kva tilbydar som held den private nøkkelen, eller om det framleis ligg ei kopi i Downloads-mappa di.
Steg 1: Les P12 før ho forlet maskina di
Start med sjølve fila. Viss du ikkje kan namngje subjektet, utferdaren og utløpsdatoen i ho, importerer du noko du ikkje vil kunne verifisere seinare.
Ei PKCS#12-pakke inneheld vanlegvis eit klientssertifikat, den private nøkkelen og utferdarkjeda. openssl pkcs12 -in client.p12 -info -noout skriv ut MAC og krypteringsalgoritmane utan å dumpe nøkkelmateriale, så du ser om pakka er passordverna og med kva chiffer. Følg opp med keytool -list -v -keystore client.p12 -storetype PKCS12 for å få alias, SHA-256-fingeravtrykket og gyldigheitsvindauget du skal samanlikne med telefonen.
Send passordet gjennom ein annan kanal enn fila, eller overlever fila i ein styrt distribusjonsflyt som ikkje let etter seg ei kopi. Eit passord som vert limt inn i same chatmeldinga som arkivet, gjer to kontrollar til éin.
Steg 2: Installer det i sporet VPN-appen faktisk les
På vanleg Android 11 til 14 går vegen gjennom Innstillingar, Sikkerheit, Kryptering og påloggingsinformasjon, Installer eit sertifikat, deretter VPN og appbrukarsertifikat. Ordlyden og innstikkinga flyttar seg mellom utgivingar og leverandørskal, så følg etiketten for påloggingsinformasjonstypen i staden for ein innlærd menyplassering. I ein arbeidsprofil installerer du frå innsida av arbeidssida, fordi påloggingsinformasjon ikkje kryssar profilgrensa.
Ikkje legg ein klientidentitet i CA-sertifikatsporet. Det sporet matar tillitslageret til brukaren, og sidan Android 7 har appar ignorert brukartilførte CA-ar med mindre nettverkssikkerheitskonfigurasjonen deira tillèt det, så eit klientsertifikat som vert parkert der, dukkar aldri opp i VPN-nøkkelveljaren.
Nokre VPN-klientar rører aldri systemlageret og importerer P12 i sin eigen appkatalog i staden. Det er ein legitim design, men han endrar kvart seinare steg: nøkkelen lever no under sandkassa til appen og er nøyaktig så sterk som den appen handterer sitt eige lager. Sjekk klientdokumentasjonen før du går ut frå at KeyChain er i spel.
Steg 3: Prov kva tilbydar som held nøkkelen
Ein import stadfester parsing, ikkje maskinvarestøtte. På Android 12 og nyare rapporterer KeyInfo.getSecurityLevel() om ein nøkkel sit i det klarerte køyremiljøet, i StrongBox eller i programvare, og det erstattar det eldre isInsideSecureHardware()-kallet. Viss VPN-klienten ikkje viser den verdien, er fingeravtrykket frå steg 1 din reserve. Eit sertifikat som vert koda på nytt under import, vil ikkje samsvare byte for byte, men den offentlege nøkkelen og subjektet vil framleis gjere det.
Ikkje-eksporterbar er ikkje det same som ubrukeleg. Ein nøkkel som ikkje kan forlate eininga, kan framleis brukast av kvar app brukaren gjev løyve til å velje det aliaset, og difor er alias-spurnaden ein reell kontroll og ikkje ein formalitet. Android Keystore-dokumentasjonen er verdt ein gjennomlesing viss du tek den designavgjerda.
Rekn så med kopiane du laga. P12 på den berebære, den i saksvedlegget og den i førre månads sikkerheitskopi er alle framleis gyldige identitetar til utferdaren kallar dei tilbake. Maskinvarevernet av førekomsten på telefonen gjer ingenting for dei.
Steg 4: Finn ut kven som eig kravet om skjermlås
Tre hemmelegheiter vert blanda saman her: opplåsings-PIN-en til eininga, passfrasen for den private nøkkelen og passordet for VPN-kontoen. Ein spurnad om éin er aldri ei oppmoding om å nullstille dei andre, og å nullstille feil er måten folk låser seg ute av ein profil som fungerte fint.
Når ein einingadministrator eller ein policy for styrt profil krev ein lås, høyrer kravet til den policyen, ikkje til sertifikatet. adb shell dumpsys device_policy listar dei aktive administratorane og passordkvaliteten dei handhevar, som er den raskaste måten å sjå om ein MDM-agent er grunnen til at PIN-reglane dine endra seg. Å fjerne sertifikatet lempar ikkje policyen, og å fjerne policyen er ei administrativ avgjerd snarare enn ei innstillingsjustering.
Vent også ein kompromiss med brukarvenlegheita. Viss nøkkelen krev brukargodkjenning, kan tunnelen ikkje kome opp før første opplåsing, så planlagde synkroniseringar og fjernoppvakningar feilar per design. Avgjer det før utrulling, ikkje etter.
Unngå snarvegen med å redigere locksettings.db eller spele av ein gammal omveg for eit gløymt mønster. Desse rutinane vart skrivne for bestemte bygg, dei kan late påloggingslageret i ein tilstand som rammeverket ikkje lenger ventar, og dei endrar aldri policyen som bad om låsen i utgangspunktet.
Steg 5: Avvikle identiteten og verifiser avvisinga
Avvikling har tre delar, og berre den første er lokal. Fjern VPN-profilen, slett brukarsertifikatet under Innstillingar, Sikkerheit, Kryptering og påloggingsinformasjon, Brukarpåloggingsinformasjon, og lat deretter utferdaren kalle tilbake serienummeret til sertifikatet. Den lokale slettinga åleine let etter seg påloggingsinformasjon som tenaren framleis godtek om nokon heldt på P12.
Verifiser resultatet i staden for å gå ut frå det. Prøv ei tilkopling med den avvikla profilen og stadfest at tenaren avviser han. Ein tunnel som framleis kjem opp, betyr at du kalla tilbake feil serienummer, eller at klienten stille fall tilbake til ein annan installert identitet.
Viss du rullar tilbake ein mislykka import, importer på nytt frå den opphavlege krypterte pakka og sjekk fingeravtrykket igjen i staden for å bruke om att ei dekryptert nøkkelfil du lét liggje på disken.