Chiffrement à l'aide de certificats

Vue d'ensemble

Zabbix peut utiliser des certificats RSA au format PEM, signés par une autorité de certification (CA) publique ou interne.

La vérification du certificat est effectuée à l'aide d'un certificat CA préconfiguré. En option, des listes de révocation de certificats (CRL) peuvent être utilisées.

Chaque composant Zabbix ne peut avoir qu'un seul certificat configuré.

Pour plus d'informations sur la mise en place et l'exploitation d'une CA interne, la génération et la signature de demandes de certificat, ainsi que la révocation de certificats, consultez des tutoriels tels que le OpenSSL PKI Tutorial v2.0.

Examinez et testez soigneusement les extensions de votre certificat. Pour plus de détails, voir Limitations on using X.509 v3 certificate extensions.

Paramètres de configuration des certificats

Les paramètres de configuration suivants sont pris en charge pour la configuration des certificats sur les composants Zabbix.

Parameter Mandatory Description
TLSCAFile yes Chemin complet d'un fichier contenant les certificats des CA de niveau supérieur pour la vérification du certificat du pair.
Si vous utilisez une chaîne de certificats avec plusieurs membres, ordonnez les certificats en plaçant d'abord les certificats des CA de niveau inférieur, puis ceux des CA de niveau supérieur.
Des certificats provenant de plusieurs CA peuvent être inclus dans un seul fichier.
TLSCRLFile no Chemin complet d'un fichier contenant les listes de révocation de certificats (CRL).
TLSCertFile yes Chemin complet d'un fichier contenant le certificat.
Si vous utilisez une chaîne de certificats avec plusieurs membres, ordonnez les certificats en plaçant d'abord le certificat du serveur, du proxy ou de l'agent, puis les certificats des CA de niveau inférieur, et terminez par les certificats des CA de niveau supérieur.
TLSKeyFile yes Chemin complet d'un fichier contenant la clé privée.
Assurez-vous que ce fichier n'est lisible que par l'utilisateur Zabbix en définissant les droits d'accès appropriés.
TLSServerCertIssuer no Émetteur autorisé du certificat du serveur.
TLSServerCertSubject no Sujet autorisé du certificat du serveur.

Exemples de configuration

Après avoir configuré les certificats nécessaires, configurez les composants Zabbix pour utiliser le chiffrement basé sur des certificats.

Vous trouverez ci-dessous les étapes détaillées pour configurer :

serveur Zabbix

1. Préparez le fichier de certificat CA.

Afin de vérifier les certificats des pairs, le serveur Zabbix doit avoir accès au fichier contenant les certificats racine CA auto-signés de niveau supérieur. Par exemple, si des certificats provenant de deux CA racines indépendantes sont nécessaires, placez-les dans un fichier à /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. Placez le certificat/la chaîne de certificats du serveur Zabbix dans un fichier, par exemple à /home/zabbix/zabbix_server.crt. Le premier certificat est le certificat du serveur Zabbix, suivi du certificat de l'AC intermédiaire :

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

Utilisez uniquement les attributs mentionnés ci-dessus pour les certificats client et serveur afin d'éviter d'affecter le processus de vérification du certificat. Par exemple, OpenSSL peut ne pas parvenir à établir une connexion chiffrée si les extensions X509v3 Subject Alternative Name ou Netscape Cert Type sont utilisées. Pour plus d'informations, consultez Limitations on using X.509 v3 certificate extensions.

3. Placez la clé privée du serveur Zabbix dans un fichier, par exemple à /home/zabbix/zabbix_server.key :

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

4. Modifiez les paramètres de configuration TLS dans le fichier de configuration du serveur Zabbix :

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

1. Préparez les fichiers contenant les certificats CA de niveau supérieur, le certificat/la chaîne de certificats du proxy Zabbix, ainsi que la clé privée, comme décrit dans la section serveur Zabbix. Ensuite, modifiez les paramètres TLSCAFile, TLSCertFile et TLSKeyFile dans le fichier de configuration du proxy Zabbix en conséquence.

2. Modifiez les paramètres TLS supplémentaires dans le fichier de configuration du proxy Zabbix :

  • Pour un proxy actif : TLSConnect=cert
  • Pour un proxy passif : TLSAccept=cert

Pour améliorer la sécurité du proxy, vous pouvez également définir les paramètres TLSServerCertIssuer et TLSServerCertSubject. Pour plus d'informations, consultez Restreindre l'émetteur et le sujet du certificat autorisés.

Les paramètres TLS dans le fichier de configuration final du proxy peuvent ressembler à ce qui suit :

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. Configurez le chiffrement pour ce proxy dans l'interface Zabbix :

  • Accédez à : Administration > Proxies.
  • Sélectionnez le proxy et cliquez sur l'onglet Encryption.

Dans les exemples ci-dessous, les champs Issuer et Subject sont renseignés. Pour plus d'informations sur les raisons et la manière d'utiliser ces champs, consultez Restreindre l'émetteur et le sujet du certificat autorisés.

Pour un proxy actif :

Pour un proxy passif :

Zabbix agent

1. Préparez les fichiers contenant les certificats CA de niveau supérieur, le certificat/la chaîne de certificats de l'agent Zabbix, ainsi que la clé privée, comme décrit dans la section serveur Zabbix. Ensuite, modifiez en conséquence les paramètres TLSCAFile, TLSCertFile et TLSKeyFile dans le fichier de configuration de l'agent Zabbix.

2. Modifiez les paramètres TLS supplémentaires dans le fichier de configuration de l'agent Zabbix :

  • Pour l'agent actif : TLSConnect=cert
  • Pour l'agent passif : TLSAccept=cert

Pour améliorer la sécurité de l'agent, vous pouvez définir les paramètres TLSServerCertIssuer et TLSServerCertSubject. Pour plus d'informations, consultez Restreindre l'émetteur et le sujet du certificat autorisés.

Les paramètres TLS dans le fichier de configuration final de l'agent peuvent ressembler à ce qui suit. Notez que l'exemple suppose que l'hôte est surveillé par un proxy, c'est pourquoi celui-ci est spécifié comme Subject du certificat :

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. Configurez le chiffrement dans l'interface Zabbix pour l'hôte surveillé par cet agent.

  • Accédez à : Collecte de données > Hôtes.
  • Sélectionnez l'hôte et cliquez sur l'onglet Chiffrement.

Dans l'exemple ci-dessous, les champs Issuer et Subject sont renseignés. Pour plus d'informations sur les raisons et la manière d'utiliser ces champs, consultez Restreindre l'émetteur et le sujet du certificat autorisés.

Service web Zabbix

1. Préparez les fichiers contenant les certificats CA de niveau supérieur, le certificat/la chaîne de certificats du service web Zabbix, ainsi que la clé privée, comme décrit dans la section serveur Zabbix. Ensuite, modifiez les paramètres TLSCAFile, TLSCertFile et TLSKeyFile dans le fichier de configuration du service web Zabbix en conséquence.

2. Modifiez un paramètre TLS supplémentaire dans le fichier de configuration du service web Zabbix : TLSAccept=cert

Les paramètres TLS dans le fichier de configuration final du service web peuvent ressembler à ce qui suit :

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

3. Configurez le serveur Zabbix pour qu'il se connecte au service web Zabbix configuré avec TLS en modifiant le paramètre WebServiceURL dans le fichier de configuration du serveur Zabbix :

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

Restriction de l'émetteur et du sujet de certificat autorisés

Lorsque deux composants Zabbix (par exemple, le serveur et l'agent) établissent une connexion TLS, ils valident mutuellement leurs certificats. Si un certificat de pair est signé par une autorité de certification de confiance (avec un certificat de niveau supérieur préconfiguré dans TLSCAFile), est valide, n'a pas expiré et passe les autres vérifications, alors la communication entre les composants peut se poursuivre. Dans ce cas le plus simple, l'émetteur et le sujet du certificat ne sont pas vérifiés.

Cependant, cela présente un risque: toute personne disposant d'un certificat valide peut se faire passer pour quelqu'un d'autre (par exemple, un certificat d'hôte pourrait être utilisé pour usurper l'identité d'un serveur). Bien que cela puisse être acceptable dans de petits environnements où les certificats sont signés par une autorité de certification interne dédiée et où le risque d'usurpation est faible, cela peut ne pas suffire dans des environnements plus vastes ou plus sensibles sur le plan de la sécurité.

