Criptografia usando certificados

Visão geral

O Zabbix pode usar certificados RSA no formato PEM, assinados por uma autoridade certificadora (CA) pública ou interna.

A verificação do certificado é realizada com base em um certificado de CA pré-configurado. Opcionalmente, Listas de Revogação de Certificados (CRL) podem ser usadas.

Cada componente do Zabbix pode ter apenas um certificado configurado.

Para obter mais informações sobre como configurar e operar uma CA interna, gerar e assinar solicitações de certificado e revogar certificados, consulte tutoriais como o OpenSSL PKI Tutorial v2.0.

Considere e teste cuidadosamente as extensões do seu certificado. Para mais detalhes, consulte Limitações no uso de extensões de certificado X.509 v3.

Parâmetros de configuração de certificado

Os seguintes parâmetros de configuração são suportados para configurar certificados nos componentes do Zabbix.

Parameter Mandatory Description
TLSCAFile yes Caminho completo de um arquivo que contém os certificados da(s) CA(s) de nível superior para verificação do certificado do par.
Se estiver usando uma cadeia de certificados com vários membros, ordene os certificados com os certificados da(s) CA(s) de nível inferior primeiro, seguidos pelos certificados da(s) CA(s) de nível superior.
Certificados de várias CAs podem ser incluídos em um único arquivo.
TLSCRLFile no Caminho completo de um arquivo que contém Listas de Revogação de Certificados (CRL).
TLSCertFile yes Caminho completo de um arquivo que contém o certificado.
Se estiver usando uma cadeia de certificados com vários membros, ordene os certificados com o certificado do server, proxy ou agent primeiro, seguido pelos certificados da(s) CA(s) de nível inferior e, por fim, pelos certificados da(s) CA(s) de nível superior.
TLSKeyFile yes Caminho completo de um arquivo que contém a chave privada.
Certifique-se de que este arquivo seja legível apenas pelo usuário do Zabbix, definindo as permissões de acesso apropriadas.
TLSServerCertIssuer no Emissor permitido do certificado do server.
TLSServerCertSubject no Assunto permitido do certificado do server.

Exemplos de configuração

Após configurar os certificados necessários, configure os componentes do Zabbix para usar criptografia baseada em certificado.

Abaixo estão as etapas detalhadas para configurar:

Zabbix server

1. Prepare o arquivo de certificado da CA.

Para verificar certificados de pares, o Zabbix server deve ter acesso ao arquivo que contém os certificados raiz da CA de nível superior, autoassinados. Por exemplo, se forem necessários certificados de duas CAs raiz independentes, coloque-os em um arquivo em /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. Coloque o certificado/cadeia de certificados do Zabbix server em um arquivo, por exemplo, em /home/zabbix/zabbix_server.crt. O primeiro certificado é o certificado do Zabbix server, seguido pelo certificado da CA intermediária:

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-----

Use apenas os atributos mencionados acima para os certificados do cliente e do server para evitar afetar o processo de verificação do certificado. Por exemplo, o OpenSSL pode falhar ao estabelecer uma conexão criptografada se as extensões X509v3 Subject Alternative Name ou Netscape Cert Type forem usadas. Para mais informações, consulte Limitações no uso de extensões de certificado X.509 v3.

3. Coloque a chave privada do Zabbix server em um arquivo, por exemplo, em /home/zabbix/zabbix_server.key:

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

4. Edite os parâmetros de configuração de TLS no arquivo de configuração do Zabbix server:

TLSCAFile=/home/zabbix/zabbix_ca_file.crt
TLSCertFile=/home/zabbix/zabbix_server.crt
TLSKeyFile=/home/zabbix/zabbix_server.key
Zabbix proxy

1. Prepare os arquivos com os certificados CA de nível superior, o certificado/cadeia de certificados do Zabbix proxy e a chave privada, conforme descrito na seção Zabbix server. Em seguida, edite os parâmetros TLSCAFile, TLSCertFile e TLSKeyFile no arquivo de configuração do Zabbix proxy de acordo.

2. Edite parâmetros TLS adicionais no arquivo de configuração do Zabbix proxy:

  • Para proxy ativo: TLSConnect=cert
  • Para proxy passivo: TLSAccept=cert

Para melhorar a segurança do proxy, você também pode definir os parâmetros TLSServerCertIssuer e TLSServerCertSubject. Para mais informações, consulte Restricting allowed certificate issuer and subject.

Os parâmetros TLS no arquivo final de configuração do proxy podem ser semelhantes aos seguintes:

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. Configure a criptografia para este proxy no frontend do Zabbix:

  • Acesse: Administration > Proxies.
  • Selecione o proxy e clique na aba Encryption.

Nos exemplos abaixo, os campos Issuer e Subject estão preenchidos. Para mais informações sobre por que e como usar esses campos, consulte Restricting allowed certificate issuer and subject.

Para proxy ativo:

Para proxy passivo:

}

