Secure connection fatal error 40

SSL fatal error, handshake failure 40

Client sends the «Client Hello» msg with those ciphers included in the cipher suite.

In the server.xml none of these ciphers appear. Here is the catalina entry:

Connector port=»4443″ SSLEnabled=»true» acceptCount=»20000″ maxThreads=»5000″ allowTrace=»false» scheme=»https» secure=»true» clientAuth=»false» sslProtocol=»TLS» keystoreFile=»/usr/local/tomcat6/conf/Default-Cert.p12″ keystoreType=»PKCS12″ keystorePass=»uuuuuu» ciphers=». «

and the ciphers are SSL_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

Server sends “Server Hello” selecting “TLS_RSA_WITH_AES_128_CBC_SHA 0x002f)” and after

1,5 milliseconds Server sends a fatal alert (Handshake Failure (40)).

Can we explain the handshake failure? Is this due to the fact that TLS_RSA_WITH_AES_128_CBC_SHA is not included in the client cipher list?

-servername . -tls1 and -servername ensure SNI is used.

-cipher «AES128-SHA» and $ openssl s_client -tls1 -connect :

1 Answer 1

SSL fatal error, handshake failure 40 indicates the secure connection failed to establish because the client and the server couldn’t agree on connection settings. Usually because the client or the server is way too old, only supporting removed protocols/ciphers.

In historic order, the protocols are SSLv2, SSLv3, TLS 1.0, TLS 1.2, TLS 1.3.

From the debugging info and cipher names you gave:

• The server only did SSL, don’t know which subversion. SSL was obsolete since before the question was opened (before 2015), replaced by TLS.
• The client wanted TLS. In 2015 it could have been TLS 1.0 and/or TLS 1.2.

In this specific case the server was running on abandoned SSL and in dire need of an upgrade. Looks like a tomcat 6 on java 6, indeed obsolete at the time (2015).

If you’re reading this in 2020 or later. The absolute minimum version of java for https to work is java 8 (full support for TLS 1.2).

Источник

Opera: Secure connection: fatal error (40) from server.

Opera-developer — это chromium в подправленной оболочке. Синхронизация с линк-сервером не работает. Вручную переносить закладки, пароли и куки?

может всё-таки можно поменять тип шифрования на что-то более распространённое? все сайты на https работают, кроме нашего!

я так понимаю, что проблема в из-за ecdsa. может просто dsa сделать?

Заработало — Opera 26.0 , с нее и сообщаю !

Страница на https://archlinux.org.ru/forum/forum/5/ временно недоступна или перемещена на новый веб-адрес.

я так понимаю, что проблема в из-за ecdsa. может просто dsa сделать?

Всем доброго времени суток!

Сообщаю о том, что есть решение как починить своими силами работу сертификата Cloudflare, иными словами заставить работать archlinux.org.ru (и, возможно другие сайты, с сертификатами изданными Cloudflare) в настоящем браузере Opera (я имею ввиду 12.x версии)! И не придется страдать мазохизмом, пользуясь клоном гуглхрома под брендом Оперы или открывать сайт в другом браузере.

1. Скачать zip-архив отсюда https://app.box.com/s/5p00vediw04ds7xkxwgg . В архиве находятся обновленные корневые сертификаты одного из девелоперских билдов 12-й версии (Presto-ветки, до перехода на хром).

2. Открыть каталог настроек Оперы (путь см. в Help — About — Opera directory) . Создать резервные копии файлов (это на всякий случай):
oprand.dat
opuntrust.dat
optrust.dat
opcacrt6.dat
opicacrt6.dat
opcert6.dat
opssl6.dat
optrb.dat

Вообщем сделать резервные копии всех файлов op*.dat

3. Закрыть Opera

4. Распаковать содержимое архива ROOT_cert_patch_cloudfire__cert_old.zip в каталог пользовательских настроек Opera с заменой файлов.

5. Запустить Opera 12. Теперь можно пользоваться archlinux.org.ru в любимом браузере.
P.S. Совет взят с форума поклонников браузера Опера — operafan.net. Авторство идеи не мое. Инструкция моя.

© 2006-2023, Русскоязычное сообщество Arch Linux.
Название и логотип Arch Linux ™ являются признанными торговыми марками.
Linux ® — зарегистрированная торговая марка Linus Torvalds и LMI.

Источник

