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

21.03.2017 08:58:25
и файла *.key нет есть только такие ![]() |
|||
|
|
06.04.2017 16:51:29
Еще вариант решения
в /etc/hosts 127.0.0.1 localhost 00.000.00.00 site1.ru site2.ru site3.ru гда 00.000.00.00 - ip адрес сервера |
|
|
|
22.12.2017 12:54:53
Была та же проблема недоустановки сертификатов 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 - Называется он «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 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
Проверяем сертификат:
И – вуаля! Общий уровень – “A”! |
|
|
|
16.04.2018 10:32:06
|
|||
|
|
28.05.2018 19:01:05
как я решал эту проблему...
тоже напоролся дважды при переводе сайта из1251 на ю-8 и уходе из облака в коробку на Б-24 ошибка пакостная действительно, на нее завязано много полезных функций, которые попросту не станут работать начинаем сначала комбинация такая Linux CentOS 7.4 + nginx 1.12.2 + тело 1. раздобыть сертификат SSL у нас изначально стоял КОМОД и по принципу "от добра добра не ищут" поперся обратно к ним же, т.к. дают на 3 месяца бесплатный с возможностью продления самоподписанты - дело хорошее, но до поры - до времени и не для публичного сайта для знакомых с английским языком не по наслышке - можно напрямую написать через сайт КОМОДа, для нуждающихся в шефской помощи - мне лично понравился сервис и отношение к клиентам на FirstSSL у КОМОДа примерно час, у этих минут 30 заняло беда!: КОМОД пришлет 4 файла, из которых 1 - это сам сертфикат, а три других надо саморучно подвергнуть конкатенации, дабы слепить из них *.ca-bundle файл одна ошибка в последовательности и сертификат уже не пройдет проверку на ssllabs и прочих подобных ресурсах, будет или некорректно построеная цепочка, или отсутствие цепочки или еще чего не так, и снова - все на "НЕРУССКОМ ЯЗЫКЕ":
вот тут как раз и зарыта большая собака, т.к. корневой сертификат надо класть в конец файла а оба иммедиата в начало но в строго определенном порядке №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, ибо он тоже на это завязан |
|
|
|
24.09.2018 13:56:42
Была ошибка при проверке системы, хотя сайт благополучно работал по https.
Решение заключается в том, что нужно либо загрузить на Cloudflare свой доменный сертификат (доступно только на платном аккаунте), либо отключить проксирование и настроить сертификат на оригинальном сервере с сайтом. --- |
|||
|
|
24.01.2019 15:32:21
Одно из возможных решений для сугубо локального сервера нашлось в теме
|
|
|
|
16.02.2019 18:28:29
В /etc/hosts прописываем
127.0.0.1 our.site.ru (указываем то имя, с которого делали проверку) Если проверка была по адресу Значит пишем так 127.0.0.1 Обратите внимение на то, что "www" |
|
|
|
20.03.2019 09:14:49
Для устранения ошибки проверки сайта (Работа с сокетами - 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 Сорри, если для кого-то информация будет лишней. Но, надеюсь кому-то она поможет. ![]() |
|
|
|
19.11.2019 00:34:23
|
|||
|
|
07.04.2020 16:07:38
Столкнулся с этой же проблемой, но мне нужно было смотреть SEO параметры страницы. Проблема в нефункционировании IPv6.
Решил добавлением одной строчки в конфиг nginx. Составил краткую инструкцию для себя, может кому поможет. Для включения работы сайтов по IPv6 протоколу. 1. Приобрести ipv6. 2. Настроить работу сервера по этому протокол у как описано в инструкции: 3. В настройки сайтов добавить строчку: listen [::]:80; # для http или listen [::]:443 http2; # для работы по https Начало файла настроек выглядит так: server { listen 80 ; listen [::]:80; server_name 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. |
|
|
|
11.06.2020 20:36:01
При проверка сайта получал множество ошибок. Основная ошибка: Работа с сокетами (check_socket): Fail
Проблема в сертификате, а именно в корневом сертификате, который подтверждает подлинность. Они тоже могут заканчиваться. У меня так и вышло. Корневой сертификат закончился 30-ого мая, 2020 года. Проверка Битрикса не проходила проверку. У меня сертификат Sectigo (ранее Comodo). Мой регистратор сертификатов позволяет скачивать комплект сертификатов. Там я скачал обновлённые сертификаты, объединил сертификат с корневым, после этих действий всё заработало. Проблема в том, что у многих работают Sectigo/Comodo сертификаты и ошибка работы с сокетами у многих всего 13-ть дней, на данный момент, и многие просто не увидели ещё ошибку на сайте или Б24. Нужно просто пересобрать сертификат и всё будет хорошо.
Телеграм: @sk33m | Mail:
|
|
|
|
15.07.2020 10:37:55
Работа с сокетами Ошибка! Не работает
Ошибка исчезает если удалить файл init.php (переименовать). Но если подключать даже пустой файл local/php_interface/init.php, то все равно ошибка {Работа с сокетами (check_socket): Fail} |
|
|
|
19.07.2020 08:04:34
|
|
|
|
20.07.2020 10:47:06
127.0.0.1 ВашДомен:443 - потестил не то.
Ошибка исчезает если удалить файл init.php (переименовать) - видимо глюк какой-то - его техподдержка битрикс выявила. |
|
|
|
02.08.2020 17:32:43
На VDS таймвеба заработало, когда саппорт закомментировал строку в /etc/hosts
127.0.0.1 localhost 127.0.1.1 ubuntu18 #127.0.0.1 ваш_сайт.ру |
|
|
|
11.08.2020 20:32:50
Доброго дня всем.
Как я победил эту ошибку с сертификатом. 1. Наш сертификат сайта подписан нашим СА сертификатом (Самозаверенный). В настройках Apache2 прописаны сертификат и ключ. Если есть цепочка сертификатов, то дописываем ее в конфигурации сайта. 2. В файле php.ini найти секцию OpenSSL и в строке: openssl.cafile= /ssl/CA.crt [Путь и имя файла добавляете свои. Это пример!] Рас комментировал и добавил полный путь до файла CA.crt После чего перезагрузил службу, в моем случае это php7.4-fpm.service. Проверка сайта на "Работа с сокетами" прошла успешно. Не знаю, может кому пригодится. |
|
|
|
25.11.2020 14:52:47
Перерепробовал все описанные варианты, с сертификатом проблем нет, IPv6 отключил – ничего не помогло. С клиентов этот GET возвращает SUCCESS (инкогнито, без авторизации в админке). А вот с самого сервера curl возвращает страницу авторизации в админку. Смущает также HTTP/1.1, в nginx для https включен HTTP/2 и стоит безусловный редирект с http на https.
![]() |
|
|
|
04.07.2021 20:35:34
Указал путь к цепочке сертификатов в web админке и ошибка ушла.
|
|
|
|
02.10.2021 13:08:16
Не понимаю, откуда берется эта проблема. У меня на разных серверах, на всех сайтах появилась эта ошибка, единственное, что всех объединяет, это ssl сертификаты. Почему все работало нормально больше года, а теперь вдруг ошибка? |
|||
|
|
04.10.2021 06:56:49
Вроде у корневого сертификата Lets Encrypt истек срок годности. Может быть из-за этого?
|
|
|
|
04.10.2021 10:28:58
Я так понимаю, надо удалить старые сертификаты и сделать новые, буду пробовать! Спасибо за помощь! P.S. обновление сертификатов не решило проблему... |
|||
|
|
04.10.2021 14:00:19
|
||||
|
|
|||