Uploaded image for project: 'ZABBIX BUGS AND ISSUES'
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-9293

monitor (localhost) https with self-signed certificate

XMLWordPrintable

    • Icon: Incident report Incident report
    • Resolution: Unresolved
    • Icon: Trivial Trivial
    • None
    • 2.4.3
    • Agent (G)
    • None
    • CentOS 6

      Hello, we have many servers with multi-vhost environment, and SSL.
      default vhost (SSL) has self-signed certificate.
      If we check localhost with net.tcp.service[https] it always fails because of invalid SSL cert. Actually localhost itself suppose to have invalid certificate cause that's not a real hostname.
      We use default vhost as a catch-all location for scanners and other bad internet guys and things. So only if you know the relevant hostname - server will serve it. otherwise everything goes to that catch-all location with some self-signed default cert.

      With this monitor we check the general port's availability like with net.tcp.service[http] we check http.

      Until now we used to monitor it with either tcp 443 or with net.tcp.service[http,

      {HOST.IP}

      ,443]
      https check was introduced in 2.2, so we thought to try replace our "hacks" with it.

      from debug log (nginx) I see no difference between http and tcp 80 check (the port opens and immediately closed, so both look like standard port check). However, https checks for certificate and thus fails. With self-signed certificates it's a problem, so wanted to ask if it's possible to fix this (for localhost only for example) or introduce something else to let know zabbix ignore the certificate validity and just proceed to finalize negotiation (like curl -k). Self signed certs are used all across internal systems where we don't have a real need for a valid certificate, but just some kinda SSL termination/behavior.

      Of course real SSL monitors happen from outside (web scenarios) to relevant hostnames with page checks and so on, but it's important for us to know if port 443 having problems, not just in terms of being open/closed but also in terms of SSL ability. This also can be a dependency for other things to avoid massive spam if something goes wrong (so not all relevant/related triggers will fire up)

      Hope this could be useful for everybody else (if it gets implemented for 'localhost' or generally for self-signed, other validation-problems certs)
      After all there are additional checks (web scenarios and SSL cert validity) to take care of more serious things

      Thanks!
      Alex

            Unassigned Unassigned
            ShivaS Alex
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: