OCSP so với CRL: mỗi cách kiểm tra thu hồi thực sự hoạt động ra sao

Một trong hai cách kiểm tra thu hồi này trả về một câu trả lời đã ký về một chứng chỉ duy nhất, cách còn lại trả về một danh sách đã ký mà bạn tải xuống toàn bộ. Cả hai đều nhằm cho bộ xác minh biết liệu một thông tin xác thực còn đáng tin hay không, và cả hai đều thất bại theo những cách hoàn toàn không giống nhau. Trình tự dưới đây bám theo điều mà người vận hành thực sự gặp trong môi trường sản xuất, bắt đầu từ các byte trên đường truyền và kết thúc bằng một cổng từ chối kết nối. Bỏ qua một bước chính là cách một triển khai kết thúc với chính sách thu hồi chỉ tồn tại trên giấy.

Bước 1: Mỗi cách kiểm tra trả về gì và dùng được trong bao lâu

CRL được công bố như một đối tượng đã ký duy nhất bao phủ mọi chứng chỉ mà nhà phát hành đã thu hồi, nên bộ xác minh lấy nó một lần và dùng lại cho đến khi nextUpdate của danh sách trôi qua. Phản hồi OCSP hẹp hơn: nó trả lời chính xác cho một chứng chỉ và mang thisUpdate, producedAt và thường cả nextUpdate. Chính khác biệt đó chi phối mọi thứ còn lại. CRL được lưu đệm lặng lẽ cũ đi, vì tệp vẫn phân tích được và chữ ký của nó vẫn xác minh được, trong khi phản hồi OCSP hết hạn rõ ràng là vô giá trị ngay lúc bạn đọc các dấu thời gian của nó.

Vì vậy lưu đệm là điều đầu tiên cần xác định: thành phần nào giữ bản sao và bản sao đó tuân theo mức trần nào. Trên một cổng, mức trần phải là nextUpdate trừ đi một biên an toàn, không bao giờ là thứ mà một tiêu đề bộ đệm HTTP tình cờ gợi ý. openssl crl -in issuer.crl -noout -lastupdate -nextupdate in ra cả hai ngày, và một danh sách có nextUpdate đã ở trong quá khứ phải được coi là thiếu chứ không chỉ là cũ.

Bước 2: Chứng chỉ chỉ khách hàng đi đâu

Chứng chỉ lá thường mang hai gợi ý: một tiện ích mở rộng điểm phân phối CRL và một mục truy cập thông tin nhà cấp phép cho OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints in ra mục thứ nhất, còn mục thứ hai nằm dưới phần AIA của openssl x509 -in client.pem -noout -text. Bất kỳ tiện ích nào cũng chỉ là con trỏ, không phải nghĩa vụ. Một khách hàng không bao giờ triển khai kiểm tra thu hồi vẫn kết nối tốt với một chứng chỉ mà các tiện ích mở rộng của nó nêu tên một bộ phản hồi đã chết từ một năm nay.

Các điểm phân phối thường nêu tên một máy chủ nội bộ chỉ được phân giải trong một phân đoạn mạng, và một số khách hàng cũ từ chối thẳng URL ldap. Hãy kiểm tra khả năng tiếp cận từ máy chủ kết thúc đường hầm, không phải từ máy tính xách tay của bạn, vì đó là góc nhìn duy nhất mà sự cố của nó thực sự quan trọng.

Bước 3: Chọn fail-closed hoặc fail-open trước khi xảy ra sự cố

Một bộ phản hồi không tiếp cận được hoặc một danh sách hết hạn buộc phải quyết định: từ chối kết nối, hoặc chấp nhận và ghi lại khoảng trống. Lệnh con verify của OpenSSL làm rõ lựa chọn nghiêm ngặt, vì thêm -crl_check biến một CRL không khả dụng thành unable to get certificate CRL và một lần xác minh thất bại. Soft-fail trong hầu hết các chồng phần mềm hoàn toàn không phải một cờ, mà là việc thiếu kiểm tra, và đó chính là lý do nó được phát hành do tai nạn.

Để xem một khách hàng thực sự có hành vi nào, hãy bỏ bộ phản hồi đi và kết nối lại. Nếu đường hầm vẫn dựng lên, hãy tìm dòng nhật ký ghi lại lần kiểm tra bị bỏ qua, rồi tự hỏi liệu có ai đọc dòng đó trong một sự cố hay không. Cùng một nhà cung cấp có thể khác nhau theo giao thức: một khách hàng IKEv2 và một khách hàng OpenVPN trên cùng một máy đọc những cài đặt cấu hình không liên quan.

Bước 4: Chứng minh kiểm tra chạy ở nơi lưu lượng được chấp nhận

Tìm tiến trình kết thúc hoặc cấp phép kết nối, rồi hỏi nó dòng cấu hình bật kiểm tra thu hồi. Một cổng xác thực chuỗi nhưng không bao giờ hỏi về thu hồi đang áp dụng chính sách khác với chính sách trong tài liệu của bạn, và không ảnh chụp màn hình chuỗi chứng chỉ nào chứng minh điều ngược lại. OpenVPN ghi tùy chọn này là crl-verify; strongSwan giữ các tra cứu CRL và OCSP dưới cấu hình CA, nơi đặt crl_uris hoặc ocsp_uris. Nếu bạn không chỉ ra được cách nào trong hai, hãy cho rằng kiểm tra không tồn tại.

Phản hồi OCSP chỉ có giá trị khi CA phát hành đã ký nó, hoặc khi một bộ phản hồi có mục đích sử dụng khóa mở rộng OCSPSigning do CA đó ủy quyền đã ký nó, nên một câu trả lời từ dịch vụ không liên quan không chứng minh được gì. Nếu bạn tự vận hành bộ phản hồi, hãy giám sát nó như một phụ thuộc cứng, vì một dịch vụ chết sẽ trở thành sự cố cho mọi khách hàng fail-closed cùng một lúc.

Bước 5: Cố ý thu hồi một chứng chỉ

Lấy một chứng chỉ thử nghiệm, thu hồi nó qua cùng kênh mà môi trường sản xuất dùng, và hỏi trực tiếp bộ phản hồi. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text phải báo cáo Cert Status: revoked cùng với thời điểm thu hồi, và câu trả lời good nghĩa là việc thu hồi của bạn không đến được bộ phản hồi mà khách hàng của bạn hỏi. Sau đó chạy openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem để thấy cùng quyết định qua đường danh sách. Hãy đọc chuỗi lý do thay vì mã thoát, vì việc từ chối do thu hồi và lỗi chuỗi đều kết thúc bằng thất bại.

Bước thực sự quan trọng là bước cuối: kết nối lại bằng hồ sơ cũ trước điểm thực thi thật và xác nhận rằng việc từ chối đến từ hành động thu hồi. Sau đó kết nối lại bằng một chứng chỉ mới và hợp lệ để chứng minh bạn không chỉ làm hỏng trình lắng nghe. Xóa hồ sơ trên khách hàng không chứng minh được gì về quyết định của máy chủ, và việc chạy openssl verify thành công trên một máy không bao giờ kết thúc đường hầm cũng vậy. RFC 6960 định nghĩa một phản hồi OCSP tuân thủ chứa những gì, bao gồm các giá trị trạng thái mà bài kiểm tra này đọc.