Шифрование с использованием сертификатов

Обзор

Zabbix может использовать RSA-сертификаты в формате PEM, подписанные общедоступным или внутренним центром сертификации (CA).

Проверка сертификата выполняется по предварительно настроенному сертификату CA. При необходимости можно использовать списки отзыва сертификатов (CRL).

Для каждого компонента Zabbix можно настроить только один сертификат.

Дополнительные сведения о настройке и эксплуатации внутреннего CA, создании и подписании запросов на сертификаты, а также об отзыве сертификатов см. в руководствах, например в OpenSSL PKI Tutorial v2.0.

Тщательно продумайте и протестируйте расширения сертификата. Подробнее см. в разделе Ограничения на использование расширений сертификата X.509 v3.

Параметры конфигурации сертификатов

Следующие параметры конфигурации поддерживаются для настройки сертификатов на компонентах Zabbix.

Parameter Mandatory Description
TLSCAFile yes Полный путь к файлу, содержащему сертификаты CA верхнего уровня для проверки сертификата удаленной стороны.
Если используется цепочка сертификатов с несколькими элементами, располагайте сертификаты CA нижнего уровня первыми, а затем сертификаты CA более высокого уровня.
Сертификаты от нескольких CA можно включить в один файл.
TLSCRLFile no Полный путь к файлу, содержащему списки отзыва сертификатов (CRL).
TLSCertFile yes Полный путь к файлу, содержащему сертификат.
Если используется цепочка сертификатов с несколькими элементами, располагайте сертификат сервера, прокси или агента первым, затем сертификаты CA нижнего уровня и завершайте сертификатами CA более высокого уровня.
TLSKeyFile yes Полный путь к файлу, содержащему закрытый ключ.
Убедитесь, что этот файл доступен для чтения только пользователю Zabbix, задав соответствующие права доступа.
TLSServerCertIssuer no Допустимый издатель сертификата сервера.
TLSServerCertSubject no Допустимый субъект сертификата сервера.

Примеры конфигурации

После настройки необходимых сертификатов настройте компоненты Zabbix для использования шифрования на основе сертификатов.

Ниже приведены подробные шаги по настройке:

Сервер Zabbix

1. Подготовьте файл сертификата CA.

Чтобы проверять сертификаты узлов, сервер Zabbix должен иметь доступ к файлу, содержащему корневые самоподписанные сертификаты CA верхнего уровня. Например, если нужны сертификаты от двух независимых корневых CA, поместите их в файл /home/zabbix/zabbix_ca_file.crt:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1 CA
            ...
        Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root1 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
            ...
-----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=Root2 CA
            ...
        Subject: DC=com, DC=zabbix, O=Zabbix SIA, OU=Development group, CN=Root2 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
            ....       
-----BEGIN CERTIFICATE-----
MIID3DCCAsSgAwIBAgIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQB
...
vdGNYoSfvu41GQAR5Vj5FnRJRzv5XQOZ3B6894GY1zY=
-----END CERTIFICATE-----

2. Поместите сертификат/цепочку сертификатов сервера Zabbix в файл, например, /home/zabbix/zabbix_server.crt. Первый сертификат — это сертификат сервера Zabbix, за ним следует сертификат промежуточного CA:

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, Key Encipherment
            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=Root1 CA
        ...
        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-----

Используйте только атрибуты, указанные выше, как для клиентских, так и для серверных сертификатов, чтобы не повлиять на процесс проверки сертификата. Например, OpenSSL может не установить зашифрованное соединение, если используются расширения X509v3 Subject Alternative Name или Netscape Cert Type. Дополнительные сведения см. в разделе Ограничения на использование расширений сертификатов X.509 v3.

3. Поместите закрытый ключ сервера Zabbix в файл, например, /home/zabbix/zabbix_server.key:

-----BEGIN PRIVATE KEY-----
MIIEwAIBADANBgkqhkiG9w0BAQEFAASCBKowggSmAgEAAoIBAQC9tIXIJoVnNXDl
...
IJLkhbybBYEf47MLhffWa7XvZTY=
-----END PRIVATE KEY-----

4. Отредактируйте параметры конфигурации TLS в файле конфигурации сервера Zabbix:

TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSCertFile=/home/zabbix/zabbix_server.crt
TLSKeyFile=/home/zabbix/zabbix_server.key
Zabbix прокси

1. Подготовьте файлы с корневыми CA-сертификатами, сертификатом/цепочкой сертификатов Zabbix прокси и закрытым ключом, как описано в разделе Zabbix server. Затем соответствующим образом отредактируйте параметры TLSCAFile, TLSCertFile и TLSKeyFile в файле конфигурации Zabbix прокси.

2. Отредактируйте дополнительные параметры TLS в файле конфигурации Zabbix прокси:

  • Для активного прокси: TLSConnect=cert
  • Для пассивного прокси: TLSAccept=cert

Чтобы повысить безопасность прокси, вы также можете задать параметры TLSServerCertIssuer и TLSServerCertSubject. Дополнительные сведения см. в разделе Ограничение разрешенных издателя и субъекта сертификата.

Параметры TLS в итоговом файле конфигурации прокси могут выглядеть следующим образом:

TLSConnect=cert
TLSAccept=cert
TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix server,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSCertFile=/home/zabbix/zabbix_proxy.crt
TLSKeyFile=/home/zabbix/zabbix_proxy.key

3. Настройте шифрование для этого прокси в веб-интерфейсе Zabbix:

  • Перейдите в: Administration > Proxies.
  • Выберите прокси и нажмите вкладку Encryption.

В приведенных ниже примерах заполнены поля Issuer и Subject. Дополнительные сведения о том, зачем и как использовать эти поля, см. в разделе Ограничение разрешенных издателя и субъекта сертификата.

Для активного прокси:

Для пассивного прокси:

Zabbix agent

1. Подготовьте файлы с корневыми CA-сертификатами, сертификатом/цепочкой сертификатов Zabbix agent и закрытым ключом, как описано в разделе Zabbix server. Затем соответствующим образом отредактируйте параметры TLSCAFile, TLSCertFile и TLSKeyFile в файле конфигурации Zabbix agent.

2. Отредактируйте дополнительные параметры TLS в файле конфигурации Zabbix agent:

  • Для активного agent: TLSConnect=cert
  • Для пассивного agent: TLSAccept=cert

Чтобы повысить безопасность agent, можно задать параметры TLSServerCertIssuer и TLSServerCertSubject. Дополнительную информацию см. в разделе Ограничение разрешенных издателя и субъекта сертификата.

Параметры TLS в итоговом файле конфигурации agent могут выглядеть следующим образом. Обратите внимание, что в примере предполагается, что узел сети контролируется через proxy, поэтому он указан как Subject сертификата:

TLSConnect=cert
TLSAccept=cert
TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix proxy,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSCertFile=/home/zabbix/zabbix_agentd.crt
TLSKeyFile=/home/zabbix/zabbix_agentd.key

3. Настройте шифрование в веб-интерфейсе Zabbix для узла сети, контролируемого этим agent.

  • Перейдите в: Сбор данных > Узлы сети.
  • Выберите узел сети и нажмите вкладку Шифрование.

В примере ниже заполнены поля Issuer и Subject. Дополнительную информацию о том, зачем и как использовать эти поля, см. в разделе Ограничение разрешенных издателя и субъекта сертификата.

Zabbix web service

1. Подготовьте файлы с корневыми CA-сертификатами, сертификатом/цепочкой сертификатов Zabbix web service и закрытым ключом, как описано в разделе Zabbix server. Затем соответствующим образом отредактируйте параметры TLSCAFile, TLSCertFile и TLSKeyFile в файле конфигурации Zabbix web service.

2. Отредактируйте дополнительный TLS-параметр в файле конфигурации Zabbix web service: TLSAccept=cert

