Apakah saya memerlukan sertifikat SSL terpisah untuk pengalihan DNS?


17

Saya menerapkan aplikasi multi-tenant di mana aplikasi saya menjadi host dan menyajikan dokumentasi teknis untuk produk tenant.

Sekarang, pendekatan yang saya sedang mempertimbangkan itu - saya host dokumentasi di docs.<tenant>.mycompany.comdan meminta penyewa saya untuk setup data CNAME DNS ke titik docs.tenantcompany.comke docs.<tenant>.mycompany.com.

Saya ingin situs ini diaktifkan SSL dengan sertifikat penyewa saya. Saya ingin memahami jika perusahaan penyewa saya memiliki sertifikat SSL wildcard, apakah akan berfungsi dengan pengaturan ini atau akankah sertifikat SSL baru harus dibeli docs.tenantcompany.com?


Hanya untuk memperjelas, Anda memiliki wildcard untuk * .mycompany.com?
zymhan

@WildVelociraptor ya saya punya sertifikat wildcard SSL untuk*.mycompany.com
codematix

@codematix Untuk menghindari keraguan, sertifikat wildcard untuk *.example.com tidak akan cocok docs.tenantname.example.com ! Wildcard hanya baik untuk satu 'sub-domain'; itu akan cocok docs-tenantname.example.com , misalnya. S3 Amazon adalah contoh yang bagus untuk hal ini: *.s3.amazonaws.comsertifikat gagal saat mengakses ember dengan titik, seperti www.example.com(yang berakhir dengan nama host seperti www.example.com.s3.amazonaws.com); nama bucket seperti itu diperlukan untuk hosting web S3.
Calrion

Perhatikan bahwa penggunaan cname yang menunjuk ke server Anda sendiri berarti Anda dapat menghindari kebutuhan akan sertifikat yang disediakan penyewa. Beberapa penyedia sertifikat (termasuk letsencrypt.org ) mendukung validasi kepemilikan domain melalui https. Sebagai praktik keamanan terbaik, pendekatan ini jauh lebih unggul (Sudah dibahas di serverfault.com/a/765957/4480 ). Tidak apa-apa untuk memungkinkan penyewa Anda memberikan sertifikat sendiri (meskipun membuatnya sendiri lebih mudah bagi penyewa), tetapi mereka TIDAK boleh memberikan sertifikat wild-card.
Brian

Jawaban:


39

Nama sertifikat harus cocok dengan apa yang dimasukkan pengguna di browser, bukan catatan DNS 'final'. Jika pengguna masuk docs.tenantcompany.commaka sertifikat SSL Anda harus membahasnya.

Jika docs.tenantcompany.comCNAME adalah untuk foo.example.com, sertifikat tidak perlu mencakup foo.example.com, adil docs.tenantcompany.com.


25

Jawaban Jason benar. Tetapi hanya untuk memperjelas istilah sedikit di sini, "DNS redirect" sedikit keliru. DNS memiliki catatan CNAME (alias alias) yang merupakan nama yang menunjuk ke nama lain. Tapi itu bukan redirect. Terjemahan dari nama ke nama ke IP semua terjadi di latar belakang dan browser Anda hanya peduli tentang nama awal.

Satu-satunya hal yang mengarahkan ulang adalah server web di mana server secara eksplisit memberitahu browser Anda untuk pergi ke tempat lain. Jika web server Anda sedang benar-benar melakukan redirect ke nama lain, Anda akan benar-benar perlu sertifikat untuk kedua nama browser Anda akhirnya akan menghubungkan mereka berdua secara terpisah.


2
Terima kasih telah mengoreksi saya. Anda benar, itu bukan pengalihan tetapi CNAME alias.
codematix

Klien saya memiliki Server Adomain with example.com. Saya membuat situs web untuknya dan mengelola situs dalam Server B. Klien saya mengkonfigurasi DNS-nya A Recordyang menunjuk dog.example.comke alamat IP server saya Server B. Sekarang klien saya mendapatkan SSL untuk dog.example.com. Pertanyaan saya adalah, apakah klien saya harus memberikan sertifikasi SSL kepada saya untuk dimasukkan ke dalam Server B? Atau dia hanya harus memasukkannya Server A? Atau apa lagi yang harus kita lakukan? Kami berdua bingung tentang ini, terima kasih!
user2875289

1
Jika A merekam dog.example.compoin langsung ke IP server Anda, maka ya. Server Anda harus berisi sertifikat dan kunci pribadi untuk nama itu. Server A dalam contoh Anda tidak relevan.
Ryan Bolger

@RyanBolger Ya, seperti yang Anda katakan. Klien saya menerapkan sertifikat untuk dog.example.comdan mengirim sertifikat dan kunci pribadi kepada saya. Saya meletakkannya di dalam Server Bdan mengkonfigurasi Nginx untuk menggunakannya. Dan semuanya bekerja dengan baik sekarang. Terimakasih!
user2875289

