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.