Как исправить ошибку «работа с сокетами: ошибка! не работает.»

Битрикс настройка SSL, ошибка работы с сокетами

После установки SSL сертификата в битриксе на виртуальной машине BitrixVM версии 7.4.1 начала появляться ошибка с сокетами, при этом если перейти на сайт по обычному http, то такой проблемы не наблюдается. Ниже описано как решить данную проблему с сокетами при использование SSL сертификата и протокола HTTPS в Bitrix virtual appliance version 7.4.1 («1С-Битрикс: Веб-окружение»).

Открываем SSH клиет (PuTTY). Если меню битрикса не отображается сразу, то заходим в меню следующей командой:

Затем выбираем поочередно пункты в меню:

8. Manage pool web servers 3. Configure certificates 2. Configure own certificate

Если данных пунктов у вас нет, то сначала нужно обязательно создать пул: 1. Create Management pool of server

После того, как зашли в пункт 2. Configure own certificate, указываем сайт или оставляем по умолчанию Enter site name (default):

Указываем: Private Key path: /etc/nginx/ssl/cert.key Certificate path: /etc/nginx/ssl/cert.crt Certificate Chain path: /etc/nginx/ssl/cert_ca.crt

Пути заменяем на свои, либо предварительно запишите файлы сертификатов с такими именами по таким же путям.

После вопроса Please confirm you want to update certificate settings for the sites (N|y): вводим Y и нажимаем enter.

Готово, сайт должен открываться по HTTPS, но у меня не работало, поскольку я не указывал Certificate Chain path, у меня не было сертификатов для цепочки (промежуточных) и пока я не указал эти сертификаты в Certificate Chain path у меня SSL не работал. Точнее сам сайт по HTTPS открывался нормально в защищённом режиме, но в проверке системы битрикс показывалась ошибка с сокетами: Ошибка! Работа с сокетами (check_socket): Fail Connection to ssl://site.com:443 Fail, Connection to ssl://site.com:443 Fail Socket error : Подробности ошибки указаны в журнале проверки системы.

Также если обратится к сайту в консоли через curl командой: curl https:// site.com :443 выходило следующие curl: (60) Peer’s Certificate issuer is not recognized. При нормальной работе должен показываться HTML код сайта.

Проблема еще была в том, что у меня не было никаких промежуточных сертификатов, а только публичный сертификат (CRT) и приватный ключ (Private KEY).

Центр сертификации мне больше ничего не выдавал, а точнее хостинг где я их покупал. Техподдержка не отвечала, у них были праздничные выходные.

Как же их получить? Нашёл решение такое, открываем сайт в браузере Firefox, нажимаем на замочек, затем на стрелку справа от зеленной надписи «Защищенное соединение», затем внизу «Подробнее». После чего откроется окно «Информация о странице». Там нажимаем «Просмотреть сертификат». Откроется страница с различными данными и параметрами сертификата. Находим ниже ссылки Загрузить PEM (сертификат) и PEM (цепочка сертификатов). Именно последний нам и нужен. Качаем PEM (цепочка сертификатов).

Формат PEM я переименовал в CRT. У меня сработало с ним, но возможно и с PEM сработает. После того как я указал этот chain сертификат, как указано выше в Certificate Chain path, у меня наконец-то пропала ошибка с сокетами и все наконец стало работать как надо.

Записи о сертификатах создаются в файле: /etc/nginx/bx/site_avaliable/ssl.s1.conf

там указано где хранятся сертификаты: ssl_certificate /etc/nginx/certs/default/cert.crt; ssl_certificate_key /etc/nginx/certs/default/cert.key; ssl_trusted_certificate /etc/nginx/certs/default/cert_ca.crt;

Также данные записи были сделаны в файле /etc/nginx/bx/conf/ssl-push-custom.conf А изначально настройки брались из /etc/nginx/bx/conf/ssl.conf

В документации вообще сказано, что для сайта по умолчанию s1 (который находится в директории /home/bitrix/www) файл будет называться /etc/nginx/bx/site_avaliable/s1.ssl.conf, а для дополнительных сайтов (которые создаются в директории /home/bitrix/ext_www/название_хоста) — /etc/nginx/bx/site_avaliable/bx_ext_ssl_название_хоста.conf.

Поэтому нужный файл конфигурации здесь еще нужно постараться определить.

Не забываем также указать в файле /etc/hosts ваш IP и домен. я указал два ip версии 4 и 6, а также 127.0.0.1 localhost

После правок нужно выполнить команду nginx -t И перезагрузить service nginx restart или # /etc/init.d/nginx restart

