421 Запит на перенаправлення

11

Іноді я отримую таку помилку 421:

Неправильний запит

Клієнту потрібне нове підключення для цього запиту, оскільки запитуване ім'я хоста не відповідає вказуваному імені сервера (SNI), використовуваному для цього з'єднання.

Однак оновлення браузера видаляє помилку і сторінка завантажується нормально. Наступного разу завантаження сторінки не призведе до помилок і, як такий, візерунок здається досить випадковим. Єдиний шаблон, який я бачу, це те, що це може статися, коли я перенаправляю сторінку за допомогою заголовка ("Location:". $ Url);

У мене є сертифікат багатодоменних позитивів SSL від Comodo. Мої сервери є Apache на спільній веб-службі хостингу, тому я не маю доступу до конфігурації.

Я завантажую сторінки з одного домену, а всередині сторінки - це посилання на другий домен у сертифікаті.

Все, що я читав щодо цієї помилки, схоже, вказує на цю проблему, пов’язану з тим, що це багатодоменний сертифікат.

Що я хотів би знати, якщо на веб-сторінці (php) є щось, що може кодувати речі, що можуть спричинити це (і це можна виправити) або якщо це помилка конфігурації чи, можливо, помилка сервера, і лише мій сервіс хостингу може полагодьте це.

Наразі мій сервіс хостингу не міг нічого надати, і просив передзвонити з точним часом, коли це станеться далі, щоб вони могли це дослідити. Будь-яка допомога буде вдячна, оскільки я не надто впевнений, що вони можуть це зрозуміти.

ОНОВЛЕННЯ Добре, майже через пару років і вирішив, що пора з цим розібратися. Мені вдалося вирішити більшість проблем, видаливши мої статичні домени, які подавали зображення та JavaScript. Однак я все ще використовував другий домен для деякого цього контенту, і зокрема, Safari все ще створював мені проблеми.

Я зробив більше досліджень і натрапив на ще одну статтю, яка тут розповідає про це . Саме так описує @Kevin. У статті підтверджено, що це відбувається в Safari. Отож, приймаючи поради, я взявся за отримання окремих сертифікатів для кожного домену. Я перебуваю на спільному хості (Webhostinghub) і виявив, що зараз вони пропонують безкоштовний SSL (AutoSSL), який автоматично оновлюється. Добре звучало, щоб бути правдою. Вони встановили мені 5 безкоштовних сертифікатів. Все йде нормально. Я навіть можу спробувати повторно включити статичні домени для тестування. Якщо це все спрацює, я заощаджую $ до завантаження як бонус, а мої сертифікати Comodo закінчуться в липні.

ssl apache-2.4 https

— mseifert
джерело

Ви розміщуєте кілька веб-сайтів на одному сервері Apache І використовуєте один і той же сертифікат SSL. І при переключенні між цими доменними іменами виникає помилка?

— Джон Хенлі

Якщо відповідь ТАК, перевірте, чи IP-адреса кожного домену відображається на одному віртуальному сервері. Якщо так, то у вас є два варіанти (що я можу придумати): 1) видайте окремі сертифікати SSL для кожного доменного імені. 2) Перемістіть веб-сервери, щоб кожен домен знаходився на різних серверах (різні IP-адреси). З огляду на те, що ви перебуваєте на спільному хостингу, варіант 1, мабуть, найкраще рішення. Ви можете протестувати це рішення, використовуючи Let's Encrypt, щоб видати кілька безкоштовних сертифікатів для встановлення на інших веб-серверах.

— Джон Хенлі

Запитайте свого постачальника хостингу, чи зможе він відключити mod_http2.

— Джон Хенлі

@JohnHanley - повторно # 1, так, це той самий SSL з 6 доменами. Нелегко точно сказати, коли трапиться помилка. Основний сценарій полягає в тому, що я в одному домені витягаю вміст (зображення та js) з двох інших доменів. Re # 2: IP-адреса, безумовно, однакова - я збираюсь видавати окремі сертифікати, кожне доменне ім’я було б дорожче. Я переглянув Let’s Encrypt, але він не підтримується моїм провайдером. Мій провайдер протягом останніх 6 місяців пропонував безкоштовні сертифікати, тож коли оновлення відбудеться в цьому місяці, я переключусь і побачу, що відбувається. Re # 3 - вони не можуть відключити mod_http2. Спасибі

— mseifert

