Crittografia tramite certificati

Panoramica

Zabbix può utilizzare certificati RSA in formato PEM, firmati da un'autorità di certificazione (CA) pubblica o interna.

La verifica del certificato viene eseguita rispetto a un certificato CA preconfigurato. Facoltativamente, è possibile utilizzare le Certificate Revocation Lists (CRL).

Ogni componente Zabbix può avere configurato un solo certificato.

Per ulteriori informazioni sulla configurazione e gestione di una CA interna, sulla generazione e firma delle richieste di certificato e sulla revoca dei certificati, fare riferimento a tutorial come l'OpenSSL PKI Tutorial v2.0.

Valutare e testare con attenzione le estensioni del certificato. Per ulteriori dettagli, vedere Limitations on using X.509 v3 certificate extensions.

Parametri di configurazione dei certificati

I seguenti parametri di configurazione sono supportati per la configurazione dei certificati sui componenti di Zabbix.

Parametro Obbligatorio Descrizione
TLSCAFile sì Percorso completo di un file contenente i certificati della CA di livello superiore per la verifica del certificato del peer.
Se si utilizza una catena di certificati con più membri, ordinare i certificati con i certificati delle CA di livello inferiore per primi, seguiti dai certificati delle CA di livello superiore.
I certificati di più CA possono essere inclusi in un singolo file.
TLSCRLFile no Percorso completo di un file contenente le Certificate Revocation Lists (CRL).
TLSCertFile sì Percorso completo di un file contenente il certificato.
Se si utilizza una catena di certificati con più membri, ordinare i certificati con il certificato del server, proxy o agent per primo, seguiti dai certificati delle CA di livello inferiore e conclusi dai certificati delle CA di livello superiore.
TLSKeyFile sì Percorso completo di un file contenente la chiave privata.
Assicurarsi che questo file sia leggibile solo dall'utente Zabbix impostando i diritti di accesso appropriati.
TLSServerCertIssuer no Emittente consentito del certificato del server.
TLSServerCertSubject no Soggetto consentito del certificato del server.

Esempi di configurazione

Dopo aver configurato i certificati necessari, configura i componenti di Zabbix per usare la crittografia basata su certificati.

Di seguito sono riportati i passaggi dettagliati per configurare:

Zabbix server

1. Prepara il file del certificato CA.

Per verificare i certificati dei peer, Zabbix server deve avere accesso al file contenente i certificati CA root autofirmati di livello superiore. Ad esempio, se sono necessari certificati di due CA root indipendenti, inseriscili in un file in /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. Inserisci il certificato/la catena di certificati di Zabbix server in un file, ad esempio in /home/zabbix/zabbix_server.crt. Il primo certificato è il certificato di Zabbix server, seguito dal certificato della CA intermedia:

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

Usa solo gli attributi menzionati sopra sia per i certificati client sia per quelli server, per evitare di influire sul processo di verifica del certificato. Ad esempio, OpenSSL potrebbe non riuscire a stabilire una connessione crittografata se vengono usate le estensioni X509v3 Subject Alternative Name o Netscape Cert Type. Per ulteriori informazioni, vedi Limitazioni nell'uso delle estensioni dei certificati X.509 v3.

3. Inserisci la chiave privata di Zabbix server in un file, ad esempio in /home/zabbix/zabbix_server.key:

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

4. Modifica i parametri di configurazione TLS nel file di configurazione di Zabbix server:

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

1. Preparate i file con i certificati CA di livello superiore, il certificato/la catena di certificati di Zabbix proxy e la chiave privata, come descritto nella sezione Zabbix server. Quindi, modifica di conseguenza i parametri TLSCAFile, TLSCertFile e TLSKeyFile nel file di configurazione di Zabbix proxy.

2. Modifica i parametri TLS aggiuntivi nel file di configurazione di Zabbix proxy:

  • Per proxy attivo: TLSConnect=cert
  • Per proxy passivo: TLSAccept=cert

Per migliorare la sicurezza del proxy, puoi anche impostare i parametri TLSServerCertIssuer e TLSServerCertSubject. Per ulteriori informazioni, consulta Restricting allowed certificate issuer and subject.

I parametri TLS nel file di configurazione finale del proxy possono essere simili ai seguenti:

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. Configura la crittografia per questo proxy in Zabbix frontend:

  • Vai a: Administration > Proxies.
  • Seleziona il proxy e fai clic sulla scheda Encryption.

Negli esempi seguenti, i campi Issuer e Subject sono compilati. Per ulteriori informazioni sul motivo e sul modo di utilizzare questi campi, consulta Restricting allowed certificate issuer and subject.

Per proxy attivo:

Per proxy passivo:

Zabbix agent

1. Preparare i file con i certificati CA di livello superiore, il certificato/la catena di certificati di Zabbix agent e la chiave privata come descritto nella sezione Zabbix server. Quindi, modificare di conseguenza i parametri TLSCAFile, TLSCertFile e TLSKeyFile nel file di configurazione di Zabbix agent.