Zabbix agent

1. Prepare files with the top-level CA certificates, the Zabbix agent certificate/certificate chain, and the private key as described in the Zabbix server section. Then, edit the TLSCAFile, TLSCertFile, and TLSKeyFile parameters in the Zabbix agent configuration file accordingly.

2. Edit additional TLS parameters in the Zabbix agent configuration file:

  • For active agent: TLSConnect=cert
  • For passive agent: TLSAccept=cert

Para melhorar a segurança do agent, você pode definir os parâmetros TLSServerCertIssuer e TLSServerCertSubject. Para mais informações, consulte Restricting allowed certificate issuer and subject.

Os parâmetros TLS no arquivo final de configuração do agent podem ser semelhantes ao seguinte. Observe que o exemplo pressupõe que o host seja monitorado por um proxy, portanto ele é especificado como o Subject do certificado:

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. Configure a criptografia no frontend do Zabbix para o host monitorado por este agent.

  • Vá para: Data collection > Hosts.
  • Selecione o host e clique na aba Encryption.

No exemplo abaixo, os campos Issuer e Subject estão preenchidos. Para mais informações sobre por que e como usar esses campos, consulte Restricting allowed certificate issuer and subject.

Zabbix web service

1. Prepare os arquivos com os certificados CA de nível superior, o certificado/cadeia de certificados do Zabbix web service e a chave privada, conforme descrito na seção Zabbix server. Em seguida, edite os parâmetros TLSCAFile, TLSCertFile e TLSKeyFile no arquivo de configuração do Zabbix web service de acordo.

2. Edite um parâmetro TLS adicional no arquivo de configuração do Zabbix web service: TLSAccept=cert

Os parâmetros TLS no arquivo final de configuração do web service podem ser semelhantes ao seguinte:

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

3. Configure o Zabbix server para se conectar ao Zabbix web service configurado com TLS editando o parâmetro WebServiceURL no arquivo de configuração do Zabbix server:

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

Restrição do emissor e do assunto do certificado permitidos

Quando dois componentes do Zabbix (por exemplo, server e agent) estabelecem uma conexão TLS, eles validam os certificados um do outro. Se um certificado do par for assinado por uma CA confiável (com um certificado de nível superior pré-configurado em TLSCAFile), for válido, não tiver expirado e passar em outras verificações, então a comunicação entre os componentes pode prosseguir. Nesse caso mais simples, o emissor e o assunto do certificado não são verificados.

No entanto, isso apresenta um risco: qualquer pessoa com um certificado válido pode se passar por outra pessoa (por exemplo, um certificado de host poderia ser usado para se passar por um server). Embora isso possa ser aceitável em ambientes pequenos, onde os certificados são assinados por uma CA interna dedicada e o risco de personificação é baixo, pode não ser suficiente em ambientes maiores ou mais sensíveis do ponto de vista de segurança.

Se a sua CA de nível superior emite certificados que não devem ser aceitos pelo Zabbix ou se você quiser reduzir o risco de personificação, você pode restringir os certificados permitidos especificando o emissor e o assunto deles.

Por exemplo, no arquivo de configuração do Zabbix proxy, você poderia especificar:

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

Com essas configurações, um proxy ativo não se comunicará com um Zabbix server cujo certificado tenha um emissor ou assunto diferente. Da mesma forma, um proxy passivo não aceitará solicitações desse server.

Regras para correspondência de strings Issuer e Subject

