Hoe om 'n VPN-sertifikaat op Android in te voer en die sleutel te verifieer
Voer 'n P12 op Android in, bevestig watter verskaffer die sleutel hou, en bepaal wie werklik die skermslot-vereiste besit.
Die invoer van 'n VPN-klientsertifikaat op Android neem 'n paar minute. Om te kontroleer dat dit op die regte plek geland het, neem langer, en dit is die deel wat die meeste mense oorslaan sodra die installasievenster sukses meld. 'n Suksesboodskap beteken net dat die leër geparseer is. Dit sê niks oor watter verskaffer die private sleutel hou of of 'n kopie steeds in jou Downloads-lêer sit nie.
Stap 1: Lees die P12 voordat dit jou masjien verlaat
Begin met die lêer self. As jy nie die onderwerp, die uitsteller en die vervaldatum daarin kan benoem nie, voer jy iets in wat jy later nie sal kan verifieer nie.
’n PKCS#12-bundel bevat gewoonlik ’n klientsertifikaat, sy private sleutel en die uitstellerketting. openssl pkcs12 -in client.p12 -info -noout druk die MAC en die enkripsie-algoritmes uit sonder om sleutelmateriaal te dump, sodat jy kan sien of die bundel wagwoordbeskermd is en met watter cipher. Volg dit met keytool -list -v -keystore client.p12 -storetype PKCS12 om die alias, die SHA-256-vingerafdruk en die geldigheidsvenster te kry wat jy teen die foon sal vergelyk.
Stuur die wagwoord deur ’n ander kanaal as die lêer, of oorhandig die lêer binne ’n bestuurde verspreidingsvloei wat geen kopie agterlaat nie. ’n Wagwoord wat in dieselfde kletsboodskap as die argief geplak word, maak twee kontroles een.
Stap 2: Installeer dit in die gleuf wat die VPN-program werklik lees
Op standaard Android 11 tot 14 loop die pad deur Instellings, Sekuriteit, Enkripsie en gemagtigdes, Installeer ’n sertifikaat, dan VPN en programgebruikersertifikaat. Die bewoording en die nesvorming verskuif tussen weergawes en verskaffervelle, so volg die gemagtigdestipe-etiket eerder as ’n gememoriseerde kieslysit. In ’n werkprofiel, installeer van binne die werkkant, want gemagtigdes kruis nie die profielgrens nie.
Moenie ’n kliëntidentiteit in die CA-sertifikaatgleuf plaas nie. Daardie gleuf voed die gebruikersvertrouestoor, en sedert Android 7 ignoreer programme gebruikertoegevoegde CA's tensy hul netwerksekuriteitskonfigurasie dit aanvaar, so ’n kliëntsertifikaat wat daar geparkeer is, verskyn nooit in die VPN-sleutelkieser nie.
Sommige VPN-kliënte raak nooit die stelselstoor aan nie en voer die P12 eerder in hul eie programgids in. Dit is ’n wettige ontwerp, maar dit verander elke latere stap: die sleutel woon nou onder die program-sandbox en is presies so sterk as wat daardie program sy eie berging hanteer. Kontroleer die kliëntdokumentasie voordat jy aanneem KeyChain is in spel.
Stap 3: Bewys watter verskaffer die sleutel hou
’n Invoer bevestig parsing, nie hardeware-ondersteuning nie. Op Android 12 en later rapporteer KeyInfo.getSecurityLevel() of ’n sleutel in die Trusted Execution Environment, in StrongBox of in sagteware sit, en dit vervang die ouer isInsideSecureHardware()-oproep. As die VPN-kliënt daardie waarde nie openbaar nie, is die vingerafdruk van stap 1 jou terugval. ’n Sertifikaat wat tydens invoer herkodeer is, sal nie byte vir byte ooreenstem nie, maar die publieke sleutel en die onderwerp sal steeds.
Nie-uitvoerbaar is nie dieselfde as onbruikbaar nie. ’n Sleutel wat die toestel nie kan verlaat nie, kan steeds deur enige program gebruik word wat die gebruiker magtig om daardie alias te kies, en daarom is die alias-oproep ’n werklike kontrole en nie ’n formaliteit nie. Die Android Keystore-dokumentasie is werd om een keer te lees as jy daardie ontwerpbesluit maak.
Reken dan vir die kopieë wat jy gemaak het. Die P12 op jou skootrekenaar, die een in die kaartjieaanhangsel en die een in verlede maand se rugsteun is almal steeds geldige identiteite totdat die uitsteller hulle herroep. Hardewarebeskerming van die instansie op die foon doen niks vir daardie een nie.
Stap 4: Vind wie die skermslot-vereiste besit
Drie geheime word hier verwar: die toestel-ontsluit-PIN, die private sleutel-wagfrase en die VPN-rekeningwagwoord. ’n Oproep vir een is nooit ’n versoek om die ander te herstel nie, en die verkeerde een herstel is hoe mense hulself uitsluit van ’n profiel wat goed gewerk het.
Wanneer ’n toesteladministrateur of ’n bestuurde profielbeleid ’n slot vereis, behoort die vereiste aan daardie beleid, nie aan die sertifikaat nie. adb shell dumpsys device_policy lys die aktiewe administrateurs en die wagwoordgehalte wat hulle afdwing, wat die vinnigste manier is om te sien of ’n MDM-agent die rede is dat jou PIN-reëls verander het. Die verwydering van die sertifikaat sal die beleid nie verslap nie, en die verwydering van die beleid is ’n administratiewe besluit eerder as ’n instellingsaanpassing.
Verwag ook ’n bruikbaarheidsafweging. As die sleutel gebruikermagtiging vereis, kan die tonnel nie voor die eerste ontsluiting opkoms nie, so geskeduleerde sinchronisering en afgeleë wakker-word misluk per ontwerp. Besluit dit voor ontplooiing, nie daarna nie.
Vermy die kortpad om locksettings.db te redigeer of ’n ou vergete-patroon-oplossing weer te speel. Daardie roetines is vir spesifieke bouwe geskryf, hulle kan die gemagtigdestoor in ’n toestand laat wat die raamwerk nie meer verwag nie, en hulle verander nooit die beleid wat die slot in die eerste plek geëis het nie.
Stap 5: Trek die identiteit terug en verifieer die weiering
Terugtrekking het drie dele en net die eerste is plaaslik. Verwyder die VPN-profiel, skrap die gebruikersertifikaat onder Instellings, Sekuriteit, Enkripsie en gemagtigdes, Gebruikergemagtigdes, en laat die uitsteller dan die sertifikaatserienommer herroep. Die plaaslike skrapping op sy eie laat ’n gemagtigde wat die bediener steeds aanvaar as iemand die P12 gehou het.
Verifieer die resultaat eerder as om dit aan te neem. Probeer ’n verbinding met die afgetrede profiel en bevestig dat die bediener dit verwerp. ’n Tonnel wat steeds opkom, beteken jy het die verkeerde serienommer herroep of die kliënt het stilweg na ’n ander geïnstalleerde identiteit teruggeval.
As jy ’n mislukte invoer terugrol, herinvoer vanaf die oorspronklike geënkripteerde bundel en herkontroleer die vingerafdruk eerder as om ’n gedekripteerde sleutellêer wat jy op skyf gelaat het, hergebruik.