2. Modificare i parametri TLS aggiuntivi nel file di configurazione di Zabbix agent:

  • Per l'agent attivo: TLSConnect=cert
  • Per l'agent passivo: TLSAccept=cert

Per migliorare la sicurezza dell'agent, è possibile impostare i parametri TLSServerCertIssuer e TLSServerCertSubject. Per ulteriori informazioni, vedere Restricting allowed certificate issuer and subject.

I parametri TLS nel file di configurazione finale dell'agent possono essere simili ai seguenti. Si noti che l'esempio presuppone che l'host sia monitorato da un proxy, quindi questo è specificato come Subject del certificato:

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. Configurare la crittografia nel frontend di Zabbix per l'host monitorato da questo agent.

  • Andare su: Data collection > Hosts.
  • Selezionare l'host e fare clic sulla scheda Encryption.

Nell'esempio seguente, i campi Issuer e Subject sono compilati. Per ulteriori informazioni sul motivo e sulle modalità di utilizzo di questi campi, vedere Restricting allowed certificate issuer and subject.

Zabbix web service

1. Preparare i file con i certificati CA di livello superiore, il certificato/la catena di certificati del Zabbix web service e la chiave privata come descritto nella sezione Zabbix server. Quindi, modificare di conseguenza i parametri TLSCAFile, TLSCertFile e TLSKeyFile nel file di configurazione del Zabbix web service.

2. Modificare un ulteriore parametro TLS nel file di configurazione del Zabbix web service: TLSAccept=cert

I parametri TLS nel file di configurazione finale del web service possono essere simili ai seguenti:

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

3. Configurare Zabbix server per connettersi al Zabbix web service configurato con TLS modificando il parametro WebServiceURL nel file di configurazione di Zabbix server:

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

Limitazione dell'issuer e del subject del certificato consentiti

Quando due componenti Zabbix (ad esempio, server e agent) stabiliscono una connessione TLS, convalidano reciprocamente i certificati. Se il certificato del peer è firmato da una CA attendibile (con un certificato di livello superiore preconfigurato in TLSCAFile), è valido, non è scaduto e supera gli altri controlli, la comunicazione tra i componenti può proseguire. In questo caso più semplice, l'issuer e il subject del certificato non vengono verificati.

Tuttavia, questo comporta un rischio: chiunque disponga di un certificato valido può impersonare chiunque altro (ad esempio, un certificato di host potrebbe essere usato per impersonare un server). Sebbene ciò possa essere accettabile in ambienti piccoli in cui i certificati sono firmati da una CA interna dedicata e il rischio di impersonificazione è basso, potrebbe non essere sufficiente in ambienti più grandi o più sensibili dal punto di vista della sicurezza.

Se la CA di livello superiore emette certificati che non devono essere accettati da Zabbix oppure se si desidera ridurre il rischio di impersonificazione, è possibile limitare i certificati consentiti specificandone issuer e subject.

Ad esempio, nel file di configurazione del proxy Zabbix, si potrebbe specificare:

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

Con queste impostazioni, un proxy attivo non comunicherà con un server Zabbix il cui certificato abbia un issuer o un subject diverso. Analogamente, un proxy passivo non accetterà richieste da tale server.

Regole per la corrispondenza delle stringhe Issuer e Subject

Le regole per la corrispondenza delle stringhe Issuer e Subject sono le seguenti:

  • Le stringhe Issuer e Subject vengono verificate in modo indipendente. Entrambe sono facoltative.
  • Una stringa non specificata significa che viene accettata qualsiasi stringa.
  • Le stringhe vengono confrontate così come sono e devono corrispondere esattamente.
  • Sono supportati i caratteri UTF-8. Tuttavia, non sono supportati i caratteri jolly (*) né le espressioni regolari.
  • Sono implementati i seguenti requisiti di RFC 4514 - i caratteri che richiedono l'escape (con una barra rovesciata '\', U+005C):
    • in qualsiasi punto della stringa: '"' (U+0022), '+' (U+002B), ',' (U+002C), ';' (U+003B), '<' (U+003C), '>' (U+003E), '\\' (U+005C);
    • all'inizio della stringa: spazio (' ', U+0020) o cancelletto ('#', U+0023);
    • alla fine della stringa: spazio (' ', U+0020).
  • I caratteri nulli (U+0000) non sono supportati. Se viene rilevato un carattere nullo, la corrispondenza fallirà.
  • Gli standard RFC 4517 e RFC 4518 non sono supportati.

Ad esempio, se le stringhe dell'organizzazione (O) di Issuer e Subject contengono spazi finali e la stringa dell'unità organizzativa (OU) di Subject contiene virgolette doppie, questi caratteri devono essere escapati:

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
Ordine e formattazione dei campi

Zabbix segue le raccomandazioni di RFC 4514, che specifica un ordine "inverso" per questi campi, iniziando dai campi di livello più basso (CN), proseguendo con i campi di livello intermedio (OU, O) e concludendo con i campi di livello più 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

