Shulou(Shulou.com)06/03 Report--

Chapter XIX data encrypted Communication

A very important feature in Zabbix 3.0 is that it supports encryption of communications between Zabbixserver, Zabbix proxy, Zabbix agent, zabbix_sender and zabbix_get, and supports encryption of Certificate-based (certificate-based) and pre-shared key-based (based on pre-shared keys), which no longer requires additional solutions as in previous versions.

Encryption is a stand-alone component in Zabbix 3.0. it is very flexible to configure as a configuration option, and different encryption methods can be set for different hosts. For example, some proxy and agents configurations use Certificate-based encryption to communicate with server, some use pre-sharedkey-based encryption, and others do not configure encryption. This is shown in figure 19-1 below.

Figure 19-1

19.1 compiled Zabbix supports encryption

Zabbix uses Transport LayerSecurity (TLS) protocol v1.2 for encryption. In order for Zabbix to support encryption, you must link to one of the following three encryption libraries when compiling and installing source code.

Mbed TLS: formerly known as PolarSSL, currently only 1.3.x is supported. Note that version 2.x is not supported.

GnuTLS: v3.1.18 and later are supported.

OpenSSL: v1.0.1 and later are supported.

Depending on your choice, the configure script can use one of the following options:

-- with-mbedtls [= DIR]

-- with-gnutls [= DIR]

-- with-openssl [= DIR]

For example:

#. / configure--enable-server-enable-agent-with-mysql-enable-ipv6-with-net-snmp--with-libcurl-with-libxml2-with-openssl

Different encryption libraries can be used when compiling and installing different components of Zabbix, such as server using OpenSSL,agent and GnuTLS. OpenSSL is recommended, and OpenSSL is the fastest in the actual test, followed by GnuTLS.

If you use the installation package to install Zabbix components, encryption is already supported by default. You can determine the features of the Zabbix installation by looking at the log files. For example, the following is a list of features that are displayed when Zabbixserver starts.

# vi/var/log/zabbix/zabbix_server.log

1065Monopoly 20150817 Enabled features * 103017.520 *

1065:20150817:103017.520SNMP monitoring: YES

1065:20150817:103017.520IPMI monitoring: YES

1065:20150817:103017.520 Webmonitoring: YES

1065:20150817:103017.520VMware monitoring: YES

1065:20150817:103017.520SMTP authentication: YES

1065:20150817:103017.520Jabber notifications: YES

1065:20150817:103017.520 EzTexting notifications: YES

1065:20150817:103017.520ODBC: YES

1065:20150817:103017.520SSH2 support: YES

1065:20150817:103017.520IPv6 support: YES

1065:20150817:103017.520 TLSsupport: YES

1065 Flex 20150817 103017.520 *

Recently, we have completed the recording and release of the video tutorial "zabbix 4.0", which is based on zabbix 4.2 and provides a comprehensive explanation of Zabbix. Welcome to watch. Course link: https://edu.51cto.com/sd/ce000

19.2 pre-shared keys encryption

When using PSK (pre-shared key) encryption in Zabbix, you need to provide an identifier (PSKidentity) and an encrypted string (PSK string). PSK identity is a non-empty UTF-8 string, such as PSK ID 001 zabbix agent, which is simply the name of a specific PSK to facilitate references to components in the Zabbix. Because PSK identity is transmitted in clear text over the network, do not refer to sensitive information in the name. A PSK string is a hexadecimal string, such as e560cb0d918d26d31b4f642181f5f570ad89a390931102e5391d08327ba434e9.

19.2.1 length limit

When using PSK encryption in Zabbix, there are limits on the length of PSK identity and PSK string. Configuring PSK identity in the Zabbix front-end page can be up to 128characters long, and PSK string can be up to 2048 bit long, depending on the limits of the encryption library used. If the configured string length exceeds the limit, the communication between the components of Zabbix will fail.

For example, before Zabbix server uses PSK to connect to agent, server will look up the PSK identity and PSK string configured by agent in the database, and compare them after receiving the PSK identity and PSK string configured by agent. If both parties have the same PSK identity and PSK string, they will connect successfully.

The parameters of the length limit are shown in table 19-1 below.

Table 19-1

module

Maximum length of PSK identity

Minimum length of PSK string

Maximum length of PSK string

Zabbix

128 UTF-8 characters

128-bit (16-byte PSK, entered as 32 hexadecimal digits)

2048-bit (256-byte PSK, entered as 512 hexadecimal digits)

GnuTLS

128 bytes (may include UTF-8 characters)

--

2048-bit (256-byte PSK, entered as 512 hexadecimal digits)

Mbed TLS

128 UTF-8 characters

--

256-bit (default limit) (32-byte PSK, entered as 64 hexadecimal digits)

OpenSSL

127 bytes (may include UTF-8 characters)

--

2048-bit (256-byte PSK, entered as 512 hexadecimal digits)

19.2.2 PSK generation

You can use different tools to generate PSK in CentOS. Let's take a look at generating a 256-bit (32-byte) PSK as an example.

Use OpenSSL

# openssl rand-hex 32

3e2b2ef85c2ad0af3410c9a495fe77d0a8741c2f1243c2af73a2e17623f70098

Use GnuTLS

# yum install gnutls-utils

# psktool-u psk_identity-p mypsk.psk-s 32

Generating arandom key for user 'psk_identity'

Key stored to mypsk.psk

# cat mypsk.psk psk_identity:9b8eafedfaae00cece62e85d5f4792c7d9c9bcc851b23216a1d300311cc4f7cb

When you use the psktool tool, you will generate a file in the format of pskidentity:psk string. When you use this file in Zabbix, you need to delete pskidentity:, leaving only psk string.

19.2.3 configure instance 19.2.3.1 configure the use of PSK between server and agent

Configuration steps:

1. In the agnet host, save the PSK string to a file. For example, / etc/zabbix/zabbix_agentd.psk.

# vi / etc/zabbix/zabbix_agentd.psk

3e2b2ef85c2ad0af3410c9a495fe77d0a8741c2f1243c2af73a2e17623f70098

2. Set the access rights of zabbix_agentd.psk files.

# chown zabbix:zabbix / etc/zabbix/zabbix_agentd.psk

# chmod 644 / etc/zabbix/zabbix_agentd.psk

3. Edit zabbix_agentd.conf configuration file.

# vi / etc/zabbix/zabbix_agentd.conf

TLSConnect=psk

TLSAccept=psk

TLSPSKFile=/etc/zabbix/zabbix_agentd.psk

TLSPSKIdentity=PSKAgent

If the agnet type is active (active) agent, then agent connects to the server and receives connections from server and zabbix_get encrypted with PSK, and PSK identity is PSK Agent.

4. Restart agent and use zabbix_get for testing.

# zabbix_get-s 127.0.0.1-k "system.cpu.load [all,avg1]"-tls-connect=psk\

-tls-psk-identity= "PSK Agent"-tls-psk-file=/etc/zabbix/zabbix_agentd.psk

5. Configure encryption in the Zabbix front-end page, click the name of the host to be configured in the Configuration-- > Hosts page, and enter the Encryption tab of the host configuration page to set it. This is shown in figure 19-2 below.

Figure 19-2

The current encryption method can be clearly seen in the AGENT ENCRYPTION column in the host list, as shown in figure 19-3 below.

Figure 19-3

19.2.3.2 configure the use of PSK between server and active proxy

Configuration steps:

1. In the proxy host, save the PSK string to a file. For example, / etc/zabbix/zabbix_proxy.psk.

# vi / etc/zabbix/zabbix_proxy.psk

3e2b2ef85c2ad0af3410c9a495fe77d0a8741c2f1243c2af73a2e17623f70098

2. Set the access rights of zabbix_proxy.psk files.

# chown zabbix:zabbix / etc/zabbix/zabbix_proxy.psk

# chmod 644 / etc/zabbix/zabbix_proxy.psk

3. Edit zabbix_proxy.conf configuration file.

# vi / etc/zabbix/zabbix_proxy.conf

TLSConnect=psk

TLSPSKFile=/etc/zabbix/zabbix_proxy.psk

TLSPSKIdentity=PSKProxy

4. Restart proxy,Proxy to connect the server,PSK identity to PSK Proxy using PSK encryption.

5. Configure encryption in the Zabbix front-end page, click the proxy name to be configured in the Administration-- > Proxies page, and go to the Encryption tab of the proxy configuration page to set it. This is shown in figure 19-4 below.

Figure 19-4

Check the log files of Zabbix server and proxy, and a similar message below indicates that there is a problem with the configuration.

# tail-f / var/log/zabbix/zabbix_server.log

2124:20160823:122631.486cannot parse host availability data from active proxy at "192.168.10.116": connection of type "unencrypted" is notallowed for proxy "Zabbix proxy"

# tail-f / var/log/zabbix/zabbix_proxy.log

2558:20160823:122630.484cannot send history data to server at "192.168.10.107": connection oftype "unencrypted" is not allowed for proxy "Zabbix proxy"

The setup process of Passive (passive) proxy is similar to that of active proxy, except that TLSAccept=psk is set in the configuration file of proxy and Connections to proxy is set in the front-end page of Zabbix.

19.3 Certificate-based encryption

Zabbix can use a PEM format RSA certificate signed by a public or internal certification authority, and certificate verification depends on a preconfigured CA certificate. Zabbix does not support self-signed certificates and must be issued by CA. Only one certificate can be configured per Zabbix component.

Using OpenSSL's powerful command line tool, we can generate and create files needed to configure certificate encryption in Zabbix, including top-level self-signed root CA certificate files, Zabbix component private key (private key) files, and signed Zabbix component certificates or certificate chain (certificatechain) files.

The contents of the certificate include: CA information, public key user information, public key, CA signature and validity, and so on. The format and verification methods of certificates generally follow the X.509 international standard.

CA also has a certificate (containing a public key) and a private key. The user trusts the certificate by verifying the signature of CA, and anyone can get the certificate of CA (containing the public key) to verify the certificate issued by it. Therefore, Zabbixserver must be able to access the top-level self-signed root CA certificate file. If you use multiple certificates from different root CAs, you can put them in the same file, as shown in the file / etc/zabbix/zabbix_root_ca.cert below.

# cat / etc/zabbix/zabbix_root_ca.cert

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 1 (0x1)

Signature Algorithm: sha1WithRSAEncryption

Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1CA

...

Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1CA

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

...

X509v3 extensions:

X509v3 Key Usage: critical

Certificate Sign, CRL Sign

X509v3 Basic Constraints: critical

CA:TRUE

...

-BEGIN CERTIFICATE-

MIID2jCCAsKgAwIBAgIBATANBgkqhkiG9w0BAQUFADB+MRMwEQYKCZImiZPyLGQB

....

9wEzdN8uTrqoyU78gi12npLj08LegRKjb5hFTVmO

-END CERTIFICATE-

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 1 (0x1)

Signature Algorithm: sha1WithRSAEncryption

Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root2CA

...

Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root2CA

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

....

X509v3 extensions:

X509v3 Key Usage: critical

Certificate Sign, CRL Sign

X509v3 Basic Constraints: critical

CA:TRUE

....

-BEGIN CERTIFICATE-

MIID3DCCAsSgAwIBAgIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQB

...

VdGNYoSfvu41GQAR5Vj5FnRJRzv5XQOZ3B6894GY1zY=

-END CERTIFICATE-

The strict hierarchical structure of CA can be described as an inverted tree. On this inverted tree, the root represents a CA that is of special significance to all entities in the entire PKI domain, often called root CA, as the root of trust or "trust anchor". Below the root CA is the zero-layer or multi-layer intermediate CA, because it belongs to the root, also known as the sub-CA, the sub-CA can be used as an intermediate node, then protruding branches, and finally the leaves of the tree, which is called the end entity or end user.

The certificate chain consists of two links: trust anchor (CA certificate) and signed certificate. The self-signed certificate is only one link in length, and the trust anchor link is the signed certificate itself.

The certificate chain can have the length of any link. So in the three-section certificate chain, the trust anchor certificate CA can sign the intermediate certificate, and the owner of the intermediate certificate can sign another certificate with his own private key. A certificate chain is a sequence of certificates issued by a CA certificate, which ends with the root CA certificate. The certificate was originally generated as a self-signed certificate, which is the same as the issuing authority name (Issuer) and the certificate user name (Subjet). A self-signed certificate is the last certificate in the certificate chain. Each certificate in the certificate chain needs to be verified using the public key of the previous certificate in the chain up to the self-signed root certificate.

The certificate chain file is shown in the following example.

# cat / etc/zabbix/zabbix_server.cert

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 1 (0x1)

Signature Algorithm: sha1WithRSAEncryption

Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group,CN=Signing CA

...

Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group,CN=Zabbix server

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

...

X509v3 extensions:

X509v3 Key Usage: critical

Digital Signature, KeyEncipherment

X509v3 Basic Constraints:

CA:FALSE

...

-BEGIN CERTIFICATE-

MIIECDCCAvCgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBgTETMBEGCgmSJomT8ixk

...

H02u1GHiy46GIZOXFR3LsPwFKlkTaaLaLGGHiy46GIZOU1GHiy46GIXFR3LsPwFKlkTaaLaLand 6aaoQcodes =

