Trước khi chuyển đổi: khóa SSH và chứng chỉ OpenVPN

Việc nhập thất bại với lỗi chứng chỉ, nên bước hiển nhiên trông giống như một lần chuyển đổi. Bản năng đó dẫn người ta vào con đường mà phần mở rộng tệp thay đổi còn sự từ chối vẫn y nguyên. Một dòng ssh-ed25519 trong authorized_keys và một chứng chỉ máy khách OpenVPN là những đối tượng thông tin xác thực riêng biệt, với nhà phát hành, cách mã hóa và đường thu hồi khác nhau. Đi qua các kiểm tra này theo thứ tự sẽ cho bạn biết trong một phút liệu việc chuyển đổi có giúp được gì không.

Bạn thực sự đang giữ đối tượng nào?

Có năm thứ mà người ta gọi là khóa, và chỉ một trong số đó là thứ một hồ sơ TLS cần. Khóa công khai SSH là một dòng văn bản với tiền tố kiểu và tải trọng base64. Chứng chỉ OpenSSH là khóa đó cùng một chữ ký, principals và các tùy chọn, do ssh-keygen tạo ra khi hoạt động như CA nhỏ của chính nó. Chứng chỉ X.509 là một cấu trúc hoàn toàn khác, mang chủ thể, cửa sổ hiệu lực, các phần mở rộng và chữ ký từ một tổ chức phát hành chứng chỉ. Khóa riêng là nửa bí mật, và gói được phát hành thường là chứng chỉ cùng chuỗi của nó cùng khóa riêng trong một tệp.

Bài kiểm tra đầu tiên chỉ tốn một lệnh. Trỏ openssl vào tệp và yêu cầu nó phân tích cấu trúc chứng chỉ:

openssl x509 -in client.crt -noout -subject -issuer

Nếu lệnh đó thất bại với lỗi không tải được hoặc PEM, tệp không phải chứng chỉ X.509 bất kể bạn đã đặt tên gì. Đổi tên không viết lại ASN.1 bên trong, và việc bọc một dòng khóa công khai trong văn bản tiêu đề PEM cũng không làm được điều đó.

Hồ sơ có yêu cầu chứng chỉ hay không?

Chứng chỉ máy khách là một trong số các phương thức xác thực, và nhiều hồ sơ TLS đang hoạt động không bao giờ yêu cầu một chứng chỉ nào. Máy chủ có thể xác thực người dùng qua plugin, tên người dùng và mật khẩu, hoặc backend token, trong khi vẫn yêu cầu máy khách xác minh danh tính máy chủ. Nếu hồ sơ không có chỉ thị chứng chỉ máy khách, sẽ không bao giờ có chứng chỉ nào được yêu cầu, và không bản chuyển đổi nào khiến cổng vào yêu cầu một chứng chỉ.

Các cấu hình khóa tĩnh cũ là trường hợp thứ ba. Chúng có trước quá trình bắt tay TLS và mong đợi một tệp bí mật được chia sẻ trước, đó là lý do việc dán khóa công khai vào trường đó cũng không thể hoạt động. Hãy đọc xem hồ sơ thực sự yêu cầu gì trước khi kết luận rằng thông tin xác thực sai.

Mã hóa lại có thể làm gì và không thể làm gì

Khóa riêng thực sự có những vật chứa thay thế hợp lệ. Cùng một khóa RSA hoặc EC có thể được ghi dưới dạng PEM truyền thống, dạng PKCS#8, hoặc bên trong một gói PKCS#12, và các công cụ sẵn lòng chuyển đổi giữa chúng. Khóa công khai cũng có câu chuyện tương tự: ssh-keygen có thể xuất dạng RFC 4716 của một khóa SSH, và OpenSSH cũng hiểu định dạng chứng chỉ của riêng nó. Tất cả những thứ đó là biểu diễn, và biểu diễn không phải là tin cậy.

Điều mà chuyển đổi không thể làm là tạo ra chữ ký từ một tổ chức phát hành chứng chỉ chưa bao giờ thấy khóa của bạn. Chứng chỉ là lời khẳng định của nhà phát hành rằng một khóa công khai cụ thể thuộc về một chủ thể cụ thể cho một mục đích cụ thể. Mã hóa lại giữ nguyên các byte của khóa và để lời khẳng định vắng mặt, nên cổng vào không có gì để kiểm tra với kho tin cậy của nó.

Đây là bước mà hầu hết các nỗ lực âm thầm thất bại: tệp giờ kết thúc bằng .crt, máy khách đọc nó mà không phàn nàn, và quá trình bắt tay vẫn bị hủy vì phía đối diện không thể xây chuỗi đến một nhà phát hành tin cậy.

Tổ chức phát hành chứng chỉ xuất hiện ở đâu trong bức tranh

Việc đăng ký thực sự bắt đầu với một cặp khóa do bạn kiểm soát và một yêu cầu ký chứng chỉ mang chủ thể mà người vận hành mong đợi. Người vận hành xác minh quyền, ký yêu cầu bằng khóa CA và trả lại chứng chỉ đã phát hành cùng với bất kỳ chuỗi trung gian nào mà máy khách phải xuất trình. Sau đó máy khách cần chứng chỉ CA đã ký nó, vì đó là thứ cho phép nó xác nhận rằng máy chủ nó đang nói chuyện thuộc cùng một lần triển khai.

Tệp cuối cùng đó dễ quên và không thể thay thế. Bản thân khóa ký của CA không bao giờ thuộc về cấu hình máy khách, và không lượng chuyển đổi cục bộ nào tạo ra chuỗi mà lẽ ra bạn phải nhận được.

Cái giá của việc dùng lại khóa SSH

Giả sử một lần chuyển đổi thực sự tạo ra thứ gì đó chấp nhận được. Dùng lại một cặp khóa cho cả truy cập SSH và xác thực VPN vẫn ghép hai quyết định bảo mật độc lập với nhau. Xóa một mục trong authorized_keys dừng các lần đăng nhập SSH, và nó không làm gì với chứng chỉ mà CA của VPN đã phát hành cho cùng khóa công khai đó. Phía VPN bị thu hồi bằng cơ chế riêng của nó, tức là danh sách thu hồi chứng chỉ hoặc hồ sơ đăng ký của người vận hành.

Vì vậy danh sách kiểm tra kết thúc bằng một điều kiện dừng chứ không phải một mẹo. Nếu openssl không phân tích tệp như một chứng chỉ, hãy dừng chuyển đổi và mô tả bạn đang có gì: khóa SSH, chứng chỉ SSH, chứng chỉ X.509, khóa riêng hay gói. Nếu hồ sơ không yêu cầu chứng chỉ máy khách, hãy dừng lại và hỏi máy chủ mong đợi phương thức xác thực nào. Chỉ khi cả hai câu trả lời đều chỉ về X.509 thì đăng ký mới trở thành bước tiếp theo, và cuộc trao đổi đó diễn ra nhanh hơn nhiều khi câu đầu tiên có đúng danh từ.