Al contrario, OpenSSL per impostazione predefinita visualizza le stringhe Issuer e Subject in ordine dal livello più alto a quello più basso. Nell'esempio seguente, i campi Issuer e Subject iniziano con il livello più alto (DC) e terminano con il campo di livello più basso (CN). Anche la formattazione con spazi e separatori di campo varia in base alle opzioni utilizzate e quindi non corrisponderà al formato richiesto da 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

Per formattare correttamente le stringhe Issuer e Subject per Zabbix, invoca OpenSSL con le seguenti opzioni:

$ 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

L'output sarà quindi in ordine inverso, separato da virgole e utilizzabile nei file di configurazione di Zabbix e nel 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

Limitazioni nell'uso delle estensioni dei certificati X.509 v3

Quando si implementano certificati X.509 v3 in Zabbix, alcune estensioni potrebbero non essere completamente supportate oppure potrebbero causare un comportamento incoerente.

Estensione Subject Alternative Name

Zabbix non supporta l'estensione Subject Alternative Name, che viene usata per specificare nomi DNS alternativi come indirizzi IP o indirizzi email. Zabbix può convalidare solo il valore del campo Subject del certificato (vedere Restricting Allowed Certificate Issuer and Subject). Se i certificati includono il campo subjectAltName, l'esito della convalida del certificato può variare a seconda dei toolkit crittografici specifici usati per compilare i componenti di Zabbix. Di conseguenza, Zabbix può accettare o rifiutare i certificati in base a queste combinazioni.

Estensione Extended Key Usage

Zabbix supporta l'estensione Extended Key Usage. Tuttavia, se viene usata, in genere è necessario specificare sia l'attributo clientAuth (per l'autenticazione TLS WWW client) sia l'attributo serverAuth (per l'autenticazione TLS WWW server). Ad esempio:

  • Nei controlli passivi, in cui l'agent Zabbix opera come server TLS, l'attributo serverAuth deve essere incluso nel certificato dell'agent.
  • Nei controlli attivi, in cui l'agent opera come client TLS, l'attributo clientAuth deve essere incluso nel certificato dell'agent.

Sebbene GnuTLS possa generare un avviso per violazioni dell'uso delle chiavi, in genere consente comunque alla comunicazione di proseguire nonostante questi avvisi.

Estensione Name Constraints

Il supporto per l'estensione Name Constraints varia tra i toolkit crittografici. Assicurarsi che il toolkit scelto supporti questa estensione. Questa estensione può impedire a Zabbix di caricare i certificati CA se questa sezione è contrassegnata come critica, a seconda del toolkit specifico in uso.

Liste di revoca dei certificati (CRL)

Se un certificato viene compromesso, la Certificate Authority (CA) può revocarlo includendo il certificato in una Certificate Revocation List (CRL). Le CRL sono gestite tramite file di configurazione e possono essere specificate usando il parametro TLSCRLFile nei file di configurazione di server, proxy e agent. Ad esempio:

TLSCRLFile=/home/zabbix/zabbix_crl_file.crt

In questo caso, zabbix_crl_file.crt può contenere CRL di più CA e potrebbe avere un aspetto simile al seguente:

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

Il file CRL viene caricato solo all'avvio di Zabbix. Per aggiornare la CRL, riavvia Zabbix.

Se i componenti di Zabbix sono compilati con OpenSSL e vengono utilizzate CRL, assicurati che ogni CA di livello superiore e intermedia nelle catene di certificati abbia una CRL corrispondente (anche se vuota) inclusa nel TLSCRLFile.

Risoluzione dei problemi relativi ai certificati

OpenSSL usato con CRL e per alcuni CA nella catena di certificati la relativa CRL non è inclusa in TLSCRLFile

Nel log del server TLS nel caso di 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"

Nel log del server TLS nel caso di 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 scaduto o che scade durante il funzionamento del server

[OpenSSL]{.underline}, nel log del server:

  • prima della scadenza:
<!-- -->
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"
  • dopo la scadenza:
<!-- -->
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"

Il punto qui è che con un CRL valido un certificato revocato viene segnalato come "certificate revoked". Quando il CRL scade, il messaggio di errore cambia in "certificate expired", il che è piuttosto fuorviante.

[GnuTLS]{.underline}, nel log del server:

  • prima e dopo la scadenza lo stesso:
<!-- -->
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.
Certificato autofirmato, CA sconosciuta

[OpenSSL]{.underline}, nel 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"'

Questo è stato osservato quando il certificato del server, per errore, aveva la stessa stringa Issuer e Subject, anche se era firmato da una CA. Issuer e Subject sono uguali nel certificato CA di livello superiore, ma non possono essere uguali nel certificato del server. (Lo stesso vale per i certificati di proxy e agent.)

Per verificare se un certificato contiene le stesse voci Issuer e Subject, eseguire:

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

È accettabile che il certificato root (di livello superiore) abbia valori identici per Issuer e Subject.