Bạn sao chép một hồ sơ OpenVPN 2 đang hoạt động vào một ứng dụng khách Windows mới hơn, và chứng chỉ mà ứng dụng khách cũ tự tìm thấy không còn được cung cấp nữa. Dòng đã làm cho điều đó hoạt động là một bộ chọn riêng của Windows thuộc về ứng dụng khách Community 2, và ứng dụng mới hơn là một chương trình khác với một đường dẫn thông tin xác thực khác. Hồ sơ không thay đổi ngoài dòng đó, và đó chính là điều khiến khó nhìn ra sự khác biệt.

Ba lớp bị trộn lẫn trong báo cáo đó: ứng dụng khách Community, thư viện lõi và frontend mà ai đó đã cài. Chỉ một trong số chúng từng hiểu chỉ thị này.

Tùy chọn này có nghĩa gì ở nơi nó tồn tại

Trong ứng dụng khách Community OpenVPN 2 trên Windows, cryptoapicert chỉ định một chứng chỉ mà ứng dụng khách phải tìm trong kho chứng chỉ của Windows thay vì trong một tệp. Đây là một tiện ích riêng của Windows, và nó hoạt động vì ứng dụng khách đó biết cách liệt kê kho và chuyển khóa thu được cho ngăn xếp TLS của chính nó. Vì vậy chỉ thị là một phần ngôn ngữ cấu hình của ứng dụng khách đó, không phải một thuộc tính của giao thức OpenVPN. Không có gì trong định dạng truyền tải mang nó.

Sao chép cùng dòng đó vào một ứng dụng khác và bạn đã sao chép một từ mà chương trình mới có thể phân tích, bỏ qua hoặc từ chối. Chỉ thị không phải là một tính năng của giao thức, và cái này thậm chí không phải là tính năng của mọi ứng dụng khách nói OpenVPN.

Thay vào đó thư viện lõi cung cấp gì

OpenVPN 3 Core là một thư viện mà các ứng dụng khác nhúng vào, và nó xử lý thông tin xác thực bên ngoài qua một API thay vì tra cứu kho. Ứng dụng nhúng cung cấp một chuỗi chứng chỉ và sau đó yêu cầu thư viện ký bằng khóa bên ngoài, và thư viện gọi lại ứng dụng để làm việc đó. Đó là một thiết kế tổng quát hơn, và nó có nghĩa là frontend quyết định những nhà cung cấp nào tồn tại. Trong chính việc xử lý tùy chọn của thư viện, cryptoapicert xuất hiện trong số các chỉ thị chưa được triển khai, điều này phù hợp với cách phân chia trách nhiệm đó.

Sự tồn tại của các lệnh gọi lại đó không có nghĩa là một ứng dụng đóng gói cụ thể liệt kê kho cá nhân của người dùng hiện tại, hỗ trợ một nhà cung cấp khóa cụ thể hay có thể hoàn tất lời nhắc thẻ thông minh. Đó là các thuộc tính của frontend, và mỗi thuộc tính phải được frontend ghi lại.

Thay vào đó frontend của Windows làm gì

OpenVPN Connect đi theo một hướng khác: người vận hành nhập một tệp PKCS#12 chứa chứng chỉ và khóa riêng của nó vào một OpenVPN Certificate Store được tạo cho mục đích đó, rồi gán chứng chỉ bên ngoài cho hồ sơ. Đó là một bước nhập có chủ đích, không phải tự động phát hiện những gì tình cờ nằm trong kho cá nhân. Sự phân biệt này quan trọng khi ai đó cho rằng một chứng chỉ được cài cho mục đích khác sẽ chỉ đơn giản xuất hiện trong danh sách của ứng dụng khách.

Việc nhập cũng có hệ quả cho chính sách khóa, vì xuất một khóa ra tệp P12 chính là điều mà một khóa không thể xuất được thiết kế để ngăn chặn. Đây là một câu hỏi về chính sách chứ không phải về cấu hình, và nó xứng đáng có câu trả lời trước khi ai đó thử nhập.

Hãy chọn một hướng phù hợp với chính sách của khóa

Nếu thông tin xác thực có thể xuất được và chính sách cho phép việc nhập đã được ghi lại, hãy dùng quy trình đăng ký được bảo vệ của tổ chức và giữ tệp P12 tạm thời cùng mật khẩu của nó ngoài nhật ký và tập lệnh. Nếu khóa không bao giờ được rời khỏi thẻ thông minh hoặc một nhà cung cấp được bảo vệ, hãy chọn một kết hợp ứng dụng khách và nhà cung cấp hỗ trợ rõ ràng yêu cầu đó, hoặc lấy xác nhận từ nhà cung cấp cho phiên bản bạn đã cài. Không nhánh nào là cách thay thế cho nhánh kia.

Thêm lại chỉ thị vào hồ sơ không thể cung cấp một tích hợp mà ứng dụng không có. Một phiên bản ứng dụng khách mới hơn cũng không nhất thiết thêm nó, vì năng lực đó thuộc về thiết kế của chính frontend.

Sau khi khóa cục bộ hoạt động, máy chủ vẫn kiểm tra danh tính của chứng chỉ, chuỗi và quyền. Một khóa cục bộ dùng được và một danh tính VPN được chấp nhận là hai kết quả riêng biệt, và giữ chúng riêng biệt chính là điều ngăn một hạn chế của frontend biến thành một chính sách chứng chỉ suy yếu.

Bài viết liên quan