-END CERTIFICATE-

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 2 (0x2)

Signature Algorithm: sha1WithRSAEncryption

Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1CA

...

Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group,CN=Signing CA

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

...

X509v3 extensions:

X509v3 Key Usage: critical

Certificate Sign, CRL Sign

X509v3 Basic Constraints: critical

CA:TRUE, pathlen:0

...

-BEGIN CERTIFICATE-

MIID4TCCAsmgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB+MRMwEQYKCZImiZPyLGQB

...

DyCeWnvL7u5sd6ffo8iRny0QzbHKmQt/wUtcVIvWXdMIFJM0Hw==

-END CERTIFICATE-

The private key (private key) of the Zabbix component should be saved to a separate file, as shown in the following file.

# cat / etc/zabbix/ zabbix_server.key

-BEGIN PRIVATE KEY-

MIIEwAIBADANBgkqhkiG9w0BAQEFAASCBKowggSmAgEAAoIBAQC9tIXIJoVnNXDl

...

IJLkhbybBYEf47MLhffWa7XvZTY=

-END PRIVATE KEY-

19.3.5 some restrictions on certificate encryption

When a TLS connection is established between Zabbix server, proxy or agent, certificates will be checked between each other. If both certificates are issued by the same trusted CA, they will be considered to be valid and legal. After checking the validity period of the certificate and some other parameters, the connection will be established and started to communicate. In the simplest scenario, the Issuer and Subject of the certificate are not checked, but it is risky to do so, and a person holding a certificate issued by the same trusted CA can pretend to be someone else. To improve security, we can configure Issuer and Subject for specific certificates in Zabbix proxy or agent, allowing only matching certificates.

For example, specify Issuer and Subject in the proxy configuration file:

TLSServerCertIssuer=CN=zabbix ca root,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

TLSServerCertSubject=CN=zabbix server,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

When the above configuration is completed, the active (active) proxy does not establish a connection with a Zabbix server that is different from the Issuer or Subject in the certificate. Passive (passive) proxy does not respond to requests from server.

The zabbix_get and zabbix_sender tools can also use Issuer and Subject on the command line.

Note when matching Issuer and Subject strings in Zabbix:

Issuer and Subject strings are checked separately, both of which are optional.

UTF-8 characters are allowed.

When no string is specified, it means that any string can be accepted.

The string comparison must be exactly the same to be considered a successful match.

Matching between wildcards and regular expressions is not supported.

Only RFC 4514Lightweight Directory Access Protocol (LDAP) is implemented: there are only partial requirements in String Representation ofistinguished Names.

You can use the escape characters'(Ubun0022),'+ 'Ubun002B,', 'Ubun002C,'; 'Ubun003B,' 'Uzz003E,'\ 'Ubun005C.

Escape character spaces (''Ubun0020) and array symbols (' # 'Ubun0023) can only be used at the beginning of a string.

If the null character (Ubun0000) is encountered, the match will fail.

The requirements in RFC 4517Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules and RFC 4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation are not supported.

In addition, there are requirements for the format of Issuer and Subject strings in Zabbix, and Zabbix follows the recommendation of RFC 4514 to use reverse order. By default, OpenSSL displays the Issuer and Subject of the certificate in the normal order, for example:

# openssl x509-noout-in/etc/zabbix/zabbix_proxy.cert-issuer-subject

Issuer= / C=CN/ST=Beijing/O=My Company/OU=IT Dept/CN=zabbix ca root

Subject= / C=CN/ST=Beijing/O=My Company/OU=IT Dept/CN=zabbix proxy

The reverse display of Issuer and Subject can be obtained by using the special parameters of the OpenSSL command line, for example:

# openssl x509-noout-issuer-subject-nameopt esc_2253,esc_ctrl,utf8,dump_nostr,\ dump_unknown,dump_der,sep_comma_plus,dn_rev,sname-in / etc/zabbix/zabbix_proxy.cert

Issuer= CN=zabbix ca root,OU=IT Dept,O=My Company,ST=Beijing,C=CN

Subject= CN=zabbix proxy,OU=IT Dept,O=My Company,ST=Beijing,C=CN

What you see now is the reverse display of Issuer and Subject, with each field separated by a comma, and this string can be used in the Zabbix proxy configuration file or in the Zabbix front-end page.

There are also some restrictions on using the X.509 v3 certificate extension when generating certificates:

Subject Alternative Name (subjectAltName) extension: Alternative subject names defined in the subjectAltName extension (such as IP address, e-mail address, etc.) is not supported in Zabbix. Only the value of the Subject field is checked in Zabbix.

Extended Key Usage extension: clientAuth (TLS WWW clientauthentication) and serverAuth (TLS WWW server authentication) are required if you use this extension. For example, in a passive check, Zabbix agent is like a TLS server, so serverAuth must be set in the agent certificate. ClientAuth needs to be set in the agent certificate in an active check. An error is reported in GnuTLS but a connection is allowed to communicate.

Name Constraints extension: this extension is not supported by all encryption tools, and this extension prevents Zabbix from loading what is marked as critical in the CA certificate (relying on a specific encryption toolkit).

Using OpenSSL to create certificates

This book only explains the process of creating CA certificates through OpenSSL, and asks readers to refer to relevant materials for more knowledge of PKI and CA.

The specific steps for implementing a private CA with OpenSSL are as follows:

1. Generate CA private key (automatically extract public key without generating) and generate self-signed certificate and related files.

2. Generate user key and certificate issuance request

3. The user certificate is signed by CA.

The configuration file for OpenSSL in CentOS 7 is located in / etc/pki/tls/openssl.cnf, and the directory where the default certificate is saved is / etc/pki/CA, where the created certificate and other related files are saved. Before you start creating a certificate using OpenSSL's command-line tool, you need to create several files necessary to generate the certificate in the / etc/pki/CA directory.

# cd/etc/pki/CA

Create a text database file that has been issued with a certificate, and the file is initialized to empty.

# touch index.txt

Create a serial number file to be used when issuing the certificate, which holds the serial number in hexadecimal format and must be created with a valid serial number.

# echo 00 > serial

Create a certificate revocation list serial number file, which is used when creating a certificate revocation list and saves the serial number in hexadecimal format.

# echo 00 > crlnumber

The directory structure is as follows.

# tree.

.

├── certs # saves issued certificates

├── crl # saves revoked certificates

├── crlnumbe # Certificate revocation list Serial number

├── index.txt # database files

├── newcerts # saves the new certificate generated by CA

├── private # Save the private key file

└── serial # Certificate Serial number File

Now let's use the OpenSSL command line to create certificates for each component of CA and Zabbix, as follows:

# cd / etc/pki/CA

Generate CA private key and certificate issuance request.

# openssl req-new-keyout private/zabbix_root_ca.key-outprivate/zabbix_root_ca.csr\

-subj "/ C=CN/ST=Beijing/L=Beijing/O=My Company/OU=IT Dept/CN=Zabbix RootCA"

Generating a 2048 bit RSA private key

. +

.. +

Writing new private key to'private/zabbix_root_ca.key'

Enter PEM pass phrase:

Verifying-Enter PEM pass phrase:

-

Generate a self-signed CA certificate.

# openssl ca-out certs/zabbix_root_ca.cert-batch-keyfile private/zabbix_root_ca.key\

-selfsign-extensions v3_ca-infiles private/zabbix_root_ca.csr

Using configuration from/etc/pki/tls/openssl.cnf

Enter pass phrase forprivate/zabbix_root_ca.key:

Check that the request matches thesignature

Signature ok

Certificate Details:

Serial Number: 0 (0x0)

Validity

Not Before: Aug 31 04:03:37 2016 GMT

Not After: Aug 31 04:03:37 2017 GMT

Subject:

CountryName = CN

StateOrProvinceName = Beijing

OrganizationName = MyCompany

OrganizationalUnitName = ITDept

CommonName = ZabbixRoot CA

X509v3 extensions:

X509v3 Subject Key Identifier:

47:95:AF:32:4E:F1:53:DF:30:DE:02:19:CD:15:14:C3:04:73:5F:B4

X509v3 Authority Key Identifier:

Keyid:47:95:AF:32:4E:F1:53:DF:30:DE:02:19:CD:15:14:C3:04:73:5F:B4

X509v3 Basic Constraints:

CA:TRUE

Certificate is to be certified until Aug 3104 days 03 days 37 2017 days

Write out database with 1 new entries

Data Base Updated

Generate Zabbix server private key and certificate issuance request.

# openssl req-new-nodes-keyout private/zabbix_server.key-outprivate/zabbix_server.csr\-subj "/ C=CN/ST=Beijing/L=Beijing/O=MyCompany/OU=IT Dept/CN=Zabbix Server"-days 3650

Generating a 2048 bit RSA private key

. +

. .. +

Writing new private key to'private/zabbix_server.key'

