Tệp CA nào thuộc hồ sơ OpenVPN chỉ dùng mật khẩu?

Đi qua bốn câu hỏi theo thứ tự và hộp thoại CA không còn mơ hồ nữa. Nhà vận hành thực sự đã phát hành tài liệu nào, hồ sơ đã chứa gì, trường nào đang hỏi và điều gì xảy ra sau khi tệp được nạp? Hãy dừng ở câu hỏi đầu tiên mà bạn không thể trả lời từ chính hướng dẫn của nhà vận hành, vì đoán vượt qua nó chính là con đường khiến một chứng chỉ CA công khai bị ghép với một khóa riêng lẽ ra không bao giờ được rời khỏi máy chủ.

Thứ tự quan trọng: hai câu hỏi cuối chỉ có nghĩa khi bạn biết tài liệu nào đáng lẽ phải tồn tại.

Bắt đầu từ những gì hồ sơ đã có

Mở hồ sơ trong trình soạn thảo văn bản và tìm khối ca trước khi tìm tệp. Một khối ca nhúng chứa CA công khai của nhà vận hành nghĩa là hồ sơ tự chứa, và ứng dụng khách vẫn yêu cầu tệp CA có thể đang đọc hồ sơ khác hoặc bản nhập không đầy đủ. Nếu hồ sơ thay vào đó có dòng ca trỏ tới một đường dẫn, đường dẫn đó là tương đối với thư mục làm việc của ứng dụng khách trong một số tích hợp và tuyệt đối trong những tích hợp khác. Ghi lại dạng bạn có trước khi thay đổi bất cứ điều gì.

ca /absolute/path/operator-ca.crt
auth-user-pass
remote-cert-tls server

Kiểm tra gói được giao để tìm các tệp mà hồ sơ tham chiếu: chứng chỉ CA, đôi khi chứng chỉ và khóa của ứng dụng khách riêng, và có thể một tệp tls-auth hoặc tls-crypt. Hồ sơ tham chiếu bốn tệp nhưng đến với hai là không đầy đủ, và không lượng chỉ trỏ trường nào sửa được điều đó. Hãy yêu cầu nhà vận hành phần còn thiếu thay vì thay bằng chứng chỉ mà bạn tình cờ có.

Tách bốn loại tài liệu

Chứng chỉ CA là tài liệu công khai dùng để xác minh danh tính máy chủ. Chứng chỉ của ứng dụng khách nhận diện người dùng hoặc thiết bị với máy chủ. Khóa riêng là nửa bí mật của chứng chỉ khách đó, và nó không bao giờ được là khóa ký của CA hay khóa máy chủ. Tài liệu tls-auth hoặc tls-crypt là một bí mật chia sẻ riêng bảo vệ kênh điều khiển. Bốn thứ này không thể hoán đổi, và trỏ trường CA vào chứng chỉ khách tạo ra lỗi xác minh trông giống vấn đề tin cậy.

Xác thực chỉ bằng mật khẩu thay đổi việc bạn cần cái nào trong bốn, không thay đổi ý nghĩa của chúng. Với auth-user-pass và remote-cert-tls server, ứng dụng khách vẫn xác minh máy chủ dựa trên CA, vì thế trường CA xuất hiện ngay cả khi không có chứng chỉ khách. Chính sách của nhà vận hành quyết định có cần chứng chỉ khách hay không, và không hộp thoại nào có thể nói cho bạn điều đó.

Trỏ ứng dụng khách tới tệp tin cậy

Chọn chính tệp chứng chỉ CA, không phải thư mục chứa nó và không phải gói .p12 chứa danh tính khách. Trên Windows, cú pháp đường dẫn và bộ chọn tệp hoạt động khác với ví dụ Linux trong hầu hết các hướng dẫn, vì vậy hãy dùng thứ ứng dụng khách đã cài chấp nhận và xác nhận tệp đọc được bởi tài khoản chạy nó. Vấn đề quyền và tệp thiếu trông giống nhau trong hộp thoại nhưng tạo ra các dòng nhật ký khác nhau. Sau khi chọn, mở lại cài đặt hồ sơ để xác nhận ứng dụng khách đã giữ lựa chọn.

<ca>
-----BEGIN CERTIFICATE-----
...operator-provided public CA...
-----END CERTIFICATE-----
</ca>

Nếu ứng dụng khách hỗ trợ khối nhúng, hãy ưu tiên hồ sơ nhúng của nhà vận hành hơn hồ sơ tự lắp. Tài liệu nhúng đi cùng hồ sơ và sống sót qua lần nhập lại, trong khi đường dẫn tuyệt đối vỡ ngay khi hồ sơ chuyển sang máy khác.

Đọc lỗi tiếp theo, không phải cùng một lỗi

Mục đích của việc cung cấp CA đúng là thay đổi lỗi, không phải làm nó biến mất. Lỗi danh tính máy chủ sau khi nạp CA nghĩa là chứng chỉ không khớp với tên mong đợi hoặc kỳ vọng remote-cert-tls, đó là cách sửa khác với việc mật khẩu bị từ chối. Mật khẩu bị từ chối nghĩa là lớp TLS đã thành công và thông tin đăng nhập sai. Giữ thông báo mới đầu tiên; đó mới là thông báo hữu ích.

Một ứng dụng khách kết nối được nhưng không chạm tới đâu đã vượt qua hoàn toàn sự tin cậy và giờ đối mặt với câu hỏi định tuyến hoặc DNS.

Đừng bao giờ tắt xác minh để vượt qua hộp thoại đó. Một ứng dụng khách chấp nhận mọi chứng chỉ không có lý do gì để hỏi CA, và đường hầm nó xây không phải đường hầm mà nhà vận hành dự định.