7/21/2015

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 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"

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.

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.

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.

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 ]

7/05/2015

Tomcat is a java Servlet, JSP web service provider. Red Hat Enterprise Linux doesn't install all of it without enabling the Optional Subscription Channel after RHN registration. Also an unresolved RPM java-gcj-compat requirement installs Java 1.5.0 gcj even if it is not used for running Tomcat.

The 'provides' tag was not added to subsequent newer versions of java as the gcj was gcj specific and is now for all intents and purposes retired. Sun, Oracle, IBM maintainers have no reason to add in this tag as a 'provides' and thus to satisfy the requirement pulls in the only java that satisfies it.. 1.5.0

There are ['ways'] of tricking the rpm dependency database into thinking it already has this requirement satisfied.. but they are not supported or approved by Red Hat.

Installing Tomcat without enabling the "Optional Subscription Channel" in RHN will result in a Tomcat service which has broken dependencies between java classes and java services in code written for the Tomcat service.

In particular the following package is only available from the "Optional Channel"

jakarta-taglibs-standard rhel-x86_64-server-optional-6

Pulling in Java 1.5.0 is suboptimal because Java 1.5.0 is no longer supported by its upstream provider.

However Java 1.8.0 changed and removed many of the java classes in use by a large portion of the web service code in common use today (i.e. Hashmaps).

Therefore it is more desirable to install Java 1.6.0 or Java 1.7.0

However while this is possible (and because the Alternatives symlinking will result in Tomcat running on the designated version of Java once it is installed) java 1.5.0 cannot be removed with the YUM package manager without causing a catastrophic "unwinding" that removes all packages that have the java-gcj-compat requirement.

To paraphrase the most recent statement from bug 1175457

2015-05-12

This bug is not fixed, however a workaround is provided for rhel7.

The true fix will probably never go into rhel6

With these issues in mind the barest base install of Tomcat on RHEL 6.6 can be made with the command:

One reason is that these other packages pull in even more dependencies for supporting the Example and Sample JSP and Servlet applications, which "people tend to install tomcat because they want to serve JSP and Servlet applications.."

If you install only the group web-servlet, your very secure.. but most of your JSP and Servlet apps will not work unless you selectively install supporting packaged versions of support software for JSP and Servlet apps. Kind of a knock on side-effect. Figuring out which packages contain those support services.. is "fun"

Upon enabling the Optional Channel and installing all of the packages, Tomcat behaves more like a freshly compiled source code distribution.

By installing an alternate version of java [before] the java_1.5.0 version is pulled in by a dependency (i.e. on a freshly installed server) the later version of java will take priority and keep the alternatives pointers fixed on the newer version of java [ alternatively the "alternatives" command can be used to manually adjust the pointers, however its just easier to install a different java version before 1.5.0 is pulled in ] [ the non-devel package will pull in only the java runtimes JRE, the "-devel" package will pull in the java development kit javac compiler JDK which could be useful ]

The APR, OpenSSL, JNI - libtcnative.so or tomcat-native component is apparently not available as a packaged option on RHEL6. While facility to accomodate it was made in the /etc/sysconfig/tomcat6 file under JAVA_OPTS= it was never packaged for the x86_64 architecture.

It can in theory be compiled and inserted into the /usr/lib64 path "since it is in fact a C" library. But then you run the risk of further maintenance addressing CVEs and other Security audits.

For RHEL7 and Tomcat 7.0 it appears libtcnative may be available as a packaged option.

EPEL and RHSCL also do not appear to offer much support for Tomcat6 on RHEL6.

JBoss however, if contracted and installed, does appear to have a libtcnative however that is not to my knowlege a generally supported option unless you are running that platform.