At this time, encryption is a very new feature in Zabbix. While it has been developed and tested extremely carefully and pedantically, it is likely to receive further improvements. Make sure to read through the official documentation on encryption for more details and in case changes are made. Right now, let's touch on basic concerns and features that are missing.

So far in this chapter, we've covered Zabbix server, agents, zabbix_get, and zabbix_sender—what about Zabbix proxies? Zabbix proxies fully support encryption. Configuration on the proxy side is very similar to agent configuration, and configuration in the frontend side is done in a similar way to agent encryption configuration, too. Keep in mind that all involved components must be compiled with TLS support—any proxies you have might have to be recompiled. When considering encryption, think about the areas where it's needed most—maybe you have the Zabbix server and proxy communicating over the Internet while all other connections are in local networks. In that case, it might make sense to set up encryption only for server-proxy communication at first. Note that encryption is not supported when communicating with the Zabbix Java gateway, but one could easily have the gateway communicate with a Zabbix proxy on the localhost, which in turn provides encryption for the channel to the Zabbix server.

We've already figured out how the upgrading and transitioning to encryption can happen seamlessly without interrupting data collection—the ability for all components to accept various connection types allows us to roll the changes out sequentially.

An important reason why one might want to implement encryption only partially is performance. Currently, Zabbix does not reuse connections, implement a TLS session cache, or use any other mechanism that would avoid setting up an encrypted connection from scratch every time. This can be especially devastating if you have lots of passive agent items. Make sure to understand the potential impact before reconfiguring it all.

Encryption isn't currently supported for authentication purposes. That is, we cannot omit active agent hostnames and figure out which host it is based on the certificate alone. Similarly, we cannot use encrypted connections for active agent autoregistration.

For certificate-based encryption, we only specified the certificates and the CA information. If the CA used is large enough, that would not be very secure—any certificate signed by that CA would be accepted. Zabbix also allows verifying both the issuer and subject of the remote certificate. Unless you are using an internal CA that is used for Zabbix only, it is highly recommended to limit the issuer and subject. This can be done on the host or proxy properties in the frontend and by using the TLSServerCertIssuer and TLSServerCertSubject parameters in the agent or proxy configuration file.