Hanya catatan tentang masalah teknis; karena sekarang ada catatan "ALIAS", saya tidak akan mengatakan bahwa CNAME juga alias;]
Garet Claborn

9

Saya ingin memahami apakah perusahaan penyewa saya memiliki sertifikat SSL wildcard, apakah akan berfungsi dengan pengaturan ini atau sertifikat SSL baru harus dibeli docs.tenantcompany.com?

Jawaban singkat: Tidak. Jika perusahaan penyewa Anda memiliki wildcard dalam nama *.tenantcompany.com, itu cukup untuk diinstal pada server Anda untuk menutupi akses melalui nama itu. Apakah Anda ingin melakukan ini atau tidak adalah cerita lain.

Sertifikat dalam nama docs.<tenant>.mycompany.com(mis. Sertifikat langsung, atau wildcard *.<tenant>.mycompany.com) tidak berguna jika akses selalu dilakukan melalui docs.tenantcompany.comnama.


Jawaban yang lebih panjang

Misalkan Anda menjelajah ke https://docs.tenantcompany.comdalam browser yang masuk akal. Browser menjalankan TLS melalui protokol HTTP. Ini peduli secara khusus tentang dua hal; bahwa:

  • subsistem DNS dari browser dan sistem operasi mengembalikan alamat IP dari host yang cocok, yang menjalankan server web pada port yang sesuai di tempat lain di jaringan lokal atau internet. Untuk lalu lintas HTTPS (diamankan), port defaultnya 443kecuali dinyatakan sebaliknya dalam URL.

  • Ketika jabat tangan TLS terjadi antara browser dan server jarak jauh, server menyajikan sertifikat tepercaya yang memungkinkannya menyediakan layanan TLS di alamat yang diminta ( docs.tenantcompany.com).

DNS

Browser melihat DNS sebagai kotak hitam. Itu membuat panggilan ke perpustakaan DNS yang sesuai untuk meminta pemetaan dari nama domain yang memenuhi syarat ramah (FQDN) menjadi alamat IP yang sesuai (v4 atau v6). Tidak peduli bagaimana mendapatkan alamat IP itu. Jika ada 20 CNAMEalias dalam DNS antara catatan asli dan Aatau AAAAcatatan, penyelesai DNS akan mengikuti mereka sampai alamat IP diperoleh.

TLS

Ketika browser melakukan jabat tangan TLS , perlu untuk memverifikasi bahwa server sedang berkomunikasi dengan berwenang untuk memberikan layanan situs Web aman di FQDN yang diminta: docs.tenantcompany.com.

Ingat: browser tidak peduli docs.<tenant>.mycompany.com- resolver DNS telah mengabstraksikan semua pengetahuan tentang tipuan melalui CNAMEcatatan.

Metode kami mengotorisasi server untuk melayani sesi aman docs.tenantcompany.comadalah dengan menggunakan sertifikat SSL yang ditandatangani oleh otoritas yang telah dipercaya sebelumnya di toko sertifikat root browser. Ini tidak selalu merupakan bentuk otentikasi terkuat dari server ke klien - banyak yang bisa salah dalam model CA terpusat - tetapi ini adalah yang terbaik yang kami miliki saat ini.

Ada dua peringatan lebih lanjut di sini:

Berbagi kunci

Banyak vendor sertifikat SSL komersial hanya akan menandatangani permintaan penandatanganan tunggal, yang secara efektif mengikat sertifikat wildcard ke kunci privat tunggal. Perusahaan penyewa mungkin merasa tidak nyaman membagikan hal ini di luar organisasi mereka, karena siapa pun yang memiliki kunci pribadi jelas dapat membahayakan komunikasi dengan perusahaan lain yang dijamin sistem keamanannya.

Beberapa vendor akan menandatangani beberapa permintaan penandatanganan sertifikat di bawah sertifikat yang sama, yang memungkinkan sertifikat wildcard tunggal diinstal pada beberapa server dan sistem tanpa berbagi kunci pribadi di antara mereka.

Menyamar

Jika perusahaan penyewa memberi Anda salinan sertifikat wildcard mereka (baik dengan membagikan kunci pribadi, atau menandatangani CSR Anda sendiri), Anda dapat menyamar sebagai <anydomain>.tenantcompany.com, memecah perlindungan penting yang memastikan integritas server yang diidentifikasi dalam tenantcompany.comnamespace DNS. Ini bisa menjadi posisi yang buruk bagi Anda dan perusahaan penyewa untuk ditempatkan, dari perspektif hukum / kewajiban.


Terima kasih banyak untuk jawaban terinci. Ini sangat membantu dan membantu saya mempertimbangkan aspek etika dan hukum dari apa yang saya coba lakukan.
codematix
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.