Chyba keystore na Android VPN: znova zapísať, odomknúť alebo skúsiť znova?

Profil je stále v zozname, certifikát sa stále zobrazuje ako nainštalovaný a tlačidlo pripojenia zlyháva so správou, ktorá hovorí len Chyba keystore a nič viac. Skôr než vymažete úložisko aplikácie alebo telefón odovzdáte, zistite, ktorá operácia s kľúčom zlyhala. Tri výsledky vytvárajú rovnaký dialóg a reagujú na tri rôzne kroky — iba jeden z nich je deštruktívny. Porovnanie stojí za desať minút, pretože nesprávna vetva vás stojí identitu, ktorú ste sa snažili zachovať.

Tri zlyhania za jedným dialógom

Prvé je autentifikácia. Kľúč existuje a je platný, no jeho použitie vyžaduje, aby používateľ preukázal prítomnosť — odomknutie zariadenia, biometriu alebo výzvu pracovného profilu. Ak sa nedávno zmenil časový limit zámku, zaregistrovaná biometria alebo stav profilu, použitie kľúča môže zlyhať, hoci samotný kľúč je úplne v poriadku.

Druhé je trvalé zneplatnenie. Časť kľúčového materiálu zneplatní politika platformy pri obnovení spôsobu uzamknutia alebo zmene biometrického zápisu, pretože väzba, ktorá ho chránila, už neplatí. Kľúč sa nedá opraviť a opakovanie nie je plán obnovy; identitu treba nahradiť procesom zápisu, ktorý ju vydal.

Tretie je zlyhanie poskytovateľa: služba keystore práve nedokázala dokončiť operáciu. To je trieda, ktorú má niekedy zmysel opakovať, a jediná taká.

Všimnite si, že dve z troch nie sú deštruktívne a jedna nemá na úrovni zariadenia vôbec riešenie. Žiadnu z nich nerieši vymazanie telefónu, čo je krok, ktorý ľudia urobia ako prvý, pretože dialóg im nedáva nič iné.

Opätovný zápis versus vymazanie údajov

Zvonku vyzerajú podobne a nie sú. Opätovný zápis požiada vydávajúci systém o novú identitu — nový certifikát alebo kľúč viazaný na toto zariadenie — a starú vyradí. Vymazanie údajov odstráni uložený stav aplikácie, čo môže odstrániť odkaz na kľúč bez odstránenia kľúča, alebo môže odstrániť kľúč a nechať vás bez oprávnenia ho znova vytvoriť.

Rozdiel je dôležitý, pretože neexportovateľné kľúče nie sú z princípu prenosné. Žijú v keystore zariadenia, podporované dostupným hardvérom alebo poskytovateľom, a nie sú niečím, čo záloha zachytí a obnova vráti. Ak je identita v nasadení neexportovateľný kľúč, počítajte s opätovným zápisom ako obnovou a vopred si potvrďte, že máte schválenú cestu na jeho získanie — niektoré organizácie na to vyžadujú prístup do súkromnej siete, čo je presne to, čo poskytoval pokazený VPN.

Poradie je teda: vyskúšajte podporovanú cestu autentifikácie, potom zistite, či je kľúč trvalo zneplatnený, a identitu nahraďte, len ak áno. Vymazanie úložiska patrí na koniec, až keď viete, čo sa znova vytvorí, nie na začiatok preto, že je jednoduché.

Opakujte len to, čo sa opakovať dá

Staršie verzie platformy zlievali chyby keystore do jednej výnimky, a preto toľko klientov opakuje všetko. Od API 33 nesie typ výnimky štruktúru: číselnú chybu, príznak prechodného zlyhania a politiku opakovania. Pre vývojára klienta má politika opakovania zmysel len vtedy, keď je príznak prechodnosti pravdivý; trvalé zneplatnenie nemá žiadny plán opakovania a dobíjanie ho dookola len vybíja batériu a zapĺňa log.

Ak diagnostikujete namiesto písania klienta, praktický dôsledok je rovnaký. Rovnaké zlyhania pri každom pokuse vylučujú jednorazový výpadok, ale neoddelia trvalo zneplatnený kľúč od poskytovateľa, ktorý je už nejaký čas nedostupný — výpadok poskytovateľa vyzerá pri desiatom pokuse presne tak ako pri prvom. Bez štruktúrovaných polí API 33 berte opakovanie ako dôvod hľadať druhý signál — kód chyby, ak ho vaše zostavenie ukazuje, stav operátora alebo úspech iného kľúča na tom istom zariadení — a nie ako dôkaz, že kľúč je mŕtvy.

Čítajte reťaz príčin, nie označenie

Aplikácie obaľujú pôvodnú výnimku a prívetivý reťazec v rozhraní často skrýva jediné pole, ktoré rozhoduje o vetve. Zachovajte reťaz príčin a časovú značku pokusu: vonkajšia výnimka zvyčajne pomenúva operáciu a príčina pomenúva stav kľúča.

Nepodľahnite záveru, že dve zlyhávajúce aplikácie dokazujú chybný telefón. Rôzne kľúče môžu podporovať rôzni poskytovatelia a rôzne úrovne zabezpečenia a aplikácia, ktorá stále funguje, nemusí vôbec vykonávať tú istú operáciu — podpis, dešifrovanie a atestácia kľúča sú rôzne požiadavky na tú istú službu. Referencia KeyStoreException opisuje štruktúrované polia na novších úrovniach API a je miestom, kde si overíte, čo vaše zostavenie skutočne dokáže hlásiť.

To, čo by podporilo záver o hardvéri, je užšie, než väčšina ľudí predpokladá: tá istá operácia, u toho istého poskytovateľa, zlyhávajúca na nezávislých kľúčoch s chybou na úrovni poskytovateľa, nie kľúča. To je otázka pre diagnostiku platformy, nie pre vlákno fóra podpory o dávke zariadení.

Čo si zapisovať, kým sa rozhodujete

Zapíšte zostavenie Androidu, verziu klienta, vybraný profil, operáciu, ktorá zlyhala, a či sa nedávno niečo zmenilo — aktualizácia OS, zmena uzamknutej obrazovky, nový odtlačok, opätovný zápis. Zaznamenávajte postupnosť ako kontext, nie ako dôkaz príčiny; zmena zámku pred zlyhaním kľúča je pravdepodobná korelácia, nie demonštrácia.

Potom konajte podľa zistenej vetvy. Prechodné: ponechajte identitu, použite podporovanú cestu opakovania. Vyžaduje sa autentifikácia: dokončite podporovaný tok odomknutia a zachovajte politiku uzamknutia, ktorú nasadenie vyžaduje, namiesto jej vypnutia, aby ste prešli cez dialóg. Trvalo zneplatnené: nahraďte a vyraďte identitu bežným zápisom.

Na záver preukážte výsledok na novom autorizovanom pripojení k reálnemu zdroju s naďalej zapnutým overovaním servera. Čokoľvek funguje len s uvoľnenými kontrolami certifikátov, neopravilo problém kľúča — presunulo ho do sieťovej vrstvy, kde sa neskôr objaví s horšími príznakmi.

• Tri vetvy: potrebuje autentifikáciu, trvalo zneplatnený, prechodné zlyhanie poskytovateľa.
• Iba tretia má úžitok z opakovania, a to len podľa svojej politiky opakovania.
• Náhradný zápis obnoví prístup; vymazanie údajov túto možnosť odstráni.
• Overte na novom pripojení a pri bežných kontrolách identity servera.