421 Błędnie skierowane żądanie


11

Czasami pojawia się następujący błąd 421:

Błędnie skierowane żądanie

Klient potrzebuje nowego połączenia dla tego żądania, ponieważ żądana nazwa hosta nie jest zgodna ze wskazaniem nazwy serwera (SNI) używanym dla tego połączenia.

Jednak odświeżenie przeglądarki usuwa błąd i strona ładuje się normalnie. Następnym razem ładowanie strony nie spowoduje wystąpienia błędu i dlatego wzór wydaje się dość przypadkowy. Jedyny wzorzec, jaki widzę, to może się zdarzyć, gdy przekierowuję stronę za pomocą nagłówka („Lokalizacja:”. $ Url);

Mam certyfikat PositiveSSL Multi-Domain od Comodo. Moje serwery to Apache we wspólnej usłudze hostingowej, więc nie mam dostępu do konfiguracji.

Ładuję strony z jednej domeny, a na stronie znajdują się linki do drugiej domeny na certyfikacie.

Wszystko, co przeczytałem na temat tego błędu, wydaje się wskazywać na to, że ten problem jest związany z tym, że jest to certyfikat wielu domen.

Chciałbym wiedzieć, czy na stronie internetowej (php) jest coś, co może to powodować (i można to naprawić) lub jeśli jest to błąd konfiguracji lub błąd serwera i tylko moja usługa hostingowa może napraw to.

Moja usługa hostingowa do tej pory nie była w stanie nic zaoferować i poprosiła o oddzwonienie z dokładną godziną, kiedy to nastąpi, aby mogli to sprawdzić. Jakakolwiek pomoc byłaby mile widziana, ponieważ nie jestem zbyt pewny, że mogą to zrozumieć.

AKTUALIZACJA Ok, prawie kilka lat później i zdecydowałem, że czas się tym zająć. Byłem w stanie rozwiązać większość problemów, usuwając moje statyczne domeny, które obsługiwały obrazy i JavaScript. Nadal jednak korzystałem z drugiej domeny dla niektórych z tych treści, a w szczególności Safari wciąż sprawiało mi problemy.

Zrobiłem więcej badań i natknąłem się na inny artykuł, który mówi o tym tutaj . Dokładnie to, co opisuje @Kevin. W artykule potwierdzono, że dzieje się to w przeglądarce Safari. Korzystając z porady, postanowiłem uzyskać osobne certyfikaty dla każdej domeny. Jestem na wspólnym hoście (Webhostinghub) i odkryłem, że oferują teraz bezpłatny SSL (AutoSSL), który odnawia się automatycznie. Brzmiało dobrze, żeby było prawdziwe. Ustawili mnie z 5 darmowymi certyfikatami. Na razie w porządku. Mogę nawet spróbować ponownie włączyć domeny statyczne do testowania. Jeśli to wszystko zadziała, zaoszczędzę $ na rozruch jako bonus i pozwolę, aby moje certyfikaty Comodo wygasły w lipcu.


Czy hostujesz wiele witryn na tym samym serwerze Apache ORAZ używasz tego samego certyfikatu SSL ORAZ błąd występuje podczas przełączania między tymi nazwami domen?
John Hanley,

Jeśli odpowiedź brzmi TAK, sprawdź, czy adres IP każdej domeny jest odwzorowany na tym samym serwerze wirtualnym. Jeśli TAK, masz dwie możliwości (o których myślę): 1) Wydaj osobne certyfikaty SSL dla każdej nazwy domeny. 2) Przenieś serwery sieciowe dla każdej domeny na różne serwery (różne adresy IP). Biorąc pod uwagę, że korzystasz z hostingu współdzielonego, opcja 1 jest prawdopodobnie najlepszym rozwiązaniem. Możesz przetestować to rozwiązanie za pomocą Let's Encrypt, aby wydać kilka bezpłatnych certyfikatów do zainstalowania na innych serwerach internetowych.
John Hanley,

Zapytaj swojego dostawcę usług hostingowych, czy może wyłączyć mod_http2.
John Hanley,

@JohnHanley - ponownie nr 1, tak, to ten sam SSL z 6 domenami. Nie jest łatwo dokładnie określić, kiedy wystąpi błąd. Główny scenariusz polega na tym, że jestem w jednej domenie, wyciągając zawartość (obrazy i js) z dwóch innych domen. Re # 2: Adres IP jest zdecydowanie taki sam - zbieram wystawiając osobne certyfikaty, każda nazwa domeny byłaby znacznie droższa. Zajrzałem do Let's Encrypt, ale nie jest obsługiwany przez mojego dostawcę. Mój dostawca w ciągu ostatnich 6 miesięcy oferował bezpłatne certyfikaty, więc kiedy nastąpi odnowienie w tym miesiącu, przełączę się i zobaczę, co się stanie. Re # 3 - nie mogą wyłączyć mod_http2. Dzięki
mseifert,

W rzeczywistości wszyscy dostawcy obsługują Let's Encrypt, chyba że go specjalnie zablokują. Certyfikaty SSL są takie same bez względu na to, skąd je otrzymujesz. Jedyną różnicą jest rodzaj walidacji (DV, OV, EV) oraz sposób pakowania / format pliku. Apache jest tak popularny, że wszyscy je obsługują. Tak długo, jak twój sprzedawca wspiera przesyłanie własnego certyfikatu (certyfikatu i klucza prywatnego), możesz użyć weryfikacji DNS, aby je obejść. Jeśli nie obsługują przesyłania własnego certyfikatu, zmieniłbym sprzedawców.
John Hanley,

