2014-09-22 17 views
5

Tôi đã tạo chứng chỉ cho máy chủ nội bộ cũng có thể truy cập từ bên ngoài. Theo this SO trả lời CN và các trường SAN khen nhau và do đó, tôi đặt CN thành server.domain.local và trong SAN tôi có DNS: server.domain.tldTên thường gặp không hợp lệ khi sử dụng chứng chỉ SAN

Tuy nhiên, với Chrome ít nhất , Tôi có thể duyệt đến server.domain.tld (mục nhập SAN) mà không có lỗi nhưng tôi nhận được một lỗi không khớp tên phổ biến tại server.domain.local (CN)

Đây có phải là lỗi triển khai trong NSS trên Chrome hay không. Có gì đó không đúng? Tôi có nên có cả server.domain.local và server.domain.tld trong trường SAN không?

Trả lời

6

.. CN và các lĩnh vực SAN khen nhau ..

Đó là chỉ đúng trong trường hợp PKI chung, nhưng giao thức cụ thể có hành vi khác nhau. RFC liên quan để kiểm tra giấy chứng nhận trong HTTPS là RFC2818 (hay muộn RFC6125) trong đó nêu:

If a subjectAltName extension of type dNSName is present, that MUST 
be used as the identity. Otherwise, the (most specific) Common Name 
field in the Subject field of the certificate MUST be used. Although 
the use of the Common Name is existing practice, it is deprecated and 
Certification Authorities are encouraged to use the dNSName instead. 

Điều đó có nghĩa, nếu bạn có một phần SAN nó phải có đầy đủ tên, vì CN sẽ không được kiểm tra.

+0

Tôi tin rằng bạn cuz đó là những gì tôi đang trải qua IRL nhưng những gì về RFC 5280 (Phần 4.1.2.6) mà có dấu ngoặc kép câu trả lời khác? – JonoCoetzee

+0

RFC5280 chỉ chung cho các cấu trúc PKI. RFC2818 và RFC5216 thay vì đối phó với xác minh chứng chỉ trong ngữ cảnh của các giao thức ứng dụng cụ thể. Ví dụ: RFC5280 rõ ràng không giải quyết việc xử lý các ký tự đại diện, trong khi RFC2818 thực hiện. Vâng, điều này rất khó hiểu: ( –

+0

Bạn không đề cập đến RFC 6125 thay vì 5216? – Bruno

4

CN và các lĩnh vực SAN khen nhau và do đó phù hợp tôi đặt CN để server.domain.local và trong SAN Tôi có DNS: server.domain.tld

Không (nhưng bài đăng đó đã cũ rồi).

Đặt tên DNS là Tên chung (CN) không được chấp nhận bởi cả IETF và Diễn đàn CA/Trình duyệt. Bạn nên đặt tất cả các tên DNS trong Subject Alternate Name (SAN). Sử dụng CN cho một tên thân thiện như "Example LLP" kể từ khi nó được hiển thị cho người dùng.

Theo yêu cầu cơ bản của CA/Trình duyệt (BR), tên DNS trong CN cũng phải có mặt trong SAN. Xem CA/B BR, Section 9.2.


Chrome ít nhất, tôi có thể duyệt đến server.domain.tld (SAN entry) mà không có lỗi nhưng tôi nhận được một lỗi tên không khớp thường gặp ở server.domain.local (CN)

Chrome đang từ chối giấy chứng nhận nếuserver.domain.local hiện diện trong CN, nhưng không phải là hiện diện trong SAN. Vi phạm CA/B BR nếu nó không có trong cả hai.


Tôi có nên có cả hai server.domain.local và server.domain.tld trong lĩnh vực SAN

Vâng, đặt cả tên DNS trong SAN. Không đặt tên DNS trong CN. Sử dụng CN cho một tên thân thiện.


Để hoàn chỉnh, CA/B là viết tắt của CAtrình duyệt. Họ có một câu lạc bộ khép kín và họ có chính sách riêng để cấp chứng chỉ. Đừng mong đợi các trình duyệt làm những việc như được chỉ định trong các tài liệu IETF.

Và nếu bạn đang xác thực chứng chỉ X509 được sử dụng trong tự nhiên do CA là thành viên của CA/B, thì bạn nên xác thực bằng CA/B BR chứ không phải tài liệu IETF.

1

Câu hỏi ban đầu đã được trả lời, nhưng tôi muốn trả lại một điểm được đưa ra trong một trong các câu trả lời.

Sử dụng CN cho một cái tên thân thiện, trong khi hấp dẫn và hợp lý với tôi, không được hỗ trợ bởi CA/B BR. Trong phiên bản trước của BR/CA BR, đây là phần 9.2.2, nhưng dường như gần đây đã chuyển. https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf


7.1.4.2.2. Chủ đề Tên phân biệt Các trường

a. Trường Chứng chỉ: subject: commonName (OID 2.5.4.3) Bắt buộc/Tùy chọn: Không được chấp nhận (Không 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 một trong các giá trị chứa trong phần mở rộng subjectAltName của chứng chỉ.


Kính, --obivon

Các vấn đề liên quan