top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

SSL Configuration with in Tomcat

+1 vote

I am using tomcat version 5.5.7 in windows 7 Os. My problem is that , After I configure tomcat to use SSL , I get 'Keystore was tampered or incorrect password' error when I start tomcat.

I purchased a certificate from symantec verisign , and they verified the installation was correct and they said they cannot assist me further, as it is not their part.

I tried creating a self signed certificate like this ( ) , still I get same error.

Please help me to resolve this.

posted Oct 2, 2013 by Luv Kumar

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+1 vote

Your version is over eight years old, and Tomcat 5.5 hasn't been supported for quite some time. Move to Tomcat 7 before you do anything else.

answer Oct 2, 2013 by Anderson
+1 vote

Finally I got it worked in my tomcat5. I removed element and configured keystorefile and keystorepass in element. Then It worked for me

answer Oct 3, 2013 by anonymous
If you really are a beginner and staring fresh, then using Tomcat 5.5 is a serious mistake. Tomcat 8 will be emerge from alpha soon and you'll be more than 2 versions out of date.

Honestly, you should completely abandon Tomcat 5.5 and get the latest Tomcat 7.0.x to continue your education.
Similar Questions
0 votes

My project is planning to upgrade to Tomcat 7.0.57 that has the fix for POODLE vulnerability and have the SSL protocol disable by default. We were up till now using the manual configuration change in server.xml in
order to disable use of SSL.

My questions is that after upgrading to Tomcat 7.0.57, is there any similar configuration change available, through which we can re enable SSL protocols again.

Please let me know if my question is not clear.

+2 votes

Does anyone knows how-to disable SSL v3 in older tomcat version, I have tried to variety solution including sslProtocols or sslEnabledProtocols but it both did not work well, the Firefox I am using to test is only select TLS 1 and result is that I were not able to access the site.

Below is the server information:

Server version: Apache Tomcat/6.0.18
Server built: Jul 22 2008 02:00:36
Server number:
OS Name: Windows 2003
OS Version: 5.2
Architecture: x86
JVM Version: 1.6.0-b105
JVM Vendor: Sun Microsystems Inc

+1 vote

In my webapp there's a directory '/admin' that's protected under SSL. Users are forced to use SSL via a security constraint in web.xml. It works great.

As mentioned in the docs and other places, it would be good to prevent SSL everywhere else on the site, but I searched around and couldn't find anything that works.I tried adding another security constraint with transport guarantee set to NONE for url-pattern '/*' but it didn't prevent https access to the site as a whole.

What's the correct way to selectively restrict https to only one area of a webapp?

0 votes

How to use multiple virtual hosts with a single SSL instance running on the standard https port.

+1 vote

I've been off the list for a bit, getting ducks in a row here and everything.

I noticed a number of posts about SSL & TLS security settings lately and I wanted to point out that maintaining your SSL configurations is an on-going processes.

New exploits are discovered and released quite often, and often the fault lies with a cipher and not necessarily an overall SSL/TLS protocol.

So using a cipher list like "all except RC4" is probably not sufficient anymore. And what is secure may depend completely on the SSL/TLS software you use, be it OpenSSL or Java's built in SSL libraries.

For example, with OpenSSL, you should be using 1.0.1t or higher, and even then only TLS1.2 with a handful of ciphers. I'm not sure what the recommended options for java's libraries are at the moment. A really good, free tool is Qualys' SSL Labs server test tool located at: Run that against your implementation and follow its recommendations.

Of course, at the end of the day, it will be up to you and your firm to decide what risks you are willing to take with your SSL communications and whether or not you need to support insecure browsers, i.e. browsers that cannot negotiate up to the most secure protocol and ciphers.