Handling Self-Signed Certificates for PowerVault Devices
We are experiencing issues connecting to the PowerVault devices on port 443, likely due to the use of self-signed certificates. Is there a way to configure the specific collector to trust the target host? The DS HTTPS 443 port has been showing status code 5 (Network Error) since September 29th 2024, and from that date, we have stopped receiving data for the PowerVault DS, which is now returning "No Data."
- Could you please recommend an approach for handling self-signed certificates to trust the host?
Sharath Ramanna
Posted 1 year ago·Last reply 1 year ago
6 comments
allen
·1 year agoThe error net: ERR_CERT_DATE_INVALID typically appears as a warning in web browsers like Google Chrome. The error indicates a problem with the validity period of the SSL Certificate, which could be because it has expired or isn't yet valid. This issue typically occurs due to incorrect system date and time settings on the user's end. It can also display an error message stating, "Your connection is not private".
There are numerous reasons, apart from incorrect date and time settings, that can give birth to the error, such as:-
allen
·1 year agoThe error
Sharath Ramanna
OP1 year agoCan you please confirm?
Mike Moniz
·1 year agoWhat is the specific SSL error code that the browser is reporting? Like net::ERR_CERT_DATE_INVALID or net::ERR_CERT_AUTHORITY_INVALID? Browsers will let you bypass self-signed but not other errors, are you able to also bypass the error and continue to the page? I'm still pretty confident that the LM HTTPS check doesn't care about self-signed certs.
But for your questions, I think you should to reach out to LM Support. I know I haven't played with those collector options myself. I also don't see documentation about them from LM, so best to ask them directly imho.
Sharath Ramanna
OP1 year agoI checked the device, and it displays the message: "Device uses an invalid security certificate. The certificate is not trusted because it is self-signed."
This indicates that the self-signed certificate is the reason the browser—and likely LogicMonitor—is not trusting the connection. Is there a way to configure the Collector to trust this certificate?
We plan to configure the LogicMonitor Collector to trust this host by adding the following JVM options to the wrapper.conf file:
wrapper.java.additional.<n>=-Dtrust.unsecure.ssl=true
wrapper.java.additional.<n+1>=-Dtrust.unsecure.ssl.hosts="Device IP"
<n> means "properties, incrementing"
1) I don't know. Is this the correct and recommended way to handle this specific error for a single host in LogicMonitor?
2) Are there any potential downsides or security considerations we should be aware of when using these JVM options?
3) After making this change and restarting the Collector, should LogicMonitor's webpage check (or other relevant monitors) now be able to connect successfully to the Device on port 443?
Mike Moniz
·1 year agoI'm pretty sure most LM checks do not care if the cert is self-signed, but it would care if it is invalid in other ways. Like if it has expired or using old algorithms. Did that self-signed cert expire on Sept 29, 2024? If so, you should get it re-signed with a new self-signed cert.