Archived

This forum has been archived. Please start a new discussion on GitHub.

Unexplainable IceSSL error

Ok, I have been wrestling with this error for a while, and I have tried everything I can think of...

Here is the background. I am using IceGrid with IceSSL. I have the icegridregistry communicating with a Java based Ice server, and a Java based Ice client. Each of the 3 have their own SSL certificate and all 3 are using VerifyPeer=2.

I had this setup working perfectly on a Debian Lenny system. I had Sun's Java 6 jdk, and the default Ice install for that system was 3.2.1. Like I said, it worked perfectly.

I recently upgraded to Debian Sqeeze. I still had Java 6, but it was still a slightly newer version. The default Ice install is 3.3.1 though. Now when i run it, the Ice server contacts the registry, authenticates correctly and is successful. When the client starts, it also authenticates correctly to the registry to get the connection params of the server. When the client contacts the server, it gets an SSL handshake error on both the client and server.

Looking into debug logs, the error is "No cipher suites in common". I even tried enabling ALL cipher suites on the client and server, but it still fails. The debug logs print out that both the client and server are enabling the exact same cipher suites, but it still fails. Changing VerifyPeer to 0 on both client and server succeeds if ALL ciphers are enabled, but VerifyPeer=1 fails for the same reason.

I have tried it with both Sun's JDK and the OpenJDK, and have identical results.

Any ideas on what could be causing the issue?

Comments

  • Could be a 3.3 bug

    So I punished myself today to try and debug this some more. After having no luck, I decided to remove Ice 3.3 from my system, and put on the 3.2 version that comes with Debian Lenny.

    Guess what, it worked. This leads me to think that there is a bug in Ice 3.3, there is a problem with the 3.3 debian packaging, or there is a major interface change in 3.3 that I am not aware of.

    I look forward to any feedback from the ICE team, and when Debian Squeeze updates to Ice 3.4, I will try it out and see if I get the same errors.
  • benoit
    benoit Rennes, France
    Hi,

    Could you also try with the latest Ice 3.4.1 version (we only provide support for free here on the forums for the latest Ice version)?

    If you are enabling Ice.CheckCertName, you could also try to disable it and see if it makes a difference (we fixed some bugs related to this property in Ice 3.3).

    Cheers,
    Benoit.
  • Ok, so I hadn't had to deal with this for a while because I just kept using my Ice 3.2 fix.

    However, I just upgraded to Debian Wheezy, and its default Ice install is 3.4.2. I put on my code that works great on 3.2 and tried it again, hoping 3.4 had solved the problem.

    Here is what I found:

    There is still a problem, but it is not exactly the problem I had with 3.3. When the server starts, it connects and registers itself successfully with the registry. When the client starts, it too can connect to the registry and get connection parameters of the server. But when it connects to the server, it just fails with a security exception and not much more info than that. On the server however, it starts spewing this:

    !! <date and time> <adaptername>: error: Ice.ThreadPool.Server-0: exception in 'Ice.ThreadPool.Server':
    java.lang.NullPointerException
    event handler: local address = <my server ip>:<my server port>
    remote address: <my ip>:59342

    This information spews repeatedly and constantly until I kill the application. The timestamp changes, but the remote port doesnt. Hitting Ctrl-C on the console will cause it to stop spewing, and then the app shuts down gracefully.

    One last bit of info that may be helpful: Because Ice 3.2 required Ice.ThreadPerConnection to use IceSSL, I still have that property set. But ICE 3.4 says it doesnt recognize that and ignores it. Do I need to set something else?

    Thanks so much for your help.
  • mes
    mes California
    Hi Beau,

    Sorry to hear you're still having trouble with this.

    What would really help us to track this problem down quickly is a small example that we can use to reproduce it. For example, by modifying one of the IceGrid sample applications from the Ice distribution to use some dummy certificates and posting it here. Otherwise, we would probably waste lots of time trying to guess at what your application is doing, how everything is configured, and so on.

    Best regards,
    Mark
  • Ok, I got a demo put together. There is a build script in the root that will build both the client and server. There is also a start script for both the client and server. I see the same behavior in this demo as I described in my previous post.

    Again, the system I am using is a debian wheezy with the zeroc-ice package installed.
  • mes
    mes California
    Great, we'll take a look at it.

    Thanks,
    Mark
  • mes
    mes California
    Beau,

    Does your test case work if you comment out the IceSSL.Alias properties for the client and server?

    Mark
  • Yes, both the demo app and my real app work correctly with that property removed. Is this expected? I thought that property was just used to say which named cert in the .jks file to use.

    Thanks again for taking the time to help me.
  • mes
    mes California
    No, this behavior is not expected. It looks like there's a bug in the handling of Alias properties. We'll get this fixed in the next release.

    Regards,
    Mark