When using Tomcat without a robust web server frontend ( like Apache or Nginx ) to manage SSL connections and sessions. Java keystore problems can produce several misleading error message in browsers. In addition to that, the imported certificate and private key used per website must have the same password/passphrase as the keystore itself and cannot be "blank".
The browser may display a cryptic error message and refuse to open an encrypted data channel using the certificate, resulting in an open http:// connection with the following message in the browser window:
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Keytool does not have a method for importing a third party signed certificate and its private key into a new keystore natively.
The Openssl toolkit can create a Microsoft PCKS12 format cert and private key pair.
The Java keytool tool can then be used to import/convert a PCKS12 storage container into a keystore and set the "keypass" and "storepass" at the same time.
For example, it is common in Red Hat Enterprise Linux to use the /etc/pki/tls directories and genkey utilities from the crypto-utils package to create PEM encoded private key and CSR pairs and receive a signed PEM format CER cert. This is the least friction, most common method known of obtaining SSL certs and is fairly well documented.
The following will produce a keystore that contains the private key and signed cert in a keystore with the private key and keystore pass set to the same value:
Since this keystore is intended to be used with Tomcat, the alias should be "tomcat"# cd /etc/pki/tls# openssl pkcs12 -export -in certs/www.server.com.cer -inkey private//www.server.com.key -out www.server.com.p12 -name tomcat -CAfile certs/ca_bundle.cer -caname root -chain# mv www.server.com.p12 /usr/share/jdk1.7.0/bin/ ; cd /usr/share/jdk1.7.0/bin/# keytool -importkeystore -deststorepass changeit! -destkeypass changeit! -destkeystore tomcat_java.keystore -srckeystore www.server.com.p12 -srcstoretype PKCS12 -srcstorepass changeit! -alias tomcat
Also since the server is now expected to provide the certificate chain, and in the correct order the following steps might be wise; It would be wise to also be aware that bundle files often come with multiple certs in one file and the keytool will silently discard and not import more than one certificate at a time, in which case if the file does contain multiple certificates breaking the file into one file per cert and importing them separately would be advised. The root of the chain possibly appearing as the "last" certificate in the bundled "chain file" and might need to be imported "first" in order to avoid problems with mobilty clients.
# keytool -import -trustcacerts -alias AddTrustExternalCARoot -file ca_bundle3.crt -keystore tomcat_java.keystore# keytool -import -trustcacerts -alias USERTrustRSACA -file ca_bundle2.crt -keystore tomcat_java.keystore# keytool -import -trustcacerts -alias RSAServerCA -file ca_bundle1.crt -keystore tomcat_java.keystore
And finally to address the ciphers problem.
The Tomcat connector ( server.xml ) needs to explicitly "tip toe" about known Common Vulnerabilities and Exploits (CVE)s, this may work like "magic" but the set is carefully crafted around a balance between known vulnerabilities, the capabilities of a jdk without enhanced cipher capabilties and what browsers will allow a connection to be formed with.
<Connector
port="443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150"
SSLEnabled="true"
scheme="https"
keystoreFile="/usr/share/jdk1.7.0/bin/tomcat_java.keystore"
keystorePass="changeit!"
secure="true"
clientAuth="false"
sslProtocol="TLS"
ciphers="Its best to consider carefully whether to forego using the "Free" wisdom and customs gathered and standardized by the more mature and currently very vital and active web server projects like Apache and Nginx. They are constantly being updated and repaired for Zero-Day attacks and exploits.
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA
"
/>
Java is a "language" and does not prioritize "web services" as a daily updated and maintained feature.. by "definition"
Tomcat is almost certainly "guaranteed" to be "Exploitable" the day it is released
To serve the useful purpose of an Example of "What Not To Do.." this has been widely and strongly publicized almost from its inception.
The position has not been changed, regardless of less experienced users promoting propaganda that "that's what they used to say.. it is still True Today .. it is still in the documentation" it speaks highly of programmer experience level to say otherwise.
The AJP and Mod_jk projects explicitly "exist" because of the Java libraries that support them, they are not token projects that serve merely as examples.. they are there for a reason.. whenever "bindings" between projects exist and are maintained for "generations" do be curious and suspicious of why the the High Level of effort is continually put in place to maintain them.. usually unused code would fail over time if it were not actively being used. There Is A Reason.. Be Curious !!
Finally, Java "is a Language" with many aspects that "look like" an operating system, its JVM is not as old or robust.. or as well maintained by "language developers" as dedicated "operating system developers". A person who mows your lawn does not often fix cars as well as they mow lawns.. please keep this analogy in mind.
If "language developers" were to ever devote the same level of energy, effort and accumulated expertise.. you would probably not appreciate the language as much as a language developed by dedicated "language developers" [ Expertise in one area, does not often translate into "Unrelated" Expertise in another area.. to assume so is usually disasterous ]
