Zabbix 3.0中非常重要的一个特性就是支持对Zabbixserver、Zabbix proxy、Zabbix agent、zabbix_sender和zabbix_get之间的通信进行加密，支持Certificate-based（基于证书）和pre-shared key-based（基于预共享秘钥）的加密，不再像早期版本那样需要额外的解决方案。
Zabbix 3.0中加密是独立组件，作为配置选项进行配置时非常灵活，可以针对不同的hosts设置不同的加密方式。例如有些proxy 和agents配置使用Certificate-based加密和server之间的通信，有些使用pre-sharedkey-based加密，而另外一些没有配置加密。如下图19-1所示。
图 19-1
Zabbix使用Transport LayerSecurity (TLS) protocol v1.2进行加密，为了让Zabbix支持加密功能，在源码编译安装时必须要链接到下面三个加密库中的其中一个。
mbed TLS：早期也叫PolarSSL，目前仅支持1.3.x版本。注意不支持2.x版本。
GnuTLS：支持v3.1.18及更高的版本。
OpenSSL：支持v1.0.1及更高的版本。
根据你的选择，configure脚本可以使用下面的某个选项：
--with-mbedtls[=DIR]
--with-gnutls[=DIR]
--with-openssl[=DIR]
例如：
# ./configure--enable-server --enable-agent --with-mysql --enable-ipv6 --with-net-snmp--with-libcurl --with-libxml2 --with-openssl
在编译安装Zabbix的不同组件时可以使用不同的加密库，例如server使用OpenSSL，agent使用GnuTLS。建议使用OpenSSL，在实际测试中OpenSSL是最快的，接下来是GnuTLS。
如果你使用安装包安装Zabbix组件时，默认已经支持加密功能。你可以通过查看日志文件确定Zabbix安装的功能特性。例如下面是Zabbixserver启动时显示的特性列表。
# vi/var/log/zabbix/zabbix_server.log
1065:20150817:103017.520****** Enabled features ******
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:20150817:103017.520******************************
近日完成《深入浅出 zabbix 4.0》视频教程的录制并正式发布，该教程基于 zabbix 4.2 ，对Zabbix进行全面讲解。欢迎大家围观。课程链接：https://edu.51cto.com/sd/ce000
Zabbix中使用PSK（pre-shared key）加密时，需要提供标识符（PSKidentity）和加密字符串（PSK string）。PSK identity是一个非空的UTF-8字符串，例如PSK ID 001 zabbix agent，在这里仅仅作为一个特定PSK的名称，方便Zabbix中各组件的引用。由于PSK identity在网络中是明文传输，因此在名称中不要涉及到敏感信息。PSK string是由十六进制组成的字符串，例如e560cb0d918d26d31b4f642181f5f570ad89a390931102e5391d08327ba434e9。
在Zabbix中使用PSK加密时，对PSK identity和PSK string长度是有限制的。在Zabbix前端页面中配置PSK identity的长度可以达到128个字符，PSK string的长度可以达到2048个bit，但也要看使用的加密库的限制。如果配置的字符串长度超过限制会导致Zabbix各组件之间通信失败。
例如Zabbix server使用PSK连接到agent之前，server会在数据库中查找agent配置的PSK identity和PSK string，当收到agent配置的PSK identity和PSK string后进行比较，如果双方具有相同的PSK identity和PSK string时将成功连接。
长度限制的参数如下表19-1所示。
表 19-1
组件 | PSK identity最大长度 | PSK string最小长度 | 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) |
在CentOS中可以使用不同的工具生成PSK，下面就以生成一个256-bit（32字节）PSK为例来看一下。
使用OpenSSL
# openssl rand -hex 32
3e2b2ef85c2ad0af3410c9a495fe77d0a8741c2f1243c2af73a2e17623f70098
使用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
使用psktool工具时会生成一个文件，格式为pskidentity:psk string，在Zabbix中使用该文件时需要把psk identity:删除，只保留psk string。
配置步骤：
1、 在agnet主机中，将PSK string保存到一个文件中。例如 /etc/zabbix/zabbix_agentd.psk。
# vi /etc/zabbix/zabbix_agentd.psk
3e2b2ef85c2ad0af3410c9a495fe77d0a8741c2f1243c2af73a2e17623f70098
2、 设置zabbix_agentd.psk文件的访问权限。
# chown zabbix:zabbix /etc/zabbix/zabbix_agentd.psk
# chmod 644 /etc/zabbix/zabbix_agentd.psk
3、 编辑zabbix_agentd.conf配置文件。
# vi /etc/zabbix/zabbix_agentd.conf
TLSConnect=psk
TLSAccept=psk
TLSPSKFile=/etc/zabbix/zabbix_agentd.psk
TLSPSKIdentity=PSKAgent
如果agnet类型为active（主动式）agent，那么agent将连接到server并接收来自server和zabbix_get使用PSK加密的连接，PSK identity为PSK Agent。
4、 重启agent，使用zabbix_get进行测试。
# 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、 在Zabbix前端页面中配置加密，在Configuration--> Hosts页面中点击需要配置的主机名称，进入主机配置页面的Encryption标签中进行设置。如下图19-2所示。
图 19-2
在主机列表中AGENT ENCRYPTION列中可以很清楚的看到当前使用的加密方式，如下图19-3所示。
图 19-3
配置步骤：
1、 在proxy主机中，将PSK string保存到一个文件中。例如 /etc/zabbix/zabbix_proxy.psk。
# vi /etc/zabbix/zabbix_proxy.psk
3e2b2ef85c2ad0af3410c9a495fe77d0a8741c2f1243c2af73a2e17623f70098
2、 设置zabbix_proxy.psk文件的访问权限。
# chown zabbix:zabbix /etc/zabbix/zabbix_proxy.psk
# chmod 644 /etc/zabbix/zabbix_proxy.psk
3、 编辑zabbix_proxy.conf配置文件。
# vi /etc/zabbix/zabbix_proxy.conf
TLSConnect=psk
TLSPSKFile=/etc/zabbix/zabbix_proxy.psk
TLSPSKIdentity=PSKProxy
4、 重启proxy，Proxy将使用PSK加密连接到server，PSK identity为PSK Proxy。
5、 在Zabbix前端页面中配置加密，在Administration--> Proxies页面中点击需要配置的proxy名称，进入proxy配置页面的Encryption标签中进行设置。如下图19-4所示。
图 19-4
检查Zabbix server和proxy的日志文件，出现下面类似的信息说明配置有问题。
# 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"
Passive（被动式）proxy的设置过程和主动式proxy的类似，唯一不同的是在proxy的配置文件中设置了TLSAccept=psk，并在Zabbix前端页面中设置Connections to proxy。
Zabbix可以使用一个公共的或内部证书颁发机构签名的PEM格式的RSA证书，证书的验证依赖一个预先配置的CA证书。Zabbix不支持自签名的证书，必须是CA颁发的证书。每个Zabbix组件只能配置一个证书。
利用OpenSSL强大的命令行工具，我们可以生成和创建Zabbix中配置证书加密需要的文件，包括顶级自签名的根CA证书文件、Zabbix组件私钥（private key）文件及签署的Zabbix组件证书或证书链（certificatechain）文件。
证书的内容包括：CA的信息、公钥用户的信息、公钥、CA的签字和有效期等等。证书的格式和验证方法普遍遵循X.509国际标准。
CA也拥有一个证书（内含公钥）和私钥。用户通过验证CA的签字从而信任证书，任何人都可以得到CA的证书（内含公钥），用以验证它所签发的证书。因此Zabbixserver必须能够访问到顶级自签名的根CA证书文件。如果你使用多个来自不同根CAs的证书时，可以将它们放在同一个文件中，例如下面的文件/etc/zabbix/zabbix_root_ca.cert所示。
# 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-----
CA的严格层次结构可以描绘为一棵倒置的树，在这棵倒置的树上，根代表一个对整个PKI域内的所有实体都具有特别意义的CA，通常被称作根CA，把它作为信任的根或称“信任锚”。在根CA的下面是零层或多层的中间CA，因为是属于根的，也称作子CA，子CA可作为中间节点，再伸出分支，最后是树的叶子，被称作终端实体或称为终端用户。
证书链由两个环节组成：信任锚环节（CA证书）和已签名证书环节。自我签名的证书仅有一个环节的长度，信任锚环节就是已签名证书本身。
证书链可以拥有任意环节的长度。所以在三节的证书链中，信任锚证书CA环节可以对中间证书签名，中间证书的拥有者可以用自己的私钥对另一个证书签名。 证书链是CA证书发出的证书序列，最终以根CA证书结束。证书最初生成时是一个自签名证书，自签名证书是签发机构名（Issuer）和证书用户名（Subjet）相同的证书。自签名证书是证书链中的最后一个证书。证书链中的每个证书都需要使用链中的前一个证书的公钥进行验证，直到自签名的根证书。
证书链文件如下面的例子所示。
# 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
...
h02u1GHiy46GI+xfR3LsPwFKlkTaaLaL/6aaoQ==
-----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-----
Zabbix组件私钥（private key）应单独保存到一个文件，例如下面的文件所示。
# cat /etc/zabbix/ zabbix_server.key
-----BEGIN PRIVATE KEY-----
MIIEwAIBADANBgkqhkiG9w0BAQEFAASCBKowggSmAgEAAoIBAQC9tIXIJoVnNXDl
...
IJLkhbybBYEf47MLhffWa7XvZTY=
-----END PRIVATE KEY-----
当Zabbix server、proxy或agent之间建立TLS连接时，相互之间会对证书进行检查，如果双方证书都是由同一个信任的CA颁发的，就会认为是有效合法的，对证书的有效期和其他一些参数检查通过后，建立连接开始通信。在最简单的场景中不检查证书的Issuer和Subject，但这样做会有风险，持有同一个信任的CA颁发的证书的人可以冒充别人。为了提高安全性，我们可以在Zabbix proxy或agent中配置特定证书的Issuer和Subject，只允许匹配的证书。
例如，在proxy配置文件中指定Issuer和Subject：
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
当完成上面的配置后，active（主动式）proxy不会和证书中Issuer或Subject不同的Zabbix server建立连接。Passive（被动式）proxy不会响应来自server的请求。
zabbix_get和zabbix_sender工具也可以在命令行中使用Issuer和Subject。
Zabbix中进行Issuer和Subject字符串匹配时需要注意：
Issuer和Subject字符串时单独检查的，两者都是可选的。
允许使用UTF-8字符。
未指定字符串时意味着可以接受任意的字符串。
字符串比较时必须完全相同才认为匹配成功。
不支持通配符和正则表达式的匹配。
只实现了RFC 4514Lightweight Directory Access Protocol (LDAP): String Representation ofistinguished Names中只有部分要求。
可以使用转义字符'“'(U+0022), '+' U+002B, ',' U+002C, ';' U+003B, '<' U+003C, '>' U+003E, '\'U+005C。
转义字符空格（' 'U+0020）和数组符号（'#' U+0023）只能在字符串的开头使用。
如果遇到null字符（U+0000）将匹配失败。
不支持RFC 4517Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules 和 RFC 4518 Lightweight Directory Access Protocol (LDAP):Internationalized String Preparation中的要求。
另外，Zabbix中对Issuer和Subject字符串的格式也有要求，Zabbix遵循RFC 4514的推荐使用逆序的方式。OpenSSL默认显示证书的Issuer和Subject用正常的顺序，例如：
# 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
利用OpenSSL命令行的特殊参数可以获得Issuer和Subject的逆序显示，例如：
# 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
现在你看到的是Issuer和Subject的逆序显示，每个字段之间用逗号分隔，这个字符串可以在Zabbix proxy配置文件中使用，也可以在Zabbix前端页面中使用。
在生成证书时，使用X.509 v3证书扩展项也有一些限制：
Subject Alternative Name(subjectAltName) extension：在subjectAltName扩展中定义的Alternative subject names（像IP address、e-mail address等）在Zabbix中不支持。在Zabbix中只检查Subject字段的值。
Extended Key Usage extension：如果使用该扩展项，clientAuth （TLS WWW clientauthentication）和serverAuth（TLS WWW server authentication）是必须的。例如，在被动式检查中，Zabbix agent就像是一个TLS server，所以在agent证书中必须设置serverAuth。在主动式检查中agent证书中需要设置clientAuth。在GnuTLS中会报错但允许建立连接进行通信。
Name Constraints extension：该扩展项并不是所有的加密工具都支持它，这个扩展可以防止Zabbix加载CA证书中标记为关键的部分（依赖特定的加密工具包）。
本书中只讲解通过OpenSSL创建CA证书的过程，更多的PKI、CA方面的知识，请读者自行参考相关资料。
用OpenSSL实现私有CA的具体步骤如下：
1、 生成CA私钥（公钥自动提取不用生成）并生成自签名证书及相关文件。
2、 生成用户秘钥及证书颁发请求
3、 由CA签署用户证书。
CentOS 7中OpenSSL的配置文件位于/etc/pki/tls/openssl.cnf，默认证书保存的目录为/etc/pki/CA，该目录中保存创建的证书等相关文件。利用OpenSSL的命令行工具开始创建证书之前，需要在 /etc/pki/CA目录中创建几个生成证书必要的文件。
# cd/etc/pki/CA
创建已签发证书的文本数据库文件，文件初始化为空。
#touch index.txt
创建签发证书时使用的序列号文件，该文件中保存16进制格式的序列号，文件创建时必须包含一个有效的序列号。
#echo 00 > serial
创建证书吊销列表序列号文件，该文件在创建证书吊销列表时使用，保存16进制格式的序列号。
#echo 00 > crlnumber
目录结构如下所示。
#tree .
.
├── certs # 保存已颁发的证书
├── crl # 保存已吊销的证书
├── crlnumbe # 证书吊销列表序列号
├── index.txt # 数据库文件
├── newcerts # 保存CA生成的新证书
├── private # 保存私钥文件
└── serial # 证书序列号文件
现在我们使用OpenSSL命令行创建CA及Zabbix各组件的证书，创建过程如下：
# cd /etc/pki/CA
生成CA私钥及证书颁发请求。
#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:
-----
生成自签名CA证书。
#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:03:37 2017 GMT (365 days)
Write out database with 1 new entries
Data Base Updated
生成Zabbix server私钥及证书颁发请求。
#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'
-----
由CA签署Zabbix server证书。
#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:04:24 2017 GMT (365 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
用同一CA分别签署颁发Zabbix proxy和agent证书。
#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
Zabbix中使用证书加密时需要配置以下几个参数：
TLSCAFile：包含完整路径名的顶层根CA证书文件，文件中首先是低级的CA证书，然后是高一级的CA。来自多个CA的证书可以包含在同一个文件中。该参数必须配置。
TLSCRLFile：包含完整路径名的证书吊销列表文件。该参数为可选配置。
TLSCertFile：包含完整路径名的证书（证书链）文件，在文件中首先是Zabbix server、proxy或agent证书，然后是上一级的CA证书，直到顶层CA。该参数必须配置。
TLSKeyFile：包含完整路径名的私钥文件，该文件的访问权限必须设置成只有zabbix用户可读。该参数必须配置。
TLSServerCertIssuer：允许的服务器证书颁发者。该参数为可选配置。
TLSServerCertSubject：允许的服务器证书拥有者。该参数为可选配置。
前面提到的配置参数在Zabbix server中只需要配置TLSCAFile、TLSCertFile和TLSKeyFile，如果需要也可以使用TLSCRLFile参数配置吊销证书列表。例如：
# 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
配置完成后需要重新启动server证书相关的配置才能够生效。
Proxy配置证书加密需要配置TLSCAFile、TLSCertFile和TLSKeyFile，分别对应顶级CA证书文件、proxy证书（证书链）文件和proxy私钥文件。如果需要也可以使用TLSCRLFile参数配置吊销证书列表。
如果proxy设置为active（主动）模式，必须配置TLSConnect为cert，passive（被动）模式中需要配置TLSAccept为cert。
例如：
# 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
通过上面的配置，你已经完成了proxy最基本的证书加密。注意需要重启proxy配置才能够生效。
为了提高proxy的安全性，在配置文件中可以配置TLSServerCertIssuer和 TLSServerCertSubject参数，例如：
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
然后到Zabbix前端页面配置proxy加密，进入Administration --> Proxies页面中，点击proxy名称进入proxy配置页面，在Encryption标签中，选择Certificate加密方式，填写Issuer和Subject字段。
Active （主动式）proxy配置如下图19-5所示。
图 19-5
Passive（被动式）proxy配置如下图19-6所示。
图 19-6
Agent配置证书加密需要配置TLSCAFile、TLSCertFile和TLSKeyFile，分别对应顶级CA证书文件、agent证书（证书链）文件和agent私钥文件。如果需要也可以使用TLSCRLFile参数配置吊销证书列表。
如果agnet设置为active（主动）模式，必须配置TLSConnect为cert，passive（被动）模式中需要配置TLSAccept为cert。
例如：
# 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
通过上面的配置，你已经完成了agent最基本的证书加密。注意需要重启proxy配置才能够生效。
为了提高agent的安全性，在配置文件中可以配置TLSServerCertIssuer和 TLSServerCertSubject参数，例如：
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
然后到Zabbix前端页面配置agent加密，进入Configuration --> Hosts页面中，点击主机名称进入主机配置页面，在Encryption标签中，选择Certificate加密方式，填写Issuer和Subject字段。如下图19-7所示。
图 19-7
证书可能因为泄露秘钥、泄露CA、从属关系改变或业务终止而指定为吊销证书，CA发布一个证书吊销列表（CRL），列出被认为不能再使用的证书的序列号。证书吊销列表可以在Zabbix server、proxy或agent配置文件中使用TLSCRLFile参数进行配置。例如：TLSCRLFile=/etc/zabbix/zabbix_crl_file。
在zabbix_crl_file中可能会包含来自多个CA的CRLs，例如：
-----BEGIN X509 CRL-----
MIIB/DCB5QIBATANBgkqhkiG9w0BAQUFADCBgTETMBEGCgmSJomT8ixkARkWA2Nv
...
treZeUPjb7LSmZ3K2hpbZN7SoOZcAoHQ3GWd9npuctg=
-----END X509 CRL-----
-----BEGIN X509 CRL-----
MIIB+TCB4gIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQBGRYDY29t
...
CAEebS2CND3ShBedZ8YSil59O6JvaDP61lR5lNs=
-----END X509 CRL-----
CRL文件只在Zabbix组件启动时加载，更新CRL文件更新后必须重启Zabbix 组件。
Zabbix中各组件之间建立加密通信时扮演的角色是一端为TLS客户端，另一端为TLS服务器端，无论是Zabbix server、proxy还是agent，都能以TLS 服务器和客户端的角色运行。例如Zabbix server连接到被动式agent时，server就是一个TLS 客户端，而agent是一个TLS 服务器。主动式agent连接到proxy时，agent就是一个TLS客户端，proxy就是一个TLS服务器。但是zabbix_get和zabbix_sender工具始终都是TLS客户端。
Zabbix使用相互身份验证，每一方都会验证对端的身份，如果对端的证书无效时会立即关闭连接并记录到日志文件中。因此，当遇到拒绝连接时应当检查服务器端的日志文件确定连接被拒绝的原因，客户端的日志中记录的错误信息比较笼统，例如Connection closed by peer或者connection was non-properly terminated等。
有时候配置错误也会产生令人困惑的错误信息，不能明确指出产生错误的真正原因。下面我们会列举出一些常见的错误信息以及可能发生问题的原因。但要注意不同的加密工具包对相同的问题会产生不同的错误信息。
1、连接类型和权限问题
server配置PSK连接到agent，但agent只接受未加密的连接。
使用mbed TLSv1.3.11加密工具包时在server或proxy的日志文件中记录的错误信息为：Get valuefrom agent failed: ssl_handshake(): SSL - The connection indicated an EOF。
使用GnuTLS v3.3.16加密工具包时在server或proxy的日志文件中记录的错误信息为：Get value from agent failed: zbx_tls_connect(): gnutls_handshake()failed: -110 The TLS connection was non-properly terminated。
使用OpenSSLv1.0.2c加密工具包时在server或proxy的日志文件中记录的错误信息为：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
一端使用证书连接但另一端只接受PSK，反之亦然。
使用mbed TLS 加密工具包时在日志文件中记录的错误信息为：failed to accept an incoming connection: from 127.0.0.1:ssl_handshake():SSL - The server has no ciphersuites in common with the client。
使用GnuTLS加密工具包时在日志文件中记录的错误信息为：failed to accept an incoming connection: from 127.0.0.1:zbx_tls_accept(): gnutls_handshake() failed: -21 Could not negotiate asupported cipher suite。
使用OpenSSL v1.0.2c加密工具包时在日志文件中记录的错误信息为：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、证书问题
OpenSSL在证书链中使用了一些CA的CRL，没有配置TLSCRLFile参数包括这些CRL。
使用mbed TLS和OpenSSL的情况下在TLS 服务器日志中记录的错误信息为：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"。
使用GnuTLS的情况下在TLS服务器日志中记录的错误信息为：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 过期或在服务器操作期间过期
使用OpenSSL时在服务器日志中记录的错误信息为：
过期之前：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"。
过期之后：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"。
使用GnuTLS时在服务器日志中记录的错误信息为（过期前后时相同的）：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。
使用mbed TLS时在服务器日志中记录的错误信息为：
过期之前：cannot connect to proxy "proxy-openssl-1.0.1e": TCPsuccessful, cannot establish TLS to [[127.0.0.1]:20004]: invalid peercertificate: revoked。
过期之后：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问题
PSK 包含奇数个十六进制数字
Proxy或agent不能正常启动，在proxy或agent日志文件中记录的错误信息为：invalidPSK in file "/etc/zabbix/proxy_or_agent.psk"
使用GnuTLS时PSK identity string的长度超过128个字节
在TLS 客户端日志文件中记录的错误信息为：gnutls_handshake()failed: -110 The TLS connection was non-properly terminated。
在TLS服务器日志文件中记录的错误信息为：gnutls_handshake()failed: -90 The SRP username supplied is illegal。
使用mbed TLS时PSK 长度超过了32字节，在Zabbix任意组件的日志文件中记录的错误信息为：ssl_set_psk():SSL - Bad input parameters to function。
出自http://ustogether.blog.51cto.com/8236854/1931618，如需转载请与作者联系。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
