Keystore-eraro ĉe Android VPN: reenregistri, malŝlosi aŭ reprovi?

La profilo ankoraŭ aperas en la listo, la atestilo ankoraŭ montriĝas kiel instalita, kaj la konekta butono malsukcesas per mesaĝo, kiu diras nur «Keystore-eraro» kaj nenion alian. Antaŭ ol vi viŝos la konservejon de la apo aŭ transdonos la telefonon, determini, kiu ŝlosila operacio malsukcesis. Tri rezultoj produktas la saman dialogon, kaj ili respondas al tri malsamaj agoj — nur unu el ili estas detrua. La komparo valoras dek minutojn, ĉar la malĝusta branĉo kostas al vi la identecon, kiun vi provis konservi.

Tri malsukcesoj malantaŭ unu dialogo

La unua estas aŭtentikigo. La ŝlosilo ekzistas kaj estas valida, sed uzi ĝin postulas, ke la uzanto pruvu ĉeeston — malŝloson de la aparato, biometrion aŭ defion de la laborprofilo. Se la ŝlosa tempolimo, la registritaj biometriaj datumoj aŭ la stato de la profilo lastatempe ŝanĝiĝis, la uzado de la ŝlosilo povas malsukcesi, dum la ŝlosilo mem estas tute en ordo.

La dua estas daŭra malvalidigo. Iujn ŝlosilajn materialojn la platforma politiko malvalidigas, kiam la ŝlosa metodo estas restarigita aŭ la biometria registrado ŝanĝiĝas, ĉar la ligo, kiu protektis ĝin, ne plu validas. La ŝlosilo ne estas riparebla, kaj reprovo ne estas riparplano; la identeco devas esti anstataŭigita per la registra procezo, kiu ĝin eldonis.

La tria estas provizanta malsukceso: la keystore-servo ne povis nun fini la operacion. Tiu estas la klaso, kiun foje indas reprovi, kaj la sola.

Rimarku, ke du el la tri ne estas detruaj kaj unu tute ne havas solvon ĉe la aparata nivelo. Neniu el ili solviĝas per viŝado de la telefono, kiu estas la paŝo, kiun homoj faras unue, ĉar la dialogo donas al ili nenion alian por agi.

Reenregistrado kontraŭ datumviŝo

Ĉi tiuj du aspektas similaj de ekstere kaj ne estas. Reenregistrado petas de la eldona sistemo novan identecon — freŝan atestilon aŭ ŝlosilon ligitan al ĉi tiu aparato — kaj emeritigas la malnovan. Datumviŝo forigas la konservitan staton de la apo, kio povas forigi la referencon al la ŝlosilo sen forigi la ŝlosilon, aŭ povas forigi la ŝlosilon kaj lasi vin sen rajtigo rekrei ĝin.

La distingo gravas, ĉar neeksporteblemaj ŝlosiloj laŭdezajne ne estas porteblaj. Ili vivas en la keystore de la aparato, subtenataj de kia ajn aparataro aŭ provizanto disponeblas, kaj ili ne estas io, kion sekurkopio kaptas kaj restaŭro reinstalas. Se la identeco de la surlokigo estas neeksporteblema ŝlosilo, planu reenregistradon kiel la riparon, kaj antaŭe konfirmu, ke vi havas aprobitan vojon por akiri tiun registradon — iuj organizoj postulas aliron al privata reto por tio, kio estas ĝuste tio, kion provizis la rompita VPN.

Do la ordo estas: provu la subtenatan aŭtentikigan vojon, poste determini, ĉu la ŝlosilo estas daŭre malvalida, kaj anstataŭigu la identecon nur se ĝi estas. Viŝado de la konservejo venas laste, post kiam vi scias, kio rekreiĝos, ne unue ĉar ĝi estas facila.

Reprovu nur tion, kio estas reprovebla

Pli malnovaj platformaj versioj kunfandis keystore-erarojn en unu escepton, kaj tial tiom da klientoj reprovas ĉion. Ekde API 33 la escepta tipo portas strukturon: numeran eraron, flagon de provizora malsukceso kaj reprovan politikon. Por klienta programisto la reprova politiko havas sencon nur kiam la provizoreca flaganto estas vera; daŭra malvalidigo havas neniun reprovan horaron, kaj frapi ĝin en buklo nur malplenigas la baterion kaj plenigas la protokolon.

