Mật khẩu VPN đúng không thể thay thế chứng chỉ bị thiếu

Thông tin đăng nhập đúng, hồ sơ nhập vào sạch sẽ, và kết nối vẫn thất bại trước khi xác thực hoàn tất. Trên Windows, thông báo có thể là lỗi 798, về một chứng chỉ không được tìm thấy cho phương thức EAP. Trên OpenVPN, nhật ký máy khách cho thấy một cú bắt tay TLS không bao giờ làm máy chủ hài lòng. Cả hai mô tả cùng một đối tượng bị thiếu: chứng chỉ máy khách mà máy khách lẽ ra phải trình bày.

Mật khẩu chứng minh hiểu biết về một bí mật; chứng chỉ chứng minh việc sở hữu một khóa, và cái này không thay thế cái kia.

Mật khẩu chưa bao giờ là vấn đề

Lỗi 798 là tìm kiếm chứng chỉ thất bại. Máy khách được yêu cầu một chứng chỉ khớp với phương thức xác thực đã cấu hình, nó đã tìm trong kho của mình và không tìm thấy gì dùng được. Điều đó có thể nghĩa là chứng chỉ không có, có mà không có khóa riêng, đã hết hạn, hoặc được lưu ở nơi mà việc tìm kiếm không tới. Thử lại mật khẩu không thể thay đổi bất kỳ điều kiện nào trong số đó, vì vậy lỗi quay lại ngay cả khi thông tin đăng nhập đúng.

Hãy đọc thông báo trước khi hành động. Từ chối thông tin đăng nhập, tìm kiếm chứng chỉ thất bại và bắt tay TLS thất bại là ba phát hiện khác nhau, và chỉ một trong số đó liên quan đến mật khẩu.

Kho của máy khách phải chứa gì

Có hai đối tượng liên quan. Chứng chỉ máy khách phải được cài đặt cho người dùng chạy máy khách VPN, cùng với khóa riêng của nó, và gốc cấp phát phải được tin cậy. Tệp .cer chỉ chứa chứng chỉ công khai, nên tự nó không thể xác thực bất cứ điều gì. Trong trình quản lý chứng chỉ của Windows, danh tính máy khách thuộc kho cá nhân của người dùng hiện tại, còn gốc thuộc kho gốc tin cậy.

Cài đặt danh tính vào kho máy hoặc chỉ vào kho gốc không đáp ứng một tìm kiếm nhắm vào kho cá nhân của người dùng. Hãy kiểm tra kho, cờ khóa riêng và ngày hiệu lực cùng lúc, rồi khởi động lại máy khách để nó đọc lại kho.

Hai sản phẩm, cùng một thông tin bị thiếu

Máy chủ OpenVPN yêu cầu chứng chỉ máy khách theo mặc định. Thêm auth-user-pass vào máy khách sẽ gửi tên người dùng và mật khẩu, và cú bắt tay TLS vẫn yêu cầu chứng chỉ, nên chỉ mật khẩu không thể hoàn tất kết nối dưới verify-client-cert require. Máy chủ có thể được đặt để không yêu cầu gì, điều đó khiến mật khẩu trở thành thông tin duy nhất của máy khách và là sự suy giảm thực sự về độ mạnh. Một tập lệnh shell phía sau auth-user-pass-verify có thể xác thực thông tin đăng nhập, và nó đòi hỏi việc thực thi tập lệnh phải được bật, điều đó khiến nó thành một thiết kế rủi ro hơn một backend xác thực đúng đắn.

Hồ sơ chỉ dựa vào mật khẩu cũng phụ thuộc vào các tùy chọn được đẩy, đến lượt chúng phụ thuộc vào việc cơ chế kéo được bật.

Đừng sửa chứng chỉ bị thiếu bằng cách tắt các kiểm tra

Cám dỗ là nới lỏng xác minh để thông báo biến mất. Điều đó loại bỏ kiểm soát đang làm việc của nó và để lại một kết nối không còn chứng minh điều nó tuyên bố. Nếu cổng mới đổi gốc của nó, hãy tải lại gói máy khách thay vì sửa hồ sơ, vì gói cũ có thể vẫn mang gốc trước đó. Nếu tùy chọn xác thực bằng chứng chỉ không có trong trình sửa hồ sơ, phiên bản Windows đã cài có thể không trình bày phương thức đó; hãy cập nhật hệ thống thay vì sửa XML bằng tay.

Ghi lại kho nào chứa chứng chỉ, người dùng nào chạy máy khách và khóa riêng có hiện diện hay không. Ba điều đó giải thích gần như mọi trường hợp của thất bại này.

Mật khẩu vẫn ổn. Thông tin mà phương thức thực sự cần nằm ở nơi khác.