Ralat Keystore pada Android VPN: daftar semula, buka kunci atau cuba lagi?

Profil masih tersenarai, sijil masih dipaparkan sebagai dipasang, dan butang sambung gagal dengan mesej yang hanya berkata «Ralat Keystore» dan tiada lagi. Sebelum anda mengosongkan storan apl atau menyerahkan telefon, tentukan operasi kunci mana yang gagal. Tiga hasil menghasilkan dialog yang sama, dan ketiga-tiganya bertindak balas terhadap tiga tindakan berbeza — hanya satu daripadanya merosakkan. Perbandingan ini berbaloi sepuluh minit kerana cabang yang salah meragut identiti yang anda cuba pertahankan.

Tiga kegagalan di sebalik satu dialog

Yang pertama ialah pengesahan. Kunci wujud dan sah, tetapi menggunakannya memerlukan pengguna membuktikan kehadiran — buka kunci peranti, biometrik atau cabaran profil kerja. Jika had masa kunci, biometrik berdaftar atau keadaan profil berubah baru-baru ini, penggunaan kunci boleh gagal walaupun kunci itu sendiri sepenuhnya baik.

Yang kedua ialah pembatalan kekal. Sesetengah bahan kunci dibatalkan oleh dasar platform apabila kaedah kunci ditetapkan semula atau pendaftaran biometrik berubah, kerana ikatan yang melindunginya tidak lagi terpakai. Kunci tidak boleh dibaiki dan cuba lagi bukan pelan pemulihan; identiti mesti diganti melalui proses pendaftaran yang mengeluarkannya.

Yang ketiga ialah kegagalan penyedia: perkhidmatan keystore tidak dapat menyelesaikan operasi sekarang. Itulah kelas yang kadangkala berbaloi dicuba lagi, dan satu-satunya.

Perhatikan bahawa dua daripada tiga tidak merosakkan dan satu langsung tiada penyelesaian di peringkat peranti. Tiada satu pun diselesaikan dengan memadam telefon, iaitu langkah yang orang ambil dahulu kerana dialog tidak memberi mereka apa-apa lagi untuk dilakukan.

Pendaftaran semula berbanding pemadaman data

Kedua-duanya kelihatan serupa dari luar dan sebenarnya tidak. Pendaftaran semula meminta identiti baharu daripada sistem pengeluar — sijil atau kunci baharu yang terikat pada peranti ini — dan mempersarakan yang lama. Pemadaman data memadamkan keadaan tersimpan apl, yang mungkin membuang rujukan kepada kunci tanpa membuang kunci, atau mungkin membuang kunci itu sendiri dan meninggalkan anda tanpa kuasa untuk menciptanya semula.

Perbezaan ini penting kerana kunci yang tidak boleh dieksport mengikut reka bentuk tidak boleh dipindahkan. Ia hidup dalam keystore peranti, disokong oleh perkakasan atau penyedia yang tersedia, dan ia bukan sesuatu yang ditangkap sandaran dan dipulihkan semula. Jika identiti penggunaan ialah kunci yang tidak boleh dieksport, rancang pendaftaran semula sebagai pemulihan, dan sahkan lebih awal bahawa anda mempunyai laluan yang diluluskan untuk mendapatkannya — sesetengah organisasi memerlukan akses rangkaian peribadi untuk itu, iaitu tepat apa yang VPN yang rosak sedang sediakan.

Jadi urutannya ialah: cuba laluan pengesahan yang disokong, kemudian tentukan sama ada kunci itu tidak sah secara kekal, dan ganti identiti hanya jika ya. Pemadaman storan datang terakhir, selepas anda tahu apa yang akan dicipta semula, bukan dahulu kerana ia mudah.

Cuba lagi hanya apa yang boleh dicuba lagi

Versi platform lama menggabungkan ralat keystore ke dalam satu pengecualian, sebab itulah ramai klien mencuba semula segala-galanya. Sejak API 33 jenis pengecualian membawa struktur: ralat berangka, bendera kegagalan sementara dan dasar cubaan semula. Bagi pembangun klien, dasar cubaan semula hanya bermakna apabila bendera kesementaraan benar; pembatalan kekal tiada jadual cubaan semula, dan memukulnya dalam gelung hanya menghabiskan bateri dan memenuhi log.