-

The Zabbix server certificate is signed by CA.

# openssl ca-cert certs/zabbix_root_ca.cert-keyfile private/zabbix_root_ca.key-out\ certs/zabbix_server.cert-infiles private/zabbix_server.csr

Using configuration from / etc/pki/tls/openssl.cnf

Enter pass phrase forprivate/zabbix_root_ca.key:

Check that the request matches thesignature

Signature ok

Certificate Details:

Serial Number: 1 (0x1)

Validity

Not Before: Aug 31 04:04:24 2016 GMT

Not After: Aug 31 04:04:24 2017 GMT

Subject:

CountryName = CN

StateOrProvinceName = Beijing

OrganizationName = MyCompany

OrganizationalUnitName = ITDept

CommonName = ZabbixServer

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

Netscape Comment:

OpenSSL Generated Certificate

X509v3 Subject Key Identifier:

92:57:C9:58:8B:78:DE:4B:83:0E:B1:F4:61:B2:DC:3D:AB:0E:76:44

X509v3 Authority Key Identifier:

Keyid:47:95:AF:32:4E:F1:53:DF:30:DE:02:19:CD:15:14:C3:04:73:5F:B4

Certificate is to be certified until Aug 3104 days 04 days 24 2017 days

Sign the certificate? [y/n]: y

1 out of 1 certificate requests certified,commit? [y/n] y

Write out database with 1 new entries

Data Base Updated

Sign and issue Zabbix proxy and agent certificates with the same CA.

# openssl req-new-nodes-keyout private/zabbix_proxy.key-outprivate/zabbix_proxy.csr\-subj "/ C=CN/ST=Beijing/L=Beijing/O=MyCompany/OU=IT Dept/CN=Zabbix Proxy"-days 3650

# openssl ca-cert certs/zabbix_root_ca.cert-keyfile private/zabbix_root_ca.key-out\ certs/zabbix_proxy.cert-infiles private/zabbix_proxy.csr

# openssl req-new-nodes-keyout private/zabbix_agent.key-outprivate/zabbix_agent.csr\

-subj "/ C=CN/ST=Beijing/L=Beijing/O=My Company/OU=IT Dept/CN=Zabbix Agent"-days 3650

# openssl ca-cert certs/zabbix_root_ca.cert-keyfile private/zabbix_root_ca.key-out\ certs/zabbix_agent.cert-infiles private/zabbix_agent.csr

19.3.2 configuration parameters

The following parameters need to be configured when using certificate encryption in Zabbix:

TLSCAFile: the top-level root CA certificate file that contains the full pathname, first the low-level CA certificate, then the high-level CA. Certificates from multiple CA can be contained in the same file. This parameter must be configured.

TLSCRLFile: a certificate revocation list file containing the full pathname. This parameter is optional.

TLSCertFile: a certificate (certificate chain) file containing the full pathname, first a Zabbix server, proxy, or agent certificate, and then a higher-level CA certificate up to the top CA. This parameter must be configured.

TLSKeyFile: a private key file containing the full path name. Access to this file must be set to be readable only to zabbix users. This parameter must be configured.

TLSServerCertIssuer: allowed server certificate issuer. This parameter is optional.

TLSServerCertSubject: allowed server certificate owner. This parameter is optional.

Configure certificate encryption

The configuration parameters mentioned earlier only need to configure TLSCAFile, TLSCertFile, and TLSKeyFile in Zabbix server, and you can also use the TLSCRLFile parameter to configure the revocation certificate list if necessary. For example:

# vi / etc/zabbix/zabbix_server.conf

TLSCAFile=/etc/zabbix/zabbix_root_ca.cert

TLSCertFile=/etc/zabbix/zabbix_server.cert

TLSKeyFile=/etc/zabbix/zabbix_server.key

After the configuration is complete, you need to restart the configuration related to the server certificate before it can take effect.

19.3.4 Proxy configure Certificate encryption

To configure certificate encryption for Proxy, you need to configure TLSCAFile, TLSCertFile and TLSKeyFile, which correspond to the top-level CA certificate file, proxy certificate (certificate chain) file and proxy private key file, respectively. You can also use the TLSCRLFile parameter to configure the revocation certificate list if necessary.

If proxy is set to active (active) mode, you must configure TLSConnect to cert,passive (passive) mode. You need to configure TLSAccept to cert.

For example:

# vi/etc/zabbix/zabbix_proxy.conf

TLSConnect=cert

TLSAccept=cert