SSL fatal error, handshake failure 40

Client sends the «Client Hello» msg with those ciphers included in the cipher suite.

In the server.xml none of these ciphers appear. Here is the catalina entry:

Connector port=»4443″ SSLEnabled=»true» acceptCount=»20000″ maxThreads=»5000″ allowTrace=»false» scheme=»https» secure=»true» clientAuth=»false» sslProtocol=»TLS» keystoreFile=»/usr/local/tomcat6/conf/Default-Cert.p12″ keystoreType=»PKCS12″ keystorePass=»uuuuuu» ciphers=». «

and the ciphers are SSL_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

Server sends “Server Hello” selecting “TLS_RSA_WITH_AES_128_CBC_SHA 0x002f)” and after

1,5 milliseconds Server sends a fatal alert (Handshake Failure (40)).

Can we explain the handshake failure? Is this due to the fact that TLS_RSA_WITH_AES_128_CBC_SHA is not included in the client cipher list?

-servername . -tls1 and -servername ensure SNI is used.

-cipher «AES128-SHA» and $ openssl s_client -tls1 -connect :

1 Answer 1

SSL fatal error, handshake failure 40 indicates the secure connection failed to establish because the client and the server couldn’t agree on connection settings. Usually because the client or the server is way too old, only supporting removed protocols/ciphers.

In historic order, the protocols are SSLv2, SSLv3, TLS 1.0, TLS 1.2, TLS 1.3.

From the debugging info and cipher names you gave:

• The server only did SSL, don’t know which subversion. SSL was obsolete since before the question was opened (before 2015), replaced by TLS.
• The client wanted TLS. In 2015 it could have been TLS 1.0 and/or TLS 1.2.

In this specific case the server was running on abandoned SSL and in dire need of an upgrade. Looks like a tomcat 6 on java 6, indeed obsolete at the time (2015).

If you’re reading this in 2020 or later. The absolute minimum version of java for https to work is java 8 (full support for TLS 1.2).

Источник

Basics for Computer Nerds!

When I needed to access a secure page (HTTPS) from Internet Explorer 11 on a Windows 2008 R2 server, I always got a «Page cannot be displayed» error. I could, though, access that page from another machine or another browser on the same server.

Looking in the Event Viewer I saw:

Log Name: System
Source: Schannel
Date: 05.01.2015 12:11:58
Event ID: 36887
Task Category: None
Level: Error
Keywords:
User: SYSTEM

Description:
The following fatal alert was received: 40.

Schannel error 40 means: SSL3_ALERT_HANDSHAKE_FAILURE

So I checked with SSL Labs which Ciphers my browser offers:

It looks like it was offering very old ciphers first

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
.

I checked the following Registry key:

It contained exactly the same old ciphers first!

So I looked at a Windows 7 client that was working and saw that there were the newer and more secure ciphers listed first:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
.

I copied the Registry entry of the working machine to the server, rebooted the server and — Bingo — I could now access the web page.

Источник

Fatal error 40 from server

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I encounter the follow error when surfing to a https website: Schannel error 36887 fatal error 40.

The details of the event are:

Process ID 696 points to SamSs and Netlogon.

The OS is Windows 7 SP1.

The browser is currently IE 8 build 7601.17514. The security protocols SSL 3 and TLS1.2 are enabled, the others are disabled.

Have someone an idea what the problem could be?

Answers

How about other computer? Only this Windows 7 SP1 got the issue?

Is the issue regarding the use of a certificate that are failing?

Is this issue regarding an application or service that relies on certificates?

In order to find which process result this error, I suggeset you use the Network Monitor to caputer the network trace both on the problematic computer and the working one. Please download the NetMon from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4865

After you capture the trace, upload them to your SkyDrive, put it in a public folder and reply a folder link here, I’ll check it later.

Before analyzing the network trace, please also compare the following keys between the working and non-working clients:

Additionally, when certificate negotiation process got failed could also cause this issue. We can check it in the network trace.

TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tnmff@microsoft.com

This posting is provided «AS IS» with no warranties, and confers no rights. | Please remember to click «Mark as Answer» on the post that helps you, and to click «Unmark as Answer» if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

How about other computer? Only this Windows 7 SP1 got the issue?

Is the issue regarding the use of a certificate that are failing?

Is this issue regarding an application or service that relies on certificates?

