[PJUG Javamail] Having security (SSL) issues moving tomcat from one host computer to another

Rob Tanner rtanner at linfield.edu
Thu Sep 13 21:04:57 UTC 2007


Bill,

The problem still persists.  I tried using a different JDK and also got 
the certificate re-issued.  No changes at all.  Also, what is 
"NONEwithRSA"?  The certificate is a PKCS#7 chain and the signature 
algorithms are SHA1withRSA and MD5withRSA.  Where does the NONEwithRSA 
come from.

BTW: who all am I going to see up in Seattle next week?

Thanks,
Rob

Bill Jackson said the following on 09/11/2007 03:55 PM:
> Hi Rob,
>
>     What is the JDK/JRE version you're using on the new system?  
> Looking at the stack trace below, Signature.getInstance (which even 
> has a special case for NONEwithRSA) should be finding 
> sun.security.rsa.RSASignature, which is in jre/lib/rt.jar.  This 
> suggests that the provider is just not being registered; can you paste 
> the "security.provider" property list from 
> jre/lib/security/java.security?  One of the providers should be 
> "sun.security.rsa.SunRsaSign".  You could also diff that file between 
> the two systems...
>
> Cheers,
> -Bill
>
>
> Joe Hoffman wrote:
>> Rob,
>>
>> Good point, I agree, you would expect the client to simply be 
>> prompted to accept the non-matching cert.
>>
>> Idea #2:  The server.xml file was changed.  Did you diff them?
>>
>> Idea #3: You had something running on the other box which provided an 
>> RSA Private key impl, which was being  used by Tomcat.
>>
>> Sorry, I"m out of ideas.
>>
>> </bad ideas>
>>
>> joe
>>
>>
>> On Sep 11, 2007, at 3:09 PM, Rob Tanner wrote:
>>
>>> Joe,
>>>
>>> The issue with the host names should be a non-issue with regard to 
>>> the problem I'm currently having.  I've dealt with that issue a 
>>> number of times when moving system around and all that happens is 
>>> that the browser brings up a dialog box with an option to accept the 
>>> non-matching certificate either for the single session of permanently.
>>>
>>> I to set the log level to debug in log4j.properties and now I 
>>> actually have an error log to share.  But, it makes no sense to me 
>>> because I am using (as far as I can tell) an identical runtime on 
>>> both the original host machine and the machine I'm moving over to.  
>>> And the key file is one both machines is identical (did an md5hash 
>>> just to make sure).  Unfortunately, I'm dealing here in an area 
>>> outside of my expertise and so I have no idea what the real problem 
>>> might be. 
>>>
>>> Do these stack traces ring any bells?
>>>
>>>
>>> DEBUG http-10.171.255.17-443-Processor25 
>>> org.apache.tomcat.util.net.PoolTcpEndpoint - Handshake failed
>>> javax.net.ssl.SSLException: Error generating DH server key exchange
>>>         at 
>>> com.sun.net.ssl.internal.ssl.Handshaker.throwSSLException(Handshaker.java:907)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:556)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:178)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:815)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1025)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1038)
>>>         at 
>>> org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:120)
>>>         at 
>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:521)
>>>         at 
>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
>>>         at 
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
>>>         at java.lang.Thread.run(Thread.java:595)
>>> Caused by: java.security.InvalidKeyException: No installed provider 
>>> supports this key: sun.security.rsa.RSAPrivateCrtKeyImpl
>>>         at 
>>> java.security.Signature$Delegate.chooseProvider(Signature.java:1059)
>>>         at 
>>> java.security.Signature$Delegate.engineInitSign(Signature.java:1109)
>>>         at java.security.Signature.initSign(Signature.java:503)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.HandshakeMessage$DH_ServerKeyExchange.<init>(HandshakeMessage.java:671)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:550)
>>>         ... 11 more
>>> Caused by: java.security.NoSuchAlgorithmException: NONEwithRSA 
>>> Signature not available
>>>         at java.security.Signature.getInstance(Signature.java:208)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.JsseJce.getSignature(JsseJce.java:104)
>>>         at 
>>> com.sun.net.ssl.internal.ssl.RSASignature.<init>(RSASignature.java:45)
>>>         at 
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>>         at 
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>>>         at 
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>>>         at 
>>> java.lang.reflect.Constructor.newInstance(Constructor.java:494)
>>>         at java.lang.Class.newInstance0(Class.java:350)
>>>         at java.lang.Class.newInstance(Class.java:303)
>>>         at 
>>> java.security.Provider$Service.newInstance(Provider.java:1075)
>>>         at 
>>> java.security.Signature$Delegate.newInstance(Signature.java:941)
>>>         at 
>>> java.security.Signature$Delegate.chooseProvider(Signature.java:1035)
>>>         ... 15 more
>>>
>>>
>>>
>>> Joe Hoffman said the following on 09/11/2007 11:05 AM:
>>>> Rob,
>>>>
>>>> I assume your SSL certs are for a specific host.  If self 
>>>> generated, just generate them again.  If they are real certs (From 
>>>> a CA), then you'll have to have them generated again for the new 
>>>> hostname.
>>>>
>>>> </guess>
>>>>
>>>> joe
>>>>
>>>> On Sep 11, 2007, at 10:51 AM, Rob Tanner wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm wondering if any has ever seen this and how did they fix it.  
>>>>> I have a production tomcat server (v5.5.23) that I need to move to 
>>>>> another host system.  I copied over the full installation and made 
>>>>> sure I was using the same version of the runtime (jdk1.5.0_03).  
>>>>> But when I try to access a secured page on the new host I get the 
>>>>> following error:
>>>>>
>>>>>  >> Firefox can't connect securely to <sitename> because the site 
>>>>> uses a security protocol which isn't enabled.
>>>>>
>>>>> All of the jar files I use are in jre/lib/ext and they are the 
>>>>> same between both servers.  Any ideas?
>>>>>
>>>>> -- Rob
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Web Site - http://www.pjug.org/
>>>>> Javamail mailing list
>>>>> Javamail at pjug.org <mailto:Javamail at pjug.org>
>>>>> http://www.pjug.org/mailman/listinfo/javamail
>>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Web Site - http://www.pjug.org/
>> Javamail mailing list
>> Javamail at pjug.org
>> http://www.pjug.org/mailman/listinfo/javamail
>>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://javac.com/pipermail/javamail/attachments/20070913/6a39d5ef/attachment-0002.html>


More information about the Javamail mailing list