База знаний
Войти

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

Подсистема может использовать RSA-сертификаты в формате PEM, подписанные публичным или внутренним центром сертификации (certificate authority, CA). Проверка сертификата выполняется с использованием заранее подготовленного сертификата CA. Опционально можно использовать списки отзывов сертификатов (CRL). Каждый компонент Подсистемы может иметь только один настроенный сертификат.

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

Параметры настройки сертификатов

Параметры настройки сертификатов приведены в таблице 168.

Настройка сертификата на Сервере

Для настройки сертификата на Сервере необходимы следующие действия:

  1. для проверки сертификатов хостов Сервер должен иметь доступ к файлу с самоподписными сертификатами их корневого CA верхнего уровня. Например, если ожидаются сертификаты от двух независимых корневых CA, можно поместить их сертификаты в файл /home/zabbix/zabbix_ca_file, примерно следующим образом:
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-----
  1. поместить цепочку сертификатов Сервера в файл, например /home/zabbix/zabbix_server.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=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-----

В данном случае первым является сертификат Сервера, за ним – сертификат промежуточного CA.

Использование каких-либо параметров, кроме упомянутых выше, не рекомендуется как для клиентских, так и для серверных сертификатов, поскольку это может повлиять на процесс проверки сертификата. Например, OpenSSL может не установить зашифрованное соединение, если выставлены Расширенное использование ключа X509v3 (X509v3 Extended Key Usage) или Тип сертификата Netscape (Netscape Cert Type).

  1. поместить закрытый ключ Сервера в файл, например /home/zabbix/zabbix_server.key:
-----BEGIN PRIVATE KEY-----MIIEwAIBADANBgkqhkiG9w0BAQEFAASCBKowggSmAgEAAoIBAQC9tIXIJoVnNXDl
...
IJLkhbybBYEf47MLhffWa7XvZTY=
-----END PRIVATE KEY-----
  1. изменить параметры TLS в файле конфигурации Сервера, например:
TLSCAFile=/home/zabbix/zabbix_ca_file
TLSCertFile=/home/zabbix/zabbix_server.crt
TLSKeyFile=/home/zabbix/zabbix_server.key

Настройка шифрования на основе сертификата для Прокси

Для настройки шифрования на основе сертификата для Прокси:

  1. подготовить файлы с сертификатами CA верхнего уровня, сертификатом (цепочкой) Прокси и закрытым ключом; изменить параметры TLSCAFile, TLSCertFile, TLSKeyFile в файле конфигурации Прокси соответственно;
  2. для активного Прокси изменить параметр TLSConnect:
TLSConnect=cert

для пассивного Прокси изменить параметр TLSAccept:

TLSAccept=cert
  1. при минимальной настройке Прокси на основе сертификата можно улучшить безопасность Прокси, указав параметры TLSServerCertIssuer и TLSServerCertSubject.
  2. в конечном итоге параметры TLS в файле конфигурации Прокси могут выглядеть следующим образом:
TLSConnect=certTLSAccept=cert
TLSCAFile=/home/zabbix/zabbix_ca_file
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
  1. настроить шифрование для этого Прокси в веб-интерфейсе:
  • перейти к "Администрирование → Прокси";
  • выбрать Прокси и нажать на вкладку Шифрование.

Для активного Прокси – как на рисунке 161.

Рисунок 161 — Шифрование для активного Прокси

Для пассивного Прокси – как на рисунке 162.

Рисунок 162 — Шифрование для пассивного Прокси

Настройка шифрования на основе сертификата для Агента

Для настройки шифрования на основе сертификата для Агента:

  1. подготовить файлы с сертификатами CA верхнего уровня, сертификатом (цепочкой) Агента и закрытым ключом; изменить параметры TLSCAFile, TLSCertFile, TLSKeyFile в файле конфигурации Агента соответственно;
  2. при активных проверках изменить параметр TLSConnect:
TLSConnect=cert

При пассивных проверках изменить параметр TLSAccept:

TLSAccept=cert
  1. при минимальной настройке Агента на основе сертификата можно улучшить безопасность Агента, указав параметры TLSServerCertIssuer и TLSServerCertSubject.
  2. в конечном итоге параметры TLS в файле конфигурации Агента могут выглядеть следующим образом:
TLSConnect=certTLSAccept=certTLSCAFile=/home/zabbix/zabbix_ca_file
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

