Zabbix 2.4 features, part 3 – SSL verification and authentication controls

In these Zabbix 2.4 feature series we have already seen some improvements for the built-in web monitoring – the ability to specify custom headers and control redirects. Web monitoring got improved further – let’s explore the new options regarding SSL authentication. There are two of them:

  • Verifying SSL certificates
  • Supplying client certificate

Articles in 2.4 feature series:

It is worth noting that the built-in web monitoring was improved in 2.2 as well – if you missed that detail, the improvements back then were:

But let’s get back to the new SSL authentication options. With 2.4, all authentication details have been brought out in a separate tab in the scenario properties, Authentication.

Verifying SSL certificates

Previous Zabbix versions did not verify anything about the SSL certificate – if the page worked, that was good enough. 2.4 will offer two new checkboxes for this:

  • SSL verify peer
  • SSL verify host

What these do might be obvious to some, but we will do a quick overview for everybody else. Note that these options will do something only for “https” urls, with plain “http” these options will be ignored.

Verifying peer

With this checkbox marked, Zabbix will check that certificate is valid – trusted by a known certificate authority, not expired etc.

For this feature libcurl option CURLOPT_SSL_VERIFYPEER is used.

Verifying host

Just checking that a certificate is not enough, though – a rogue host might present a valid certificate that belongs to some other host. With this option, Zabbix will check that the server name matches the name in the certificate.

For this feature libcurl option CURLOPT_SSL_VERIFYHOST is used.

What’s a known certificate authority?

We used term “known certificate authority” previously – but what does that really mean? It’s a certificate authority which has it certificate available to libcurl. Most recent Linux distributions provide a systemwide collection of these certificates. While it is possible to add certificates to this systemwide location, in most cases it should be easier to add such certificates specifically for Zabbix web monitoring. This is possible by placing the certificates in the directory, specified by option SSLCALocation in the server configuration file.

Note that this option overrides, not supplements, systemwide directory.

Supplying client certificate

Previous options concerned client (Zabbix) verifying that server is what it claims to be. It is also possible to use SSL certificates so that server would be sure client is what it claims to be. HTTP password authentication is one way, SSL certificates are like using SSH keys instead of passwords. Zabbix 2.4 will support such certificates, as evident in the Authentication tab:

Here you may specify:

  • Only certificate if it’s unencrypted or includes the key
  • Key if the key is in a separate file
  • Key password if the key is encrypted

But if one specifies files here, where would Zabbix look them up? This is controlled by two parameters in the server configuration file:

  • SSLCertLocation
  • SSLKeyLocation

These default to ${datadir}/zabbix/ssl/certs and ${datadir}/zabbix/ssl/certs – what datadir is depends on compile time options and if one would compile without changing default locations, these directories would be in /usr/local/share.

If authentication fails, the error messages can be fairly cryptic – but those are returned by libcurl and there’s nothing Zabbix could do to improve them.

Note that there’s a minor bug and combined certificate with an encrypted key does not work right now. You can follow the corresponding issue (ZBXNEXT-282) for progress.

Leave a Reply