Lỗi keystore trên Android VPN: đăng ký lại, mở khóa hay thử lại?

Hồ sơ vẫn được liệt kê, chứng chỉ vẫn hiển thị là đã cài đặt, và nút kết nối thất bại với thông báo chỉ nói Lỗi keystore và không gì khác. Trước khi xóa bộ nhớ ứng dụng hoặc mang điện thoại đi, hãy xác định thao tác khóa nào đã thất bại. Ba kết quả tạo ra cùng một hộp thoại và ứng với ba hành động khác nhau — chỉ một trong số đó là phá hủy. Việc so sánh đáng giá mười phút, vì nhánh sai khiến bạn mất danh tính mà bạn đang cố giữ.

Ba lỗi đằng sau một hộp thoại

Đầu tiên là xác thực. Khóa tồn tại và hợp lệ, nhưng việc sử dụng nó đòi hỏi người dùng chứng minh sự hiện diện — mở khóa thiết bị, sinh trắc học hoặc thử thách hồ sơ công việc. Nếu thời gian chờ khóa, sinh trắc học đã đăng ký hoặc trạng thái hồ sơ thay đổi gần đây, việc dùng khóa có thể thất bại trong khi bản thân khóa hoàn toàn ổn.

Thứ hai là vô hiệu hóa vĩnh viễn. Một số vật liệu khóa bị vô hiệu hóa theo chính sách nền tảng khi phương thức khóa được đặt lại hoặc đăng ký sinh trắc học thay đổi, vì ràng buộc bảo vệ nó không còn giữ. Không thể sửa khóa và thử lại không phải kế hoạch khôi phục; danh tính phải được thay thế thông qua quy trình đăng ký đã cấp nó.

Thứ ba là lỗi nhà cung cấp: dịch vụ keystore không thể hoàn tất thao tác ngay lúc này. Đây là loại đôi khi đáng thử lại, và là loại duy nhất.

Lưu ý rằng hai trong ba không phá hủy và một không có cách khắc phục nào ở cấp thiết bị. Không có cái nào được giải quyết bằng cách xóa điện thoại, bước mà mọi người thường làm trước tiên vì hộp thoại không cho họ điều gì khác để hành động.

Đăng ký lại so với xóa dữ liệu

Hai việc này trông giống nhau từ bên ngoài và không phải vậy. Đăng ký lại yêu cầu hệ thống cấp một danh tính mới — chứng chỉ hoặc khóa mới gắn với thiết bị này — và cho danh tính cũ nghỉ hưu. Xóa dữ liệu xóa trạng thái đã lưu của ứng dụng, có thể gỡ tham chiếu đến khóa mà không gỡ khóa, hoặc có thể gỡ khóa và khiến bạn không có thẩm quyền tạo lại nó.

Sự khác biệt quan trọng vì khóa không thể xuất theo thiết kế không di động. Chúng sống trong keystore của thiết bị, được hỗ trợ bởi phần cứng hoặc nhà cung cấp sẵn có, và chúng không phải thứ mà bản sao lưu bắt lấy và khôi phục trả lại. Nếu danh tính của triển khai là khóa không thể xuất, hãy lên kế hoạch đăng ký lại làm cách khôi phục, và xác nhận trước rằng bạn có tuyến đường được phê duyệt để có được đăng ký đó — một số tổ chức yêu cầu quyền truy cập mạng riêng cho việc này, đúng là thứ mà VPN hỏng đang cung cấp.

Vậy thứ tự là: thử đường xác thực được hỗ trợ, sau đó xác định khóa có bị vô hiệu vĩnh viễn không, và chỉ thay danh tính nếu đúng như vậy. Xóa bộ nhớ nằm cuối cùng, sau khi bạn biết điều gì sẽ được tạo lại, không phải đầu tiên vì nó dễ.

Chỉ thử lại những gì có thể thử lại

Các phiên bản nền tảng cũ gộp lỗi keystore thành một ngoại lệ duy nhất, đó là lý do nhiều ứng dụng khách thử lại mọi thứ. Từ API 33, loại ngoại lệ mang cấu trúc: lỗi số, cờ lỗi tạm thời và chính sách thử lại. Với nhà phát triển ứng dụng khách, chính sách thử lại chỉ có ý nghĩa khi cờ tạm thời đúng; vô hiệu hóa vĩnh viễn không có lịch thử lại, và đập nó trong vòng lặp chỉ làm cạn pin và làm đầy nhật ký.

