Добрый день.
Тут на форуме есть похожая тема:
https://dev.1c-bitrix.ru/support/forum/forum6/topic97363/
но не нашел на решения.
Суть проблемы: установил систему оплаты яндекс касса (от 3), все прописал правильно
http://prntscr.com/r6r1dt
http://prntscr.com/r6r1oy
об этом мне даже сказала служба поддержки яндекс кассы
Система оплаты видна на сайта при оформлении заказа, ее можно выбрать и оформить с ней заказ, но после на странице где есть переход на саму оплату и при попытки перейти к оплате ( /personal/order/payment/?ORDER_ID=50&PAYMENT_ID=50/1 ) — происходит ошибка Socket connection error (только эта строка и выходит, на этой странице просто вызов bitrix:sale.order.payment, он и вызывает эту ошибку)
сайт на https, при проверке в админке битрикса ошибок сокетов нету
я попробовал найти в коде эту ошибку, и обнаружил следующее
если запустить такой код:
Код |
---|
<? require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php"); $APPLICATION->SetTitle("test"); use BitrixMainApplication, BitrixMainWebUri, BitrixMainWebHttpClient; function PRX($e) { echo "<pre>".print_r($e,true)."</pre>"; } // опции по умолчанию: $options = array( "redirect" => true, // true, если нужно выполнять редиректы "redirectMax" => 5, // Максимальное количество редиректов "waitResponse" => true, // true - ждать ответа, false - отключаться после запроса "socketTimeout" => 30, // Таймаут соединения, сек "streamTimeout" => 60, // Таймаут чтения ответа, сек, 0 - без таймаута "version" => HttpClient::HTTP_1_0, // версия HTTP (HttpClient::HTTP_1_0 или HttpClient::HTTP_1_1) "proxyHost" => "", // адрес "proxyPort" => "", // порт "proxyUser" => "", // имя "proxyPassword" => "", // пароль "compress" => false, // true - принимать gzip (Accept-Encoding: gzip) "charset" => "", // Кодировка тела для POST и PUT "disableSslVerification" => false, // true - отключить проверку ssl (с 15.5.9) ); $httpClient = new HttpClient($options); $params = array( 'a'=> 1 ); $url = 'https://winkyou.ru'; $postData = json_encode($params); $response = $httpClient->post($url, $postData); if ($response === false){ $errors = $httpClient->getError(); PRX( $errors ); } else { PRX("OK"); } $url = 'https://payment.yandex.net/api/v3/payments'; echo $url; $postData = json_encode($params); $response = $httpClient->post($url, $postData); if ($response === false){ $errors = $httpClient->getError(); PRX( $errors ); }else { PRX("OK"); } $url = 'https://myeggershop.ru'; echo $url; $postData = json_encode($params); $response = $httpClient->post($url, $postData); if ($response === false){ $errors = $httpClient->getError(); PRX( $errors ); }else { PRX("OK"); } |
( по сути такие же запросы и компонент кассы юзает )
то этот код выводит следующее:
т.е. проблема именно когда идет обращение к яндекс кассе, при этом такая же ошибка возникает, если обратиться например по несуществующему адресу например:
https://asdfasdfa.ru https://payment.yandex.net/api/v3/payments
— этот адрес юзается яндекс кассой, однако выдает ошибку, поддержка яндекса пишет — что проблема не у них (наш домен не забанен), хостер тоже пишет, что де мол https в норме.
редакция битрикса: 1С-Битрикс: Управление сайтом 20.0.450. © Битрикс, 2016
еще попробовал установить модуль
Мибок: Платежный модуль для сайта
(mibok.pay) — тоже для яндекс кассы, но эффект тот же самый.
В чем может быть проблема?
поддержка яндекс касса послала к поддержке битрикса, поддержка битрикса — говорит мол очень плотный график, в течении 4 дней ответят
( по сути такие же запросы и компонент кассы юзает )
то этот код выводит следующее:
Цитата |
---|
https://winkyou.ru OK |
т.е. проблема именно когда идет обращение к яндекс кассе, при этом такая же ошибка возникает, если обратиться например по несуществующему адресу например: https://asdfasdfa.ru
https://payment.yandex.net/api/v3/payments — этот адрес юзается яндекс кассой, однако выдает ошибку, поддержка яндекса пишет — что проблема не у них (наш домен не забанен), хостер тоже пишет, что де мол https в норме.
редакция битрикса: 1С-Битрикс: Управление сайтом 20.0.450. © Битрикс, 2016
еще попробовал установить модуль Мибок: Платежный модуль для сайта (mibok.pay) — тоже для яндекс кассы, но эффект тот же самый.
В чем может быть проблема?
поддержка яндекс касса послала к поддержке битрикса, поддержка битрикса — говорит мол очень плотный график, в течении 4 дней ответят
Источник
Socket connection error — яндекс касса
Суть проблемы: установил систему оплаты яндекс касса (от 3), все прописал правильно
http://prntscr.com/r6r1dt
http://prntscr.com/r6r1oy
об этом мне даже сказала служба поддержки яндекс кассы
Система оплаты видна на сайта при оформлении заказа, ее можно выбрать и оформить с ней заказ, но после на странице где есть переход на саму оплату и при попытки перейти к оплате ( /personal/order/payment/?ORDER_ID=50&PAYMENT_ID=50/1 ) — происходит ошибка Socket connection error (только эта строка и выходит, на этой странице просто вызов bitrix:sale.order.payment, он и вызывает эту ошибку)
сайт на https, при проверке в админке битрикса ошибок сокетов нету
я попробовал найти в коде эту ошибку, и обнаружил следующее
если запустить такой код:
Код | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
«; > // опции по умолчанию: $options = array( «redirect» => true, // true, если нужно выполнять редиректы «redirectMax» => 5, // Максимальное количество редиректов «waitResponse» => true, // true — ждать ответа, false — отключаться после запроса «socketTimeout» => 30, // Таймаут соединения, сек «streamTimeout» => 60, // Таймаут чтения ответа, сек, 0 — без таймаута «version» => HttpClient::HTTP_1_0, // версия HTTP (HttpClient::HTTP_1_0 или HttpClient::HTTP_1_1) «proxyHost» => «», // адрес «proxyPort» => «», // порт «proxyUser» => «», // имя «proxyPassword» => «», // пароль «compress» => false, // true — принимать gzip (Accept-Encoding: gzip) «charset» => «», // Кодировка тела для POST и PUT «disableSslVerification» => false, // true — отключить проверку ssl (с 15.5.9) ); $httpClient = new HttpClient($options); $params = array( ‘a’=> 1 ); $url = ‘https://winkyou.ru’; $postData = json_encode($params); $response = $httpClient->post($url, $postData); if ($response === false)< $errors = $httpClient->getError(); PRX( $errors ); > else < PRX(«OK»); >$url = ‘https://payment.yandex.net/api/v3/payments’; echo $url; $postData = json_encode($params); $response = $httpClient->post($url, $postData); if ($response === false)< $errors = $httpClient->getError(); PRX( $errors ); >else < PRX(«OK»); >$url = ‘https://myeggershop.ru’; echo $url; $postData = json_encode($params); $response = $httpClient->post($url, $postData); if ($response === false)< $errors = $httpClient->getError(); PRX( $errors ); >else
( по сути такие же запросы и компонент кассы юзает )
т.е. проблема именно когда идет обращение к яндекс кассе, при этом такая же ошибка возникает, если обратиться например по несуществующему адресу например: https://asdfasdfa.ru https://payment.yandex.net/api/v3/payments — этот адрес юзается яндекс кассой, однако выдает ошибку, поддержка яндекса пишет — что проблема не у них (наш домен не забанен), хостер тоже пишет, что де мол https в норме. редакция битрикса: 1С-Битрикс: Управление сайтом 20.0.450. © Битрикс, 2016 еще попробовал установить модуль Мибок: Платежный модуль для сайта (mibok.pay) — тоже для яндекс кассы, но эффект тот же самый. В чем может быть проблема? поддержка яндекс касса послала к поддержке битрикса, поддержка битрикса — говорит мол очень плотный график, в течении 4 дней ответят Источник Socket connection error — яндекс кассаСуть проблемы: установил систему оплаты яндекс касса (от 3), все прописал правильно Система оплаты видна на сайта при оформлении заказа, ее можно выбрать и оформить с ней заказ, но после на странице где есть переход на саму оплату и при попытки перейти к оплате ( /personal/order/payment/?ORDER_ID=50&PAYMENT_ID=50/1 ) — происходит ошибка Socket connection error (только эта строка и выходит, на этой странице просто вызов bitrix:sale.order.payment, он и вызывает эту ошибку) сайт на https, при проверке в админке битрикса ошибок сокетов нету я попробовал найти в коде эту ошибку, и обнаружил следующее
|
Во время тестирования сайта, выскакивает следующая ошибка:
Работа с сокетами (check_socket): Fail
А в журнале мы видим следующий лог:
2016-Feb-27 13:41:10 Работа с сокетами (check_socket): Fail Connection to site.ru:80 Success == Request == GET /bitrix/admin/site_checker.php?test_type=socket_test&unique_id=83f81a8666278b68e58012ce161a1dd0 HTTP/1.1 Host: site.ru == Response == HTTP/1.1 404 Not Found Server: nginx/1.4.6 (Ubuntu) Date: Sat, 27 Feb 2016 12:41:10 GMT Content-Type: text/html Content-Length: 177 Connection: keep-alive == Body == <html> <head><title>404 Not Found</title></head> <body bgcolor="white"> <center><h1>404 Not Found</h1></center> <hr><center>nginx/1.4.6 (Ubuntu)</center> </body> </html> ==========
Для начала мы видим в этом логе, что при запросе система получает 404 ошибку. Нам нужно понять почему она происходит. Для этого нам нужно проверить логи веб-сервера. Так как у меня работает на nginx + apache2, я открыл логи nginx (Linux /var/log/nginx/error.log).
В данном логе я ищу мой запрос
2016/02/27 13:41:10 [error] 2309#0: *658 openat() "/usr/share/nginx/html/bitrix/admin/site_checker.php" failed (2: No such file or directory), client: 127.0.0.1, server: localhost, request: "GET /bitrix/admin/site_checker.php?test_type=socket_test&unique_id=83f81a8666278b68e58012ce161a1dd0 HTTP/1.1", host: "site.ru"
И что мы тут видим? Когда скрипт обращается сам к себе, то происходит обращение вообще не понятно по какому адресу «/usr/share/nginx/html/bitrix/admin/site_checker.php», тогда как сайт лежит: /var/www/site.ru/www/bitrix/admin/site_checker.php
Так же обратите внимание по какому адресу обращается скрипт:
client: 127.0.0.1, server: localhost,
Из этого мы делаем вывод что site.ru привязан к localhost и при обращении сайта к самому себе пытается найти файлы не в папке сайта, а в папке nginx по умолчанию. Открыв фаил /etc/hosts я увидел следующую запись:
127.0.0.1 localhost.localdomain localhost site.ru
Изменив эту строчку на
127.0.0.1 localhost.localdomain localhost
я успешно прошел тест, и ошибка больше не возникала!
Содержание
- Ошибка работы с сокетами
- Не удалось проверить из-за ошибки в работе с сокетами
- Ошибка проверки сайта Работа с сокетами — Socket error [111]: Connection refused
- Ошибка проверки сайта Работа с сокетами — Socket error [111]: Connection refused
Ошибка работы с сокетами
В инструментах запустил проверку системы. После завершения проверки, отображается ошибка работы с сокетами «Ошибка! Не работает».
В логе проверки вот такое выдает:
Цитата |
---|
Александр Гусев написал: 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 |
Особенно подчеркну предложение Александра. Кроме 404 и 302 ошибка бывает Советую внимательно посмотреть логи и какой ответ сервера. Вот на фото подчеркнуто красным. Чуть ниже надписи Работа с сокетами (check_socket): Fail . Долго искал в поисковике bitrix socket error , нашел интересную и подробную статью Bitrix. Исправляем ошибку «Работа с сокетами — Ошибка! , чтобы сформулировать правильное задание ТЗ , а то вовсе без техподдержки решить проблему после » Полного тестирования системы» /bitrix/admin/site_checker.php?lang=ru
У меня другая ошибка была, неправильный redirect Но суть в том, что эта проблема с сокетом. может быть причиной значительного увеличения нагрузки на сервер.. (фото ДО и после ))
Очень рад что есть такой полезный инструмент «Проверка системы», он позволяет не создавать лишней работы по оптимизация скриптов и вообще избежать много другого страшного гемора, например потерянные ссылки на сайте.
Источник
Не удалось проверить из-за ошибки в работе с сокетами
Коллеги, помогите пожалуйста разобраться раз и навсегда, после установки коробки, при тестировании системы на ошибки вышло много ошибок связанных с сокетами. Вот скрин: https://prnt.sc/xo6dso
Не удалось проверить из-за ошибки в работе с сокетами. Как исправить данную ошибку, помогите пожалуйста научиться раз и навсегда. Благодарю!
Цитата |
---|
Александр Гусев написал: Нажмите вопрос и в открывшемся окне нажмите «журнал ошибок» или что-то в этом роде, там расшифровка ошибок идёт |
Я смотрел, исходя из того что написано там, я так и не понял что конкретно требуется сделать.
Осуществляется сетевое подключение с веб-сервера к самому себе. Это необходимо чтобы проверить работу сетевых функций, а также требуется для ряда последующих тестов.
А значит, если этот базовый тест не отработал, то дальнейшие тесты, где требуется создание независимого php процесса, не могут быть произведены.
Обычно проблема возникает, если подключение запрещено фаерволом, доступ к административной части запрещен по IP или для входа на сайт требуется HTTP/NTLM авторизация. На этапе тестирования необходимо отключить эти ограничения.
А в журнале ошибок написано:
2021-Jan-26 21:53:49 Работа с сокетами (check_socket): Fail Connection to 176.120.203.37:80 Fail Socket error [111]: Connection refused Ошибка! Не работает
Источник
Ошибка проверки сайта Работа с сокетами — 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): Fail
Connection to 123.456.789.123:80
Socket error [110]: Connection refused
В моем случае проблема была в том, что заказчик предоставил только адрес шлюза 123.456.789.123, а на нем пробросил порт 80 на хост с виртуалкой. А виртуалка ничего не знала про этот IP.
В своем локальном файле c:WindowsSystem32driversetchosts я добавил запись:
80.66.94.230 portal.localdom
А на виртуалке добавил /etc/hosts имя portal.localdom
127.0.0.1 localhost.localdom localhost localhost portal.localdom
После этого проверка сокетов прошла успешно.
Еще одна причина возникновения данной ошибки:
На сайте стоит http-авторизация через утилиту passwd и .htaccess в вышележащей папке.
Соответственно, после того, как убираем из .htaccess в папке «..»
AuthName «Private zone»
AuthType Basic
AuthUserFile .htpasswd
require 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
Как только мы в .htaccess указываем mbstring.internal_encoding utf-8, то в журнале просто нет хоста, к которому проверяется подключение:
2013-Dec-19 15:34:42 Работа с сокетами (check_socket): Fail
Connection to :80 Fail
Socket error [0]: php_network_getaddresses: getaddrinfo failed: Name or service not known
>Connection to xn——dlcdhdea0afa5acqdcd1cjk8r.xn--p1ai:80 Success
>Connection to :80 Fail
т.е. система не видит адреса, к которому нужно подключаться.
____________________________________________________________
Есть подозрение, что проблема в кириллическом домене, т.к. на этой площадке стоят еще две системы и ничего похожего там не происходит, тестирование проходит успешно.
Источник
Ошибка проверки сайта Работа с сокетами — 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
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, ибо он тоже на это завязан
Источник
После установки SSL сертификата в битриксе на виртуальной машине BitrixVM версии 7.4.1 начала появляться ошибка с сокетами, при этом если перейти на сайт по обычному http, то такой проблемы не наблюдается.
Ниже описано как решить данную проблему с сокетами при использование SSL сертификата и протокола HTTPS в Bitrix virtual appliance version 7.4.1 («1С-Битрикс: Веб-окружение»).
Открываем SSH клиет (PuTTY).
Если меню битрикса не отображается сразу, то заходим в меню следующей командой:
cd
./menu.sh
Затем выбираем поочередно пункты в меню:
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
Загрузка
— На основе оценок
2
человек
При прохождении теста настроек Битрикса часто вылазит ошибка Socket error [111]: Connection refused, причин может быть несколько. Чтобы понять в чем именно причина, можно посмотреть логи проверки, но лучше в командной строке ввести аналогичную команду (по сути, битрикс ее выполняет).
curl https://ваш_сайт
#Если сайт через SSL работает
curl https://ваш_сайт:443
Битрикс не видит своего домена по URL
Если наблюдается такая ошибка (ее можно посмотреть в логах проверки битрикса), то необходимо в /etc/hosts прописать 127.0.0.1 ваш_сайт и ваш.IP ваш_сайт (все с новой строчки).
Ошибка с SSL.
curl: (60) server certificate verification failed.
Еще один распространенный вариант — неправильная установка SSL сертификата. Даже если у вас сайт открывается с зеленой полоской, нужно проверить еще раз тут — https://www.sslshopper.com/ssl-checker.html или в командной строке ввести запрос на сайт через curl.
Лечить данную проблему нужно правильной установкой SSL (логично). Проблему помогает решить внесение ca-bundle к crt сертификату. Чтобы не генерировать ca-bundle, просто возьмите себе тут — https://www.namecheap.com/support/knowledgebase/article.aspx/9393/69/where-do-i-find-ssl-ca-bundle (искать по названию).
curl: (7) Failed connect to crm.domain.ru:443;
Connection refused
Это значит, что исходящее обращение блокируется. Скорее всего, порты для вашего домена закрыты. Чтоыб проверить, нужно ввести команду
nmap -p80,443 crm.domain.ru
#если выдаст такое, значит порты закрыты
Starting Nmap 6.40 ( http://nmap.org ) at 2017-08-29 18:07 MSK
Nmap scan report for crm.capitalest.ru (192.2.2.2)
Host is up (0.00043s latency).
PORT STATE SERVICE
80/tcp closed http
443/tcp closed https
Данная проблема лечится, как и писал выше, добавлением в /etc/hosts строчки 127.0.0.1 ваш_сайт и ваш.IP ваш_сайт (все с новой строчки).
Вас могут заинтересовать следующие услуги
Итак, многие сталкиваются с такой проблемой как ошибка сокетов при проверке сайта (а с 30 сентября 2021 так еще больше таких проблем, решение будет ниже):
Из-за этой ошибки сайт не может проверить все остальные параметры и вы видите очень много красных предупреждений: «Замечание. Не удалось проверить из-за ошибки в работе с сокетами». Она бывает при установке сайта на виртуальную машину Битрикс.
Что делать?
Первое что нужно сделать при запуске сайта на виртуальной машине Битрикс, это прописать домен в файле hosts. Заходим на сервер по sftp под root-пользователем, идем в корневую папку etc, открываем файл hosts.
В первой строке через пробел прописываем домен (если доменов несколько, прописываем все через пробелы в этой строке).
Получится примерно так:
127.0.0.1 localhost.localdomain localhost rushstudio.by
Сохраняем файл и перезагружаемся. Готово, все работает.
Домен прописан, ошибка осталась
Сейчас (осень 2021) у всех массово возникли проблемы. Это касается изменений на стороне центра сертификации let’s encrypt (30 сентября 2021 года подошел к концу срок действия корневого сертификата IdenTrust DST Root CA X3.). И если у вас было все настроено и работало, ошибка все-равно появляется.
Решается все довольно просто. Подключаемся по SSH, выходим из открывшегося меню (ctrl+c) и вводим команды подряд:
yum install ca-certificates
update-ca-trust
Готово. Теперь все будет работать.
Думаю в следующих обновлениях Виртуальной машины это поправят, но пока это решение рабочее на 100%.
Все-равно не помогло?
Первым делом проверьте AAAA-запись у домена, если она есть, удалите.
Не помогло? Проверьте что доступ к админке, где вы запускаете тест, открыт (нет ограничений по IP или других блокировок).
Дальнейшие случаи крааайне редки, но встречаются. Тут вам понадобятся немного знаний по системному администриролванию и нужно проверить firewall (сервер пытается подключиться сам к себе, а доступ закрыт) или для входа на сайт требуется HTTP/NTLM авторизация (тут уже просто на время тестирования отключите ее).