Bitrix ошибки работа с сокетами ошибка не работает

Содержание

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

Битрикс настройка 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 [0]:
Подробности ошибки указаны в журнале проверки системы.

Также если обратится к сайту в консоли через 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

Источник

Ошибка работы с сокетами

В инструментах запустил проверку системы. После завершения проверки, отображается ошибка работы с сокетами «Ошибка! Не работает».
В логе проверки вот такое выдает:

Цитата
Александр Гусев написал: My_site.eu — в логах так и пишется?

Цитата
Scrooge написал: домен наверно еще не знает про новый сервер?

Цитата
Scrooge написал: Если на сайт через hosts заходите, то будет писать эту ошибку, как домен делегируете, ошибка сама исчезнет

Цитата
Александр Гусев написал: значит покопайте, почему 404 для /bitrix/admin/site_checker.php

Особенно подчеркну предложение Александра. Кроме 404 и 302 ошибка бывает Советую внимательно посмотреть логи и какой ответ сервера. Вот на фото подчеркнуто красным. Чуть ниже надписи Работа с сокетами (check_socket): Fail . Долго искал в поисковике bitrix socket error , нашел интересную и подробную статью Bitrix. Исправляем ошибку «Работа с сокетами — Ошибка! , чтобы сформулировать правильное задание ТЗ , а то вовсе без техподдержки решить проблему после » Полного тестирования системы» /bitrix/admin/site_checker.php?lang=ru

У меня другая ошибка была, неправильный redirect Но суть в том, что эта проблема с сокетом. может быть причиной значительного увеличения нагрузки на сервер.. (фото ДО и после ))
Очень рад что есть такой полезный инструмент «Проверка системы», он позволяет не создавать лишней работы по оптимизация скриптов и вообще избежать много другого страшного гемора, например потерянные ссылки на сайте.

Цитата
Александр Гусев написал: значит покопайте, почему 404 для /bitrix/admin/site_checker.php

Источник

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

Цитата
Дмитрий Ипатов написал: Затем в настройках nginx /etc/nginx/bx/conf/ssl.conf прописал пути к файлам сертификата

подскажите алгоритм установка не самоподписанного ?

и файла *.key нет
есть только такие

Еще вариант решения
в /etc/hosts

127.0.0.1 localhost
00.000.00.00 site1.ru site2.ru site3.ru

гда 00.000.00.00 — ip адрес сервера

Проверить правильность очень просто: в консоли выполните

И к тому же что apache, что nginx выдавали что-то типа «httpd: (98)Address already in use: make_sock: could not bind to address», первый – немного, второй – много занятых портов.

Пробовал решать различными путями – ничего не помогало. Набрел на инструкцию Comodo — https://support.comodo.com/index.php?/Knowledgebase/Article/View/1091/37/certificate-installation—nginx В ней говорится, что для nginx нужно объединить сертификаты «xxx. ca-bundle» и «xxx.crt» и уже такой объединенный файл подсовывать nginx-у. Но у меня-то небыло ни crt-файла ни ca-bundle-файла. На это Comodo на этой же страничке инструкции предлагает скачать ca-bundle-файл, а вернее, несколько файлов – для домена, файл расширенной валидации и файл для организации. Мне нужен был для домена, его я и скачал — https://support.comodo.com/index.php?/Knowledgebase/Article/GetAttachment/1091/1282988

Называется он «domain_validated.ca-bundle»

Ну хорошо, ca-bundle-файл – есть, но никакого crt – нет как нет. Поэтому за неимением вместо crt взял pem-файл.

В консоли перешел в папку сертификатов: «cd /etc/nginx/ssl/».

И запустил объединение файлов командой «cat server.pem domain_validated.ca-bundle > ssl-bundle.crt», в результате чего в папке сертификатов был создан объединенный файл «ssl-bundle.crt».

Вот этот вновь созданный сертификат я и подсунул nginx, то есть в файле конфигурации было: «ssl_certificate /etc/nginx/ssl/xxx.pem;»

А стало: «ssl_certificate /etc/nginx/ssl/ssl-bundle.crt;»

Рестартанул nginx “service nginx restart”

И пошел проверять. В Битрикс – админке – ошибки исчезли. В Битрикс скрипте проверки – тоже.

Тест в консоли «curl https://somebody.ru:443» — также прошел на ура и выдал содержимое страницы в консоль. Тесты на сайтах тестирования сертификатов – улучшились, но уровень «A» таки получить не удалось, — остался «B» — https://www.ssllabs.com/ssltest/ . Тестер комодо — https://sslanalyzer.comodoca.com/ тоже выдал некоторые проблемы с « DH 1024-bit». И в инфо на https://weakdh.org/sysadmin.html было рекомендовано создать новую группу командой «openssl dhparam -out dhparams.pem 2048», что я и сделал в консоли. Скрипт предупредил, что это может продлиться долго – на практике это заняло 1-2 минуты (как раз чтобы налить себе чаю).

