IKEv2 có hai chữ ký: chứng chỉ và IKE_AUTH

Phiếu của bạn nói chứng chỉ là SHA-256 trong khi nhật ký cổng lại nêu một thuật toán chữ ký khác, và ai đó đã soạn sẵn một yêu cầu cấp lại CA. Trước khi yêu cầu đó đi đâu, hãy tách hai chữ ký: một là con dấu của nhà phát hành trên khóa công khai, còn lại là bằng chứng rằng đối tác giữ khóa riêng tương ứng trong IKE_AUTH. Các thành phần khác nhau chọn chúng, và chúng được phép khác nhau. Đọc từng cái từ nơi nó sống cần hai lệnh và một bảng.

Đọc chữ ký của nhà phát hành từ chứng chỉ

CA đặt chữ ký của mình lên mối ràng buộc giữa một danh tính và một khóa. Chữ ký đó ghi lại điều CA đã làm khi phát hành, không phải điều chủ thể sẽ làm khi kết nối, nên thuật toán của nó mô tả lựa chọn hàm băm và khóa của chính CA. Một khóa chủ thể thuộc loại này có thể nằm dưới khóa CA thuộc loại khác mà không có mâu thuẫn nào, và việc luân chuyển khóa CA là thường lệ chứ không phải lỗi. Đọc hai trường là bạn có nửa bản kiểm kê:

openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"

Ghi cả hai nhãn thành các mục riêng. Nhãn thứ nhất mô tả CA, nhãn thứ hai mô tả khóa của chủ thể, và không nhãn nào dự đoán chữ ký trực tuyến.

Đọc chữ ký trực tuyến từ trao đổi IKE

Trong quá trình xác thực, mỗi đối tác ký dữ liệu trao đổi bằng khóa riêng của mình, và phía bên kia kiểm tra bằng chứng đó dựa trên danh tính, chuỗi tin cậy và chính sách của chứng chỉ. Với RSA, phần đệm và hàm băm thuộc sơ đồ trực tuyến này, nên một khóa dài hơn hay chứng chỉ SHA-256 mới không thể tự chọn RSA-PSS cho chữ ký xác thực. Phương thức đã thương lượng xuất hiện trong nhật ký của daemon hoặc trong danh sách kết nối của nó, không bao giờ trong chứng chỉ. Hãy hỏi mỗi bên đã thương lượng gì, vì hai chiều có thể khác nhau.

ipsec statusall | grep -i "auth\|proposal"

Khi một bên nêu sơ đồ mà bên kia không tạo được, bạn đã tìm ra sự không khớp mà phiếu nói tới. Cấp lại CA là cách sửa sai, vì chứng chỉ chưa bao giờ là thứ đã hỏng.

RFC 7427 thay đổi điều gì và không thay đổi điều gì

Các phương thức ban đầu được đánh số theo từng tổ hợp thuật toán trong RFC 7296. Phần mở rộng chữ ký RFC 7427 về sau bổ sung một phương thức Digital Signature tổng quát với tín hiệu hỗ trợ hàm băm chữ ký, nên một hàm băm mới không còn cần số phương thức riêng. Điều này được thương lượng chứ không mặc định: đối tác không có được phần mở rộng chỉ vì thư viện của nó phân tích được cùng các chứng chỉ, và đối tác chỉ triển khai các phương thức ban đầu buộc cổng phải giữ một trong số đó. Đó là trao đổi chính sách với chi phí tương thích, không phải khiếm khuyết.

Hỗ trợ tính theo từng chiều và từng kết nối, nên hãy thử bản dựng trước mắt thay vì tin vào tuyên bố ở cấp họ sản phẩm. Một ma trận năng lực viết ba năm trước mô tả những bản dựng ba năm tuổi.

Đưa bốn dòng vào bản kiểm kê

Bản ghi kết thúc cuộc tranh luận có bốn dòng, mỗi dòng đọc ở một nơi khác và mỗi dòng do một người khác sửa. Hãy điền trước khi quyết định bất cứ điều gì, vì chính dòng sai mới là thứ chọn cách sửa.

Mỗi dòng mang hệ quả tương thích riêng. Thay đổi mật mã ESP không chọn chữ ký của nhà phát hành, và nới lỏng kiểm tra CA không thêm một phương thức trực tuyến mà các đối tác chưa bao giờ thương lượng. Khi một phiếu khẳng định có sự không khớp chữ ký, dòng thực sự sai hầu như không bao giờ là dòng đầu tiên.

Giải quyết trường hợp cũ mà không làm yếu PKI

Một đối tác cũ hơn có thể chỉ đưa ra sơ đồ mà chính sách của bạn không còn cho phép. Các lựa chọn là một ngoại lệ tương thích có thời hạn, cập nhật máy khách, hoặc một cách bố trí xác thực khác chỉ cho đối tác đó. Xây lại PKI quanh một chữ ký chứng chỉ yếu hơn không khắc phục hạn chế trong trao đổi trực tuyến và làm yếu mọi dịch vụ khác tin cùng CA. Ghi lại bạn đã đổi dòng nào và khi nào ngoại lệ hết hạn.

Sau đó chạy lại hai lần đọc từ đầu, vì thay đổi ở một dòng có thể dịch chuyển điều được thương lượng ở dòng khác. Toàn bộ bản kiểm kê là hai lệnh và một bảng, và công việc vẫn vậy dù đối tác là bộ định tuyến, máy tính xách tay hay thiết bị.