ssl_error_rx_record_too_long и Apache SSL

Question

ssl_error_rx_record_too_long и Apache SSL

196

У меня есть клиент, пытающийся получить доступ к одному из моих сайтов, и они продолжают получать эту ошибку > ssl_error_rx_record_too_long

Они получают эту ошибку во всех браузерах, на всех платформах. Я вообще не могу воспроизвести проблему.

Мой сервер и я находятся в США, клиент находится в Индии.

Я столкнулся с проблемой, и основным источником кажется, что порт SSL говорит в HTTP. Я проверил свой сервер, и этого не происходит. Я попробовал решение, упомянутое здесь, но клиент заявил, что он не исправит проблему.

Может ли кто-нибудь сказать мне, как я могу это исправить, или как я могу воспроизвести это?

РЕШЕНИЕ

Оказалось, что у клиента был неверно настроенный локальный прокси-сервер!

Надеюсь, что кто-нибудь найдет этот вопрос, пытаясь отладить его в будущем.

Subimage 23 сен. 2008, в 05:12

Источник

0

Я думаю, что это также может быть вызвано неверно настроенным прокси на их стороне вещей. Есть мысли по этому поводу?
Subimage 23 сен. 2008, в 06:40
26

Так как это было закрыто как не по теме, но, кажется, очень ценный вопрос (очень высоко оценивается в Google за это сообщение об ошибке), может быть, его следует перенести в ServerFault? Это 6-летний вопрос, так что, возможно, SF не был доступен, когда вопрос был задан изначально ...
kdmurray 31 авг. 2014, в 22:10
0

Интересно, что есть 5+ решений, все разные, к одному и тому же сообщению об ошибке. Странно, что мы все получаем загадочный и бесполезный « record_too_long » по разным причинам!
Demis 10 авг. 2017, в 03:15
7

Это первый результат веб-поиска для SSL_ERROR_RX_RECORD_TOO_LONG. У него 32 фаворита, 193 отзыва, несколько ответов с большим количеством голосов ... и он закрыт как не по теме, по словам человека, который лучше нас знает, что этот вопрос не имеет права на существование.
Vladimir Kornea 21 окт. 2017, в 18:57
2

Я могу отладить проблемы с сертификатами, генерирующие это сообщение с помощью openssl s_client -connect my-domain.tld:443
azmeuk 22 нояб. 2017, в 11:01
0

Мне не хватает представителей, но те, кто есть, пожалуйста, проголосуйте, чтобы вновь открыть вопрос!
dr01 02 июль 2018, в 09:44
0

Я обнаружил один сайт, который не разрешал загрузку из-за этой ошибки - отключение надстройки «HTTP Everywhere» было (временным) решением.
Jool 12 дек. 2018, в 13:46
0

@Subimage "РЕШЕНИЕ Оказывается, у клиента неправильно настроен локальный прокси!" Пожалуйста, объясните, что это значит. Вы могли бы быть более конкретным; печально знать, что у вас есть решение, но вы его явно не прописываете
ptrcao 22 дек. 2018, в 09:32

Показать ещё 6 комментариев

Теги:

apache

ssl

configuration

webserver

mod-ssl

15 ответов

89

Решение для меня состояло в том, что default-ssl не был включен в apache 2.... просто поместив SSLEngine On

Мне пришлось выполнить a2ensite default-ssl, и все сработало.

Webnet 30 март 2010, в 19:55

2

Я использовал a2enmod ssl но не забудьте a2ensite default-ssl из стандартного vhost conf. Спасибо!
erm3nda 24 май 2015, в 16:18
0

Они должны просто включить default-ssl уже в Ubuntu.
BadHorsie 04 март 2016, в 23:55
0

OMG этот ответ работает на меня. Ты спас мне жизнь !!! Слава Богу :))
Mít 28 сен. 2018, в 09:48

Показать ещё 1 комментарий

29