openssl dhparam -out dhparams.pem 2048

Generating DH parameters, 2048 bit long safe prime, generator 2

This is going to take a long time

Файл сертификата “dhparams.pem” был создан по адресу: /etc/nginx/ssl/

Проверяем nginx – nginx –t

service nginx restart

И – вуаля! Общий уровень – “A”!

Цитата
Андрей Иванов написал: Проблему решил так, необходимо объединить crt и ca-bundle:

как я решал эту проблему .

тоже напоролся дважды при переводе сайта из1251 на ю-8 и уходе из облака в коробку на Б-24

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

комбинация такая Linux CentOS 7.4 + nginx 1.12.2 + тело

1. раздобыть сертификат SSL
у нас изначально стоял КОМОД и по принципу «от добра добра не ищут» поперся обратно к ним же, т.к. дают на 3 месяца бесплатный с возможностью продления
самоподписанты — дело хорошее, но до поры — до времени и не для публичного сайта

для знакомых с английским языком не по наслышке — можно напрямую написать через сайт КОМОДа, для нуждающихся в шефской помощи — мне лично понравился сервис и отношение к клиентам на FirstSSL
у КОМОДа примерно час, у этих минут 30 заняло

беда! : КОМОД пришлет 4 файла, из которых 1 — это сам сертфикат, а три других надо саморучно подвергнуть конкатенации, дабы слепить из них *.ca-bundle файл
одна ошибка в последовательности и сертификат уже не пройдет проверку на ssllabs и прочих подобных ресурсах, будет или некорректно построеная цепочка, или отсутствие цепочки или еще чего не так, и снова — все на «НЕРУССКОМ ЯЗЫКЕ»:

Root CA Certificate — AddTrustExternalCARoot.crt
Intermediate CA Certificate — COMODORSAAddTrustCA.crt
Intermediate CA Certificate — COMODORSADomainValidationSecureServerCA.crt
Your Free SSL Certificate — your_domain_ru.crt

вот тут как раз и зарыта большая собака, т.к. корневой сертификат надо класть в конец файла а оба иммедиата в начало но в строго определенном порядке №1-№2_корень

если тип сертификата предполагает не 1 и не 2 промежуточных — то заплутать очень даже большая вероятность!

от FirstSSL же пришло все готовенькое, оставалось только засунуть в нужное место, т.е. сам сертификат и собраный *.ca-bundle

2. теперь пытаемся пробраться в каталог /etc/nginx/ssl/ и засунуть туда оба эти произведения ИТ-исскуства, предварительно хорошенько запомнив их названия! для этой цели я использовал классический прием по типу Мойдомен_ру.*
после того, как они уже там — поиграться с правами на доступ

3. теперь надо зайти в каталог /etc/nginx/bx/conf/ и отредактировать файл ssl.conf

там уже будут три строчки:

которые относятся ко встроенному сертификату Битрик Вэбокружение, которому никто не доверяет все равно
приводим их к такому виду :

и выше пишем все с точностью, меняя только название и расширение для своих сертификатов (по умолчанию там будет *.pem, и придется заменить на *.crt & *.key)

не забываем перезапустить сам nginx после всех этих манипуляций

если же у вас просто апач, то принцип то действий похожий, вот только каталог будет /etc/pki/tls// и в нем две папочки
— cert для сертификатов
-private для ключей

также рекомендуется перезапустить апач

радости не было конца, думал, что все уже решил, однако не тут то было! часть ошибок с сокетами ушла, которая ниже этажом, а сама строка Работа с сокетами = по прежнему fail.

бежим в файл /etc/hosts и видим такую печальную картину

127.0.0.1 local local.localdomain
::1 local local.domain local6 local.localdomain6

#ANSIBLE MANAGED. НЕ совать ничего после этой строчки
ваш_внутренний адрес_сервера имя сервера имя_сервера.домен

если все работает только внутри сети = это еще куда ни шло, но когда выпустили джинна наружу, то вместо пустоты выше последних строк
пишем

ваш_внутренний адрес_сервера DNS_адрес_узла
(192.168.1.23 my_domain.*)
причем записать надо разом оба варианта с www и без
можно даже употребить формочку

#bx-host
(192.168.1.23 my_domain.*)
если у вас на сервре будет крутиться несколько сайтов
и для некоторых сетей может потребоваться добавление и внешнего IP тоже, хотя не всегда

только после ВСЕХ этих манипуляций все прекрасно завелось и поехало, замок позеленел с досады, что больше не к чему придраться и придется открывать страницу

и только после того как — удалось поднять Push, ибо он тоже на это завязан

Источник