In order to find which process result this error, I suggeset you use the Network Monitor to caputer the network trace both on the problematic computer and the working one. Please download the NetMon from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=4865

After you capture the trace, upload them to your SkyDrive, put it in a public folder and reply a folder link here, I’ll check it later.

Before analyzing the network trace, please also compare the following keys between the working and non-working clients:

Additionally, when certificate negotiation process got failed could also cause this issue. We can check it in the network trace.

TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tnmff@microsoft.com

This posting is provided «AS IS» with no warranties, and confers no rights. | Please remember to click «Mark as Answer» on the post that helps you, and to click «Unmark as Answer» if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Please feel free to give us any update.

TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tnmff@microsoft.com

This posting is provided «AS IS» with no warranties, and confers no rights. | Please remember to click «Mark as Answer» on the post that helps you, and to click «Unmark as Answer» if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios. If the issue still persists, please feel free to reply this post directly so we will be notified to follow it up.

Thanks for your understanding and cooperation!

TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tnmff@microsoft.com

This posting is provided «AS IS» with no warranties, and confers no rights. | Please remember to click «Mark as Answer» on the post that helps you, and to click «Unmark as Answer» if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Источник

Opera: Secure connection: fatal error (40) from server.

Opera-developer — это chromium в подправленной оболочке. Синхронизация с линк-сервером не работает. Вручную переносить закладки, пароли и куки?

может всё-таки можно поменять тип шифрования на что-то более распространённое? все сайты на https работают, кроме нашего!

я так понимаю, что проблема в из-за ecdsa. может просто dsa сделать?

Заработало — Opera 26.0 , с нее и сообщаю !

Страница на https://archlinux.org.ru/forum/forum/5/ временно недоступна или перемещена на новый веб-адрес.

я так понимаю, что проблема в из-за ecdsa. может просто dsa сделать?

Всем доброго времени суток!

Сообщаю о том, что есть решение как починить своими силами работу сертификата Cloudflare, иными словами заставить работать archlinux.org.ru (и, возможно другие сайты, с сертификатами изданными Cloudflare) в настоящем браузере Opera (я имею ввиду 12.x версии)! И не придется страдать мазохизмом, пользуясь клоном гуглхрома под брендом Оперы или открывать сайт в другом браузере.

1. Скачать zip-архив отсюда https://app.box.com/s/5p00vediw04ds7xkxwgg . В архиве находятся обновленные корневые сертификаты одного из девелоперских билдов 12-й версии (Presto-ветки, до перехода на хром).

2. Открыть каталог настроек Оперы (путь см. в Help — About — Opera directory) . Создать резервные копии файлов (это на всякий случай):
oprand.dat
opuntrust.dat
optrust.dat
opcacrt6.dat
opicacrt6.dat
opcert6.dat
opssl6.dat
optrb.dat

Вообщем сделать резервные копии всех файлов op*.dat

3. Закрыть Opera

4. Распаковать содержимое архива ROOT_cert_patch_cloudfire__cert_old.zip в каталог пользовательских настроек Opera с заменой файлов.

5. Запустить Opera 12. Теперь можно пользоваться archlinux.org.ru в любимом браузере.
P.S. Совет взят с форума поклонников браузера Опера — operafan.net. Авторство идеи не мое. Инструкция моя.

© 2006-2023, Русскоязычное сообщество Arch Linux.
Название и логотип Arch Linux ™ являются признанными торговыми марками.
Linux ® — зарегистрированная торговая марка Linus Torvalds и LMI.

Источник

fatal error: 40: no cipher suites in common enabling SSL #1576

Comments

RobertoBoni67 commented Apr 1, 2021 •

I have to enable SSL in a spring reactive application using Netty as HTTPS server.

For test purpose, I made a very simple spring boot reactive application with a very simple rest controller that simply returns «Hello World».

I get the error «fatal error: 40: no cipher suites in common» in SSL handshake while connecting to the Netty server even from a browser (chrome and firefox).

Here is the full trace of the SSL handshake:

I use self signed certificates made with openssl and then converted in JKS.

I tryed different versions of spring-boot and the latest that works is spring-boot 2.2.1.RELEASE: with this versions the SSL handshake is successfully completed and all is working fine, but with any newer versions I tryed, I always get the no cipher suites in common error.

I also used nmap to do an SSL scan and it reports certificates and ciphers correctly with the working versions, but it doesn’t report anything with the versions that gives the no ciphers error. it seems that that this server dosn’t have any chipher available.

