Archived
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:
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 id.name="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:
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?
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 id.name="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' facet: 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?
0
Comments
-
Hi,
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!
Cheers,
Benoit.0 -
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 10.68.229.67:4062 ] [ 2/7/08 12:59:19:652 IceGrid Admin: Network: ssl connection established local address = 10.68.229.143:2713 remote address = 10.68.229.67:4062 ] [ 2/7/08 12:59:19:699 IceGrid Admin: Network: trying to establish ssl onnection to 10.68.229.67:4062 ] [ 2/7/08 12:59:19:745 IceGrid Admin: Network: ssl connection established local address = 10.68.229.143:2714 remote address = 10.68.229.67:4062 ]
And again, if I add a tcp endpointIceGrid.Registry.Client.Endpoints = ssl -p 4062 -h maddox : tcp -p 4061 -h maddox
I get the same behaviour from the command line client.0 -
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?
Thanks,
Benoit.0 -
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?0 -
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!
Cheers,
Benoit.0