Не удалось установить SSL-соединение, как я могу исправить свой SSL-сертификат?

Ответ 1

SSL23_GET_SERVER_HELLO: неизвестный протокол

Эта ошибка возникает, когда OpenSSL получает что-то отличное от ServerHello в версии протокола, которую он понимает с сервера. Это может произойти, если сервер отвечает простым (незашифрованным) HTTP. Это также может произойти, если сервер поддерживает только, например. TLS 1.2, и клиент не понимает эту версию протокола. Как правило, серверы обратно совместимы по меньшей мере с SSL 3.0/TLS 1.0, но, возможно, этот конкретный сервер не является (путем реализации или конфигурации).

Непонятно, пытались ли вы пройти --no-check-certificate или нет. Я был бы удивлен, если бы это сработало.

Простым тестом является использование wget (или браузера) для запроса http://example.com:443 (обратите внимание на http://, not https://); если он работает, SSL не включен на порт 443. Чтобы продолжить отладку, используйте openssl s_client с параметром -debug, который перед сообщением об ошибке выгружает первые несколько байтов ответа сервера, который OpenSSL не смог разобрать. Это может помочь выявить проблему, особенно если сервер не отвечает сообщением ServerHello. Чтобы узнать, что именно ожидает OpenSSL, проверьте источник: найдите SSL_R_UNKNOWN_PROTOCOL в ssl/s23_clnt.c.

В любом случае, просмотр журнала ошибок apache также может дать некоторое представление.

Ответ 2

В моем случае я не включил сайт "default-ssl". Только "000-default" был указан в папке /etc/apache2/sites-enabled.

Включить сайт SSL на Ubuntu 14 LTS, Apache 2.4.7:

a2ensite default-ssl
service apache2 reload

Ответ 3

Простое примечание (и возможная причина).

В файле Apache.conf вы можете иметь совершенно правильную настройку VirtualHost с _default_:443 и т.д.

Но... Если даже один .conf файл включен с неправильными настройками, который также прослушивает порт 443, тогда он приведет к отключению всей системы SSL.

Поэтому, если вы уверены, что ваш .conf файл прав, попробуйте отключить другие .conf файлы сайта в sites-enabled.

Ответ 4

Есть несколько возможностей:

• На вашей рабочей станции нет корневого CA-сертификата, используемого для подписи вашего сертификата сервера. Как именно вы это исправите, зависит от того, какая ОС вы используете и какой выпуск и т.д. (я подозреваю, что это не связано)
• Ваш сертификат установлен неправильно. Если ваш сертификат SSL требует наличия промежуточного сертификата, и вы не установили его, вы можете получить эти предупреждения.
• Вы уверены, что активировали SSL на порту 443?

Во-первых, чтобы устранить (3), что произойдет, если вы подключитесь к этому порту?

Предполагая, что это не (3), то в зависимости от ваших потребностей вы можете быть в порядке, игнорируя эти ошибки и просто передавая -no-certificate-check. Вероятно, вы захотите использовать обычный браузер (который обычно связывает корневые сертификаты напрямую) и посмотрите, довольны ли они.

Если вы хотите вручную проверить сертификат, отправьте более подробную информацию из вывода openssl s_client. Или используйте openssl x509 -text -in /path/to/cert, чтобы распечатать его на своем терминале.

Ответ 5

У меня возникла эта проблема при создании нового экземпляра EC2. Я не добавил HTTPS в свою группу безопасности, и поэтому порт 443 не был открыт.

Ответ 6

Для меня DNS-имя моего сервера было добавлено в /etc/hosts, и оно было сопоставлено с 127.0.0.1, в результате чего

SL23_GET_SERVER_HELLO: неизвестный протокол

Удаление отображения моего реального DNS-имени до 127.0.0.1 разрешило проблему.

Ответ 7

Я отвечаю на этот же вопрос. Порт 443 не был открыт в Centos.

Проверьте порт 443 с помощью следующей команды:

sudo lsof -i tcp: 443

В первой строке файла /etc/httpd/conf.d/ssl.conf добавьте две строки:

LoadModule ssl_module modules/mod_ssl.so
Listen 443

Ответ 8

Проблема, с которой я столкнулся, была в среде клиентского сервера. Клиент пытался подключиться через http-порт 80, но хотел, чтобы серверный прокси перенаправлял запрос на другой порт, а данные были https. Таким образом, в основном запрашивается безопасная информация по http. Таким образом, сервер должен иметь http-порт 80, а также запрашивать порт-клиент, скажем urla:1111\subB.

Проблема заключалась в том, что сервер размещал это на каком-то другом порту e, g urla:2222\subB; поэтому клиент пытался получить доступ через 1111, получая ошибку. Исправление номера порта должно исправить эту проблему. В этом случае на номер порта 1111.