Цитата |
---|
Дмитрий Ипатов написал: Затем в настройках 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 адрес сервера |
|
|
|
10.05.2017 20:45:05
Проблему решил так, необходимо объединить crt и ca-bundle:
далее в nginx прописал его, а не server.crt
Проверить правильность очень просто: в консоли выполните
Изменено: Андрей Иванов - 10.05.2017 20:51:32
|
|||||||
|
|
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
Изменено: Вячеслав Борисов - 16.04.2018 10:32:31
|
|||
|
|
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"
Изменено: Дмитрий Хрусталев - 08.03.2019 16:17:22
|
|
|
|
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. Нужно просто пересобрать сертификат и всё будет хорошо.
Изменено: Денис Пушкин - 11.06.2020 20:36:42
Скайп: demsky447 | Mail:
|
|
|
|
15.07.2020 10:37:55
Работа с сокетами Ошибка! Не работает
Ошибка исчезает если удалить файл init.php (переименовать). Но если подключать даже пустой файл local/php_interface/init.php, то все равно ошибка {Работа с сокетами (check_socket): Fail}
Изменено: Семён Дядькин - 15.07.2020 10:41:08
|
|
|
|
19.07.2020 08:04:34
|
|
|
|
20.07.2020 10:47:06
127.0.0.1 ВашДомен:443 - потестил не то.
Ошибка исчезает если удалить файл init.php (переименовать) - видимо глюк какой-то - его техподдержка битрикс выявила.
Изменено: Семён Дядькин - 20.07.2020 10:47:30
|
|
|
|
02.08.2020 17:32:43
На VDS таймвеба заработало, когда саппорт закомментировал строку в /etc/hosts
127.0.0.1 localhost 127.0.1.1 ubuntu18 #127.0.0.1 ваш_сайт.ру
Изменено: Иван Трухин - 02.08.2020 17:36:00
|
|
|
|
25.11.2020 14:52:47
Перерепробовал все описанные варианты, с сертификатом проблем нет, IPv6 отключил – ничего не помогло. С клиентов этот GET возвращает SUCCESS (инкогнито, без авторизации в админке). А вот с самого сервера curl возвращает страницу авторизации в админку. Смущает также HTTP/1.1, в nginx для https включен HTTP/2 и стоит безусловный редирект с http на https.
![]()
Изменено: Александр Нефёлов - 25.11.2020 17:27:06
|
||||
|
|
|||