SAN của chứng chỉ IKEv2: vì sao kiểm tra danh tính thất bại

Chứng chỉ của bạn chuỗi tới một CA tin cậy, ngày tháng hợp lệ, và đối tác vẫn từ chối hoàn tất pha 1 với lỗi danh tính. Khả năng tiếp cận và chữ ký hợp lệ chỉ là một nửa những gì một ứng dụng IKEv2 kiểm tra. Nửa còn lại là danh tính mà nó mong đợi có xuất hiện trong chứng chỉ ở đúng trường hay không, và kỳ vọng đó do hồ sơ đặt ra, không phải tên tệp chứng chỉ.

Triệu chứng luôn có cùng một dạng

Một hồ sơ kết nối được đổi từ tên máy chủ sang địa chỉ IP, hoặc được gia hạn từ chứng chỉ mang tên DNS sang chứng chỉ chỉ mang địa chỉ, vàđường hầm ngừng thương lượng. Không có gì thay đổi trên đường mạng. Ứng dụng tới được đối tác, nhận chứng chỉ và từ chối danh tính của đối tác vì định danh mà nó được yêu cầu chờ đợi không có trong trường mà nó chấp nhận. Gia hạn là nguyên nhân thường gặp, vì chứng chỉ thay thế thường đến từ một mẫu khác với chứng chỉ bị thay thế.

Sau đó hai bên ghi nhật ký những thứ vô ích, đó là lý do sự cố thường được báo cáo như vấn đề chứng chỉ. Nhật ký ứng dụng có thể nêu danh tính mà nó muốn, và cái tên đó chính là manh mối bạn cần, không phải ngày hết hạn.

Ghép loại định danh, không chỉ giá trị

SAN dNSName và SAN iPAddress là các trường khác nhau với quy tắc khớp khác nhau, nên chứng chỉ mang 203.0.113.10 dưới dạng chuỗi DNS không thỏa mãn ứng dụng mong đợi danh tính IP. Các trình xác thực hiện đại phần lớn bỏ qua tên chung, nên nhãn thân thiện trong chi tiết chứng chỉ không chứng minh được gì về cái sẽ khớp. Nếu tên máy chủ đã bị thay bằng địa chỉ trong lúc khắc phục sự cố, hãy giả định danh tính mong đợi cũng di chuyển theo cho tới khi bạn kiểm tra. So sánh chuỗi trong hồ sơ với chuỗi trong SAN từng ký tự, vì một dấu chấm ở cuối hay một khoảng trắng thừa là đủ.

Ký tự đại diện chỉ là tiện ích của DNS và tuân theo quy tắc khớp riêng, đó là lý do khác khiến hồ sơ dựa trên IP không bao giờ nên dựa vào chúng.

Tìm nơi mỗi ứng dụng lưu kỳ vọng

Trong strongSwan, giá trị được so với chứng chỉ đến từ thiết lập danh tính đối tác: rightid trong cấu hình cổ điển, hoặc id của một phần kết nối từ xa trong swanctl. Tài liệu của nó về khả năng tương tác Apple IKEv2 hữu ích ở đây vì giải thích các quy ước danh tính mà ứng dụng được điều khiển bằng hồ sơ dùng, và những quy ước đó giải thích một nhóm không khớp trông có vẻ ngẫu nhiên trên đường truyền.

Hồ sơ cấu hình của Apple có trường định danh từ xa, và giá trị ở đó là cái ứng dụng kiểm tra, không phải địa chỉ máy chủ trong thiết lập kết nối. Ứng dụng Windows và thiết bị mỗi bên có trường riêng với giá trị mặc định riêng, và giá trị mặc định thường theo địa chỉ bạn đã nhập. Khi hai trường không đồng ý, bên mà ứng dụng thực sự đọc sẽ thắng, và hiếm khi là bên bạn đã sửa.

Sửa hồ sơ hoặc chứng chỉ, một cách có chủ đích

Trước khi thay đổi bất cứ điều gì, hãy kiểm tra chứng chỉ của đối tác bằng công cụ được phê duyệt và liệt kê các mục SAN cùng loại của chúng. Việc kiểm tra đó không cần khóa riêng và không cần tải lên, và giải quyết câu hỏi trong vài giây. Nếu triển khai dự định một danh tính DNS, chứng chỉ phải mang nó như một mục dNSName, và nếu triển khai dự định một địa chỉ, chứng chỉ cần một mục iPAddress cho đúng địa chỉ đó.

Khi chứng chỉ sai, hãy yêu cầu người vận hành cấp bản đã sửa với định danh mong đợi cụ thể. Khi hồ sơ sai, hãy sửa hồ sơ và để chứng chỉ yên. Tắt xác thực danh tính làm lỗi biến mất và loại bỏ việc kiểm tra rằng đường hầm đang nói chuyện với đối tác bạn định.

Ghi lại danh tính mong đợi cho từng nền tảng ứng dụng, vì một giá trị mà ứng dụng này tự suy ra có thể phải nêu rõ ở ứng dụng khác.

Cung cấp bốn dữ kiện cho yêu cầu gia hạn

Ghi lại định danh mong đợi và loại của nó, các mục SAN mà chứng chỉ hiện tại thực sự có, ứng dụng và phiên bản đang kiểm tra, và văn bản lỗi chính xác. Một yêu cầu gia hạn dựng từ bốn dòng này sẽ nhận được chứng chỉ đúng ngay lần đầu, thay vì một chứng chỉ khác có cùng tên tệp quen thuộc.