Odpowiedzi:


14

Jest to spowodowane następującą sekwencją zdarzeń:

  1. Serwer i klient obsługują i używają protokołu HTTP / 2.
  2. Klient żąda strony pod adresem foo.example.com.
  3. Podczas negocjacji TLS serwer przedstawia certyfikat, który jest ważny dla obu foo.example.comi bar.example.com(a klient akceptuje go). Można to zrobić za pomocą certyfikatu wieloznacznego lub certyfikatu SAN.
  4. Klient ponownie wykorzystuje połączenie, aby wysłać żądanie bar.example.com.
  5. Serwer nie jest w stanie lub nie chce obsługiwać ponownego korzystania z połączenia między domenami (na przykład ponieważ inaczej skonfigurowałeś ich SSL, a Apache chce wymusić renegocjację TLS) i obsługuje HTTP 421.
  6. Klient nie próbuje automatycznie ponownie przy nowym połączeniu (patrz na przykład błąd Chrome # 546991 , teraz naprawiony). Istotne RfC mówi, że klient może powtórzyć, że nie powinien on lub moszczu. Niepowodzenie ponownej próby nie jest szczególnie przyjazne dla użytkownika, ale może być pożądane w przypadku narzędzia do debugowania lub biblioteki HTTP.

Zdarzenie nr 6 jest poza twoją kontrolą, ale w zależności od oprogramowania serwera, numer 5 może być naprawiony. Zapoznaj się z dokumentacją HTTP / 2 swojego serwera, aby uzyskać więcej informacji na temat tego, jak i kiedy wysyła on HTTP 421. Alternatywnie możesz wydawać osobne certyfikaty dla każdej domeny, ale powoduje to dodatkowe obciążenie administracyjne i może nie być tego warte. Możesz także całkowicie wyłączyć HTTP / 2, ale w większości przypadków to prawdopodobnie przesada.


Mam certyfikat Comodo PositiveSSL Multi-Domain - który jest rzeczywiście pojedynczym certyfikatem SSL. Przejście do oddzielnych certyfikatów jest w tym momencie znaczącym wysiłkiem i / lub wydatkiem. Główne problemy pojawiły się przy próbie posiadania statycznych domen bez plików cookie do obsługi moich zdjęć. To nie było warte liczby 421, które dostawałem. Na razie wyłączyłem domeny statyczne. Nadal mam pewien podział zasobów między domenami, ale liczba 421 drastycznie spadła. Obecnie nie jest warta rzekomej wydajności. Pewnego dnia przetestuję twoją rekomendację, kiedy będę miał więcej czasu.
mseifert,

Dziękuję za szczegółowe wyjaśnienie. Chociaż jest to dość irytujący problem (i zauważasz to głównie podczas korzystania z Safari), ciąg wydarzeń, które prowadzą do tego problemu,
wydaje mi się

1

Może to komuś pomoże.

Wystąpił ten błąd, gdy próbowałem zmienić konfigurację wirtualnego hosta Apache na HTTPS, ale zmieniłem tylko port z 80 na 443 i zapomniałem dodać

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

Konfiguracja powodująca błąd 421:

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

Prawidłowa konfiguracja:

<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>

0

Ten sam problem zaobserwowaliśmy w przeglądarce Safari (komputer stacjonarny i iPhone) na niektórych stronach internetowych korzystających z Debian 10 z Apache.

Oprogramowanie:

  • Debian 10
  • Apache2 2.4.38-3 + deb10u3 z HTTP / 2
  • PHP 7.3.14-1 ~ deb10u1 z php-fpm

Domeny:

  • www.example.com
  • a.example.com
  • b.example.com
  • wszystkie domeny wskazują na ten sam DocumentRoot

Certyfikat:

  • Jeden certyfikat dla wszystkich używanych domen
  • Wystawcą jest DFN PKI

Rozwiązanie było dość łatwe, ale znalezienie go wymagało wiele wysiłku. Na koniec był to błąd próbny.

Konfiguracja powodująca błąd 421:

    # in /etc/apache2/site-enabled/www.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/www.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/www.example.com/www.example.com.key

    # in /etc/apache2/site-enabled/a.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/a.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/a.example.com/www.example.com.key

    # in /etc/apache2/site-enabled/b.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/b.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/b.example.com/www.example.com.key

Konfiguracja robocza:

    # in /etc/apache2/site-enabled/www.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/www.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/www.example.com/www.example.com.key

    # in /etc/apache2/site-enabled/a.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/www.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/www.example.com/www.example.com.key

    # in /etc/apache2/site-enabled/b.example.com.conf
    SSLCertificateFile      /etc/apache2/ssl/www.example.com/cert-123.pem
    SSLCertificateKeyFile   /etc/apache2/ssl/www.example.com/www.example.com.key

Rozwiązanie (w naszym przypadku): Kopiowanie tego samego certyfikatu i klucza prywatnego w różnych lokalizacjach jest niedozwolone!

Zanim skopiowaliśmy certyfikat do katalogu VirtualHost. Powoduje to zachowanie Błędnego żądania tylko w Safari.

Niestety nie umiem ci wyjaśnić, dlaczego :-( (błąd Apache2? Błąd Safari? Funkcja Safari?)


-1

Miałem ten sam problem. Przełączenie się na dwa SSL z jednym gniazdem załatwiło sprawę.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.