OpenSSL trả lại chứng chỉ SSL khác nhau cho chứng chỉ được hiển thị bởi Chrome


13

Khi truy vấn url CDN của Sparkfun bằng OpenSSL bằng lệnh sau:

openssl s_client -showcerts -connect dlnmh9ip6v2uc.cloudfront.net:443

Tên chung được trả về trong chứng chỉ là *.sparkfun.comkhông xác minh được, nhưng nếu bạn tải máy chủ trong Chrome, tên chung được hiển thị là*.cloudfront.net

Chuyện gì đang xảy ra ở đây?

Điều này gây ra sự cố vì môi trường tôi ở proxy SSL thông qua Squid SSL_Bump, tạo ra chứng chỉ được ký bởi CA đáng tin cậy tại địa phương của tôi cho tên miền. Điều này hoạt động cho tất cả các tên miền nhưng ở trên, vì CN không khớp với chứng chỉ mới được tạo bằng OpenSSL.

EDIT - Tôi đã xác minh điều tương tự xảy ra với OpenSSL trên máy chủ trong một trung tâm dữ liệu từ xa có kết nối trực tiếp với internet mà không có proxy hoặc bộ lọc liên quan.

EDIT - Vấn đề là do SNI, như đã được chấp nhận, nhưng để điền thông tin về lý do tại sao nó gây ra sự cố với Squid và SSL_Bump:

Dự án này sẽ không hỗ trợ chuyển tiếp thông tin Chỉ định Tên Máy chủ SSL (SNI) đến máy chủ gốc và sẽ khiến việc hỗ trợ như vậy trở nên khó khăn hơn một chút. Tuy nhiên, chuyển tiếp SNI có những thách thức nghiêm trọng của riêng nó (vượt quá phạm vi của tài liệu này) vượt xa những khó khăn chuyển tiếp được thêm vào.

Lấy từ: http://wiki.squid-cache.org/Features/BumpSslServerFirst

Câu trả lời:


23

CloudFront sử dụng SNI, một cách để có thể sử dụng nhiều chứng chỉ trên một IP. Tất cả các trình duyệt hiện đại đều hỗ trợ điều này, cũng như lệnh s_client của openssl, nhưng s_client không thực hiện điều này một cách kỳ diệu. Bạn phải bảo nó sử dụng nó:

openssl s_client -servername dlnmh9ip6v2uc.cloudfront.net  -connect dlnmh9ip6v2uc.cloudfront.net:443 -showcerts

2
Yaaay Dennis, đó là " oooh, tôi không biết điều đó " được sắp xếp cho SF ngày hôm nay, và thậm chí còn chưa đến 9 giờ sáng! +1 từ tôi.
MadHatter

9

Chrome hỗ trợ SNI , báo cho máy chủ biết phải gửi chứng chỉ nào. Các s_clientlệnh thì không.

Có nhiều chi tiết hơn về việc sử dụng SNI của CloudFront tại đây .

Khi bạn sử dụng SNI Custom SSL, một số người dùng có thể không truy cập được nội dung của bạn vì một số trình duyệt cũ hơn không hỗ trợ SNI và sẽ không thể thiết lập kết nối với CloudFront để tải phiên bản HTTPS của nội dung của bạn. Để biết thêm thông tin về SNI, bao gồm danh sách các trình duyệt được hỗ trợ, vui lòng truy cập trang Câu hỏi thường gặp của chúng tôi .

và:

SNI Custom SSL dựa trên phần mở rộng SNI của giao thức Bảo mật lớp vận chuyển, cho phép nhiều tên miền phục vụ lưu lượng SSL trên cùng một địa chỉ IP bằng cách bao gồm các trình xem tên máy chủ đang cố gắng kết nối. Như với SSL tùy chỉnh IP chuyên dụng, CloudFront cung cấp nội dung từ từng vị trí cạnh của Amazon CloudFront và có cùng bảo mật như tính năng SSL tùy chỉnh IP chuyên dụng. SNI Custom SSL hoạt động với hầu hết các trình duyệt hiện đại, bao gồm Chrome phiên bản 6 trở lên (chạy trên Windows XP trở lên hoặc OS X 10.5.7 trở lên), Safari phiên bản 3 trở lên (chạy trên Windows Vista trở lên hoặc Mac OS X 10.5. 6. trở lên), Firefox 2.0 trở lên và Internet Explorer 7 trở lên (chạy trên Windows Vista trở lên). Các trình duyệt cũ không hỗ trợ SNI không thể thiết lập kết nối với CloudFront để tải phiên bản HTTPS của nội dung của bạn.


s_client hỗ trợ SNI tốt ...
Dennis Kaarsemaker

+1 từ tôi dù sao, vì tài liệu tuyệt vời được hiển thị.
MadHatter

Tôi không nói là s_clientkhông hỗ trợ CLI. Tôi đã nói s_clientlệnh (trong OP) không.
David Schwartz

@DavidSchwartz - Trên thực tế, ứng dụng khách OpenSSL của tôi hỗ trợ SNI và tôi có thể xác minh bằng cách sử dụng thông tin được mô tả ở đây.
Geoffrey

@Geoffrey Tôi đồng ý. Đó là lệnh trong OP không hỗ trợ SNI.
David Schwartz
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.