В моем случае мне пришлось изменить < VirtualHost * > обратно в < VirtualHost *: 80 > (который является значением по умолчанию для Ubuntu). В противном случае порт 443 не использовал SSL и отправлял простой HTML обратно в браузер.

Вы можете проверить, достаточно ли вам в этом случае: просто подключитесь к серверу http://www.example.com:443. Если вы видите простой HTML, ваш Apache не использует SSL на порту 443 вообще, скорее всего, из-за неправильной конфигурации VirtualHost.

Ура!

alexm 20 май 2009, в 12:06

1

localhost: 443 загружает plian html, что делать?
niran 19 нояб. 2016, в 02:33
0

@ niran Я думаю, это зависит от настроек вашей ОС по умолчанию для директивы <VirtualHost> . Попробуйте найти значение по умолчанию и настроить его соответствующим образом и убедитесь, что SSL включен на этом VirtualHost.
alexm 31 май 2017, в 15:51
1

Была эта проблема с vhost, потому что 000-default.conf имел неиспользуемый раздел: 443 без SSLEngine. Журнал Apache показал это, и я оказался на правильном пути: AH01916: Init: (myhost.example.com:443) You configured HTTP(80) on the standard HTTPS(443) port!
mivk 22 июль 2017, в 23:02
0

Моя проблема была в том, что я не запустил "sudo a2ensite default-ssl.conf". Ssl conf просто не был в каталоге с включенными сайтами, только в доступных для сайтов.
David 28 май 2018, в 13:38

Показать ещё 2 комментария

17

В моем случае я забыл установить SSLEngine On в конфигурации. Таким образом,

<VirtualHost _default_:443>
  SSLEngine On
  ...
</VirtualHost>

http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslengine

Christian Davén 12 май 2009, в 17:45

8

Если у вас есть ошибка после установки, новый https-vhost и конфигурация, кажется, правы, не забудьте также установить ссылку в sites-enabled.

drillingman 18 нояб. 2010, в 13:27

2

Звучит глупо, но это поймало меня
Alexei Tenitski 09 авг. 2012, в 03:37
2

используйте a2ensite, а не ссылку, это правильный путь на большинстве систем
AsTeR 30 апр. 2013, в 09:39
1

Также проверьте правило на apache2.conf (Ubuntu): IncludeOptional sites-enabled / *. Conf. Убедитесь, что ваши ссылки заканчиваются на «.conf» или измените это правило, чтобы включить все файлы.
lepe 04 авг. 2015, в 06:53
1

Я создал конфигурацию сайта с правильным синтаксисом и связал его с сайтами, доступными. Проблема была: имя моего конфига не заканчивалось на «.conf», так как оно никогда не загружалось, и я получил ошибку выше. Конфиги в моем случае были загружены с директивой "IncludeOptional sites-enabled / *. Conf", поэтому конфиг также должен иметь имя <Whither> .conf. Тривиально, но не вызывает никакой синтаксической ошибки (никогда не загружается в конце концов), и раздражает, потому что ls показывал это на сайтах, доступных ...
roland.minner 31 окт. 2015, в 09:42

Показать ещё 2 комментария

6

Старый вопрос, но первый результат в Google для меня, поэтому вот что мне нужно было сделать.

Ubuntu 12.04 Рабочий стол с установленным Apache

Вся конфигурация и mod_ssl были установлены, когда я установил Apache, но он еще не был связан в правильных местах. Примечание: все пути ниже относятся к /etc/apache2/

mod_ssl хранится в ./mods-available, а конфигурация сайта SSL находится в ./sites-available, вам просто нужно связать их с их правильными местами в ./mods-enabled и ./sites-enabled

cd /etc/apache2
cd ./mods-enabled
sudo ln -s ../mods-available/ssl.* ./
cd ../sites-enabled
sudo ln -s ../sites-available/default-ssl ./

Перезапустите Apache, и он должен работать. Я пытался получить доступ к https://localhost, поэтому ваши результаты могут отличаться для внешнего доступа, но это сработало для меня.

Tarka 16 апр. 2012, в 18:57

9