Jika anda mendiagnosis dan bukannya menulis klien, kesan praktikalnya sama. Kegagalan serupa pada setiap cubaan menyingkirkan gangguan sekali sekala, tetapi ia tidak memisahkan kunci yang dibatalkan kekal daripada penyedia yang sudah lama tidak tersedia — gangguan penyedia kelihatan sama tepat pada cubaan kesepuluh seperti pada yang pertama. Tanpa medan berstruktur API 33, anggap pengulangan sebagai sebab untuk mencari isyarat kedua — kod ralat jika build anda menunjukkannya, status pengendali, atau kunci lain pada peranti yang sama berjaya — bukan sebagai bukti bahawa kunci itu mati.

Baca rantaian punca, bukan labelnya

Apl membalut pengecualian asal, dan teks mesra dalam antara muka sering menyembunyikan satu medan yang menentukan cabang. Kekalkan rantaian punca dan cap masa percubaan: pengecualian luar biasanya menamakan operasi, dan puncanya menamakan keadaan kunci.

Tolak tanggapan bahawa dua apl yang gagal membuktikan telefon yang cacat. Kunci berbeza boleh disokong oleh penyedia dan tahap keselamatan berbeza, dan apl yang masih berfungsi mungkin tidak menjalankan operasi yang sama langsung — tandatangan, penyahsulitan dan atestasi kunci ialah permintaan berbeza kepada perkhidmatan yang sama. rujukan KeyStoreException menerangkan medan berstruktur pada tahap API yang lebih baharu dan merupakan tempat untuk menyemak apa yang sebenarnya boleh dilaporkan oleh build anda.

Apa yang akan menyokong kesimpulan perkakasan lebih sempit daripada yang disangka kebanyakan orang: operasi yang sama, pada penyedia yang sama, gagal merentas kunci bebas dengan ralat peringkat penyedia dan bukan peringkat kunci. Itu soalan untuk diagnostik platform, bukan untuk utas forum sokongan tentang satu kelompok peranti.

Apa yang perlu direkodkan semasa anda membuat keputusan

Rekodkan build Android, versi klien, profil yang dipilih, operasi yang gagal, dan sama ada sesuatu berubah baru-baru ini — kemas kini OS, perubahan skrin kunci, cap jari baharu, pendaftaran semula. Rekodkan urutan sebagai konteks dan bukan sebagai bukti punca; perubahan kunci sebelum kegagalan kunci ialah korelasi yang munasabah, bukan demonstrasi.

Kemudian bertindak mengikut cabang yang anda tetapkan. Sementara: kekalkan identiti, gunakan laluan cubaan semula yang disokong. Pengesahan diperlukan: lengkapkan aliran buka kunci yang disokong dan kekalkan dasar kunci yang dikehendaki oleh penggunaan dan bukannya melumpuhkannya untuk melepasi dialog. Tidak sah secara kekal: ganti dan persarakan identiti melalui pendaftaran biasa.

Akhiri dengan membuktikan hasilnya pada sambungan dibenarkan yang baharu, ke sumber sebenar, dengan pengesahan pelayan masih diaktifkan. Apa-apa yang hanya berfungsi dengan pemeriksaan sijil yang dilonggarkan belum membaiki masalah kunci — ia telah memindahkannya ke lapisan rangkaian, tempat ia akan muncul kemudian dengan gejala yang lebih buruk.

• Tiga cabang: perlu pengesahan, tidak sah secara kekal, sementara pada penyedia.
• Hanya yang ketiga mendapat manfaat daripada cubaan semula, dan hanya mengikut dasar cubaan semulanya sendiri.
• Pendaftaran pengganti memulihkan akses; pemadaman data membuang pilihan itu.
• Sahkan dengan sambungan baharu dan pemeriksaan identiti pelayan biasa.