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

IceGrid + SSL

I'm tying to use IceSSL to secure my grid registry and seem to be doing something wrong. I'd like to use SSL authentication (no user/password) so I've got this in my registry conf:
IceGrid.Registry.Client.Endpoints = ssl -p 4062
IceGrid.Registry.Server.Endpoints = ssl
IceGrid.Registry.Internal.Endpoints = ssl
IceGrid.Registry.AdminSSLPermissionsVerifier = IceGrid/NullSSLPermissionsVerifier
Ice.Plugin.IceSSL = IceSSL:createIceSSL
IceSSL.DefaultDir = /home/courtt/.iceca/
IceSSL.CertFile = registry.cert.pem
IceSSL.KeyFile = registry.key.pem
IceSSL.CertAuthFile = ca_cert.pem

The registry server starts with this config and servers can register but I'm running into two (probably related) problems:

1. Running the command line icegridadmin with the --ssl option works fine but the IceGridGUI tool does not. I've built a jks with my client's key/cert but when I try to connect it complains that it "Could not retrieve replica Name: Ice.ObjectNotExist"some guid" id.category="IceGrid" operation="getReplicaName". The registry log shows that the ssl connection is established and an admin session was created. If I enable an AdminPermissionsVerifier and disable the GUI option for using SSL authentication then it works.

2. I'd like to add a tcp endpoint to the Client adapter so that clients can use the location services without having to bother with keys/certs. When I do this (i.e. IceGrid.Registry.Client.Endpoints = ssl -p 4062 : tcp -p 4061) the admin GUI exhibits the same behaviour as above, but the cmd line admin tool also stops working saying:
icegridadmin: Outgoing.cpp:388: Ice::ObjectNotExistException:
object does not exist:
identity: `IceGrid/5CDC357D-E964-4E73-AC05-C6631E4DCB4F'
operation: getAdmin

Using an AdminPermissionsVerifier instead of SSL authentication makes the GUI work as above, but does not get the cmd line client working.

In all cases, the only endpoint my clients are aware of is the ssl -p 4062. Any ideas what I'm doing wrong here?


  • benoit
    benoit Rennes, France

    Here, these Ice::ObjectNotExistException usually indicate that the admin client tried to access a session object from an invalid network connection. Session objects can only be invoked from the network connection used to create the session. To verify that this is the case, you could try to enable network tracing on the admin client with --Ice.Trace.Network=2.

    I suspect the problem comes from the fact that you don't specify any "-h" option for the registry endpoints:
       IceGrid.Registry.Client.Endpoints = ssl -p 4062
    Without -h option for the endpoints, the proxies returned by the session will contain one endpoint per network interface on your host. If for some reasons, these endpoints don't match the one that you specified in the admin client another connection will be created.

    Could you try adding the "-h" option to the IceGrid registry client endpoints? It should match the -h option used in the admin client. Note that you can also specify IceGrid.Registry.Client.PublishedEndpoints if you want to create proxies with endpoints that are different from the endpoint the object adapter is listening on. See the section "Published Endpoints" here in the Ice manual for more information on this property.

    Let us know if this still doesn't solve your problems!

  • Adding the -h option did not help. My new Client endpoint line without tcp is:
    IceGrid.Registry.Client.Endpoints = ssl -p 4062 -h maddox

    The GUI client gives the same error. Tracing network shows only this:
    E:\Ice-3.2.1\bin>java -jar IceGridGUI.jar --Ice.Trace.Network=2 --Ice.Trace.Loca
    tion=1 --Ice.Trace.Retry=1[ 2/7/08 12:59:19:292 IceGrid Admin: Network: trying to establish ssl onnection to ]
    [ 2/7/08 12:59:19:652 IceGrid Admin: Network: ssl connection established
      local address =
      remote address = ]
    [ 2/7/08 12:59:19:699 IceGrid Admin: Network: trying to establish ssl onnection
     to ]
    [ 2/7/08 12:59:19:745 IceGrid Admin: Network: ssl connection established
      local address =
      remote address = ]

    And again, if I add a tcp endpoint
    IceGrid.Registry.Client.Endpoints = ssl -p 4062 -h maddox : tcp -p 4061 -h maddox

    I get the same behaviour from the command line client.
  • benoit
    benoit Rennes, France
    Are you specifying a timeout option for the endpoint in the admin client or set Ice.Override.Timeout either in the client or registry configuration? The timeout setting of the endpoints used by the client should also match the timeout settings used for the registry (or otherwise a new connection might be created...).

    Could you post the configuration of both your client and registry?

  • That did the trick! I had Override.Timeout in my registry configuration but not in the client config. Adding a matching option to the client config or adding a -t option to the client's connect string fixes the problem.

    Could you provide, or point me to, some background info about exactly what is happening here? It seems counter-intuitive to me that the client has to know ahead of time what timeout settings the registry is using. Could I have done things differently so that the client wouldn't need this information to create an admin session?
  • benoit
    benoit Rennes, France
    The IceGrid registry requires that the objects for the admin session be accessed by the network connection that created the session. This ensure that these objects are invoked only by the client that created the session.

    In your case the initial connection is created to the endpoint specified in the admin client configuration. This endpoint didn't contain a timeout setting.

    However since you set Ice.Override.Timeout in your registry configuration, the proxies returned by the registry for the admin session objects contain a timeout. Ice can't re-use the existing connection to invoke on these objects because of the timeout setting is different (see "37.3.3 Connection Reuse" here in the Ice manual for more information).

    I agree this is counter intuitive, we'll fix this in future releases!