Wget openssl error

Ошибка: ошибка: 14077410: подпрограммы SSL: SSL23_GET_SERVER_HELLO: сбой квитирования оповещения sslv3

этот код работает на локальном хосте, но когда я тестирую на своем живом сервере, он выдаст мне эту ошибку Ошибка: ошибка: 14077410: подпрограммы SSL: SSL23_GET_SERVER_HELLO: сбой квитирования оповещения sslv3 тогда я попробовал это

github.com/paypal/TLS-update/tree/master/php это снова будет работать на локальном хосте, а в прямом эфире это дает мне это

мой сервер имеет эти сертификаты

Ключ сервера и сертификат № 1

# 2

# 3

проверенные требования в

Решение

TL; TR: ваше программное обеспечение устарело для поддержки этих серверов.

Оба сервера поддерживают только TLS 1.2, что видно при проверке с помощью SSLLabs . Ваша версия OpenSSL — 1.0.0s, которая еще не поддерживает TLS 1.2. Поддержка доступна только с 1.0.1.

мой сервер имеет эти сертификаты …

Настройка вашего веб-сервера (то есть сертификаты, версии TLS …) не имеет значения, потому что в этом случае вы являетесь клиентом, подключающимся к другому серверу.

Другие решения

Ваш сервер может поддерживать TLS 1.2, но вы должны убедиться, что HTTP-запросы действительно его используют. Судя по полученному вами результату, вы, очевидно, не используете TLS 1.2 с запросами.

Попробуйте добавить это к вашим опциям cURL:

Это заставит TLS 1.2.

Или обновите стек программного обеспечения вашего сервера, и это произойдет автоматически. Увидеть эта почта для более подробной информации, самое главное эта часть:

Если вы хотите использовать TLS 1.2, вам нужно будет как минимум перейти на OpenSSL 1.0.1, а затем установить CURLOPT_SSLVERSION на 6 (TLS 1.2).

Если вы хотите, чтобы TLS 1.2 использовался автоматически во время запросов SSL, вам также необходимо обновить его до PHP 5.5.19+ (это идеальное решение, но многие проекты все еще используют более старые версии PHP).

Источник

MAMP Ошибка SSL: & quot; ошибка: 14077410: процедуры SSL: SSL23_GET_SERVER_HELLO: ошибка квитирования оповещения sslv3 & quot;

Я использую MAMP на OS X Yosemite для разработки веб-сайта на моей локальной машине. Веб-сайт — это клиентское приложение для API, работающего по протоколу HTTPS. Я продолжаю получать эту ошибку, когда я пытаюсь вызвать API из PHP:

Тот же код работает на сервере, но сайт уже работает, поэтому мне нужно создать отдельную среду разработки. Я получаю точно такую ​​же ошибку, вызываю ли я API с помощью cURL или file_get_contents , Я могу использовать cURL в командной строке или загрузить URL в моем браузере, и он отлично работает. Я часами читал и пробовал все другие решения, которые мог найти на этом сайте и в других местах, и ни одно из них не сработало. Кто-нибудь еще видел эту проблему?

Обновить: Я наконец-то нашел решение в своем последнем случае, прежде чем опубликовать этот вопрос, но это был настолько болезненный процесс, что я все равно публикую его в надежде, что он может помочь кому-то еще избежать этой трагической катастрофы. Мое решение ниже.

Решение

1. brew install openssl
2. Загрузите и распакуйте последнюю версию завивать

В исходном каталоге cURL:

В PHP между curl_init а также curl_exec :

Путь к поиску решения начался с этот сайт , который описывает другую ошибку SSL на MAMP и предлагает перекомпилировать новую версию cURL с
—prefix=/Applications/MAMP/Library/ переписать тот, который использует MAMP. Я попробовал это, но это не сработало. Позже, что-то побудило меня изучить параметры компиляции cURL, и я заметил инструкции для указания другой версии OpenSSL при компиляции. Я решил попробовать (пообещав себе, что это последняя попытка, а потом я сдаюсь). Я установил обновленный пакет OpenSSL с Homebrew, и его полезная информация после установки сказала:

Это выглядело примерно так, как я видел в опциях компиляции cURL, в которых был указан правильный синтаксис:

Я добавил обратно в —prefix=/Applications/MAMP/Library/ с последующим обычным make а также make install , перезапустил MAMP и вздохнул с облегчением.

Позже я обнаружил, что один из вариантов cURL, который я добавил с другого сайта, также был необходим, чтобы избежать другой ошибки SSL («Проблема с сертификатом SSL: невозможно получить сертификат локального эмитента»). настройка CURLOPT_SSL_VERIFYPEER ложный решил, что один для меня.

Другие решения

Вот решение, которое работает для меня на MAMP Pro 3.5, работающей на OSX 10.11.1

В вашем PHP может потребоваться установить версию SSL и соответствующий шифр для curl_init() :

Для точных параметров вы можете перейти к CURLOPT_SSLVERSION увидеть: http://php.net/manual/en/function.curl-setopt.php

Также ниже могут отображаться ошибки, связанные с версиями SSL, которые используются для точного определения конфликта версий:

У меня была такая же проблема. Я решил это, вместо этого используя предпочтительную программу SSL SecureTransport. Следующее работало для меня:

1. Загрузите последнюю версию curl (zip) с Вот
2. Перейдите в папку загрузок и извлеките zip-файл, дважды щелкнув по нему. Теперь в ваших загрузочных папках будет папка с извлеченными файлами.
3. Откройте терминал и перейдите в папку
   `cd

/ Downloads / curl-folder-name ‘

Перезапустите MAMP и посмотрите, сработали ли изменения. Один из способов проверки состоит в том, чтобы вызвать следующее в вашей программе MAMP php в терминале:

/Applications/MAMP/bin/php/php5.5.14/bin/php -r ‘echo json_encode(curl_version(), JSON_PRETTY_PRINT);’

Тебе следует увидеть «ssl_version»: «SecureTransport»

Я решил это, обновив локон. (отметьте версию curl и версию openssl, они могут не совпадать)

curl 7.12.1 требует OpenSSL / 0.9.7a, но мой OpenSSL — 1.0.2m.

$ curl -V curl 7.12.1 (x86_64-redhat-linux-gnu) libcurl / 7.12.1 OpenSSL / 0.9.7a zlib / 1.2.1.2 libidn / 0.5.6 Протоколы: ftp gopher telnet dict ldap http файл https ftps Особенности : GSS-согласование IDN IPv6 Largefile NTLM SSL libz

$ openssl версия OpenSSL 1.0.2m 2 ноября 2017 г.

Источник

curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Пытаюсь установить pip на centos 5, но после команды

Инфа по версиям:

Предполагаю что проблема в том что curl вяжется к старой версии openssl, но как фиксить не понимаю

наверное сервер не хочет по дырявому SSLv3 соединяться

что значит по дырявому

подверженному уязвимостям безопасности

а что делать тогда

обновить centos 5 на что-то более современное

или хотя бы curl

«curl version 7.15.5 was released on August 7 2006.»

эта версия OpenSSL 3.0 точно никак не подцепит

Centos5 не умеет качать с бОльшей части https-интернета, т.к. не знает современные cypher’ы у openssl, а те, что знает, выключены у этой самой бОльшей части https-интернета. Именно поэтому в прошлом треде я и указал на копрофагию.

P.S. Да, у меня есть старый прод (который скоро закроется, надеюсь) на centos5, я знаю, о чем говорю.

сначала обновил curl через yum update curl, после этого к curl-у подвязался openssl-1.0.1, но curl всё равно был старенький

потом обновил curl через репозиторий city-fan, теперь версия curl 7.53.1,но опять к нему подвязался openssl 0.9.8b и опять таже ошибка с SSL23_GET_SERVER_HELLO

Что делать? спасайте

Тебе уже говорили, что это хреновая идея? Так вот, это хреновая идея. Скажи спасибо, что устаревший curl помешал тебе сделать глупость

Скачать скрипт ты можешь через любой хост. А перед выполнением проверить, что он делает

эта версия OpenSSL 3.0 точно никак не подцепит

В Debian Bullseye 1.1.1k-1. В Fedora 34 1.1.1l-1. В Fedora 36 на 2021-09-09 3.0.0-1

Ты точно ничего не употребил?

Ничего ты центос 5 и 6 не обновишь. В прошлом году все закрыли.

Источник

При проверке ssl Ошибка

Доброе время суток Centos 6.6 под webserver Методы написанные на tomcat7 java нужно было прописать https по порту 8181 Все работает отлично ssl прописывал не в apache а в tomcat настройках Но при отправке с клиентской стороны запрос выдает ошибку

* About to connect() to domain.com port 8181 * Trying 10.10.10.10. connected * Connected to domain.com (10.10.10.10) port 8181 * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSLv2, Client hello (1): error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure * Closing connection #0 curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Или проверил через онлайн сервис ssl на моем домене Unable to connect server ssl 2.0 он даже до tls1 не дошел незнаю как решить проблему

оно тухлое и obsolete, многие его закрывают уже.

Ну это я знаю что же поделать если сервис требует Нужно делать

Re: v2

что это за говносервис такой, чтоб моей ноги там не было? ладно TLSv1, его надо саппортить ради старых XMPP-клиентов и мобильников, а такая древнота.

Вот такой сервис платежный!

SSLv2 не хорошая вещь. она вроде по умолчанию выключена. её надо включать принудительно. Но вообще это делать не рекомендуется т.к. геморра будет всё равно много.

Что-то типа такого

при запуске выстави -Djavax.net.debug=all и получишь инфу о игнорировании сертификатов и протоколов и т.п. инфу.

Спасибо щас проверю

Ошибка еще вот такая вот когда клиент обращается на мой сервер

12:04:22,606 INFO Thread-4 WebServiceWorker:downloadCertificate:838 — start download certificat for: domain.com:8443 pathks:/usr/java/jre1.6.0_45/lib/security/cacerts 12:04:22,607 INFO Thread-4 WebServiceWorker:downloadCertificate:851 — loading keystore /usr/java/jre1.6.0_45/lib/security/cacerts. Opening connection to domain.com:8443.

12:04:22,631 INFO Thread-4 WebServiceWorker:downloadCertificate:870 — Starting SSL handshake. 12:04:22,640 ERROR Thread-4 WebServiceWorker:downloadCertificate:876 — javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure 12:04:22,641 ERROR Thread-4 WebServiceWorker:downloadCertificate:881 — Could not obtain server certificate chain 12:04:22,641 ERROR Thread-4 WebServiceWorker:downloadCertificate:911 — java.lang.NullPointerException Якобы связанно что не могут скачать сертификат

а ты его добавил ? Типа такого

keytool -import -trustcacerts -alias abctest -file abctest.cer -keystore cacerts

у вас что к платежкой системе нет никакой документации.

Источник

Ошибка рукопожатия wget ssl alert

Как исправить ошибку SSL-соединения (ERR_SSL_PROTOCOL_ERROR)

Я пытаюсь загрузить файлы с https-сайта и получаю следующую ошибку:

Читая блоги в Интернете, я понял, что должен предоставить сертификат сервера и сертификат клиента. Я нашел шаги по загрузке сертификата сервера, но не сертификата клиента. У кого-нибудь есть полный набор шагов по использованию wget с SSL? Я также попробовал опцию —no-check-certificate, но это не сработало.

пытаюсь загрузить все ресурсы лекций с веб-страницы курса на coursera.org. Итак, URL-адрес будет выглядеть примерно так: https://class.coursera.org/matrix-002/lecture

Для доступа к этой веб-странице в Интернете требуется проверка подлинности с помощью формы, но не уверен, что это является причиной сбоя.

• 1 Это может быть что угодно, например неподдерживаемый протокол, шифры, SNI . Но обычно это не связано с проверкой сертификата сервера. Добавьте дополнительные сведения, такие как версия wget, версия openssl и сайт, к которому вы пытаетесь получить доступ. Также используйте wget -v —debug .
• пожалуйста, помогите мне решить эту проблему. я буду очень благодарен. security.stackexchange.com/questions/240008/…

Отсюда он работает с той же версией OpenSSL, но с более новой версией wget (1.15). Если посмотреть на журнал изменений, можно заметить следующие существенные изменения, касающиеся вашей проблемы:

1.14: Добавить поддержку для указания имени сервера TLS.

Обратите внимание, что этот сайт не требует SNI. Но www.coursera.org требует этого. И если вы вызовете wget с -v —debug (как я явно рекомендовал в своем комментарии!) вы увидите:

Итак, ошибка на самом деле происходит с www.coursera.org Причина в отсутствии поддержки SNI. Вам необходимо обновить свою версию wget.

• Никогда не думал об обновлении wget. Спасибо за подсказку!
• 1 Итак, если мы работаем на сервере RHEL 6 как пользователь без возможности обновления любой пакет, как решить такую ​​проблему?
• @Vitor: если вы используете последнюю версию RHEL 6, вы используете wget-1.12-10. Согласно этой поддержке SNI была перенесена на wget-1.12-4 в 2014 году. Если это не работает для вас, это может быть другой проблемой, поэтому вам следует создать новый вопрос с достаточной детализацией.

Я был в SLES12, и у меня он работал после обновления до wget 1.14, используя —secure-protocol = TLSv1.2 и используя —auth-no-challenge.

• 6 —secure-protocol возможно auto , SSLv2 , SSLv3 или TLSv1 . Нет варианта TLSv1.2
• Но есть вариант —secure-protocol=TLSv1_2 . Думаю, это была просто опечатка.

Один из альтернатив — заменить «https» на «http» в URL-адресе, с которого вы пытаетесь выполнить загрузку, чтобы просто обойти SSL-соединение. Не самое безопасное решение, но в моем случае это сработало.

Вероятно, у вас старая версия wget. Я предлагаю установить wget с помощью Chocolatey, менеджера пакетов для Windows. Это должно дать вам более свежую версию (если не последнюю).

Выполните эту команду после установки Chocolatey (от имени администратора):

У меня была эта проблема на Ubuntu 12.04.3 LTS (я знаю, далеко за пределами EOL . ), и я решил ее:

В основном ваш OpenSSL использует SSLv3, а сайт, к которому вы обращаетесь, не поддерживает этот протокол.

Просто обновите свой wget:

sudo apt-get install wget

Или, если он уже поддерживает другой безопасный протокол, просто добавьте его в качестве аргумента:

wget https://example.com —secure-protocol=PROTOCOL_v1

Ниже приведена команда для загрузки файлов с веб-сайта TLSv1.2.

Источник

Same problem as wget interrupted by a certificate problem:

After do-release-upgrade from 16.04 to 18.01

Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. 
Check your Internet connection or proxy settings

wget https://changelogs.ubuntu.com/meta-release-lts

--2018-09-15 08:03:41--  https://changelogs.ubuntu.com/meta-release-lts
Resolving changelogs.ubuntu.com (changelogs.ubuntu.com)... 91.189.95.15, 2001:67c:1560:8008::11
Connecting to changelogs.ubuntu.com (changelogs.ubuntu.com)|91.189.95.15|:443... connected.
ERROR: cannot verify changelogs.ubuntu.com's certificate, issued by ‘CN=DigiCert SHA2 Secure Server CA,O=DigiCert Inc,C=US’:
  Unable to locally verify the issuer's authority.
To connect to changelogs.ubuntu.com insecurely, use `--no-check-certificate'.

Also (as root):

# update-ca-certificates

Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

# wget https://www.google.com/

--2018-09-16 16:54:31--  https://www.google.com/
Resolving www.google.com (www.google.com)... 216.58.201.164, 2a00:1450:4003:80a::2004
Connecting to www.google.com (www.google.com)|216.58.201.164|:443... connected.
ERROR: cannot verify www.google.com's certificate, issued by ‘CN=Google Internet Authority G3,O=Google Trust Services,C=US’:
  Unable to locally verify the issuer's authority.
To connect to www.google.com insecurely, use `--no-check-certificate'.

Update 2018-10-23:

openssl s_client -connect www.google.com:443 -debug

fails

openssl s_client  -connect www.google.com:443 --debug --CApath /etc/ssl/certs/  

works

 wget https://www.google.com/  --ca-directory=/etc/ssl/certs/ 

works, so why is the default ca-directory not /etc/ssl/certs/? and do I set it?

New Update and solved:

strace -e openat wget https://your-url

I saw that it was using /usr/local/lib/libssl.so.1.1, so I found one openssl installed on /usr/local, and after deleting it, the problem was fixed.

Thanks