Chứng chỉ lá hợp lệ, chuỗi đã hết hạn: đọc độ sâu

Bạn kiểm tra chứng chỉ máy chủ, thấy còn nhiều tháng trên đồng hồ, và ứng dụng khách vẫn từ chối kết nối với thông báo hết hạn. Ngày bạn đọc thuộc về lá, và khiếu nại có thể về một thứ sâu hơn trong đường dẫn. Việc xác minh đi qua một chuỗi, và bất kỳ chứng chỉ nào mà lượt đi này chọn đều có thể thất bại trong cửa sổ hiệu lực của chính nó. Đọc xem cái nào đã thất bại trước khi gia hạn bất cứ thứ gì.

Độ sâu nêu tên chứng chỉ đã thất bại

Trong chẩn đoán OpenSSL, độ sâu 0 là chứng chỉ đích và độ sâu 1 là nhà phát hành đã ký nó, với các số lớn hơn tiếp tục về phía neo tin cậy. Hết hạn được báo ở độ sâu 1 không bị mâu thuẫn bởi một notAfter hiện hành trên lá, vì vậy kiểm tra lại chứng chỉ nhìn thấy sẽ không bao giờ giải thích được lỗi.

Ghi lại dấu vân tay của chứng chỉ thất bại cùng với subject của nó, vì các chứng chỉ khác nhau có thể mang cùng tên CA. Ký chéo tạo ra chính tình huống đó: cùng một cơ quan xuất hiện nhiều hơn một lần, với các ngày hiệu lực khác nhau, và trình xác minh đã chọn cái bạn không ngờ tới. Một nhãn quen thuộc không phải là định danh, và dấu vân tay là thứ phân biệt hai đối tượng dùng chung một tên.

Cũng chú ý đến các sản phẩm có nhiều hơn một vai trò chứng chỉ. Trên OpenVPN Access Server, các chứng chỉ bảo vệ giao diện web tách biệt với những chứng chỉ dùng cho kết nối VPN, nên một trình duyệt mở trang quản trị không chứng minh gì về đường đi của đường hầm.

Đầu vào tin cậy không giống với các ứng viên chuỗi

Cung cấp cho trình xác minh hai đầu vào riêng biệt và rõ ràng. Tệp tin cậy chứa các neo bạn chấp nhận; gói không tin cậy chứa các chứng chỉ trung gian được đưa ra để xây dựng đường dẫn. Trộn chúng là cách người ta vô tình nâng một chứng chỉ trung gian lên thành gốc rồi tự hỏi tại sao cùng lỗi đó lại theo họ giữa các máy.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Vô hiệu hóa đường dẫn và kho lưu trữ mặc định bằng -no-CApath -no-CAstore giữ cho bài kiểm tra trung thực: kết quả khi đó phụ thuộc vào các tệp bạn đã nêu, không phải vào thứ mà máy trạm tình cờ tin tưởng. Tài liệu tham chiếu xác minh OpenSSL ghi lại các tùy chọn này và chẩn đoán mà chúng tạo ra.

-show_chain in ra chuỗi đã xây dựng khi xác minh thành công, hữu ích để xác nhận rằng đường dẫn là đường bạn định. Khi nó thất bại, hãy giữ độ sâu và subject được báo cáo; hai trường đó cho người đọc tiếp theo biết nên kiểm tra chứng chỉ nào.

Điều này không làm là tái tạo chính sách của từng ứng dụng khách. Một pin, một hạn chế mục đích hoặc một kiểm tra danh tính riêng cho khách sống trong ứng dụng khách, không phải trong lệnh này. Đó là những cài đặt cần kiểm tra khi xác minh thành công trên máy chủ mà kết nối vẫn thất bại. Giữ hai chẩn đoán tách biệt, nếu không bạn sẽ gia hạn một chứng chỉ khỏe mạnh trong khi đuổi theo lỗi pinning.

Kiểm tra chứng minh điều gì và bỏ sót điều gì

Đây là kiểm tra đường dẫn và mục đích đối với một tệp tin cậy bạn đã cung cấp. Đối với kiểm tra tên HTTPS, thêm tên máy chủ mong đợi qua tùy chọn thích hợp; đối với kết nối VPN, giữ các kiểm tra danh tính đã cấu hình của ứng dụng khách và dùng tài liệu tin cậy mà ứng dụng khách đó thực sự đọc.

Những gì một máy chủ gửi là một tập ứng viên, không phải đường dẫn mà ứng dụng khách của bạn cuối cùng sẽ xây dựng. Tin cậy cục bộ và các quy tắc xây dựng của thư viện đều định hình kết quả, đó là lý do cùng một phản hồi có thể xác minh trên một máy và thất bại trên máy khác. So sánh kho tin cậy được duy trì và việc triển khai TLS của ứng dụng khách thất bại với của một ứng dụng khách đang hoạt động trước khi giả định đánh giá giống hệt. Một khác biệt ở đó giải thích nhiều báo cáo „chỉ chiếc laptop này thất bại“.

Để xem cửa sổ của từng chứng chỉ thay vì từng cái một, in chúng như một tập:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Lệnh thứ hai đó liệt kê subject và nhà phát hành mà không giải mã từng tệp bằng tay, đó là cách bạn phát hiện một chứng chỉ trung gian đã quá ngày trong khi lá vẫn trông ổn.

Sửa đường dẫn mà không làm yếu xác minh

Khi một chứng chỉ trung gian đã hết hạn hoặc một chứng chỉ ký chéo lỗi thời được cung cấp, hãy lấy chuỗi hiện được hỗ trợ của nhà phát hành và triển khai nó qua quy trình chứng chỉ được ghi lại của dịch vụ. Khi ứng dụng khách thiếu neo được duy trì dự định, hãy cập nhật cấu hình tin cậy được quản lý hoặc phần mềm khách. Chống lại lối tắt đánh dấu mọi chứng chỉ trong gói là gốc chỉ để làm im thông báo.

Việc xử lý gốc đáng có một ghi chú, vì các bản tóm tắt thường phóng đại nó. RFC 5280 coi neo là đầu vào nằm ngoài đường dẫn tương lai, trong khi OpenSSL ghi lại các kiểm tra hiệu lực bao gồm chứng chỉ CA gốc của nó. Cả hai phát biểu đều đúng cho hệ thống của riêng chúng; khái quát hóa hành vi hết hạn gốc của một thư viện cho mọi ứng dụng khách tạo ra những câu trả lời sai một cách tự tin.

Sau thay đổi, buộc xác thực mới trên ứng dụng khách bị ảnh hưởng và xác nhận rằng thông báo hết hạn cụ thể đã biến mất. Chỉ gia hạn lá nếu bản thân lá không phù hợp. Vô hiệu hóa kiểm tra thời gian hoặc khôi phục một chứng chỉ chéo lịch sử không tạo ra đường dẫn hiện tại hợp lệ; nó chỉ trì hoãn lần thất bại tiếp theo.