Zabbix shows HTTPS is down when it's not

[Pieter Houwen]

Hi all,

I am running Zabbix Server on Ubuntu 14.04.4 LTS, and I'm monitoring some HP ProCurve 2530 switches, which have HTTPS enabled, but the server shows them as down. Zabbix doesn't check the validity of the SSL/TLS certificate right? Because in the browser I can access the page, but it gives me an error (Error code: SEC_ERROR_UNKNOWN_ISSUER).

I've tried Googling it, but I couldn't find anything.

Attached are some screenshots.

Any help is much appreciated!

[valegator]

Need more info

Please:
1. Attach a screenshot of the item keys you're using for HTTPS monitoring
2. Check TCP 443 network availability from Zabbix Server <--> Monitored Hosts by running "nmap {HOST.IP}" on the Zabbix Server command line. Port tcp/443 should be stated as open. If not, there is probably a firewall in between that's blocking the connection.

[Linwood]

Are you checking it with a simple check using "https" as a parameter? I found on ubuntu that it was failing due to a change in (if memory serves) curl that removed certain SSL/TLS versions from being accepted as valid. Some (many) network devices may be running older code and so supporting (only) older less secure protocols.

You can make it just check that the port is open by changing it to "tcp" to port 443 as opposed to the explicit name "https". Same goes for telnet and a few other protocols, putting the protocol name in does some extra checks that sometimes fail (telnet for example I ran across recently as it does not honor subnegotiation so it fails). That would ensure your issue lies in the detail and not just passing traffic.

Of course changing from "https" to "tcp" (being sure to put in 443 as the port) may not be what you want since it does not check that the connection actually works, just that the port is open.

[Pieter Houwen]

Yes, I am running a simple check which checks https rather than the availability of port 443. There are also no firewalls between the Zabbix Server and the switches I am monitoring.

EDIT: I've tried telnetting to port 443 which was successful

[Linwood]

My GUESS Is that it is the curl library. Try accessing the switch via HTTP via curl at the command line, I suspect you will get a failure. Meaning this is about the library not zabbix, if I'm right.

If I'm wrong, sorry for the tangent...

[Pieter Houwen]

My GUESS Is that it is the curl library. Try accessing the switch via HTTP via curl at the command line, I suspect you will get a failure. Meaning this is about the library not zabbix, if I'm right.

If I'm wrong, sorry for the tangent...

Yes, I did get a "connection refused" error using curl on HTTP, but when I curl on HTTPS it shows a certificate error, and with the -k parameter it works fine.
If this is in fact the curl library, how do I fix that? apt-get install curl --reinstall?
Or wouldn't that solve my problem?

[Linwood]

I didn't pursue it beyond that, I just changed to monitor via TCP/443. I recall seeing some mail list archives discussing a patch, but in a quick search now I can't find them (and I cannot say for sure they were on target for this).

For me, we don't allow ssh/ssl to network devices from the outside, and not all that worried about older versions inside (or more precisely, if they are that old, it's not for lack of trying getting someone to upgrade them anyway).

I also cannot say for certain that this is older SSL protocol issues, it wasn't high on my list to worry about, sorry. Hopefully someone else will show up to comment who knows. You might also search the zabbix bug listing, see if anyone has noted whether it is intentional or not.

[Linwood]

By the way... I should add that from a security aspect... it's finding a real problem. The RIGHT fix is to fix the device, I think. The idea of the check is whether HTTPS is working properly; unless you are saying it really is correct and curl is wrong, telling curl to ignore the problem might be argued to be even more incorrect.

Unless the issue is self-signed certificates, but that wasn't my issue, it was SSL prototocol versions that were weak.

[LenR]

Similar thing happens on web tests, but on the Authentication tab, if you don't check the verify peer and/or verify host options, it will tolerate things users are trained to "click around".

IMHO, from a security aspect, browsers shouldn't even offer the option to click around, we are giving Pavlovian reinforcement to bad user behavior.

</soapbox>

[Linwood]

Similar thing happens on web tests, but on the Authentication tab, if you don't check the verify peer and/or verify host options, it will tolerate things users are trained to "click around".

IMHO, from a security aspect, browsers shouldn't even offer the option to click around, we are giving Pavlovian reinforcement to bad user behavior.

</soapbox>

It's actually worse than that. I was surprised to find out that Chrome (and maybe others) removed the mixed-content warning. Now instead of an explicit warning, it just doesn't show a locked symbol when a page has http and https content mixed together. I take it they got too many complaints from too many poorly written web sites. Really bad when "this is not secure" becomes enough of a problem they just turn it off.

I fought (and occasionally won, meaning often lost) this when I was in corporate IT management, insisting that we buy certs for any web sites regular users had to use, even if they were internal company-only sites. The idea of "just tell them to accept it anyway" was the wrong training to send. The "Let's Encrypt" effort really takes the wind out of people who tried to argue "too costly to get certs for all extranet sites", though.