It seems a problem related to Netty and SSL.

I am using «jdk1.8.0_161», but I also used java 11 with the same result.

Does anyone have a hint for this behaviour?

The text was updated successfully, but these errors were encountered:

Источник

Fatal error 40 from server

Since few hours ago I no longer can use any sites that use HTTPS, I get:

Secure connection: fatal error (1578)
Could not verify the signatures for the site certificate’s revocation information.

I’ve tried switching to new Opera but it is unusable with tons of missing essential features that true Opera had.

Anything I can do with Opera 12 to fix this problem with https connections?

Have you tried clearing the cache ?.

Just did, getting

Secure connection: fatal error (1066)
Unable to verify the website’s identity (OCSP error).

now. I think I had it before as well though.

Some sites (like gmail) now work, some don’t with error above in this same post. (https://www.reddit.com/login)

Secure connection: fatal error (1066)

Unable to verify the website’s identity (OCSP error).

The response from the online certificate validation (OCSP) server was too old.

What version of Windows are you using ?.

We had that with Vivaldi.net also, but it seems to have fixed itself for now .

I have problem HTTPS too
fatal error (1066)
Unable to verify the website’s identity (OCSP error).
The response from the online certificate validation (OCSP) server was too old.
Not at all sites but many. What can I do?

@ktala35 Yes, i get such problem on wireshark.org, too! On Windows and Linux.

What version of Windows are you using ?.

Windows 7 64 bit.

— How I (temporarily) fixed the problem —

I went to opera:config => Security Prefs => Disabled «OCSP Validate Certificates».

Now I can at least access https sites.

I went to opera:config => Security Prefs => Disabled «OCSP Validate Certificates».

Yes, a temporary solution! because .
this may lower security, missing revoced certificates.

I also get OCSP error when trying to access this site: https://ylilauta.org/

I’ve been having this problem for the last few days, too, on numerous websites that other browsers have no trouble with. I realize they may not be very interested in Presto-based Opera any more, but this is a security issue, so I really, really hope they fix this.

Thanks for the obscure fix for the OCSP flavor. There’s another new issue with some sites though:
Secure connection: fatal error (40) from server (Failed to connect to server. The reason may be that the encryption methods supported by the server are not enabled in the security preferences_.

Still trying to figure that one out. This Russian thread says that it relates to Cloudfare. Apparently, the response from them is: «Yes, the Opera problem is a known issue and should be fixed on their end.»
https://archlinux.org.ru/forum/topic/14019

So, yes, the problem I mentioned last time, error 40, is because of CloudFlare’s new free Universal SSL service, which requires a digital signature algorithm called ECDSA. As you can see by running this test, the signature algorithms section for Opera is blank:
https://www.ssllabs.com/ssltest/viewMyClient.html

I engaged in an extended tech support back-and-forth with CloudFlare, and that’s a hopeless avenue, trust me. Even their supported browsers list is wrong:
https://www.cloudflare.com/ssl#browsers

BTW, TLS 1.1 is not enabled by default in Opera, but it’s easily enabled in Prefs. It doesn’t help though.

So, if Universal SSL catches on, it’s the end of the Opera 12 line. So far that I’ve found, it’s limited to obscure sites like the one I mentioned last time and this one:
https://dabr.eu

Fortunately, CloudFlare’s paid service doesn’t seem to have the issue. If it did, Opera 12 would have already been over.

Fyi, Opera 8.54 works fine there, after you accept RSA certificate. Same with IE7.

Fyi, Opera 8.54 works fine there, after you accept RSA certificate. Same with IE7.

That’s incredible. I wonder why.

Has anyone figured out a workaround for Error 40 yet, or at least an explanation for how an ancient version of Opera (apparently) works yet v12 doesn’t? Sites that use ECDSA continue to grow.

In checking the https://www.ssllabs.com/ssltest/viewMyClient.html site, if I employ Opera 12.14 with TLS 1.2 (and TLS 1.1 and 1) enabled, the site identifies signature algorithms of: SHA256/RSA, SHA1/RSA, MD5/RSA, SHA1/DSA. If I disable TLS 1.2, leaving enabled TLS 1.1 (and TLS 1), and revisit the site, it indeed identifies no available signature algorithms and warns the visitor about his browser not supporting TLS 1.2. (Performance is identical using Opera 11.52). It appears that the site and/or Opera doesn’t provide for signature algorithms at TLS 1.1 or below.

Also, FWIW and from what I can determine, Opera 6.x through 8.x employed protocols SSL2, SSL3, and TLS 1.0. Opera 9.x employed SSL 2 (but was not set as default), SSL3, TLS 1.0, and added TLS 1.1 support. Somewhere after 9.x (either with 10.x or 11.x), SSL 2 was dropped entirely and TLS 1.2 support was added. that being the situation with my copies of Opera 11.x and 12.x. (My Opera 10.x copy has ‘gone away’, so I can’t check it.)

Signature algorithms SHA256/ECDSA, SHA384/ECDSA, and SHA1/ECDSA are probably the ones that are key to this (and maybe «Elliptic curves» too, whatever that is) for the Error 40 sites to actually work. Though I find it very hard to believe that those magically exist in 8.54.

Источник

Basics for Computer Nerds!

When I needed to access a secure page (HTTPS) from Internet Explorer 11 on a Windows 2008 R2 server, I always got a «Page cannot be displayed» error. I could, though, access that page from another machine or another browser on the same server.

Looking in the Event Viewer I saw:

Log Name: System
Source: Schannel
Date: 05.01.2015 12:11:58
Event ID: 36887
Task Category: None
Level: Error
Keywords:
User: SYSTEM

Description:
The following fatal alert was received: 40.

Schannel error 40 means: SSL3_ALERT_HANDSHAKE_FAILURE

So I checked with SSL Labs which Ciphers my browser offers:

It looks like it was offering very old ciphers first

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
.

I checked the following Registry key:

It contained exactly the same old ciphers first!

So I looked at a Windows 7 client that was working and saw that there were the newer and more secure ciphers listed first:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
.

I copied the Registry entry of the working machine to the server, rebooted the server and — Bingo — I could now access the web page.

Источник

Как исправить неустранимую ошибку SChannel 40?

Защищенный канал SChannel (Secure Channel) включает ряд протоколов безопасности, которые обеспечивают зашифрованную аутентификацию и безопасную передачи данных. Однако в некоторых случаях не удается подключиться к определенным сайтам HTTPS через Internet Explorer, при этом в журнале событий видим, что от источника SChannel «получено следующее предупреждение о неустранимой ошибке: 40». Также в окне просмотра событий можем наблюдать сбой с кодом событии 36887 «неустранимое предупреждение 40», которое возникает после некоторых обновлений NVIDIA.

Чем вызвана ошибка?

Неустранимая ошибка возникает при установке безопасного соединения в случае, когда обнаружены несоответствия во время обмена рукопожатиями SSL/TLS. Как было указано, в установке безопасного соединения SChannel отказывают только определенные сайты. Проблема в основном возникает в Internet Explorer.

Кроме того, с неустранимой ошибкой 40 можно столкнуться в ходе обновления драйверов NVIDIA из приложения GeForce Experience.

Удаление приложения GFE

Ошибка может произойти в ходе автоматического обновления драйвера видеокарты NVIDIA через приложение GeForce Experience. По отзывам пользователей, им удалось ее устранить путем удаления GFE или обновлением до последней версии.

Если удалили приложение, попробуйте заново его установить и посмотрите, возвращается ли ошибка.

Откройте раздел «Программы и компоненты» командой appwiz.cpl , запущенной из окна «Выполнить» (Win + R).

Найдите в списке установленных программ GeForce Experience. Щелкните на ней правой кнопкой мыши и выберите «Удалить».

Следуйте инструкция на экране до завершения удаления.

Включение поддержки шифра RC4 в Internet Explorer

С неустранимой ошибкой SChannel с кодом 40 можно столкнуться при обращении к определенному сайту, когда у браузера отключена поддержка потокового шифра RC4, который используется в протоколах SSl и TSL. В этом случае нужно отключить политику алгоритмов FIPS, чтобы заставить работать RC4.

Откройте Редактор реестра командой regedit , запущенной из окна «Выполнить».

На левой панели перейдите по пути:

Найдите раздел FipsAlgorithmPolicy. Щелкните правой кнопкой мыши на параметр Enabled и выберите «Изменить». Измените его значение с 1 на 0.

Сохраните изменения, и перезагрузите компьютер.

Источник