421 Błędnie skierowane żądanie

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.

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.

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>

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

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