As regras para correspondência de strings Issuer e Subject são as seguintes:

  • As strings Issuer e Subject são verificadas independentemente. Ambas são opcionais.
  • Uma string não especificada significa que qualquer string é aceita.
  • As strings são comparadas como estão e devem corresponder exatamente.
  • Caracteres UTF-8 são suportados. No entanto, curingas (*) ou expressões regulares não são suportados.
  • Os seguintes requisitos do RFC 4514 são implementados - caracteres que exigem escape (com uma barra invertida '\', U+005C):
    • em qualquer parte da string: '"' (U+0022), '+' (U+002B), ',' (U+002C), ';' (U+003B), '<' (U+003C), '>' (U+003E), '\\' (U+005C);
    • no início da string: espaço (' ', U+0020) ou cerquilha ('#', U+0023);
    • no final da string: espaço (' ', U+0020).
  • Caracteres nulos (U+0000) não são suportados. Se um caractere nulo for encontrado, a correspondência falhará.
  • Os padrões RFC 4517 e RFC 4518 não são suportados.

Por exemplo, se as strings de organização (O) de Issuer e Subject contiverem espaços no final e a string de unidade organizacional (OU) de Subject contiver aspas duplas, esses caracteres devem ser escapados:

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
Ordem e formatação dos campos

O Zabbix segue as recomendações da RFC 4514, que especifica uma ordem "reversa" para esses campos, começando pelos campos de nível mais baixo (CN), passando pelos campos de nível intermediário (OU, O) e concluindo com os campos de nível mais alto (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

Em contraste, o OpenSSL, por padrão, exibe as strings Issuer e Subject na ordem do nível mais alto para o mais baixo. No exemplo a seguir, os campos Issuer e Subject começam com o nível mais alto (DC) e terminam com o campo de nível mais baixo (CN). A formatação com espaços e separadores de campos também varia de acordo com as opções usadas e, portanto, não corresponderá ao formato exigido pelo 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

Para formatar corretamente as strings Issuer e Subject para o Zabbix, invoque o OpenSSL com as seguintes opções:

$ 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

A saída então estará na ordem reversa, separada por vírgulas, e poderá ser usada nos arquivos de configuração do Zabbix e no frontend:

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

Limitações no uso de extensões de certificado X.509 v3

Ao implementar certificados X.509 v3 no Zabbix, algumas extensões podem não ser totalmente suportadas ou podem resultar em comportamento inconsistente.

Extensão Subject Alternative Name

O Zabbix não suporta a extensão Subject Alternative Name, que é usada para especificar nomes DNS alternativos, como endereços IP ou endereços de e-mail. O Zabbix só pode validar o valor no campo Subject do certificado (consulte Restricting Allowed Certificate Issuer and Subject). Se os certificados incluírem o campo subjectAltName, o resultado da validação do certificado pode variar dependendo dos toolkits criptográficos específicos usados para compilar os componentes do Zabbix. Como resultado, o Zabbix pode aceitar ou rejeitar certificados com base nessas combinações.

Extensão Extended Key Usage

O Zabbix suporta a extensão Extended Key Usage. No entanto, se ela for usada, geralmente é necessário que os atributos clientAuth (para autenticação de cliente TLS WWW) e serverAuth (para autenticação de servidor TLS WWW) sejam especificados. Por exemplo:

  • Em verificações passivas, nas quais o agent do Zabbix opera como um servidor TLS, o atributo serverAuth deve ser incluído no certificado do agent.
  • Em verificações ativas, nas quais o agent opera como um cliente TLS, o atributo clientAuth deve ser incluído no certificado do agent.

Embora o GnuTLS possa emitir um aviso para violações de uso de chave, ele normalmente permite que a comunicação continue apesar desses avisos.

Extensão Name Constraints

O suporte à extensão Name Constraints varia entre os toolkits criptográficos. Certifique-se de que o toolkit escolhido suporte essa extensão. Essa extensão pode impedir o Zabbix de carregar certificados CA se esta seção estiver marcada como crítica, dependendo do toolkit específico em uso.

Listas de Revogação de Certificados (CRL)

Se um certificado for comprometido, a Autoridade Certificadora (CA) pode revogá-lo incluindo o certificado em uma Lista de Revogação de Certificados (CRL). As CRLs são gerenciadas por meio de arquivos de configuração e podem ser especificadas usando o parâmetro TLSCRLFile nos arquivos de configuração do server, proxy e agent. Por exemplo:

TLSCRLFile=/home/zabbix/zabbix_crl_file.crt

Nesse caso, zabbix_crl_file.crt pode conter CRLs de várias CAs e pode ter a seguinte aparência:

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

O arquivo CRL é carregado somente quando o Zabbix é iniciado. Para atualizar a CRL, reinicie o Zabbix.

Se os componentes do Zabbix forem compilados com OpenSSL e as CRLs forem usadas, certifique-se de que cada CA de nível superior e intermediária nas cadeias de certificados tenha uma CRL correspondente (mesmo que esteja vazia) incluída no TLSCRLFile.

Solução de problemas de certificados

OpenSSL usado com CRLs e, para algumas CA na cadeia de certificados, sua CRL não está incluída em TLSCRLFile

No log do servidor TLS no caso de um peer 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"

No log do servidor TLS no caso de um peer 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 expirada ou que expira durante a operação do server

[OpenSSL]{.underline}, no log do server:

  • antes da expiração:
<!-- -->
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"
  • após a expiração:
<!-- -->
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"

O ponto aqui é que, com uma CRL válida, um certificado revogado é reportado como "certificate revoked". Quando a CRL expira, a mensagem de erro muda para "certificate expired", o que é bastante enganoso.

[GnuTLS]{.underline}, no log do server:

  • antes e depois da expiração, o mesmo:
<!-- -->
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.
Certificado autoassinado, CA desconhecida

[OpenSSL]{.underline}, no log:

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"'

Isso foi observado quando o certificado do server, por engano, tinha as mesmas strings de Issuer e Subject, embora estivesse assinado por uma CA. Issuer e Subject são iguais no certificado CA de nível superior, mas não podem ser iguais no certificado do server. (O mesmo se aplica aos certificados de proxy e agent.)

Para verificar se um certificado contém as mesmas entradas de Issuer e Subject, execute:

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

É aceitável que o certificado raiz (de nível superior) tenha valores idênticos para Issuer e Subject.