ssl_error_rx_record_too_long та SSL Apache [закрито]

У мене клієнт намагається отримати доступ до одного з моїх сайтів, і він постійно отримує цю помилку> ssl_error_rx_record_too_long

Вони отримують цю помилку у всіх браузерах, на всіх платформах. Я взагалі не можу відтворити проблему.

Мій сервер і я розташовані в США, клієнт знаходиться в Індії.

Я переглянув проблему, і головним джерелом здається, що порт SSL говорить на HTTP. Я перевірив свій сервер, і цього не відбувається. Я спробував вказане тут рішення , але замовник заявив, що це не вирішило проблему.

Хто-небудь може сказати мені, як я можу це виправити, або як я можу це відтворити ???

РІШЕННЯ

Виявляється, у замовника був неправильно налаштований локальний проксі!

Сподіваємось, що хтось допоможе знайти це питання, намагаючись налагодити його в майбутньому.

Посилання згадується Растр було право на гроші для мене. Він запропонував змінити тег віртуального хоста, тобто, з <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_вирішити помилку.

Це вирішило мою проблему. Рідко я переглядаю повідомлення про помилку в google і отримую перше звернення з правильною відповіддю! :-)

На додаток до вищезазначеного , деякі інші рішення, які знайшли інші, викликали проблему:

• Переконайтесь, що термін дії вашого сертифікату SSL не закінчився

• Спробуйте вказати шифр:

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

Для мене було рішення, яке default-sslне було включено в Apache 2 .... просто кажучиSSLEngine On

Мені довелося стратити a2ensite default-sslі все спрацювало.

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

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

Ура!

У моєму випадку я забув налаштувати SSLEngine Onконфігурацію. Так,

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

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

Якщо після установки нового https vhost виникла помилка, і конфігурація, здається, є правильною, пам’ятайте, що також посилатися sites-enabled.

Старе питання, але перший результат для 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 , тому ваші результати можуть відрізнятись від зовнішнього доступу, але це працювало для мене.

Запитайте у користувача точну URL-адресу, яку вони використовують у своєму браузері. Якщо вони вводять https://your.site:80 , вони можуть отримати помилку ssl_error_rx_record_too_long.

У моєму випадку у віртуальному файлі хоста була неправильна IP-адреса. Прослуховування було 443, а строфа була, <VirtualHost 192.168.0.1:443>але сервер не мав адреси 192.168.0.1!

Перейдіть за цим посиланням .

Я дивився на всі мої файли журналу апача , поки я не знайшов фактичну помилку (я змінив <VirtualHost>від _default_до My fqdn). Коли я виправив цю помилку, все працювало нормально.

У моєму випадку проблема полягала в тому, що https не вдалося запуститись правильно, оскільки Listen 443 знаходився в "IfDefine SSL" дерективом, але мій апарат не почався з опції -DSSL. Виправлення полягало в тому, щоб змінити мій скрипт apachectl у:

$HTTPD -k $ARGV

до:

$HTTPD -k $ARGV -DSSL

Сподіваюся, що хтось допомагає.

Моя проблема була пов'язана з низьким 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

Виправлення: інтерфейс netsh ipv4 інтерфейс "Бездротове підключення до мережі" mtu = 1400

Це може бути проблемою і для з’єднання, яке не є VPN, також ...

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

Я мав таку ж проблему в якомусь браузері, щоб отримати доступ до свого сайту SSL. Я виявив, що мені довелося надати fireFox потрібний проксі (FireFox здійснював доступ безпосередньо в Інтернет).

Залежно від конфігурації мережі (тунелювання, фільтрування, перенаправлення проксі), режим «прямого доступу до Інтернету» для FireFox видає цю помилку.

Ви також можете спробувати виправити файл хостів.

Зберігайте файл vhost з повністю кваліфікованим доменом і додайте ім'я хоста у файл хостів / etc / hosts (debian)

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

Після перезапуску apache2 помилка повинна бути відсутня.

Для мене рішенням було те, що мій ddclient не був належним чином ...