Se vi diagnozas anstataŭ verki la klienton, la praktika sekvo estas la sama. Identaj malsukcesoj ĉe ĉiu provo ekskludas unufojan fuŝon, sed ili ne apartigas daŭre malvalidigitan ŝlosilon de provizanto, kiu jam de tempo ne disponeblas — provizanta paneo aspektas ekzakte same ĉe la deka reprovo kiel ĉe la unua. Sen la strukturitaj kampoj de API 33, traktu ripeton kiel kialon serĉi duan signalon — la erarkodon, se via konstruaĵo montras ĝin, la staton de la operatoro, aŭ alian ŝlosilon sur la sama aparato, kiu sukcesas — kaj ne kiel pruvon, ke la ŝlosilo estas morta.

Legu la kaŭzan ĉenon, ne la etikedon

Aplikoj envolvas la originan escepton, kaj la afabla teksto en la interfaco ofte kaŝas la solan kampon, kiu decidas la branĉon. Konservu la kaŭzan ĉenon kaj la tempostampon de la provo: la ekstera escepto kutime nomas la operacion, kaj la kaŭzo nomas la staton de la ŝlosilo.

Rezistu la konkludon, ke du malsukcesantaj apoj pruvas difektitan telefonon. Malsamaj ŝlosiloj povas esti subtenataj de malsamaj provizantoj kaj sekurecaj niveloj, kaj apo, kiu ankoraŭ funkcias, eble tute ne plenumas la saman operacion — subskribo, malĉifrado kaj ŝlosila atestado estas malsamaj petoj al la sama servo. referenco KeyStoreException priskribas la strukturitajn kampojn ĉe pli novaj API-niveloj kaj estas la loko, kie kontroli, kion via konstruaĵo efektive povas raporti.

Kio subtenus aparataran konkludon estas pli mallarĝa, ol plej multaj supozas: la sama operacio, ĉe la sama provizanto, malsukcesanta trans sendependaj ŝlosiloj per eraro ĉe la provizanta nivelo kaj ne ĉe la ŝlosila. Tio estas demando por la diagnozilo de la platformo, ne por fadenaĵo en subtena forumo pri aro da aparatoj.

Kion noti dum vi decidas

Notu la Android-konstruaĵon, la klientan version, la elektitan profilon, la operacion, kiu malsukcesis, kaj ĉu io lastatempe ŝanĝiĝis — ĝisdatigo de la operaciumo, ŝanĝo de la ŝlosa ekrano, nova fingrospuro, reenregistrado. Notu la sinsekvon kiel kuntekston, ne kiel pruvon de kaŭzo; ŝanĝo de la ŝlosado antaŭ ŝlosila malsukceso estas kredebla korelacio, ne pruvo.

Poste agu laŭ la branĉo, kiun vi starigis. Provizora: konservu la identecon, uzu la subtenatan reprovan vojon. Aŭtentikigo bezonata: finu la subtenatan malŝlosan fluon kaj konservu la ŝlosan politikon, kiun la surlokigo postulas, anstataŭ malŝalti ĝin por preterpasi dialogon. Daŭre malvalida: anstataŭigu kaj emeritigu la identecon per normala registrado.

Finu pruvante la rezulton sur freŝa rajtigita konekto, al reala rimedo, kun la servila validado ankoraŭ ŝaltita. Io ajn, kio funkcias nur kun malstreĉitaj atestilaj kontroloj, ne riparis la ŝlosilan problemon — ĝi movis ĝin al la reta tavolo, kie ĝi aperos poste kun pli malbonaj simptomoj.

• Tri branĉoj: bezonas aŭtentikigon, daŭre malvalida, provizore provizora.
• Nur la tria profitas de reprovo, kaj nur laŭ sia reprova politiko.
• Anstataŭiga registrado restarigas aliron; datumviŝo forigas la opcion.
• Kontrolu per freŝa konekto kaj normalaj servilaj identeckontroloj.