Команды 'a2ensite default-ssl' и 'a2enmodule ssl' упрощают управление символическими ссылками модулей и сайтов.
flickerfly 28 окт. 2013, в 19:45

4

В моем случае у меня был неправильный IP-адрес в файле виртуального хоста. Слушание было 443, а строфа была <VirtualHost 192.168.0.1:443>, но на сервере не было адреса 192.168.0.1!

fimbulvetr 14 июль 2011, в 22:53

0

Я могу подтвердить, что это была проблема для меня тоже ... неправильный IP-адрес
StanleyD 09 март 2015, в 17:32

4

Запросите у пользователя точный URL-адрес, который они используют в своем браузере. Если они входят в https://your.site:80, они могут получить ошибку ssl_error_rx_record_too_long.

dan-manges 23 сен. 2008, в 06:23

0

Я видел скриншот, а его нет: 80 Попробуйте сами: monkeyfood.cashboardapp.com
Subimage 23 сен. 2008, в 06:21

3

См. эту ссылку.

Я просмотрел все файлы журнала Apache, пока не нашел фактическую ошибку (я изменил <VirtualHost> с _default_ на мой fqdn). Когда я исправил эту ошибку, все работало нормально.

rogovsky 30 июль 2010, в 14:19

2

В моем случае проблема заключалась в том, что https не удалось запустить правильно, потому что Listen 443 был в "IfDefine SSL" derective, но мой apache не начинал с опции -DSSL. Исправлено было изменение apachectl script в:

$HTTPD -k $ARGV

в

$HTTPD -k $ARGV -DSSL

Надеюсь, что кто-то поможет.

Pushnov Iliya 01 дек. 2008, в 15:06

1

У меня была испорченная конфигурация виртуального хоста. Помните, что вам нужен один виртуальный хост без SSL для порта 80, а другой - с SSL для порта 443. У вас не может быть как на одном виртуальном хосте, так и в настройках, созданных с помощью webmin.

Sven 30 июнь 2009, в 15:55

1

Моя проблема вызвана LOW MTU через VPN-соединение.

netsh interface ipv4 show inter

Idx  Met   MTU   State        Name
---  ---  -----  -----------  -------------------
  1 4275 4294967295  connected    Loopback Pseudo-Interface 1
 10 4250   **1300**  connected    Wireless Network Connection
 31   25   1400  connected    Remote Access to XYZ Network

Fix: интерфейс netsh интерфейс интерфейса ipv4 "Беспроводное сетевое соединение" mtu = 1400

Это может быть проблема и для не VPN-подключения...

Chris 21 май 2009, в 14:26

0

Для меня решение заключалось в том, что мой ddclient не выполнялся должным образом...

Anon 26 сен. 2012, в 18:06

0

Вы также можете попробовать исправить файл hosts.

Сохраните файл vhost с полным доменом и добавьте имя хоста в файл hosts /etc/hosts (debian)

ip.ip.ip.ip name name.domain.com

После перезапуска apache2 ошибка должна исчезнуть.

gaspard 16 июль 2012, в 14:34

0

У меня была такая же проблема в некоторых браузерах для доступа к моему сайту SSL. Я обнаружил, что мне пришлось предоставить fireFox правильный прокси (FireFox обращался непосредственно в Интернет).

В зависимости от конфигурации lan (туннелирование, фильтрация, перенаправление прокси) режим "прямого доступа в Интернет" для FireFox выдает эту ошибку.

Pierre-Gilles Levallois 09 сен. 2009, в 09:58

0

Некоторые прокси-серверы возвращают HTTP-ответ об ошибке на HTTPS-запрос, которого он не ожидает (например, если вы прошли через неправильный прокси-сервер или неправильно настроен прокси-сервер). Это может быть действительно трудно диагностировать, потому что браузеры просто отклонят весь диалог и выдают ошибку, вместо того, чтобы показывать вам сообщение об ошибке прокси. Wireshark делает работу, хотя. Просто столкнулся с этим сам.
Lightness Races in Orbit 04 май 2018, в 12:53