Nếu bạn đang chẩn đoán thay vì viết ứng dụng khách, hệ quả thực tế vẫn vậy. Lỗi giống hệt ở mọi lần thử loại trừ một trục trặc nhất thời, nhưng không tách khóa bị vô hiệu vĩnh viễn khỏi nhà cung cấp đã không khả dụng một thời gian — sự cố nhà cung cấp trông giống hệt ở lần thử thứ mười và lần đầu. Không có trường cấu trúc của API 33, hãy coi việc lặp lại là lý do để tìm tín hiệu thứ hai — mã lỗi nếu bản dựng của bạn hiển thị, trạng thái nhà điều hành, hoặc một khóa khác trên cùng thiết bị thành công — chứ không phải bằng chứng rằng khóa đã chết.

Đọc chuỗi nguyên nhân, không phải nhãn

Ứng dụng bọc ngoại lệ gốc, và chuỗi thân thiện trong giao diện thường giấu trường duy nhất quyết định nhánh. Giữ chuỗi nguyên nhân và dấu thời gian của lần thử: ngoại lệ bên ngoài thường nêu tên thao tác, và nguyên nhân nêu tên tình trạng của khóa.

Đừng đi đến suy luận rằng hai ứng dụng thất bại chứng minh một chiếc điện thoại bị lỗi. Các khóa khác nhau có thể được hỗ trợ bởi các nhà cung cấp và mức bảo mật khác nhau, và một ứng dụng vẫn hoạt động có thể không thực hiện cùng thao tác — chữ ký, giải mã và chứng thực khóa là những yêu cầu khác nhau gửi đến cùng một dịch vụ. Tài liệu tham khảo KeyStoreException mô tả các trường cấu trúc trên các cấp API mới hơn và là nơi để kiểm tra những gì bản dựng của bạn thực sự có thể báo cáo.

Điều sẽ hỗ trợ một kết luận về phần cứng hẹp hơn hầu hết mọi người giả định: cùng một thao tác, trên cùng một nhà cung cấp, thất bại trên các khóa độc lập với lỗi ở cấp nhà cung cấp chứ không phải cấp khóa. Đó là câu hỏi dành cho chẩn đoán của nền tảng, không phải cho một luồng diễn đàn hỗ trợ về một lô thiết bị.

Ghi lại gì trong khi bạn quyết định

Ghi lại bản dựng Android, phiên bản ứng dụng khách, hồ sơ đã chọn, thao tác đã thất bại và liệu có gì thay đổi gần đây — cập nhật hệ điều hành, thay đổi màn hình khóa, vân tay mới, đăng ký lại. Ghi trình tự như bối cảnh chứ không phải bằng chứng nguyên nhân; thay đổi khóa trước một lỗi khóa là tương quan hợp lý, không phải minh chứng.

Sau đó hành động theo nhánh bạn đã xác lập. Tạm thời: giữ danh tính, dùng đường thử lại được hỗ trợ. Cần xác thực: hoàn tất luồng mở khóa được hỗ trợ và giữ chính sách khóa mà triển khai yêu cầu thay vì tắt nó để vượt qua hộp thoại. Vô hiệu vĩnh viễn: thay thế và cho danh tính nghỉ hưu thông qua đăng ký thông thường.

Kết thúc bằng việc chứng minh kết quả trên một kết nối được ủy quyền mới, đến một tài nguyên thực, với xác thực máy chủ vẫn bật. Bất cứ thứ gì chỉ hoạt động khi kiểm tra chứng chỉ được nới lỏng thì chưa sửa được vấn đề khóa — nó đã chuyển vấn đề sang lớp mạng, nơi nó sẽ lộ ra sau này với triệu chứng tệ hơn.

• Ba nhánh: cần xác thực, vô hiệu vĩnh viễn, nhà cung cấp tạm thời.
• Chỉ nhánh thứ ba hưởng lợi từ việc thử lại, và chỉ theo chính sách thử lại của nó.
• Đăng ký thay thế khôi phục quyền truy cập; xóa dữ liệu gỡ bỏ lựa chọn đó.
• Xác minh bằng kết nối mới và kiểm tra danh tính máy chủ thông thường.