Примечание – Пример предполагает, что узел наблюдается через Прокси, отсюда возникает Субъект сертификата Прокси.

  1. настроить шифрование для этого Агента в веб-интерфейсе:
  • 5.1 перейти к "Настройка → Узлы сети";
  • 5.2 выбрать узел сети и нажать на вкладку Шифрование (рисунок 163).

Рисунок 163 — Шифрование узла сети

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

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

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

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

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

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

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

Несколько замечаний о соответствии строк Издателя и Субъекта:

  • Строки Издателя и Субъекта проверяются независимо. Обе строки опциональны.
  • Допустимы символы UTF-8.
  • Неуказанная строка означает, что принимается любая строка.
  • Строки сравниваются "как-есть", они должны в точности совпадать.
  • Шаблоны и регулярные выражения при проверке соответствия не поддерживаются.
  • Реализованы только некоторые требования из RFC 4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names en:
    • управляющие символы """ (U+0022), "+" U+002B, "," U+002C, ";" U+003B, "<" U+003C, ">" U+003E, "" U+005C в любом месте в строке.
    • управляющие символы пробела (" " U+0020) или символ решётки ("#" U+0023) в начале строки.
    • управляющий символ пробела (" " U+0020) в конце строки.
  • Совпадения не будет, если встречается нулевой символ (U+0000) (RFC 4514 en позволяет это)..
  • Требования RFC 4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules en и RFC 4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation en не поддерживаются по причине необходимого объёма работы..

Следует отметить важность очерёдности полей в строках Издателя и Субъекта, в также их форматирование. Подсистема следует рекомендации RFC 4514 en и использует "обратный" порядок этих полей.

Обратный порядок можно продемонстрировать примером:

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

Следует обратить внимание, что он начинается с нижнего уровня (CN), переходит к среднему уровню (OU, O) и заканчивается полями верхнего уровня (DC).

По умолчанию OpenSSL отображает поля Издатель и Субъект сертификата в обычном порядке в зависимости от использованных дополнительных опций:

$ 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

Здесь строки Издателя и Субъекта начинаются с верхнего уровня (DC) и заканчиваются полем нижнего уровня (CN), пробелы и разделители полей зависят от используемых опций. Ни одно из этих значений не будет совпадать в полях Издателя и Субъекта!

Для получения надлежащих строк Издателя и Субъекта, допустимых в Подсистеме, вызывают OpenSSL со специальными опциями(-nameopt esc_2253,esc_ctrl,utf8,dump_nostr,dump_unknown,dump_der,sep_comma_plus,dn_rev,sname):

$ 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
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 сертификатов

  • Расширение "Альтернативное имя субъекта" (Subject Alternative Name, subjectAltName**)**. Альтернативные имена субъектов из расширения subjectAltName (такие как IP-адрес, email-адрес) не поддерживаются Подсистемой. В Подсистеме проверяется только значение поля "Субъект". Если сертификат использует расширение subjectAltName, то результат зависит от конкретной комбинации наборов инструментов криптографии, с которыми скомпилированы компоненты Подсистемы (это расширение может работать, а может и не работать, Подсистема может отказаться принимать такие сертификаты от узлов).
  • Расширение "Использование Расширенного Ключа (Extended Key Usage)". Если используется, то, как правило, необходимо указывать как clientAuth (TLS WWW-аутентификация клиента), так и serverAuth (TLS WWW-аутентификация Сервера). Например, при пассивных проверках Агент выступает в роли TLS-сервера, поэтому необходимо указать serverAuth в сертификате Агента. При активных проверках в сертификате Агента необходимо задать clientAuth. GnuTLS выводит предупреждение в случае нарушения использования ключа, но разрешает продолжение соединения.
  • Расширение "Ограничения Имени (Name Constraints)".Не все наборы инструментов криптографии поддерживают его. Это расширение может помешать Подсистеме в загрузке сертификатов CA, где этот раздел промаркирован как критический (зависит от конкретного набора инструментов криптографии).

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

Если сертификат скомпрометирован, CA может отозвать его, включив в CRL. Списки CRL можно настраивать в файлах конфигурации Сервера, Прокси и Агента, используя параметр TLSCRLFile, например:

TLSCRLFile=/home/zabbix/zabbix_crl_file

где zabbix_crl_file может содержать списки CRL от нескольких CA и может выглядеть следующим образом:

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

CRL-файл загружается только при запуске Подсистемы. При обновлении CRL требуется перезапуск.