mfournier

SSL tunel disconnect between Linux remote hub and core when configuring queues

Discussion created by mfournier on Mar 11, 2010
Latest reply on Mar 11, 2010 by mfournier
I'm currently seeing an issue where a remote hub running on a Linux
machine (LINUX_23 install) is having difficulty connecting via SSL
tunnel back to our core hub at our office, and I was hoping someone may
be able to provide some insight.  After doing the basic Infrastructure
installation and installing the SSL certificate through the tunnelsetup
during the install, it connects just fine.  I can see it within the
domain, deploy probes, etc.

The issue occurs when a queue is
configured on the remote hub.  I want to have it send QOS and alarm
data over the SSL tunnel back to our core hub, but as soon as any queue
is created on the remote hub it seems to break the certificate.  It
will begin issuing this error:

Mar 10 14:12:07:186
hub: SSL certificate commonName(<internal core hub IP>) doesn't
match peer (<external core hub IP>/NA)
Mar 10 14:12:07:186  hub: CTRL ARMS_Core certificate error: application verification failure (50)
Mar 10 14:12:07:186  hub: CTRL ARMS_Core could not connect to server <external core hub IP>/443

Is
there any reason why creating a queue would cause the certificate on a
Linux machine to stop looking for the external NAT'd IP of the core hub
(which the cert is created with) and start expecting the internal IP of
the core hub?  We do not see this same issue with Windows hubs. 

This
breaks both when trying to post the data from the remote hub to the
core, and also when simply trying to attach locally to the queues at
the remote hub.

Outcomes