OpenSSL mengembalikan sertifikat SSL yang berbeda dengan yang ditunjukkan oleh Chrome


13

Saat menanyakan URL CDN Sparkfun menggunakan OpenSSL dengan perintah berikut:

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

Nama umum yang dikembalikan dalam sertifikat adalah *.sparkfun.com, yang gagal diverifikasi, tetapi jika Anda memuat host di Chrome, nama umum yang ditampilkan adalah*.cloudfront.net

Apa yang terjadi disini?

Ini menyebabkan masalah karena lingkungan saya dalam proxy SSL melalui Squid SSL_Bump, yang menghasilkan sertifikat yang ditandatangani oleh CA saya yang dipercaya secara lokal untuk domain tersebut. Ini berfungsi untuk semua domain tetapi di atas, karena CN tidak cocok karena sertifikat baru dihasilkan menggunakan OpenSSL.

EDIT - Saya telah memverifikasi hal yang sama terjadi dengan OpenSSL pada server di pusat data jarak jauh yang memiliki koneksi langsung ke internet tanpa melibatkan proxy atau penyaringan.

EDIT - Masalahnya adalah karena SNI, seperti yang diterima, tetapi untuk mengisi informasi mengapa hal itu menyebabkan masalah dengan Squid dan SSL_Bump:

Proyek ini tidak akan mendukung penerusan informasi SSL Nama Server (SNI) ke server asal dan akan membuat dukungan semacam itu menjadi sedikit lebih sulit. Namun, penerusan SNI memiliki tantangan serius sendiri (di luar ruang lingkup dokumen ini) yang jauh lebih besar daripada kesulitan penerusan tambahan.

Diambil dari: http://wiki.squid-cache.org/Features/BumpSslServerFirst

Jawaban:


23

CloudFront menggunakan SNI, cara untuk dapat menggunakan beberapa sertifikat pada satu IP. Semua browser modern mendukung ini, seperti halnya perintah s_client openssl, tetapi s_client tidak secara ajaib melakukan ini. Anda harus mengatakannya untuk menggunakannya:

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

2
Yaaay Dennis, itu " oooh, saya tidak tahu " diurutkan untuk SF hari ini, dan bahkan belum jam 9 pagi! +1 dari saya.
MadHatter

9

Chrome mendukung SNI , memberi tahu server sertifikat mana yang harus dikirim. The s_clientperintah tidak.

Ada detail lebih lanjut tentang penggunaan CloudFront tentang SNI di sini .

Ketika Anda menggunakan SNI Custom SSL, beberapa pengguna mungkin tidak dapat mengakses konten Anda karena beberapa browser lama tidak mendukung SNI dan tidak akan dapat membuat koneksi dengan CloudFront untuk memuat versi HTTPS dari konten Anda. Untuk informasi lebih lanjut tentang SNI, termasuk daftar browser yang didukung, silakan kunjungi halaman FAQ kami .

dan:

SNI Custom SSL bergantung pada ekstensi SNI dari protokol Transport Layer Security, yang memungkinkan banyak domain untuk melayani lalu lintas SSL melalui alamat IP yang sama dengan memasukkan nama host yang coba disambungkan oleh pemirsa. Seperti dengan Dedicated IP Kustom SSL, CloudFront memberikan konten dari setiap lokasi tepi CloudFront Amazon dan dengan keamanan yang sama seperti fitur SSL Kustom IP Dedicated. SNI Custom SSL berfungsi dengan sebagian besar browser modern, termasuk Chrome versi 6 dan yang lebih baru (berjalan di Windows XP dan yang lebih baru atau OS X 10.5.7 dan yang lebih baru), Safari versi 3 dan yang lebih baru (berjalan di Windows Vista dan yang lebih baru atau Mac OS X 10.5. 6. dan kemudian), Firefox 2.0 dan yang lebih baru, dan Internet Explorer 7 dan yang lebih baru (berjalan pada Windows Vista dan yang lebih baru). Browser lama yang tidak mendukung SNI tidak dapat membuat koneksi dengan CloudFront untuk memuat versi HTTPS dari konten Anda.


s_client mendukung SNI baik-baik saja ...
Dennis Kaarsemaker

+1 dari saya tetap, karena dokumentasi yang sangat baik ditampilkan.
MadHatter

Saya tidak mengatakan s_clienttidak mendukung CLI. Saya mengatakan s_clientperintah (di OP) tidak.
David Schwartz

@DavidSchwartz - Sebenarnya klien OpenSSL saya mendukung SNI dan saya dapat memverifikasi menggunakan informasi yang dijelaskan di sini.
Geoffrey

@ Geoffrey saya setuju. Perintah dalam OP yang tidak mendukung SNI.
David Schwartz
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.