Ещё вопросы

Я думаю, что это также может быть вызвано неверно настроенным прокси на их стороне вещей. Есть мысли по этому поводу?
Так как это было закрыто как не по теме, но, кажется, очень ценный вопрос (очень высоко оценивается в Google за это сообщение об ошибке), может быть, его следует перенести в ServerFault? Это 6-летний вопрос, так что, возможно, SF не был доступен, когда вопрос был задан изначально ...
Интересно, что есть 5+ решений, все разные, к одному и тому же сообщению об ошибке. Странно, что мы все получаем загадочный и бесполезный « record_too_long » по разным причинам!
Это первый результат веб-поиска для SSL_ERROR_RX_RECORD_TOO_LONG. У него 32 фаворита, 193 отзыва, несколько ответов с большим количеством голосов ... и он закрыт как не по теме, по словам человека, который лучше нас знает, что этот вопрос не имеет права на существование.
Я могу отладить проблемы с сертификатами, генерирующие это сообщение с помощью openssl s_client -connect my-domain.tld:443
Мне не хватает представителей, но те, кто есть, пожалуйста, проголосуйте, чтобы вновь открыть вопрос!
Я обнаружил один сайт, который не разрешал загрузку из-за этой ошибки - отключение надстройки «HTTP Everywhere» было (временным) решением.
@Subimage "РЕШЕНИЕ Оказывается, у клиента неправильно настроен локальный прокси!" Пожалуйста, объясните, что это значит. Вы могли бы быть более конкретным; печально знать, что у вас есть решение, но вы его явно не прописываете
Я использовал a2enmod ssl но не забудьте a2ensite default-ssl из стандартного vhost conf. Спасибо!
Они должны просто включить default-ssl уже в Ubuntu.
OMG этот ответ работает на меня. Ты спас мне жизнь !!! Слава Богу :))
localhost: 443 загружает plian html, что делать?
@ niran Я думаю, это зависит от настроек вашей ОС по умолчанию для директивы <VirtualHost> . Попробуйте найти значение по умолчанию и настроить его соответствующим образом и убедитесь, что SSL включен на этом VirtualHost.
Была эта проблема с vhost, потому что 000-default.conf имел неиспользуемый раздел: 443 без SSLEngine. Журнал Apache показал это, и я оказался на правильном пути: AH01916: Init: (myhost.example.com:443) You configured HTTP(80) on the standard HTTPS(443) port!
Моя проблема была в том, что я не запустил "sudo a2ensite default-ssl.conf". Ssl conf просто не был в каталоге с включенными сайтами, только в доступных для сайтов.
Звучит глупо, но это поймало меня
используйте a2ensite, а не ссылку, это правильный путь на большинстве систем
Также проверьте правило на apache2.conf (Ubuntu): IncludeOptional sites-enabled / *. Conf. Убедитесь, что ваши ссылки заканчиваются на «.conf» или измените это правило, чтобы включить все файлы.
Я создал конфигурацию сайта с правильным синтаксисом и связал его с сайтами, доступными. Проблема была: имя моего конфига не заканчивалось на «.conf», так как оно никогда не загружалось, и я получил ошибку выше. Конфиги в моем случае были загружены с директивой "IncludeOptional sites-enabled / *. Conf", поэтому конфиг также должен иметь имя <Whither> .conf. Тривиально, но не вызывает никакой синтаксической ошибки (никогда не загружается в конце концов), и раздражает, потому что ls показывал это на сайтах, доступных ...
Команды 'a2ensite default-ssl' и 'a2enmodule ssl' упрощают управление символическими ссылками модулей и сайтов.
Я могу подтвердить, что это была проблема для меня тоже ... неправильный IP-адрес
Я видел скриншот, а его нет: 80 Попробуйте сами: monkeyfood.cashboardapp.com
Некоторые прокси-серверы возвращают HTTP-ответ об ошибке на HTTPS-запрос, которого он не ожидает (например, если вы прошли через неправильный прокси-сервер или неправильно настроен прокси-сервер). Это может быть действительно трудно диагностировать, потому что браузеры просто отклонят весь диалог и выдают ошибку, вместо того, чтобы показывать вам сообщение об ошибке прокси. Wireshark делает работу, хотя. Просто столкнулся с этим сам.

