11.32 JAVA GUI connecting to ipm.commvault.com

Hi @Patrick Dijkgraaf,

How are you accessing the Java GUI?  Is this a locally installed Commcell Console package?  If not and you’re using web-based access, are you leveraging netx.jar, or using the galaxy.jnlp file with Java Web Start?

I am trying to reproduce this in my lab and at this moment I am not seeing an external connection attempt.  If you can share how you are accessing the Java Console, and let me know exactly where you are seeing that connection attempt to ipm.commvault.com I can get some more details on how to remediate this for you.

Thanks,

-Brian Bruno

Hi Brian,

Thanks for your response!

Customer is launching the Java GUI via “https://<commserve>/console”, which downloads and launhes the galaxy.jnlp.

After the GUI is lanched and the user is logged in, they get the following message:

We know how to fix the certificate issue (it’s caused by the HTTPS Proxy in between), but why would the GUI be “phoning home”? And this customer does not like that idea.

The next.jar won’t work for this customer as it tries to get the application via HTTP (port 80) from the CommServe/WebServer, and the customer says (and I quote): “We are not allowing HTTP, it’s not the 90’s)”.

Hope this helps!

Thanks @Patrick Dijkgraaf,

I’ll need to look into this more and get back to you as I can’t seem to reproduce this.

That being said, connecting via netx.jar will use HTTPS so long as the site has a valid SSL certificate.  It will only fall back to port 80 / HTTP if there is no trusted certificate.

-Brian Bruno

@Brian Bruno Thanks for looking into this.

About the netx.jar method, we are seeing different behaviour. We believe a valid certificate and we are downloading netx.jar via HTTPS. When it launches, we saw it connecting to the CommServe via port 80.

I’ll see if I can get some logging/evidence… ;-)

EDIT: Might be that it tries via 443 first, and fails for some other reason. Let’s stay on-topic here and figure out what the connection to ipm.commvault.com is coming from… :-)

Thanks, @Jacek Piechucki !

Interesting to hear that they are still putting development efforts in the Java-based CommCell console...

Hi, I encountered the same issue. To resolve it, simply bypass SSL interception for this URL in the proxy you're using. In our case, the Java applet is downloaded locally onto our laptops. We use a different proxy on the laptop, which is configured on the Commcell server.

I’m assuming you shouldn’t get your hopes up.  :)

Thanks,
Scott
​​​​​​​