Rumah  >  Artikel  >  pembangunan bahagian belakang  >  Adakah aplikasi yang mengakses hos yang ditentukan pengguna melalui HTTPS cuba memberikan bantuan dengan mencari FQDNnya?

Adakah aplikasi yang mengakses hos yang ditentukan pengguna melalui HTTPS cuba memberikan bantuan dengan mencari FQDNnya?

WBOY
WBOYke hadapan
2024-02-14 14:42:07798semak imbas

通过 HTTPS 访问用户指定主机的应用程序是否应该尝试通过查找其 FQDN 来提供帮助?

Mengakses aplikasi pada hos yang ditentukan pengguna melalui HTTPS ialah keperluan biasa, tetapi anda mungkin mengalami kekeliruan dalam aplikasi praktikal. Untuk masalah ini, editor PHP Banana berpendapat kami harus cuba membantu dengan mencari FQDN. FQDN (Nama Domain Layak Penuh) ialah nama domain yang layak sepenuhnya, termasuk nama hos dan nama domain. Dengan mencari FQDN, anda boleh memastikan bahawa hos yang ditentukan oleh pengguna terletak dengan tepat, dengan itu memberikan bantuan dan perkhidmatan yang tepat. Oleh itu, mencari FQDN ialah strategi yang bermanfaat apabila membuat akses HTTPS.

Kandungan soalan

Saya menggunakan aplikasi golang yang berkomunikasi dengan pelayan melalui HTTPS pada hos lain. Khususnya, jika konteks penting: Berkomunikasi dengan gugusan Dataproc daripada tika GCE dalam projek Google Cloud yang sama (tiada persediaan domain khas diperlukan).

Pelayan menjana sijil yang ditandatangani sendiri, yang telah saya pasang secara manual pada klien.

Kedua-dua pelayan dan pelanggan ialah tika GCE pada projek Google Cloud saya (FQDN mereka ialah 581ce0c2a03eb2244e4d3a83f2c5e59d.c.ebfcb145e568f70e9a690c02a46a321e.internal)

Jika saya cuba menyambung ke pelayan daripada klien menggunakan http.Client golang, saya mendapat ralat seperti ini:

failed to verify certificate: x509: certificate is valid for *.c.<project_id>.internal, not <server_hostname>

Tetapi jika saya luluskan FQDNnya (4c7198d8b6b4fb195532e2caff10f39a.c.ebfcb145e568f70e9a690c02a46a321e.internal) ia berfungsi di luar kotak.

FYI, tingkah laku ini konsisten dengan apa yang saya lihat semasa menjalankan cURL:

curl: (60) SSL: no alternative certificate subject name matches target host name '<server_hostname>'

Jadi soalan saya ialah:

  1. Mengapa ia tidak berfungsi dengan nama hos pendek/separa? Ia berada dalam domain yang sama, jadi ia adalah sebahagian daripada *.c.ebfcb145e568f70e9a690c02a46a321e.internal dan ia berfungsi di luar kotak, bukan? Atau adakah ia sentiasa memerlukan rentetan yang diluluskan digunakan untuk benar-benar sepadan dengan rentetan kad bebas (bermaksud ia tidak melakukan carian dan hanya berfungsi jika anda lulus dalam fqdn)?
  2. Apakah amalan terbaik semasa membina apl untuk pengedaran? Sekiranya saya menambah sedikit logik untuk memintanya mengira FQDN supaya ia boleh menukar nama pendek menjadi nama panjang yang lebih cenderung digunakan dengan sijil yang ditandatangani sendiri, atau menyerahkannya kepada pemanggil untuk mengetahui ralat rahsia mesej? Li>

NOTA: Saya tidak mahu melangkau pengesahan - saya hanya mahu memahami dengan lebih baik perkara yang sedang berlaku dan mengetahui amalan terbaik di sini.

Terima kasih!

Penyelesaian

  1. Sijil dipadankan dengan domain/hos berdasarkan nama yang terkandung di dalamnya, jadi walaupun 4c7198d8b6b4fb195532e2caff10f39a dan 4c7198d8b6b4fb195532e2caff10f39a4c7198d8b6b4fb195532e2caff10f39a.c.ebfcb145e568f70e9a690c02a46a321e.internal menyelesaikan kepada kandungan yang sama, sijil hanya mengandungi yang kedua (atau wildcard it perlawanan). Oleh kerana ini dijana sendiri, anda boleh menambah nama pendek di dalamnya sebagai SAN (Nama Alternatif Subjek). Bendera tambahan untuk OpenSSL:
-addext "subjectAltName = DNS:localhost,DNS:<server_hostname>"

CA awam tidak mungkin memberikan anda sijil SAN yang tidak boleh diselesaikan secara terbuka. (Beberapa kemungkinan, saya belum mencubanya)

Sebagai contoh, anda tidak mahu bermula dari google.com.someevildomain.org 提供或信任 google.com jadi ini adalah ciri keselamatan.

  1. Bergantung pada keadaan. Jika anda mempunyai kawalan ke atas sijil, cuma tambah nama yang ingin anda gunakan. Ini mungkin akhirnya menjadi sijil tunggal dengan banyak SAN, dalam hal ini mungkin lebih bersih untuk meminta semua orang bercakap menggunakan FQDN. Jika anda boleh mengimport banyak sijil, lebih baik setiap perkhidmatan mempunyai sijil sendiri dengan FQDN dan nama pendek.

Atas ialah kandungan terperinci Adakah aplikasi yang mengakses hos yang ditentukan pengguna melalui HTTPS cuba memberikan bantuan dengan mencari FQDNnya?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Artikel ini dikembalikan pada:stackoverflow.com. Jika ada pelanggaran, sila hubungi admin@php.cn Padam