Ubuntu 14, Tomcat 7, Java 7
our.crt, our.key und Gd_bundle-g2-g1.crt werden von Godaddy geliefert. Das Bundle enthält 3 Zertifikate (wie aus der Datei ersichtlich).
Beachten Sie, dass unser Schlüssel und CRT ohne Knoten in node.js verwendet wurden.
wir haben einen Schlüsselspeicher aus dem vorhandenen CRT erstellt:
cd /etc/ssl
openssl pkcs12 -export -in our.crt -inkey our.key -out our.p12 -name Tomcat -CAfile Gd_bundle-g2-g1.crt -caname root -chain
Die server.xml lautet wie folgt:
<Server port="8005" shutdown="SHUTDOWN">
<Listener className="org.Apache.catalina.core.JasperListener" />
<Listener className="org.Apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.Apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.Apache.catalina.core.ThreadLocalLeakPreventionListener" />
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container"
type="org.Apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.Apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/Tomcat-users.xml" />
</GlobalNamingResources>
<Service name="Catalina">
<Connector port="80" protocol="HTTP/1.1"
connectionTimeout="20000"
URIEncoding="UTF-8"
redirectPort="8443" />
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="200" scheme="https" secure="true"
keystoreType="PKCS12"
keystoreFile="/etc/ssl/our.p12" keystorePass=""
clientAuth="false" sslProtocol="TLS" />
Wir richten eine lokale Weiterleitung von 443 nach 8443 ein:
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443
Dann probieren Sie https://www.ourserver.com/ourapp
Chrome ergibt: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
curl-Beispiele, die auf einem lokalen Computer ausgeführt werden:
curl -Iv https://www.ourserver.com:8443
* Rebuilt URL to: https://www.ourserver.com:8443/
* Hostname was NOT found in DNS cache
* Trying 1xxxxxxxx...
* Connected to www.ourserver.com (1xxxx) port 8443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS alert, Server hello (2):
* 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
Irgendwelche Ideen?
UPDATE 1
Ich habe versucht, einen neuen Tomcat 7 auf einem neuen Server einzurichten, eine neue Kopie der Zertifikate zu installieren und erhielt die gleiche Fehlermeldung.
Versuchen Sie, das ciphers
-Attribut zu Ihrem Connector-Tag hinzuzufügen
ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"
Wenn dies nicht hilfreich ist, ändern Sie Ihr Protokollattribut von protocol="HTTP/1.1"
in protocol="org.Apache.coyote.http11.Http11Protocol"
.
Weitere Hinweise siehe
Vor kurzem erhielt ich die gleiche Fehlermeldung, als ich versuchte, die Anleitung Bitbucket Server mit Tomcat mithilfe von SSL zu sichern, als ich diese Lösung hier fand.
Sie müssen das Format pkcs12
in Java keystore
konvertieren:
keytool -importkeystore \
-deststorepass changeit -destkeypass changeit \
-destkeystore /path/to/my/keystore.jks \
-srckeystore our.p12 -srcstoretype PKCS12
und in Tomcat gerade eingestellt:
<Connector ...
keystoreFile="/path/to/my/keystore.jks" />
Versuchen Sie, sslProtocol auf "TLSv1, TLSv1.1, TLSv1.2" umzustellen. Möglicherweise möchten Sie SSLv2Hello vor den Testfällen von openssl/curl voranstellen, da einige ältere Bibliotheken das alte Hallo senden möchten, bevor Sie mit der Aufbereitung beginnen.
Ubuntu 14, Tomcat 7, Java 7
Welche exakten Versionen von Tomcat und Java 7?
https://wiki.Apache.org/Tomcat/FAQ/Linux_Unix#Q5
Die server.xml lautet wie folgt:
Sie erwähnen nicht, welche Connector-Implementierung Sie verwenden, aber wenn AprLifecycleListener
aus Ihrer server.xml entfernt wird, bedeutet dies, dass Sie die Implementierung von "Http11Protocol" (auch "BIO") verwenden. Gut. Es sollte in den Startprotokollen sichtbar sein. (Wenn Sie die "APR" -Implementierung verwendet hätten, müsste Ihre Konfiguration sehr unterschiedlich sein).
Eine ungerade URL Die Portnummer sollte dem Servernamen https://www.ourserver.com:8443/ourapp
folgen.
Obwohl die Nachricht "* Rebuilt URL to: https://www.ourserver.com:8443/ " von curl aussieht, scheint sie damit umzugehen.
fehler: 14077410: SSL-Routinen: SSL23_GET_SERVER_HELLO: Fehler beim Handshake für den Alarm "sslv3"
In Tomcat 7.0.57 und höher ist das SSLv3-Protokoll aufgrund einer veröffentlichten SSL-Sicherheitsanfälligkeit standardmäßig deaktiviert (CVE-2014-3566 POODLE). Durch die Filterung der SSL-Protokolle werden alle Protokolle deaktiviert, die "SSL" im Namen enthalten, einschließlich SSLv2Hello. Offensichtlich versucht curl, sich hier mit SSLv2Hello Handshake zu verbinden ("SSL23" in seiner Nachricht).
Sie benötigen einen Client, der das TLS-Protokoll unterstützt (TLS 1.0, 1.1 oder 1.2).
https://wiki.Apache.org/Tomcat/Security/POODLE
https://wiki.Apache.org/Tomcat/Security/Ciphers
Versuchen Sie, sslProtocol auf "TLSv1, TLSv1.1, TLSv1.2" umzustellen. Möglicherweise möchten Sie SSLv2Hello vor den Testfällen von openssl/curl voranstellen, da einige ältere Bibliotheken das alte Hallo senden möchten, bevor Sie mit der Aushandlung beginnen.
Gut, aber mit einer Korrektur: Das obige ist ein Wert für das sslEnabledProtocols
-Attribut (nicht sslProtocol
).
Sie können versuchen, sich mit OpenSSL zu verbinden,
openssl s_client -connect hostname:8443
openssl s_client -connect hostname:8443 -tls1
OpenSSL Doc: https://openssl.org/docs/apps/s_client.html
Konfigurationsreferenz für Tomcat 7: http://Tomcat.Apache.org/Tomcat-7.0-doc/config/http.html#SSL_Support_-_BIO_and_NIO
Ich hatte das gleiche Problem und ich habe es gelöst.
Bitte fügen Sie Ihrem Keystore ein Passwort hinzu - und es funktioniert!