Chứng chỉ VPN đã thu hồi vẫn kết nối? Kiểm tra việc thực thi CRL

Bạn đã thu hồi chứng chỉ, tạo danh sách mới, và hồ sơ cũ vẫn dựng một đường hầm. Bản thân việc thu hồi không hỏng: CRL là một tuyên bố đã ký rằng một số sê-ri không còn hợp lệ, và nó chỉ thay đổi quyền truy cập khi thành phần kết thúc TLS tải nó, cho đúng nhà phát hành, trước khi đưa ra quyết định chấp nhận. Phần lớn các trường hợp này nằm ở đó, và vì vậy thu hồi và từ chối là hai sự thật khác nhau.

Hãy đi qua năm bước kiểm tra dưới đây theo thứ tự, và dừng ở bước đầu tiên không đúng, vì mỗi bước sau đều giả định các bước trước là đúng.

Kiểm tra thành phần nào đưa ra quyết định chấp nhận

Hãy nêu tên tiến trình xác minh chứng chỉ máy khách, vì chỉ tiến trình đó mới có thể thực thi một danh sách. Trên máy chủ OpenVPN đó là chính daemon, được cấu hình với crl-verify. Trong ocserv đó là dòng crl trong ocserv.conf. Trong strongSwan đầu vào là các CRL đã tải cùng với strictcrlpolicy. Một proxy hoặc thiết bị kết thúc TLS trước VPN cũng có thể là trình xác minh thật, và nếu vậy, daemon phía sau không bao giờ thấy chứng chỉ máy khách.

WireGuard thuộc một loại khác. Nó không có chứng chỉ và không có danh sách thu hồi; một peer được chấp nhận bằng khóa công khai của nó trong cấu hình, nên chấm dứt quyền truy cập nghĩa là xóa khóa đó. Nếu bạn đang tìm CRL trong một triển khai chỉ có WireGuard, cơ chế đó không có ở đó.

Cũng hãy cảnh giác với cái bẫy phía máy khách. Một máy khách từ chối kết nối vì không thích chứng chỉ của máy chủ đang thực thi chuỗi của máy chủ, chứ không thu hồi thông tin đăng nhập của chính nó. Chứng chỉ người dùng chỉ bị thu hồi ở nơi chứng chỉ người dùng đó được xác minh, và đó gần như luôn là phía máy chủ.

Kiểm tra danh sách được ký cho nhà phát hành nào

Một CRL chỉ giới hạn trong một CA phát hành. Với một gốc và một trung gian, các chứng chỉ lá đến từ trung gian, nên danh sách quan trọng là CRL của trung gian; danh sách của gốc không nói gì về những lá đó. Một trình xác minh trỏ vào tệp sai sẽ phân tích nó vui vẻ, không tìm thấy mục nào khớp và chấp nhận mọi thứ.

Xác nhận sự ghép cặp trước khi chạm vào daemon. Nhà phát hành trên chứng chỉ phải khớp với subject của danh sách:

openssl x509 -in client.crt -noout -issuer -serial
openssl crl  -in intermediate.crl -noout -issuer -lastupdate -nextupdate

Khi cả hai đến từ cùng một CA, số sê-ri được in cho chứng chỉ là giá trị phải xuất hiện trong danh sách. Nếu chúng không khớp, bạn đang giữ CRL sai hoặc bản sao sai của nó.

Tính hợp lệ thuộc cùng bước kiểm tra. nextUpdate trong quá khứ làm danh sách trở nên cũ, và một trình xác minh thất bại theo hướng đóng sẽ từ chối mọi máy khách thay vì chỉ cái bị thu hồi.

Kiểm tra số sê-ri có trong bản sao mà daemon đã tải

Thu hồi ghi một mục vào cơ sở dữ liệu CA, và tái tạo ghi một tệp mới. Không hành động nào đến được daemon đang chạy đã tải bản sao cũ lúc khởi động. Xuất danh sách và tìm số sê-ri:

openssl crl -in intermediate.crl -noout -text | grep -i -A2 'Serial Number'
openssl ca -revoke client.crt
openssl ca -gencrl -out intermediate.crl

Sau đó kiểm tra cách triển khai của bạn nhận tệp. OpenVPN đọc một đường dẫn được cấp cho crl-verify một lần lúc khởi động, nên danh sách mới cần khởi động lại hoặc tín hiệu khởi động lại; cùng tùy chọn trỏ vào một thư mục được đọc lại ở mỗi kết nối, và đó là lý do chế độ thư mục tồn tại. strongSwan phải tải lại thông tin đăng nhập của nó, ví dụ bằng swanctl --load-creds. Việc tệp trên đĩa đúng và việc trình xác minh dùng nó là hai sự thật khác nhau.

Kiểm tra chính sách cho danh sách bị thiếu hoặc hết hạn

Đây là quyết định mà nhiều triển khai không bao giờ đưa ra một cách rõ ràng, và nó quyết định việc thu hồi bảo vệ bạn hay khóa mọi người ra ngoài. Fail-closed nghĩa là không có thông tin thu hồi khả dụng sẽ tạo ra từ chối; fail-open nghĩa là trình xác minh tiếp tục mà không có nó. strongSwan công bố lựa chọn dưới dạng strictcrlpolicy. OpenVPN với crl-verify từ chối khởi động trên tệp mà nó không thể đọc hoặc phân tích, và một danh sách hết hạn hiện ra như lỗi xác minh TLS về CRL hết hạn thay vì chấp nhận âm thầm.

Dù bạn chọn hướng nào, tự động hóa quan trọng hơn lựa chọn: một tác vụ tái tạo CRL trước nextUpdate, và một cảnh báo khi bản sao đã triển khai già đi, giữ cho cả hai chính sách không trở thành sự cố. Kiểm tra trực tuyến với OCSP chuyển độ tươi mới sang một bộ trả lời, nhưng áp dụng cùng quy tắc, vì một trình xác minh không được cấu hình để kiểm tra câu trả lời không thay đổi gì.

Kiểm tra phiên đang hoạt động, rồi đến các bản sao của khóa

Thu hồi được đánh giá trong quá trình xác minh chứng chỉ, diễn ra khi kết nối và khi thương lượng lại. Một phiên đã thiết lập tiếp tục chạy cho đến khi thương lượng lại, và mặc định của OpenVPN là mỗi giờ một lần với reneg-sec 3600. Nếu người đó phải ra khỏi mạng ngay bây giờ, hãy kết thúc phiên cùng với việc công bố danh sách, rồi xác nhận rằng việc kết nối lại bị từ chối.

Tách thông tin đăng nhập khỏi các bản sao của nó. Xóa một hồ sơ trên một máy tính xách tay không ngăn một bản sao khác của cùng khóa riêng xác thực; chính việc thu hồi làm cho mọi bản sao vô dụng, và chỉ khi các bước kiểm tra trước đó đúng. Cấp cho thiết bị thay thế chứng chỉ riêng của nó để có thể thu hồi cái này mà không chạm vào cái kia.

Trước khi coi là xong: thành phần xác minh đã được xác định, nhà phát hành của danh sách khớp với nhà phát hành của lá, số sê-ri bị thu hồi nằm trong bản sao mà daemon thực sự đã tải, chính sách cho danh sách bị thiếu hoặc hết hạn là có chủ đích và được giám sát, và phiên đang hoạt động đã được kết thúc thay vì chờ đợi. Các định dạng đằng sau tất cả những điều này được quy định trong RFC 5280.