TLSCAFile=/etc/zabbix/zabbix_root_ca.cert

TLSCertFile=/etc/zabbix/zabbix_proxy.cert

TLSKeyFile=/etc/zabbix/zabbix_proxy.key

With the above configuration, you have completed the most basic certificate encryption of proxy. Note that the proxy configuration needs to be restarted to take effect.

To improve the security of proxy, you can configure the TLSServerCertIssuer and TLSServerCertSubject parameters in the configuration file, for example:

TLSServerCertIssuer=CN=zabbix ca root,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

TLSServerCertSubject=CN=zabbix server,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

Then go to the Zabbix front-end page to configure proxy encryption, go to the Administration-> Proxies page, click the proxy name to enter the proxy configuration page, in the Encryption tab, select Certificate encryption method, and enter the Issuer and Subject fields.

The Active (active) proxy configuration is shown in figure 19-5 below.

Figure 19-5

The Passive (passive) proxy configuration is shown in figure 19-6 below.

Figure 19-6

19.3.5 Agent configure Certificate encryption

To configure certificate encryption for Agent, you need to configure TLSCAFile, TLSCertFile and TLSKeyFile, which correspond to the top-level CA certificate file, agent certificate (certificate chain) file and agent private key file, respectively. You can also use the TLSCRLFile parameter to configure the revocation certificate list if necessary.

If agnet is set to active (active) mode, you must configure TLSConnect to cert,passive (passive) mode. You need to configure TLSAccept to cert.

For example:

# vi/etc/zabbix/zabbix_proxy.conf

TLSConnect=cert

TLSAccept=cert

TLSCAFile=/etc/zabbix/zabbix_root_ca.cert

TLSCertFile=/etc/zabbix/zabbix_agent.cert

TLSKeyFile=/etc/zabbix/zabbix_agent.key

With the above configuration, you have completed the most basic certificate encryption of agent. Note that the proxy configuration needs to be restarted to take effect.

To improve the security of agent, you can configure the TLSServerCertIssuer and TLSServerCertSubject parameters in the configuration file, for example:

TLSServerCertIssuer=CN=zabbix ca root,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

TLSServerCertSubject=CN=zabbix server,OU=IT Dept,O=MyCompany,ST=Beijing,C=CN

Then go to the Zabbix front-end page to configure agent encryption, go to the Configuration-> Hosts page, click the host name to enter the host configuration page, in the Encryption tab, select Certificate encryption method, and fill in the Issuer and Subject fields. This is shown in figure 19-7 below.

Figure 19-7

19.3.5 configure Certificate revocation list

A certificate may be designated as revocation due to disclosure of the secret key, disclosure of CA, change of dependency, or termination of business, and CA publishes a certificate revocation list (CRL) that lists the serial numbers of certificates that are considered to be unusable. The certificate revocation list can be configured using the TLSCRLFile parameter in the Zabbix server, proxy, or agent configuration file. For example: TLSCRLFile=/etc/zabbix/zabbix_crl_file.

CRLs from multiple CA may be included in the zabbix_crl_file, for example:

-BEGIN X509 CRL-

MIIB/DCB5QIBATANBgkqhkiG9w0BAQUFADCBgTETMBEGCgmSJomT8ixkARkWA2Nv

...

TreZeUPjb7LSmZ3K2hpbZN7SoOZcAoHQ3GWd9npuctg=

-END X509 CRL-

-BEGIN X509 CRL-

MIIB+TCB4gIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQBGRYDY29t

...

CAEebS2CND3ShBedZ8YSil59O6JvaDP61lR5lNs=

-END X509 CRL-

The CRL file is only loaded when the Zabbix component starts, and the Zabbix component must be restarted after updating the CRL file.

19.3.5 FAQ

When establishing encrypted communication between components in Zabbix, one end is TLS client, and the other is TLS server. No matter it is Zabbix server, proxy or agent, it can run as TLS server and client. For example, when Zabbix server connects to a passive agent, server is a TLS client and agent is a TLS server. When active agent connects to proxy, agent is a TLS client and proxy is a TLS server. But the zabbix_get and zabbix_sender tools are always TLS clients.

Zabbix uses mutual authentication, and each party verifies the identity of the peer. If the certificate of the peer is invalid, the connection is immediately closed and recorded in the log file. Therefore, when you encounter a rejected connection, you should check the server-side log file to determine the reason why the connection was rejected. The error messages recorded in the client log are more general, such as Connection closed by peer or connection was non-properly terminated.

