421 Permintaan Salah Arah


10

Saya terkadang mendapatkan kesalahan 421 berikut:

Permintaan salah arah

Klien membutuhkan koneksi baru untuk permintaan ini karena nama host yang diminta tidak cocok dengan Indikasi Nama Server (SNI) yang digunakan untuk koneksi ini.

Namun, menyegarkan peramban menghapus kesalahan dan halaman dimuat secara normal. Waktu berikutnya memuat halaman tidak akan menghasilkan dan kesalahan dan dengan demikian polanya tampak cukup acak. Satu-satunya pola yang dapat saya lihat adalah hal ini dapat terjadi Ketika saya mengarahkan ulang halaman menggunakan header ("Lokasi:". $ Url);

Saya memiliki Sertifikat Multi-Domain PositiveSSL dari Comodo. Server saya adalah Apache pada layanan hosting web bersama sehingga saya tidak memiliki akses ke konfigurasi.

Saya memuat halaman dari satu domain dan di dalam halaman ada tautan ke domain kedua pada sertifikat.

Segala sesuatu yang saya baca tentang kesalahan ini tampaknya menunjukkan masalah ini terkait dengan ini menjadi sertifikat multi-domain.

Yang ingin saya ketahui adalah apakah ada sesuatu di sisi pengkodean laman web (php) yang dapat menyebabkan hal ini (dan dapat diperbaiki) atau jika itu merupakan kesalahan konfigurasi atau mungkin kesalahan server dan hanya layanan hosting saya yang dapat melakukannya. memperbaikinya.

Layanan hosting saya sejauh ini tidak dapat memberikan apa-apa dan meminta menelepon kembali dengan tepat waktu yang terjadi selanjutnya sehingga mereka dapat melakukan riset. Bantuan apa pun akan dihargai karena saya tidak terlalu percaya diri bahwa mereka dapat memecahkannya.

UPDATE Ok, hampir beberapa tahun kemudian dan memutuskan sudah waktunya untuk menghadapinya. Saya bisa menyelesaikan sebagian besar masalah dengan menghapus domain statis saya yang menyajikan gambar dan javascript. Namun, saya masih menggunakan domain kedua untuk beberapa konten ini dan Safari khususnya masih memberi saya masalah.

Saya melakukan lebih banyak riset dan menemukan artikel lain yang membicarakannya di sini . Persis seperti yang dijelaskan oleh @Kevin. Artikel tersebut mengkonfirmasi bahwa itu terjadi di Safari. Maka dengan mengambil saran, saya mulai mendapatkan sertifikat terpisah untuk setiap domain. Saya menggunakan host bersama (Webhostinghub) dan mendapati mereka sekarang menawarkan SSL gratis (AutoSSL) yang diperbarui secara otomatis. Kedengarannya bagus untuk menjadi kenyataan. Mereka mengatur saya dengan 5 sertifikat gratis. Sejauh ini bagus. Saya bahkan dapat mencoba mengaktifkan kembali domain statis untuk diuji. Jika ini berhasil, saya akan menghemat $ untuk boot sebagai bonus dan membiarkan sertifikat Comodo saya kedaluwarsa pada bulan Juli.


Apakah Anda meng-hosting beberapa situs web di server Apache yang sama DAN menggunakan sertifikat SSL yang sama DAN kesalahan terjadi ketika beralih di antara nama domain ini?
John Hanley

Jika jawabannya YA, periksa apakah alamat IP untuk setiap domain memetakan ke server virtual yang sama. Jika YA, maka Anda memiliki dua pilihan (yang dapat saya pikirkan): 1) Terbitkan sertifikat SSL terpisah untuk setiap nama domain. 2) Pindahkan server web untuk setiap domain berada di server yang berbeda (alamat IP berbeda). Karena Anda menggunakan hosting bersama, opsi 1 mungkin merupakan solusi terbaik. Anda dapat menguji solusi ini menggunakan Let's Encrypt untuk mengeluarkan beberapa sertifikat gratis untuk dipasang di server web lain.
John Hanley

Tanyakan penyedia hosting Anda apakah mereka dapat menonaktifkan mod_http2.
John Hanley

@ JohnHanley - ulang # 1, ya itu SSL yang sama dengan 6 domain di dalamnya. Tidak mudah untuk mengatakan dengan tepat kapan kesalahan terjadi. Skenario utama adalah bahwa saya berada di satu domain menarik konten (gambar dan js) dari dua domain lainnya. Re # 2: Alamat IP pasti sama - saya mengumpulkan mengeluarkan sertifikat terpisah setiap nama domain akan lebih mahal. Saya melihat Mari Mengenkripsi tetapi tidak didukung oleh penyedia saya. Penyedia saya dalam 6 bulan terakhir menawarkan sertifikat gratis, jadi ketika pembaruan muncul bulan ini, saya akan beralih dan melihat apa yang terjadi. Re # 3 - mereka tidak dapat menonaktifkan mod_http2. Terima kasih
mseifert