TLS-параметры в итоговом файле конфигурации web service могут выглядеть следующим образом:

TLSAccept=cert
TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSCertFile=/home/zabbix/zabbix_web_service.crt
TLSKeyFile=/home/zabbix/zabbix_web_service.key

3. Настройте сервер Zabbix на подключение к Zabbix web service, настроенному для работы по TLS, отредактировав параметр WebServiceURL в файле конфигурации сервера Zabbix:

WebServiceURL=https://example.com:443/report

Ограничение разрешенных издателя и субъекта сертификата

Когда два компонента Zabbix (например, сервер и агент) устанавливают TLS-соединение, они проверяют сертификаты друг друга. Если сертификат удаленной стороны подписан доверенным CA (с предварительно настроенным корневым сертификатом в TLSCAFile), действителен, не просрочен и проходит другие проверки, то обмен данными между компонентами может продолжаться. В этом простейшем случае издатель и субъект сертификата не проверяются.

Однако это создает риск: любой, у кого есть действительный сертификат, может выдать себя за кого-то другого (например, сертификат узла сети может быть использован для выдачи себя за сервер). Хотя это может быть приемлемо в небольших средах, где сертификаты подписаны выделенным внутренним CA и риск подмены невелик, этого может быть недостаточно в более крупных или более требовательных к безопасности средах.

Если ваш корневой CA выдает сертификаты, которые не должны приниматься Zabbix, или если вы хотите снизить риск подмены, вы можете ограничить разрешенные сертификаты, указав их издателя и субъект.

Например, в файле конфигурации прокси Zabbix можно указать:

TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix server,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com

С этими настройками активный прокси не будет взаимодействовать с сервером Zabbix, если сертификат сервера имеет другого издателя или другой субъект. Аналогично, пассивный прокси не будет принимать запросы от такого сервера.

Правила сопоставления строк Issuer и Subject