Randall · Accepted Answer · 2011-01-21T20-57-00.000Z

Ссылка упомянутая Subimage, была права на деньги для меня. Он предложил изменить тег виртуального хоста, то есть от <VirtualHost myserver.example.com:443> до <VirtualHost _default_:443>

Код ошибки: ssl_error_rx_record_too_long

Это обычно означает, что реализация SSL на вашем сервере неверна. Ошибка обычно вызвана проблемой на стороне сервера, которую администратор сервера должен будет исследовать.

Ниже приведены некоторые советы, которые мы рекомендуем попробовать.
Убедитесь, что порт 443 открыт и включен на вашем сервере. Это стандартный порт для связи https.

Если SSL использует нестандартный порт, FireFox 3 может иногда давать эту ошибку. Убедитесь, что SSL работает на порту 443.
Если Apache2 проверяет, что вы используете порт 443 для SSL. Это можно сделать, установив файл ports.conf следующим образом
Listen 80
Listen 443 https
Убедитесь, что у вас не более одного SSL-сертификата, использующего один и тот же IP-адрес. Убедитесь, что все SSL-сертификаты используют собственный выделенный IP-адрес.

Если вы используете Apache2, проверьте свою конфигурацию vhost. Некоторые пользователи сообщили, что изменение <VirtualHost> на _default_ разрешило ошибку.

Убедитесь, что сертификат SSL не истек.

Попробуйте указать Cipher:

SSLCipherSuite ALL:! aNULL:! ADH:! eNULL:! LOW:! EXP: RC4 + RSA: + HIGH: + MEDIUM: + SSLv3

Это исправило мою проблему. Редко, что я google сообщение об ошибке и получить первый хит с правильным ответом!: -)

Просто чтобы добавить в список вещей для проверки, после проверки всех этих элементов мне пришлось поменять местами <VirtualHost default : 443> на <VirtualHost fqdn: 443>, чтобы он наконец заработал.
У меня была эта проблема на сервере WHM / Cpanel. Я просто переустановил ssl, чтобы исправить проблему.
_default_:443 работал на меня. Нет, я могу идти спать!
Еще одна вещь, которую нужно проверить: у вас может быть SSL по умолчанию, но если у вас есть новый виртуальный хост с этой проблемой, возможно, вы еще не предоставили конфигурацию SSL, даже если порт открыт. (иначе, ой, я пропустил шаг.)
Тоже самое. по умолчанию : 443 работал для меня.
Просто изменение ports.conf меня устроило.
Чтобы SSL работал, вы должны сопоставить виртуальный хост по IP-адресу, а не по имени
@Randall: Это может показаться глупым, но также убедитесь, что ваш «[website_domain] .conf» читается Apache. (напишите мусор в if и убедитесь, что apache жалуется на запуск). У меня была эта ошибка только потому, что я забыл .conf в конце символической ссылки. Поэтому Apache не использовал conf и отправлял простой HTML (страницу с ошибкой) вместо аутентификации SSL.
Также проверьте и убедитесь, что у вас нет других conf-файлов VirtualHost, прослушивающих порт 443 с неправильными настройками. Один неверный файл может привести к остановке всех сайтов SSL.
чтобы исправить это, пришлось использовать _default_:443 , так как DNS-имя имело адреса IPv4 и IPv6, так что просто 192.168.66.99:443 было недостаточно!
В [apacheroot] /conf/extra/httpd-ssl.conf мне пришлось исправить строку: <VirtualHost default : 443> в соответствии с правильным портом SSL, который я использовал.
Указание IP-адреса в записи vhost вместо * у меня сработало
Установка VirtualHost по умолчанию, а не IP-адрес работал для меня.