CA ký chéo: khóa khớp, nhưng ràng buộc AKI thì không

Hai chứng chỉ CA có thể có cùng khóa công khai và cùng subject mà vẫn không thể hoán đổi. Một cái tự ký, cái kia được ký chéo bởi root cũ, và tên nhà phát hành, số sê-ri cùng chữ ký của chúng khác nhau. Một lá có thể gắn cụ thể vào một trong hai thông qua Authority Key Identifier của nó. Ràng buộc đó vẫn vô hình cho đến khi một client chọn sai chuỗi và handshake thất bại mà không có lý do rõ ràng.

Thực hiện năm kiểm tra này theo thứ tự: mỗi kiểm tra loại trừ một kiểu lỗi khác nhau.

Kiểm tra 1: vẽ cả hai chuỗi trước khi chạm vào mẫu

Ghi lại các đường dẫn. Nhóm cũ tin vào Root cũ A, nơi đã phát hành CA B, nơi đã phát hành lá của máy chủ. Nhóm mới tin trực tiếp vào CA B tự ký. Cả hai chứng chỉ B đều mang cùng khóa và subject, và chính vì thế người đọc một dòng subject thấy một CA trong khi client thấy hai.

Bản sao ký chéo cũng phải là chứng chỉ CA thật, với basic constraints và key usage cho phép ký.

Kiểm tra 2: so sánh các trường AKI, không chỉ khóa

Tên nhà phát hành của lá phải khớp với subject của B, và phần đó thường đúng. Authority Key Identifier là nơi hai bản sao khác nhau, vì nó có thể mang định danh khóa, nhà phát hành chứng chỉ và số sê-ri. Định danh khóa khớp với cả hai bản sao, do khóa giống hệt nhau. Các trường nhà phát hành và sê-ri chỉ khớp đúng một bản, và vì thế một chuỗi dựng theo bản tự ký có thể thất bại với bản ký chéo.

Hãy kiểm tra lá thay vì đoán: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Sau đó so sánh cả hai ứng viên bằng openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", và lệnh tương tự với bản tự ký.

Nếu lá mang nhà phát hành và số sê-ri, chỉ chứng chỉ mà các giá trị đó mô tả mới hoàn tất chuỗi, bất kể client đã tải bản nào.

Kiểm tra 3: thay đổi chính sách phát hành, không bao giờ thay đổi byte đã ký

Các tiện ích mở rộng nằm bên trong chữ ký. Thêm, bớt hay sửa một tiện ích trên lá hiện có không phải là sửa chữa, đó là chứng chỉ khác và cần phát hành lại. Thay đổi thuộc về chính sách phát hành: authorityKeyIdentifier = keyid,issuer:always khiến các lá mới mang ràng buộc riêng cho chứng chỉ, trong khi chỉ keyid giữ dạng lỏng hơn phù hợp với một chuyển đổi ký chéo có chủ đích. Hãy quyết định PKI của bạn muốn cái nào trước khi lô tiếp theo được ký.

Sửa một mẫu dùng chung cũng thay đổi mọi chứng chỉ tương lai, không chỉ máy chủ trước mặt bạn.

Kiểm tra 4: xác minh từng nhóm tin cậy riêng biệt

Thử đường cũ và đường mới như hai lần chạy riêng. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem rèn luyện tuyến ký chéo, và cùng lệnh đó với root mới và không có tệp untrusted rèn luyện tuyến tự ký. Trộn cả hai root vào một gói sẽ che đi chuỗi nào đã được chọn. Sau đó lặp lại với client thật, vì backend VPN có thể ưu tiên một chuỗi hoặc ghim một chứng chỉ theo những cách openssl không làm.

Chuyển chứng chỉ trung gian qua cấu hình dịch vụ mà client thực sự đọc, không qua một trang wiki.

Kiểm tra 5: giữ đường cũ trên đồng hồ loại bỏ

Ký chéo theo thiết kế vẫn giữ sống một đường tin cậy cũ, đó vừa là mục đích vừa là rủi ro. Nó không khắc phục một root cũ đã bị xâm phạm và không loại bỏ root đó khỏi bất kỳ client nào. Ghi lại khi nào đường cũ ngừng cấp tin cậy, và xác nhận rằng ngày đó thực sự đến.

Nếu mọi client có thể chấp nhận root mới trước khi các lá di chuyển, một đợt triển khai tin cậy kép đơn giản sẽ dễ hơn ký chéo, và để lại ít hơn một thứ cần loại bỏ.