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

Убедитесь, что правильно указан IPv6 адрес, так как curl (что используется в Битрикс) работает по нему. Такая проблема часто возникает на виртуальных серверах при переносах домена между аккаунтами: IP поменяли, сайт открывается, а курл сам на домен сайта дает 500 ошибку.
Аналогичная проблема бывает с счетчиками Яндекс.Метрики: показания снимает, но всегда недоступен (красный).
Надеюсь кому помогло.

Была та же проблема недоустановки сертификатов Comodo. Решил так:
Сертификат был приобретен не мной, «в наследство» мне достались
лишь 2 файла – xxx.pem и xxx.key. Протоколы были настроены, но битрикс
не проходил тест на сокеты – ошибка сокетов хоть ты тресни – что в админке  "Работа с сокетами Ошибка! Не работает" –
отсюда и ниже. Что в скрипте проверки
битрикс – «Warning: fsockopen(): SSL operation failed with
code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed in /home/bitrix/www/bitrix_server_test.php on line 624»

И к тому же что 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

openssl dhparam -out dhparams.pem 2048

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

This is going to take a long time

.......................+.............+....+............................................................................................*

[root@xxx]#

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

Далее:

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

Всё ОК!

Перезапускаем nginx -

service nginx restart

Проверяем сертификат: https://www.ssllabs.com/ssltest/

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

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

тоже напоролся дважды  при переводе сайта из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

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

SSL_certificete_file
SSL_certificste_key_file
dhparam_file

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

#SSL_certificete_file
#SSL_certificste_key_file
dhparam_file

и выше пишем все с точностью, меняя только название и расширение для своих сертификатов (по умолчанию там будет *.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, ибо он тоже на это завязан

Одно из возможных решений для сугубо локального сервера нашлось в теме PHP 5.6 и OpenSSL, сообщения #7 и #13.

Для устранения ошибки проверки сайта (Работа с сокетами - Socket error) в случае использования SSL необходим CA bundle - документ, содержащий корневой и промежуточный сертификаты соответствующего центра сертификации, он используется с целью валидации сертификатов, выданных известными центрами сертификации. Ошибка часто проявляется при смене сертификата, т.к. нет информации именно о корневом и промежуточных.

Итак, самым простым способом является объединение всех сертификатов в один файл.
1) Создаём пустой файл
2) Вставляем в него содержимое всех выданных файлов CRT в такой последовательности: сертификат_Вашего_домена.crt, intermediate.crt (их может быть несколько: intermediate2.crt, intermediate1.crt), root.crt
3) Можно спокойно сохранить всё это под именем my_cert.crt
4) В папку /etc/nginx/ssl/ скопировать файлы my_cert.crt и my_key.key (файл приватного ключа)
5) В файле /etc/nginx/sites-enabled/your-ssl.conf проверить правильность путей и имён файлов:
ssl_certificate /etc/nginx/ssl/my_cert.crt;
ssl_certificate_key /etc/nginx/ssl/my_key.key;
6) Перезапустить сервис Nginx: service nginx restart

В дальнейшем, при смене сертификата просто меняем содержимое my_cert.crt и my_key.key на новое и перезапускаем сервис: service nginx restart

Сорри, если для кого-то информация будет лишней. Но, надеюсь кому-то она поможет.

Столкнулся с этой же проблемой, но мне нужно было смотреть SEO параметры страницы. Проблема в нефункционировании IPv6.
Решил добавлением одной строчки в конфиг nginx.

Составил краткую инструкцию для себя, может кому поможет.

Для включения работы сайтов по IPv6 протоколу.
1. Приобрести ipv6.
2. Настроить работу сервера по этому протокол у как описано в инструкции: http://firstwiki.ru/index.php/Добавить_IP_на_сервер
3. В настройки сайтов добавить строчку:
listen [::]:80; # для http
или
listen [::]:443 http2; # для работы по https

Начало файла настроек выглядит так:
server {
   listen 80 ;
   listen [::]:80;
   server_name 33diploma.ru www.33diploma.ru;


Файлы настроек на VM Bitrix лежат тут: \etc\nginx\bx\site_avaliable\

4. Перезапустить nginx:
[root] # service nginx restart
и убедиться, что он перезапустился без ошибок.

5. В настройках DNS нужно добавить записи типа:
@ IN AAA 2a01:230:2::xx
www      IN AAA 2a01:230:2::xx

Для самого домена и субдомена www.

Работа с сокетами Ошибка! Не работает
Ошибка исчезает если удалить файл init.php (переименовать).
Но если подключать даже пустой файл local/php_interface/init.php, то все равно ошибка {Работа с сокетами (check_socket): Fail}

127.0.0.1 ВашДомен:443 - потестил не то.
Ошибка исчезает если удалить файл init.php (переименовать) - видимо глюк какой-то - его техподдержка битрикс выявила.

Доброго дня всем.

Как я победил эту ошибку с сертификатом.

1. Наш сертификат сайта подписан нашим СА сертификатом (Самозаверенный). В настройках Apache2 прописаны сертификат и ключ. Если есть цепочка сертификатов, то дописываем ее в конфигурации сайта.

2. В файле php.ini найти секцию OpenSSL и в строке:
openssl.cafile= /ssl/CA.crt [Путь и имя файла добавляете свои. Это пример!]

Рас комментировал и добавил полный путь до файла CA.crt

После чего перезагрузил службу, в моем случае это php7.4-fpm.service.

Проверка сайта на "Работа с сокетами" прошла успешно.


Не знаю, может кому пригодится.

Указал путь к цепочке сертификатов в web админке и ошибка ушла.

Вроде у корневого сертификата Lets Encrypt истек срок годности. Может быть из-за этого?