curl: Unknown SSL protocol error in connection
Ich versuche, eine Verbindung von einem server (A) in AWS auf einen anderen server (B) in AWS mit Tomcat 7 + SSL.
Server Ein:
- Ubuntu 14.04
- OpenSSL 1.0.1 f
Server B:
- Ubuntu 13.04
- Tomcat 7
- OpenSSL 1.0.1 c
- SSL-Zertifikat
Ich versuche, den folgenden Befehl im server Ein:
curl https://Server.B -v
Und ich bekomme die folgende exception:
* Connection #0 to host test.salespredict.com left intact
yakirm@ip-10-214-10-178:~$ curl https://Server.B.com -v
* Rebuilt URL to: https://Server.B.com/
* Hostname was NOT found in DNS cache
* Trying 54.245.81.*...
* Connected to Server.B.com (54.245.81.*) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to Server.B.com:443
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to Server.B.com:443
Ich versucht, zu überprüfen, mit OpenSSL
openssl s_client -connect Server.B.Address:443
Bekomme ich das folgende Ergebnis:
CONNECTED(00000003)
140284858304160:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 307 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Wenn ich versuche eine Verbindung von meinem eigenen computer aus (OS X Mavericks), den curl Erfolg, aber die openssl-Befehl zurück das gleiche.
BTW
Wenn ich mich versuche:
curl https://Server.B -v -ssl3
Arbeit vom Server Ein, aber ich will nicht angeben, das SSL-Protokoll.
Bearbeiten
Server B - Tomcat-Konfiguration:
<Connector SSLEnabled="true" acceptCount="100" clientAuth="false" disableUploadTimeout="true"
enableLookups="true" maxThreads="200" port="443" keystoreFile="/var/lib/tomcat7/conf/Path/Path_keystore" keystorePass="******" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https"
secure="true" sslProtocol="TLS" />
Nur beachten Sie, dass "-ssl3" ist nicht gleich "--sslv3" aber das gleiche wie die -s-s -l -3 ...
InformationsquelleAutor Yakiros | 2014-10-21
Du musst angemeldet sein, um einen Kommentar abzugeben.
Den wichtigsten Unterschied zwischen Einstellung --sslv3 Einstellung nicht und es ist, dass der client nicht angekündigt den support für Versionen höher als SSL3.0 in den ersten ClientHello-Nachricht. In der Regel client und server einigen sich auf eine version, die von beiden Seiten unterstützt, so dass es richtig ist für den client zu verkünden, die besten SSL-version, die es unterstützt.
Sieht es aus wie, dass in Ihrem Fall sind Sie mit einer situation konfrontiert, wo der server (oder eine middlebox) wird nicht nur nicht in der Lage zu sprechen neuere TLS-Versionen, aber die ist auch nicht in der Lage, Angebot mit SSL 3.0 richtig, denn es ist verreckt, wenn der Kunde kündigt den support für neuere Versionen. Da die server-software selbst ist nicht alt Aussehen, haben Sie ein wirklich seltsam, server-setup oder einige middlebox (z.B. load-balancer, firewall...), die nicht in der Lage ist umzugehen mit der richtigen TLS.
Mehr Informationen möglich sein könnte, wenn Sie die post mehr Informationen über den server. Auch Sie könnte prüfen, die server gegen SSLLabs.
EDIT: wie Es aussieht ist der server unterstützt TLS1.* aber einfach trennt, wenn der client bietet eine
ECDHE-RSA-AES256-SHA cipher. Mit
openssl s_client -cipher 'ALL:!ECDHE-RSA-AES256-SHA'
funktioniert wiecurl --ciphers 'ALL:!ECDHE-RSA-AES256-SHA'
. Ich nehme an, dies ist ein problem auf der server-Seite - vielleicht haben Sie konfiguriert Chiffren, die in der Realität nicht unterstützt werden durch die Implementierung von SSL in tomcat (was nicht OpenSSL, weil Java hat seine eigene Implementierung) und Java verreckt, wenn er versucht, Sie zu benutzen.Haben Sie versucht, zu überprüfen, den server gegen ssllabs, wie ich vermutete?
Ja, ich hab 100 Zertifikat, 90-Protokoll-Unterstützung, 40 in key exchange und 60 in Verschlüsselungsstärke (werde es fix in die nächste Verlängerung...). In der Handshake-Simulation hab ich fast alle von Ihnen Erfolgreich... (die meisten android fehlgeschlagen)...
Würde es ein problem sein, nur veröffentlichen den Namen der Seite hier? Es ist wirklich schwer, ein problem zu Debuggen mit nur vage Informationen: die Prozent-Bewertungen sagen nichts über die Probleme, die Sie entdeckt auf der Website.
Siehe edit - ich denke, das ist eine Fehlkonfiguration auf dem Server Ende oder ist das ein bug in Java.
InformationsquelleAutor Steffen Ullrich