Насправді всі провайдери підтримують Let's Encrypt, якщо вони спеціально не блокують його. Сертифікати SSL однакові незалежно від того, де ви їх отримаєте. Єдина відмінність - тип перевірки (DV, OV, EV) та упаковка / формат файлу. Apache настільки популярний, що всі їх підтримують. Поки ваш постачальник підтримує завантаження власного сертифікату (сертифікат та приватний ключ), ви можете використовувати перевірку DNS, щоб обійти їх. Якщо вони не підтримують завантаження вашого власного сертифікату, я б переключився на постачальників.

— Джон Хенлі

14

Це викликано такою послідовністю подій:

Сервер і клієнт одночасно підтримують і використовують HTTP / 2.
Клієнт запитує сторінку на адресу foo.example.com.
Під час переговорів TLS, сервер являє собою сертифікат , який дійсний для обох foo.example.comі bar.example.com(і клієнт приймає його). Це можна зробити за допомогою сертифікату підстановки або сертифікату SAN.
Клієнт повторно використовує з'єднання, щоб зробити запит на bar.example.com.
Сервер не в змозі або не бажає підтримувати повторне використання міждоменного з'єднання (наприклад, тому, що ви SSL сконфігурували їх по-різному і Apache хоче примусити повторне узгодження TLS) і обслуговує HTTP 421.
Клієнт не намагається автоматично повторити нове з'єднання (див., Наприклад, помилку Chrome № 546991 , тепер виправлено). Ставлення RfC каже , що клієнт може повторити спробу, що не то, що він повинен або MUST. Якщо не вдалося повторити спробу, це не дуже зручно для користувачів, але це може бути бажано для інструменту налагодження або бібліотеки HTTP.

Подія №6 перебуває поза вашим контролем, але залежно від програмного забезпечення сервера, №5 може бути виправленим. Зверніться до документації HTTP / 2 вашого сервера, щоб отримати додаткові відомості про те, як і коли він надсилає HTTP 421. Крім того, ви можете видавати окремі сертифікати для кожного домену, але це створює більше адміністративних витрат і може не варто. Ви також можете повністю відключити HTTP / 2, але це, мабуть, в більшості випадків є надмірним.

— Кевін
джерело

У мене є багатодоменний сертифікат Comodo PositiveSSL - це справді єдиний сертифікат SSL. Перехід до окремих сертифікатів є значним зусиллям та / або витратою на даний момент. Основні проблеми виникали при спробі створити статичні домени без файлів cookie для моїх зображень. Це не вартувало тієї кількості 421, яку я отримував. На даний момент я відключив статичні домени. У мене все ще є деякий розподіл ресурсів між доменами, але кількість 421 різко скоротилася. Наразі не варто передбачуваної ефективності. Колись я перевірю вашу рекомендацію, коли матиму більше часу.

— mseifert

Дякую за детальне пояснення. Хоча це досить дратівлива проблема (і ви її помічаєте лише при використанні Safari, в основному), я вважаю ланцюжок подій, що призводять до цієї проблеми, досить цікавим :)

— fritzmg

1

Можливо, це буде комусь корисним.

Я отримав цю помилку, коли спробував змінити конфігурацію віртуального хоста apache на HTTPS, але змінив лише порт з 80 на 443 і забув додати

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

Конфігурація, що викликає помилку 421:

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

Правильна конфігурація:

<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

Ми спостерігали ту саму проблему з Safari (Desktop та iPhone) на деяких веб-сайтах, використовуючи Debian 10 з Apache.

Програмне забезпечення:

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

Домени:

www.example.com
a.example.com
b.example.com
всі домени вказують на один і той же DocumentRoot

Сертифікат:

Один сертифікат для всіх використаних доменів
Емітентом є DFN PKI

Рішення було досить простим, але для його пошуку знадобилося багато зусиль. Наприкінці це була пробна помилка.

Конфігурація, що викликає помилку 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

Робоча конфігурація:

    # 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

Рішення (в нашому випадку): заборонено копіювати один і той же сертифікат і приватний ключ в різні місця!

Перш ніж ми скопіювали сертифікат у конкретний каталог VirtualHost. Це призводить до неправильної поведінки на запит лише для Safari.

На жаль, я не можу вам пояснити, чому :-( (помилка Apache2? Помилка Safari? Функція Safari?)

— Олександр
джерело

-1

У мене було те саме питання. Перехід на два однослотових SSL зробив свою справу.

— Олів'є
джерело