Если нужно установить бесплатный сертификат LetsEncrypt, об это написано в этой статье Установка SSL сертификата LetsEncrypt на BitrixVM

источник

Ошибка проверки сайта Работа с сокетами — Socket error [111]: Connection refused

в файле /etc/hosts пропишите127.0.0.1 _ВАШ_ДОМЕН_

Битрикс то ли по текущему урлу (по которому заходите) пытается законнектиться, то ли по домену сайта.Вообщем помогает выше написанное

Посмотрите лог проверки (что-то типа /home/bitrix/www/bitrix/site_checker_d64fb2e3f5834fc1af5d853 ­77f2c3f3c.log). В нем будет написано куда пытается подключиться скрипт:

2013-Feb-25 06:49:58 Работа с сокетами (check_socket): FailConnection to 123.456.789.123:80Socket error : Connection refused

В моем случае проблема была в том, что заказчик предоставил только адрес шлюза 123.456.789.123, а на нем пробросил порт 80 на хост с виртуалкой. А виртуалка ничего не знала про этот IP.

В своем локальном файле c:\Windows\System32\drivers\etc\hosts я добавил запись:80.66.94.230 portal.localdom

А на виртуалке добавил /etc/hosts имя portal.localdom127.0.0.1 localhost.localdom localhost localhost portal.localdom

После этого проверка сокетов прошла успешно.

Еще одна причина возникновения данной ошибки:На сайте стоит http-авторизация через утилиту passwd и .htaccess в вышележащей папке.

Соответственно, после того, как убираем из .htaccess в папке «..» AuthName «Private zone»AuthType BasicAuthUserFile .htpasswdrequire valid-user

Проверка сайта проходит успешно!

У меня вот какая проблема.

При проверке системы (Рабочий стол-> Настройки-> Инструменты-> Проверка системы) происходит следующее:

Если в .htaccess в корне сайта закомментирована строка php_value mbstring.internal_encoding UTF-8, то (как и следует ожидать) выводится ошибка:

Ошибка! Сайт работает в UTF кодировке, настройки mbstring: mbstring.func_overload=2 mbstring.internal_encoding= требуется: mbstring.func_overload=2 mbstring.internal_encoding=utf-8

если мы раскомментируем строку, то сообщение об ошибке кодировки не выводится, но выводится другая ошибка: Работа с сокетами — Ошибка! Не работает

Смотрим журнал проверки

Ситуация следующая (обращаю внимание — домен кириллический):. Когда не указана кодировка utf-8, то в журнале имеется запись: 2013-Dec-19 15:25:56 Работа с сокетами (check_socket): Ok Connection to xn——dlcdhdea0afa5acqdcd1cjk8r.xn--p1ai:80 Success

Когда не указана кодировка utf-8, то в журнале имеется запись: 2013-Dec-19 15:25:56 Работа с сокетами (check_socket): Ok Connection to xn——dlcdhdea0afa5acqdcd1cjk8r.xn--p1ai:80 Success

Как только мы в .htaccess указываем mbstring.internal_encoding utf-8, то в журнале просто нет хоста, к которому проверяется подключение: 2013-Dec-19 15:34:42 Работа с сокетами (check_socket): Fail Connection to :80 Fail Socket error : php_network_getaddresses: getaddrinfo failed: Name or service not known

>Connection to xn——dlcdhdea0afa5acqdcd1cjk8r.xn--p1ai:80 Success

т.е. система не видит адреса, к которому нужно подключаться.____________________________________________________________ ­

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

источник

Bitrix. Исправляем ошибку «Работа с сокетами — Ошибка! Не работает»

Во время тестирования сайта, выскакивает следующая ошибка:

Для начала мы видим в этом логе, что при запросе система получает 404 ошибку. Нам нужно понять почему она происходит. Для этого нам нужно проверить логи веб-сервера. Так как у меня работает на nginx + apache2, я открыл логи nginx (Linux /var/log/nginx/error.log).

В данном логе я ищу мой запрос

И что мы тут видим? Когда скрипт обращается сам к себе, то происходит обращение вообще не понятно по какому адресу «/usr/share/nginx/html/bitrix/admin/site_checker.php», тогда как сайт лежит: /var/www/site.ru/www/bitrix/admin/site_checker.php

Так же обратите внимание по какому адресу обращается скрипт:

Из этого мы делаем вывод что site.ru привязан к localhost и при обращении сайта к самому себе пытается найти файлы не в папке сайта, а в папке nginx по умолчанию. Открыв фаил /etc/hosts я увидел следующую запись:

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

источник

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

Adblock
detector