Sometimes configuration errors can also produce confusing error messages that do not clearly indicate the real cause of the error. Below we will list some common error messages and possible causes of problems. However, it is important to note that different encryption toolkits produce different error messages for the same problem.

1. Connection type and permission issues

Server configures PSK to connect to agent, but agent accepts only unencrypted connections.

The error message recorded in the log file of server or proxy when using the mbed TLSv1.3.11 encryption kit is: Get valuefrom agent failed: ssl_handshake (): SSL-The connection indicated an EOF.

When using the GnuTLS v3.3.16 encryption kit, the error message recorded in the log file of server or proxy is: Get value from agent failed: zbx_tls_connect (): gnutls_handshake () failed:-110 The TLS connection was non-properly terminated.

When using the OpenSSLv1.0.2c encryption kit, the error message recorded in the log file of server or proxy is: Get valuefrom agent failed: TCP connection successful, cannot establish TLS to [[127.0.0.1]: 10050]: Connection closed by peer. Check allowed connection typesand access rights

One end uses a certificate to connect but the other end only accepts PSK, and vice versa.

The error message logged in the log file when using the mbed TLS encryption kit is: failed to accept an incoming connection: from 127.0.0.1:ssl_handshake (): SSL-The server has no ciphersuites in common with the client.

The error message recorded in the log file when using the GnuTLS encryption kit is: failed to accept an incoming connection: from 127.0.0.1:zbx_tls_accept (): gnutls_handshake () failed:-21 Could not negotiate asupported cipher suite.

The error message recorded in the log file when using the OpenSSL v1.0.2c encryption kit is: failed to accept an incoming connection: from 127.0.0.1: TLShandshake returned error code 1: file.\ ssl\ s3_srvr.c line 1411:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher: TLS writefatal alert "handshake failure"

2. Certificate problem

OpenSSL uses some CA's CRL in the certificate chain, and the TLSCRLFile parameter is not configured to include these CRL.

The error message recorded in the TLS server log using mbed TLS and OpenSSL is: failed to accept an incoming connection: from 127.0.0.1: TLShandshake with 127.0.0.1 returned error code 1: file s3_srvr.c line 3251:error:14089086: SSL outines:ssl3_get_client_certificate:certificate verifyfailed: TLS write fatal alert "unknown CA".

When using GnuTLS, the error message recorded in the TLS server log is: failed toaccept an incoming connection: from 127.0.0.1: TLS handshake with 127.0.0.1returned error code 1: file rsa_pk1.c line 103: error:0407006A: rsaroutines:RSA_padding_check_PKCS1_type_1: block type is not 01 file rsa_eay.cline 705: error:04067072: rsa outines:RSA_EAY_PUBLIC_DECRYPT:paddin

CRL expires or expires during server operation

The error message logged in the server log when using OpenSSL is:

Before expiration: cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]: 20004]: SSL_connect () returnedSSL_ERROR_SSL: file s3_clnt.c line 1253: error:14090086: SSLroutines:ssl3_get_server_certificate:certificate verify failed: TLS write fatalalert "certificate revoked".

After expiration: cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]: 20004]: SSL_connect () returnedSSL_ERROR_SSL: file s3_clnt.c line 1253: error:14090086: SSLroutines:ssl3_get_server_certificate:certificate verify failed: TLS write fatalalert "certificate expired".

The error message recorded in the server log when using GnuTLS is (the same before and after expiration): cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]: 20004]: invalid peercertificate: The certificate is NOT trusted. The certificate chain is revoked .

The error message logged in the server log when using mbed TLS is:

Before expiration: cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]: 20004]: invalid peercertificate: revoked.

After expiration: cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]: 20004]: invalid peercertificate: revoked, CRL expired.

3. PSK problem

PSK contains odd hexadecimal digits

Proxy or agent cannot be started properly. The error message recorded in the proxy or agent log file is: invalidPSK in file "/ etc/zabbix/proxy_or_agent.psk"

The length of PSK identity string is more than 128bytes when using GnuTLS

The error message logged in the TLS client log file is: gnutls_handshake () failed:-110 The TLS connection was non-properly terminated.

The error message logged in the TLS server log file is: gnutls_handshake () failed:-90 The SRP username supplied is illegal.

When using mbed TLS, the PSK length exceeds 32 bytes, and the error message recorded in the log file of any component of Zabbix is: ssl_set_psk (): SSL-Bad input parameters to function.

From http://ustogether.blog.51cto.com/8236854/1931618, if you need to reprint, please contact the author.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.