Правила сопоставления строк Issuer и Subject следующие:

  • Строки Issuer и Subject проверяются независимо. Обе строки необязательны.
  • Неуказанная строка означает, что принимается любая строка.
  • Строки сравниваются как есть и должны совпадать точно.
  • Поддерживаются символы UTF-8. Однако подстановочные знаки (*) и регулярные выражения не поддерживаются.
  • Реализованы следующие требования RFC 4514 - символы, требующие экранирования (с помощью обратной косой черты '\', U+005C):
    • в любом месте строки: '"' (U+0022), '+' (U+002B), ',' (U+002C), ';' (U+003B), '<' (U+003C), '>' (U+003E), '\\' (U+005C);
    • в начале строки: пробел (' ', U+0020) или знак номера ('#', U+0023);
    • в конце строки: пробел (' ', U+0020).
  • Символы null (U+0000) не поддерживаются. Если встречается символ null, сопоставление завершится неудачей.
  • Стандарты RFC 4517 и RFC 4518 не поддерживаются.

Например, если строки организации (O) для Issuer и Subject содержат пробелы в конце, а строка организационного подразделения (OU) для Subject содержит двойные кавычки, эти символы необходимо экранировать:

TLSServerCertIssuer=CN=Signing CA,OU=Development head,O=\ Example SIA\ ,DC=example,DC=com
TLSServerCertSubject=CN=Zabbix server,OU=Development group \"5\",O=\ Example SIA\ ,DC=example,DC=com
Порядок и форматирование полей

Zabbix следует рекомендациям RFC 4514, в которых для этих полей указан "обратный" порядок: начиная с полей нижнего уровня (CN), переходя к полям среднего уровня (OU, O) и завершая полями высшего уровня (DC).

TLSServerCertIssuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
TLSServerCertSubject=CN=Zabbix proxy,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com

В отличие от этого, OpenSSL по умолчанию отображает строки Issuer и Subject в порядке от верхнего уровня к нижнему. В следующем примере поля Issuer и Subject начинаются с верхнего уровня (DC) и заканчиваются полем нижнего уровня (CN). Форматирование с пробелами и разделителями полей также зависит от используемых параметров, поэтому оно не будет соответствовать формату, требуемому Zabbix.

$ openssl x509 -noout -in /home/zabbix/zabbix_proxy.crt -issuer -subject
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 proxy

$ openssl x509 -noout -text -in /home/zabbix/zabbix_proxy.crt
Certificate:
    ...
        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 proxy

Чтобы правильно отформатировать строки Issuer и Subject для Zabbix, вызовите OpenSSL со следующими параметрами:

$ openssl x509 -noout -issuer -subject \
    -nameopt esc_2253,esc_ctrl,utf8,dump_nostr,dump_unknown,dump_der,sep_comma_plus,dn_rev,sname\
    -in /home/zabbix/zabbix_proxy.crt

После этого вывод будет в обратном порядке, с разделением запятыми и пригоден для использования в файлах конфигурации Zabbix и веб-интерфейс:

issuer=CN=Signing CA,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com
subject=CN=Zabbix proxy,OU=Development group,O=Zabbix SIA,DC=zabbix,DC=com

Ограничения на использование расширений сертификатов X.509 v3

При реализации сертификатов X.509 v3 в Zabbix некоторые расширения могут поддерживаться не полностью или приводить к непоследовательному поведению.

Расширение Subject Alternative Name

Zabbix не поддерживает расширение Subject Alternative Name, которое используется для указания альтернативных DNS-имен, таких как IP-адреса или адреса электронной почты. Zabbix может проверять только значение в поле Subject сертификата (см. Ограничение разрешенных Issuer и Subject сертификата). Если сертификаты содержат поле subjectAltName, результат проверки сертификата может различаться в зависимости от конкретных криптографических библиотек, использованных при сборке компонентов Zabbix. В результате Zabbix может как принять, так и отклонить сертификаты в зависимости от этой комбинации.

Расширение Extended Key Usage

Zabbix поддерживает расширение Extended Key Usage. Однако при его использовании, как правило, требуется указывать оба атрибута: clientAuth (для аутентификации TLS WWW client) и serverAuth (для аутентификации TLS WWW server). Например:

  • При пассивных проверках, где Zabbix агент работает как TLS-сервер, атрибут serverAuth должен быть включен в сертификат агента.
  • Для активных проверок, где агент работает как TLS-клиент, атрибут clientAuth должен быть включен в сертификат агента.

Хотя GnuTLS может выдавать предупреждение о нарушениях использования ключа, обычно он все равно позволяет продолжить обмен данными, несмотря на эти предупреждения.

Расширение Name Constraints

Поддержка расширения Name Constraints различается в зависимости от криптографических библиотек. Убедитесь, что выбранная вами библиотека поддерживает это расширение. Это расширение может не позволить Zabbix загружать CA-сертификаты, если этот раздел помечен как критический, в зависимости от используемой библиотеки.

Списки отзыва сертификатов (CRL)

Если сертификат скомпрометирован, Центр сертификации (CA) может отозвать его, включив сертификат в Список отзыва сертификатов (CRL). CRL управляются через файлы конфигурации и могут быть указаны с помощью параметра TLSCRLFile в файлах конфигурации сервера, прокси и агента. Например:

TLSCRLFile=/home/zabbix/zabbix_crl_file.crt

В этом случае zabbix_crl_file.crt может содержать CRL от нескольких CA и может выглядеть так:

-----BEGIN X509 CRL-----
MIIB/DCB5QIBATANBgkqhkiG9w0BAQUFADCBgTETMBEGCgmSJomT8ixkARkWA2Nv
...
treZeUPjb7LSmZ3K2hpbZN7SoOZcAoHQ3GWd9npuctg=
-----END X509 CRL-----
-----BEGIN X509 CRL-----
MIIB+TCB4gIBATANBgkqhkiG9w0BAQUFADB/MRMwEQYKCZImiZPyLGQBGRYDY29t
...
CAEebS2CND3ShBedZ8YSil59O6JvaDP61lR5lNs=
-----END X509 CRL-----

Файл CRL загружается только при запуске Zabbix. Чтобы обновить CRL, перезапустите Zabbix.

Если компоненты Zabbix скомпилированы с OpenSSL и используются CRL, убедитесь, что для каждого корневого и промежуточного CA в цепочках сертификатов есть соответствующий CRL (даже если он пустой), включенный в TLSCRLFile.

Устранение неполадок с сертификатами

OpenSSL используется с CRL, и для некоторого CA в цепочке сертификатов его CRL не включен в TLSCRLFile

В журнале сервера TLS в случае узла-пира OpenSSL:

failed to accept an incoming connection: from 127.0.0.1: TLS handshake with 127.0.0.1 returned error code 1: \
    file s3_srvr.c line 3251: error:14089086: SSL routines:ssl3_get_client_certificate:certificate verify failed: \
    TLS write fatal alert "unknown CA"

В журнале сервера TLS в случае узла-пира GnuTLS:

failed to accept an incoming connection: from 127.0.0.1: TLS handshake with 127.0.0.1 returned error code 1: \
    file rsa_pk1.c line 103: error:0407006A: rsa routines:RSA_padding_check_PKCS1_type_1:\
    block type is not 01 file rsa_eay.c line 705: error:04067072: rsa routines:RSA_EAY_PUBLIC_DECRYPT:paddin
CRL истек или истекает во время работы сервера

[OpenSSL]{.underline}, в журнале сервера:

  • до истечения срока действия:
<!-- -->
cannot connect to proxy "proxy-openssl-1.0.1e": TCP successful, cannot establish TLS to [[127.0.0.1]:20004]:\
    SSL_connect() returned SSL_ERROR_SSL: file s3_clnt.c line 1253: error:14090086:\
    SSL routines:ssl3_get_server_certificate:certificate verify failed:\
    TLS write fatal alert "certificate revoked"
  • после истечения срока действия:
<!-- -->
cannot connect to proxy "proxy-openssl-1.0.1e": TCP successful, cannot establish TLS to [[127.0.0.1]:20004]:\
    SSL_connect() returned SSL_ERROR_SSL: file s3_clnt.c line 1253: error:14090086:\
    SSL routines:ssl3_get_server_certificate:certificate verify failed:\
    TLS write fatal alert "certificate expired"

Суть здесь в том, что при действительном CRL отозванный сертификат сообщается как "certificate revoked". Когда CRL истекает, сообщение об ошибке меняется на "certificate expired", что довольно вводит в заблуждение.

[GnuTLS]{.underline}, в журнале сервера:

  • до и после истечения срока действия одно и то же:
<!-- -->
cannot connect to proxy "proxy-openssl-1.0.1e": TCP successful, cannot establish TLS to [[127.0.0.1]:20004]:\
      invalid peer certificate: The certificate is NOT trusted. The certificate chain is revoked.
Самоподписанный сертификат, неизвестный CA

[OpenSSL]{.underline}, в журнале:

error:'self signed certificate: SSL_connect() set result code to SSL_ERROR_SSL: file ../ssl/statem/statem_clnt.c\
      line 1924: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:\
      TLS write fatal alert "unknown CA"'

Это наблюдалось, когда сертификат сервера по ошибке имел одинаковые строки Issuer и Subject, хотя был подписан CA. Issuer и Subject равны в корневом сертификате CA верхнего уровня, но они не могут быть равны в сертификате сервера. (То же относится к сертификатам прокси и агента.)

Чтобы проверить, содержит ли сертификат одинаковые записи Issuer и Subject, выполните:

openssl x509 -in <yourcertificate.crt> -noout -text

Для корневого сертификата верхнего уровня допустимо, чтобы значения Issuer и Subject были одинаковыми.