Giả sử thuộc tính Tên Thay thế Chủ đề (SAN) của chứng chỉ SSL chứa hai tên DNS
domain.tldhost.domain.tldnhưng Common Name (CN) được thiết lập để chỉ một trong hai: CN=domain.tld.
host.domain.tld, đang được yêu cầu?Cụ thể, OpenSSL 0.9.8b + xử lý tình huống đã cho như thế nào?
Câu trả lời:
Điều này phụ thuộc vào việc triển khai, nhưng quy tắc chung là miền được kiểm tra dựa trên tất cả các SAN và tên chung. Nếu miền được tìm thấy ở đó, thì chứng chỉ có thể kết nối.
RFC 5280 , mục 4.1.2.6 cho biết "Tên chủ đề CÓ THỂ được mang trong trường chủ đề và / hoặc phần mở rộng subjectAltName". Điều này có nghĩa là tên miền phải được kiểm tra với cả phần mở rộng SubjectAltName và thuộc tính Chủ đề (cụ thể là tham số tên chung của nó) của chứng chỉ. Hai nơi này bổ sung cho nhau, và không trùng lặp. Và SubjectAltName là một nơi thích hợp để đặt các tên bổ sung, chẳng hạn như www .domain.com hoặc www2 .domain.com
Cập nhật: theo RFC 6125 , được xuất bản vào năm 2011, trình xác nhận phải kiểm tra SAN trước, và nếu SAN tồn tại, thì không nên kiểm tra CN. Lưu ý rằng RFC 6125 là tương đối gần đây và vẫn còn tồn tại các chứng chỉ và CA cấp chứng chỉ, bao gồm tên miền "chính" trong CN và các tên miền thay thế trong SAN. Tức là bằng cách loại trừ CN khỏi xác thực nếu có SAN, bạn có thể từ chối một số chứng chỉ hợp lệ khác.
Để hoàn toàn chính xác, bạn nên đặt tất cả các tên vào trường SAN.
Trường CN nên chứa Tên chủ đề không phải là tên miền, nhưng khi Netscape phát hiện ra thứ SSL này, họ đã bỏ lỡ việc xác định thị trường lớn nhất của nó. Đơn giản là không có trường chứng chỉ được xác định cho URL máy chủ.
Điều này đã được giải quyết để đưa miền vào trường CN và ngày nay việc sử dụng trường CN không được dùng nữa, nhưng vẫn được sử dụng rộng rãi. CN chỉ có thể giữ một tên miền.
Các quy tắc chung cho việc này: CN - đặt tại đây URL chính của bạn (để tương thích) SAN - đặt tất cả miền của bạn ở đây, lặp lại CN vì nó không ở đúng vị trí ở đó, nhưng nó được sử dụng cho điều đó ...
Nếu bạn tìm thấy cách triển khai chính xác, câu trả lời cho các câu hỏi của bạn sẽ như sau:
Việc thiết lập này có ý nghĩa đặc biệt hay bất kỳ ưu điểm [không] nào so với việc thiết lập cả hai CN không? Bạn không thể đặt cả hai CN, vì CN chỉ có thể chứa một tên. Bạn có thể tạo bằng 2 chứng chỉ CN đơn giản thay vì một chứng chỉ CN + SAN, nhưng bạn cần 2 địa chỉ IP cho việc này.
Điều gì xảy ra ở phía máy chủ nếu máy chủ khác, host.domain.tld, đang được yêu cầu? Không có vấn đề gì xảy ra ở phía máy chủ.
Tóm lại: Khi một ứng dụng khách của trình duyệt kết nối với máy chủ này, thì trình duyệt sẽ gửi các gói được mã hóa, các gói này được mã hóa bằng khóa công khai của máy chủ. Máy chủ giải mã gói và nếu máy chủ có thể giải mã, thì nó đã được mã hóa cho máy chủ.
Máy chủ không biết bất cứ điều gì từ máy khách trước khi giải mã, vì chỉ địa chỉ IP không được mã hóa qua kết nối. Đây là lý do tại sao bạn cần 2 IP cho 2 chứng chỉ. (Quên SNI đi, vẫn còn quá nhiều XP ngoài đó.)
Ở phía máy khách, trình duyệt nhận CN, sau đó là SAN cho đến khi tất cả các mục được kiểm tra. Nếu một trong các tên trùng khớp với trang web thì việc xác minh URL đã được thực hiện bởi trình duyệt. (Tôi không nói về việc xác minh chứng chỉ, tất nhiên rất nhiều yêu cầu ocsp, crl, aia và câu trả lời xuất hiện trên mạng mỗi lần.)
Tôi thấy chưa có ai đề cập đến phần này trong Yêu cầu cơ bản. Tôi cảm thấy họ quan trọng.
H: SSL - Tên Chung (CN) và Tên Thay thế Chủ đề (SAN) hoạt động cùng nhau như thế nào?
A: Không hề. Nếu có SAN thì có thể bỏ qua CN. - Ít nhất là nếu phần mềm thực hiện kiểm tra tuân thủ rất nghiêm ngặt các Yêu cầu Cơ bản của CABForum.
(Vì vậy, điều này có nghĩa là tôi không thể trả lời "Chỉnh sửa" cho câu hỏi của bạn. Chỉ câu hỏi ban đầu.)
Yêu cầu cơ bản về CABForum, v. 1.2.5 (kể từ ngày 2 tháng 4 năm 2015), trang 9-10 :
9.2.2 Các trường tên phân biệt chủ đề
a. Chủ đề Tên chung Trường
chứng chỉ Trường: chủ đề: commonName (OID 2.5.4.3)
Bắt buộc / Tùy chọn: Không được dùng nữa (Không được khuyến khích, nhưng không bị cấm)
Nội dung: Nếu có, trường này PHẢI chứa một địa chỉ IP hoặc Tên miền Đủ điều kiện là một của các giá trị có trong phần mở rộng SubjectAltName của Chứng chỉ (xem Phần 9.2.1).
RFC 2818: HTTP qua TLS , 2000, Phần 3.1: Nhận dạng máy chủ :
Nếu có phần mở rộng subjectAltName của loại dNSName, nó PHẢI được sử dụng làm danh tính. Nếu không, trường Tên chung (cụ thể nhất) trong trường Chủ đề của chứng chỉ PHẢI được sử dụng. Mặc dù việc sử dụng Tên chung là phương pháp hiện có, nhưng nó không được dùng nữa và Tổ chức phát hành chứng chỉ được khuyến khích sử dụng dNSName thay thế.
RFC 6125: Đại diện và xác minh danh tính dịch vụ ứng dụng dựa trên miền trong cơ sở hạ tầng khóa công khai trên Internet sử dụng chứng chỉ X.509 (PKIX) trong bối cảnh bảo mật tầng truyền tải (TLS) , 2011, Mục 6.4.4: Kiểm tra tên chung :
[...] nếu và chỉ khi các số nhận dạng được trình bày không bao gồm DNS-ID, SRV-ID, URI-ID hoặc bất kỳ loại mã nhận dạng ứng dụng cụ thể nào được ứng dụng hỗ trợ, thì ứng dụng CÓ THỂ là phương án cuối cùng kiểm tra một chuỗi có biểu mẫu khớp với chuỗi của một tên miền DNS đủ điều kiện trong trường Tên chung của trường chủ đề (tức là CN-ID).