Sebenarnya, semua penyedia mendukung Let's Encrypt kecuali mereka secara khusus memblokirnya. Sertifikat SSL adalah sama di mana pun Anda mendapatkannya. Satu-satunya perbedaan adalah jenis validasi (DV, OV, EV) dan kemasan / format file. Apache sangat populer sehingga semua orang mendukungnya. Selama vendor Anda mendukung Anda mengunggah sertifikat Anda sendiri (sertifikat dan kunci pribadi), Anda dapat menggunakan validasi DNS untuk mengatasinya. Jika mereka tidak mendukung mengunggah sertifikat Anda sendiri, maka saya akan beralih vendor.
John Hanley

Jawaban:


13

Ini disebabkan oleh urutan kejadian berikut:

  1. Server dan klien mendukung dan menggunakan HTTP / 2.
  2. Klien meminta halaman di foo.example.com.
  3. Selama negosiasi TLS, server menyajikan sertifikat yang berlaku untuk keduanya foo.example.comdan bar.example.com(dan klien menerimanya). Ini dapat dilakukan dengan sertifikat wildcard atau sertifikat SAN.
  4. Klien menggunakan kembali koneksi untuk membuat permintaan bar.example.com.
  5. Server tidak dapat atau tidak mau mendukung penggunaan kembali lintas domain (misalnya karena Anda mengonfigurasi SSL mereka secara berbeda dan Apache ingin memaksakan negosiasi ulang TLS), dan melayani HTTP 421.
  6. Klien tidak secara otomatis mencoba kembali dengan koneksi baru (lihat misalnya bug Chrome # 546991 , sekarang diperbaiki). The RFC relevan mengatakan bahwa klien MUNGKIN coba lagi, tidak bahwa itu HARUS atau HARUS. Gagal mencoba lagi tidak terlalu ramah pengguna, tetapi mungkin diinginkan untuk alat debugging atau pustaka HTTP.

Acara # 6 di luar kendali Anda, tetapi tergantung pada perangkat lunak server, # 5 mungkin dapat diperbaiki. Konsultasikan dokumentasi HTTP / 2 server Anda untuk informasi lebih lanjut tentang bagaimana dan kapan ia mengirim HTTP 421. Atau, Anda dapat mengeluarkan sertifikat terpisah untuk setiap domain, tetapi itu menciptakan overhead administrasi yang lebih banyak dan mungkin tidak sepadan. Anda juga bisa mematikan HTTP / 2 sepenuhnya, tapi itu mungkin berlebihan dalam banyak kasus.


Saya memiliki sertifikat Multi-Domain Comodo PositiveSSL - yang memang merupakan Sertifikat SSL tunggal. Pergi ke sertifikat terpisah adalah upaya dan / atau biaya yang signifikan pada saat ini. Masalah utama datang dengan mencoba memiliki domain tanpa cookie statis untuk melayani gambar saya. Itu tidak sebanding dengan jumlah 421 yang saya dapatkan. Untuk saat ini, saya telah menonaktifkan domain statis. Saya masih memiliki beberapa sumber daya berbagi antara domain, tetapi jumlah 421 telah menurun secara drastis. Saat ini tidak sepadan dengan efisiensi yang seharusnya. Suatu hari, saya akan menguji rekomendasi Anda ketika saya memiliki lebih banyak waktu.
mseifert

Terima kasih atas penjelasan terperincinya. Meskipun ini adalah masalah yang cukup menjengkelkan (dan Anda hanya menyadarinya saat menggunakan Safari, sebagian besar), saya menemukan rantai peristiwa yang mengarah ke masalah ini cukup menarik :)
fritzmg

1

Mungkin ini akan membantu seseorang.

Saya mendapatkan kesalahan ini ketika saya mencoba mengubah konfigurasi virtual host apache ke HTTPS tetapi hanya mengubah port dari 80 menjadi 443 dan lupa menambahkan

   SSLEngine on
   SSLCertificateFile "/opt/lampp/htdocs/localhost.crt"
   SSLCertificateKeyFile "/opt/lampp/htdocs/localhost.key"

Konfigurasi yang menyebabkan kesalahan 421:

<VirtualHost mydoamin.local:443>   <-- fistly I 
       DocumentRoot "/opt/lampp/htdocs/mydomain/"
       ServerName www.mydomain.local
</VirtualHost>

Konfigurasi yang benar:

<VirtualHost mydoamin.local:443>
       DocumentRoot "/opt/lampp/htdocs/mydomain/"
       ServerName www.mydomain.local
       SSLEngine on
       SSLCertificateFile "/opt/lampp/htdocs/localhost.crt"
       SSLCertificateKeyFile "/opt/lampp/htdocs/localhost.key"
</VirtualHost>

-1

Saya memiliki masalah yang sama. Beralih ke dua slot SSL tunggal berhasil.

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.