OpenConnect cần PKCS#11 URI nào cho một token?

Một thẻ thông minh đã có sẵn khóa đúng vẫn phải được cho biết nên dùng đối tượng nào trên đó. OpenConnect không muốn một tệp .key được sao chép trong tình huống đó; nó muốn một PKCS#11 URI đặt tên cho chứng chỉ và, khi tìm kiếm tự động không thể hoàn tất công việc, cả khóa riêng bên cạnh. Phần khó chịu là một URI hợp lệ về cú pháp không chứng minh được gì. Nó phải đặt tên cho đăng ký mà cổng đã tin tưởng, không chỉ một đối tượng mà thẻ sẵn lòng mở.

Khách hàng muốn gì thay cho khóa đã xuất

Tùy chọn -c thường nhận một đường dẫn tệp, nhưng khi giá trị được phân tích như PKCS#11 URI, OpenConnect coi đó là tham chiếu đến một đối tượng bên trong token thay vì một tệp trên đĩa. Tùy chọn -k hành xử tương tự với khóa riêng. Không có gì được xuất và khóa không bao giờ rời khỏi sự bảo vệ mà thẻ cung cấp. Điều khách hàng cần ở bạn là một cái tên mà mô-đun token, kho chứng chỉ và đăng ký trên cổng cùng đồng ý.

Hầu hết các lần thử đều dừng ở ràng buộc cuối cùng này. Một URI có thể được tạo hoàn toàn đúng và vẫn chọn một chứng chỉ mà cổng sẽ từ chối, vì tính hợp lệ và tính liên quan là hai câu hỏi riêng. Kiểm tra đáng làm là so sánh với bản ghi đăng ký, không phải tìm đối tượng đầu tiên tình cờ mở được.

Hai URI, hai công việc khác nhau

URI của chứng chỉ trả lời bạn đang khẳng định danh tính nào. Nó trỏ tới một đối tượng chứng chỉ có khóa công khai và dòng chủ thể khớp với hồ sơ tài khoản hoặc thiết bị mà quản trị viên VPN đã cấp. Chính chứng chỉ đó thường đi kèm một đối tượng khóa riêng được lưu bên cạnh, và cặp đó là thứ mà bắt tay TLS thực sự cần.

URI của khóa trả lời vật liệu riêng tương ứng nằm ở đâu khi OpenConnect không thể suy ra. Khi chỉ đặt -c, khách hàng xây dựng tìm kiếm khóa từ các thuộc tính của chứng chỉ; việc cung cấp -k thay thế phỏng đoán bằng tham chiếu đối tượng rõ ràng. PIN của token là đầu vào thứ ba không liên quan: nó mở khóa thẻ cho thao tác, và không bao giờ xác định một đối tượng.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

Mọi thứ trong chuỗi được trích dẫn đó đều là dữ liệu. Các dấu chấm phẩy phân tách thuộc tính URI và các escape phần trăm mã hóa những ký tự mà nếu không sẽ phá vỡ việc phân tích, vì vậy toàn bộ đối số phải đi qua shell nguyên vẹn.

Tìm URI khớp với đăng ký của bạn

GnuTLS đi kèm p11tool, công cụ liệt kê những gì người dùng hiện tại thực sự có thể tiếp cận qua p11-kit. Bắt đầu với p11tool --list-tokens, sau đó liệt kê các đối tượng chứng chỉ trên token bạn quan tâm. Thêm --login khi các đối tượng chỉ xuất hiện sau PIN, và so sánh chủ thể cùng nhà phát hành với bản ghi đăng ký thay vì chọn thứ xuất hiện đầu tiên.

Nếu token hoàn toàn không xuất hiện, vấn đề nằm dưới OpenConnect: p11-kit không có mô-đun nào được đăng ký cho phần mềm trung gian đó, hoặc mô-đun được đăng ký cho một tài khoản khác. Đăng ký toàn hệ thống nằm dưới /etc/pkcs11/modules, và thư mục theo từng người dùng có thể chứa y hệt mà không chạm vào bản sao hệ thống. Kiểm tra rằng đường dẫn nhà cung cấp trong tệp mô-đun trỏ tới thư viện mà phần mềm của trình đọc thực sự đã cài đặt.

Khi sao chép URI từ danh sách, hãy giữ các dấu ngoặc kép xung quanh. Dấu chấm phẩy không được trích dẫn sẽ cắt đối số tại thuộc tính đầu tiên và khách hàng sau đó báo cáo một đối tượng mà nó không tìm thấy.

Khi tìm kiếm khóa tự động bỏ cuộc

OpenConnect có thể suy ra tìm kiếm khóa từ URI của chứng chỉ, nhưng việc khớp chính xác mà nó thực hiện phụ thuộc vào phiên bản, và cách xử lý loại đối tượng cùng nhãn đã thay đổi theo thời gian. Lời khuyên rút ngắn URI cho đến khi nó hoạt động mô tả một cách né tránh cũ, không phải yêu cầu. Nếu tìm kiếm suy ra thất bại, hãy đặt tên khóa một cách rõ ràng bằng -k thay vì biến URI của chứng chỉ thành thứ mơ hồ hơn.

Xác nhận rằng khóa tồn tại và nhìn thấy được bằng p11tool --list-keys trước khi đổ lỗi cho khách hàng. Sau đó kiểm tra xem đối tượng có được đánh dấu là dùng được cho ký hoặc giải mã hay không, vì khóa được tạo với thuộc tính sai không thể hoàn tất bắt tay, dù URI có đúng đến đâu. Đừng chuyển giá trị pkcs11-id đã tuần tự hóa từ hồ sơ OpenVPN sang tùy chọn OpenConnect; hai khách hàng dùng định dạng định danh khác nhau ngay cả khi nói chuyện với cùng một thẻ.

Nếu URI được giải quyết và PIN được chấp nhận nhưng xác thực vẫn thất bại, hãy ngừng tinh chỉnh URI. Đọc lỗi của chính cổng, vì thất bại tiếp theo nằm phía trên token.

Những thất bại trông chỉ như vấn đề URI

Một cổng nói giao thức khác sẽ thất bại giống hệt dù URI của bạn đúng hay sai. OpenConnect đã thay thế ứng dụng vpnc cũ vì một lý do, và hỗ trợ thẻ không làm cho một giao thức cổng không tương thích trở nên tương thích. Xác nhận giao thức mong đợi của máy chủ và cách bố trí xác thực trước khi dành thêm một giờ cho các thuộc tính của đối tượng.

Việc xác thực danh tính máy chủ cũng là một tầng riêng. Khách hàng xác minh chứng chỉ của cổng dựa trên kho tin cậy của mình, và việc kiểm tra đó chạy sau khi thẻ đã hoàn thành phần của nó. Quyền của trình đọc và dịch vụ pcscd bị dừng tạo ra cùng một triệu chứng bên ngoài, một token không đọc được, nhưng cách khắc phục đơn giản hơn nhiều.

Hãy làm việc từ đối tượng ra ngoài: p11tool có thấy token không, có thấy chứng chỉ và khóa không, OpenConnect có chấp nhận URI không, và chỉ khi đó mới hỏi liệu cổng có chấp nhận danh tính không. Mỗi bước có thông điệp lỗi riêng, và mỗi bước rẻ hơn để kiểm tra so với bước sau.