Si votre autorité de certification de niveau supérieur émet des certificats qui ne doivent pas être acceptés par Zabbix ou si vous souhaitez réduire le risque d'usurpation d'identité, vous pouvez restreindre les certificats autorisés en spécifiant leur émetteur et leur sujet.

Par exemple, dans le fichier de configuration du proxy Zabbix, vous pourriez spécifier:

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

Avec ces paramètres, un proxy actif ne communiquera pas avec un serveur Zabbix dont le certificat a un émetteur ou un sujet différent. De même, un proxy passif n'acceptera pas les requêtes provenant d'un tel serveur.

Règles de correspondance des chaînes Issuer et Subject

Les règles de correspondance des chaînes Issuer et Subject sont les suivantes :

  • Les chaînes Issuer et Subject sont vérifiées indépendamment. Les deux sont facultatives.
  • Une chaîne non spécifiée signifie que n'importe quelle chaîne est acceptée.
  • Les chaînes sont comparées telles quelles et doivent correspondre exactement.
  • Les caractères UTF-8 sont pris en charge. En revanche, les jokers (*) et les expressions régulières ne sont pas pris en charge.
  • Les exigences suivantes de RFC 4514 sont implémentées - les caractères qui nécessitent un échappement (avec une barre oblique inverse '\', U+005C) :
    • partout dans la chaîne : '"' (U+0022), '+' (U+002B), ',' (U+002C), ';' (U+003B), '<' (U+003C), '>' (U+003E), '\\' (U+005C) ;
    • au début de la chaîne : espace (' ', U+0020) ou dièse ('#', U+0023) ;
    • à la fin de la chaîne : espace (' ', U+0020).
  • Les caractères nuls (U+0000) ne sont pas pris en charge. Si un caractère nul est rencontré, la correspondance échouera.
  • Les normes RFC 4517 et RFC 4518 ne sont pas prises en charge.

Par exemple, si les chaînes d'organisation (O) de Issuer et Subject contiennent des espaces de fin et si la chaîne d'unité organisationnelle (OU) de Subject contient des guillemets doubles, ces caractères doivent être échappés :

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
Ordre et format des champs

Zabbix suit les recommandations de RFC 4514, qui spécifie un ordre "inverse" pour ces champs, en commençant par les champs de niveau le plus bas (CN), en poursuivant avec les champs de niveau intermédiaire (OU, O), et en terminant par les champs de niveau le plus élevé (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

En revanche, OpenSSL affiche par défaut les chaînes Issuer et Subject dans l'ordre du niveau le plus élevé vers le niveau le plus bas. Dans l'exemple suivant, les champs Issuer et Subject commencent par le niveau le plus élevé (DC) et se terminent par le champ de niveau le plus bas (CN). Le formatage avec des espaces et des séparateurs de champs varie également selon les options utilisées et ne correspond donc pas au format requis par 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

Pour formater correctement les chaînes Issuer et Subject pour Zabbix, invoquez OpenSSL avec les options suivantes :

$ 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

La sortie sera alors dans l'ordre inverse, séparée par des virgules, et utilisable dans les fichiers de configuration Zabbix et l'interface :

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

Limitations sur l'utilisation des extensions de certificat X.509 v3

Lors de l'implémentation de certificats X.509 v3 dans Zabbix, certaines extensions peuvent ne pas être entièrement prises en charge ou peuvent entraîner un comportement incohérent.

Extension Subject Alternative Name

Zabbix ne prend pas en charge l'extension Subject Alternative Name, qui est utilisée pour spécifier des noms DNS alternatifs tels que des adresses IP ou des adresses e-mail. Zabbix peut uniquement valider la valeur du champ Subject du certificat (voir Restriction des émetteurs et sujets de certificat autorisés). Si les certificats incluent le champ subjectAltName, le résultat de la validation du certificat peut varier selon les bibliothèques cryptographiques spécifiques utilisées pour compiler les composants Zabbix. Par conséquent, Zabbix peut accepter ou rejeter des certificats en fonction de ces combinaisons.

Extension Extended Key Usage

Zabbix prend en charge l'extension Extended Key Usage. Cependant, si elle est utilisée, il est généralement nécessaire que les attributs clientAuth (pour l'authentification du client TLS WWW) et serverAuth (pour l'authentification du serveur TLS WWW) soient tous deux spécifiés. Par exemple :

  • Dans les vérifications passives, où l'agent Zabbix fonctionne comme un serveur TLS, l'attribut serverAuth doit être inclus dans le certificat de l'agent.
  • Pour les vérifications actives, où l'agent fonctionne comme un client TLS, l'attribut clientAuth doit être inclus dans le certificat de l'agent.

Bien que GnuTLS puisse émettre un avertissement en cas de violation de l'utilisation des clés, il autorise généralement la communication à se poursuivre malgré ces avertissements.

Extension Name Constraints

La prise en charge de l'extension Name Constraints varie selon les bibliothèques cryptographiques. Assurez-vous que la bibliothèque choisie prend en charge cette extension. Cette extension peut empêcher Zabbix de charger des certificats CA si cette section est marquée comme critique, selon la bibliothèque utilisée.

Listes de révocation de certificats (CRL)

Si un certificat est compromis, l'autorité de certification (CA) peut le révoquer en l'incluant dans une liste de révocation de certificats (CRL). Les CRL sont gérées via des fichiers de configuration et peuvent être spécifiées à l'aide du paramètre TLSCRLFile dans les fichiers de configuration du serveur, du proxy et de l'agent. Par exemple :

TLSCRLFile=/home/zabbix/zabbix_crl_file.crt

Dans ce cas, zabbix_crl_file.crt peut contenir des CRL provenant de plusieurs CA, et pourrait ressembler à ceci :

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

Le fichier CRL n'est chargé qu'au démarrage de Zabbix. Pour mettre à jour la CRL, redémarrez Zabbix.

Si les composants Zabbix sont compilés avec OpenSSL et que des CRL sont utilisées, assurez-vous que chaque CA de niveau supérieur et intermédiaire dans les chaînes de certificats dispose d'une CRL correspondante (même vide) incluse dans TLSCRLFile.

Résolution des problèmes de certificat

OpenSSL utilisé avec des CRL et, pour certains CA dans la chaîne de certificats, leur CRL n'est pas incluse dans TLSCRLFile

Dans le journal du serveur TLS en cas de pair 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"

Dans le journal du serveur TLS en cas de pair 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 expirée ou expirant pendant le fonctionnement du serveur

[OpenSSL]{.underline}, dans le journal du serveur :

  • avant l'expiration :
<!-- -->
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"
  • après l'expiration :
<!-- -->
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"

Le point ici est qu'avec une CRL valide, un certificat révoqué est signalé comme "certificate revoked". Lorsque la CRL expire, le message d'erreur change en "certificate expired", ce qui est assez trompeur.

[GnuTLS]{.underline}, dans le journal du serveur :

  • avant et après l'expiration, identique :
<!-- -->
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.
Certificat auto-signé, CA inconnue

[OpenSSL]{.underline}, dans le journal :

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

Ce problème a été observé lorsque le certificat du serveur avait par erreur la même chaîne Issuer et Subject, bien qu'il ait été signé par une CA. Issuer et Subject sont égaux dans le certificat CA racine, mais ils ne peuvent pas être égaux dans le certificat du serveur. (La même règle s'applique aux certificats du proxy et de l'agent.)

Pour vérifier si un certificat contient les mêmes entrées Issuer et Subject, exécutez :

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

Il est acceptable que le certificat racine (de niveau supérieur) ait des valeurs identiques pour Issuer et Subject.