Verschlüsselung mit Zertifikaten

Übersicht

Zabbix kann RSA-Zertifikate im PEM-Format verwenden, die von einer öffentlichen oder einer internen Zertifizierungsstelle (CA) signiert wurden.

Die Zertifikatsprüfung erfolgt anhand eines vorkonfigurierten CA-Zertifikats. Optional können Certificate Revocation Lists (CRL) verwendet werden.

Jede Zabbix-Komponente kann nur ein Zertifikat konfiguriert haben.

Weitere Informationen zum Einrichten und Betreiben einer internen CA, zum Erzeugen und Signieren von Zertifikatsanforderungen sowie zum Widerrufen von Zertifikaten finden Sie in Tutorials wie dem OpenSSL PKI Tutorial v2.0.

Prüfen und testen Sie Ihre Zertifikatserweiterungen sorgfältig. Weitere Details finden Sie unter Einschränkungen bei der Verwendung von X.509 v3-Zertifikatserweiterungen.

Zertifikatskonfigurationsparameter

Die folgenden Konfigurationsparameter werden für die Einrichtung von Zertifikaten auf Zabbix-Komponenten unterstützt.

Parameter Mandatory Description
TLSCAFile yes Vollständiger Pfadname einer Datei, die die Zertifikate der obersten CA(s) für die Überprüfung von Peer-Zertifikaten enthält.
Wenn eine Zertifikatskette mit mehreren Mitgliedern verwendet wird, ordnen Sie die Zertifikate so an, dass die Zertifikate der unteren CA(s) zuerst und anschließend die Zertifikate der höheren CA(s) folgen.
Zertifikate mehrerer CAs können in einer einzelnen Datei enthalten sein.
TLSCRLFile no Vollständiger Pfadname einer Datei, die Certificate Revocation Lists (CRL) enthält.
TLSCertFile yes Vollständiger Pfadname einer Datei, die das Zertifikat enthält.
Wenn eine Zertifikatskette mit mehreren Mitgliedern verwendet wird, ordnen Sie die Zertifikate so an, dass zuerst das Zertifikat des Servers, Proxys oder Agents folgt, danach die Zertifikate der unteren CA(s) und abschließend die Zertifikate der höheren CA(s).
TLSKeyFile yes Vollständiger Pfadname einer Datei, die den privaten Schlüssel enthält.
Stellen Sie sicher, dass diese Datei nur für den Zabbix-Benutzer lesbar ist, indem Sie geeignete Zugriffsrechte festlegen.
TLSServerCertIssuer no Zulässiger Aussteller des Serverzertifikats.
TLSServerCertSubject no Zulässiger Betreff des Serverzertifikats.

Konfigurationsbeispiele

Nachdem die erforderlichen Zertifikate eingerichtet wurden, konfigurieren Sie die Zabbix-Komponenten so, dass sie eine zertifikatsbasierte Verschlüsselung verwenden.

Nachfolgend finden Sie detaillierte Schritte zur Konfiguration von:

Zabbix Server

1. Bereiten Sie die CA-Zertifikatsdatei vor.

Um Peer-Zertifikate zu überprüfen, muss der Zabbix Server Zugriff auf die Datei haben, die die selbstsignierten Root-CA-Zertifikate der obersten Ebene enthält. Wenn beispielsweise Zertifikate von zwei unabhängigen Root-CAs benötigt werden, legen Sie sie in einer Datei unter /home/zabbix/zabbix_ca_file.crt ab:

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. Legen Sie das Zabbix Server-Zertifikat bzw. die Zertifikatskette in einer Datei ab, zum Beispiel unter /home/zabbix/zabbix_server.crt. Das erste Zertifikat ist das Zabbix Server-Zertifikat, gefolgt vom Zwischenzertifikat der 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-----

Verwenden Sie für Client- und Serverzertifikate nur die oben genannten Attribute, um den Zertifikatsprüfungsprozess nicht zu beeinträchtigen. Beispielsweise kann OpenSSL keine verschlüsselte Verbindung herstellen, wenn die Erweiterungen X509v3 Subject Alternative Name oder Netscape Cert Type verwendet werden. Weitere Informationen finden Sie unter Einschränkungen bei der Verwendung von X.509-v3-Zertifikatserweiterungen.

3. Legen Sie den privaten Schlüssel des Zabbix Server in einer Datei ab, zum Beispiel unter /home/zabbix/zabbix_server.key:

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

4. Bearbeiten Sie die TLS-Konfigurationsparameter in der Konfigurationsdatei des Zabbix Server:

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

1. Bereiten Sie Dateien mit den CA-Zertifikaten der obersten Ebene, dem Zabbix-Proxy-Zertifikat/Zertifikats-Chain und dem privaten Schlüssel vor, wie im Abschnitt Zabbix Server beschrieben.
Bearbeiten Sie anschließend die Parameter TLSCAFile, TLSCertFile und TLSKeyFile in der Zabbix-Proxy-Konfigurationsdatei entsprechend.

2. Bearbeiten Sie zusätzliche TLS-Parameter in der Zabbix-Proxy-Konfigurationsdatei:

  • Für aktiven Proxy: TLSConnect=cert
  • Für passiven Proxy: TLSAccept=cert

Um die Sicherheit des Proxys zu verbessern, können Sie auch die Parameter TLSServerCertIssuer und TLSServerCertSubject festlegen.
Weitere Informationen finden Sie unter Einschränken des zulässigen Zertifikatsausstellers und -subjects.

TLS-Parameter in der endgültigen Proxy-Konfigurationsdatei können wie folgt aussehen:

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. Konfigurieren Sie die Verschlüsselung für diesen Proxy im Zabbix Frontend:

  • Gehen Sie zu: Administration > Proxies.
  • Wählen Sie den Proxy aus und klicken Sie auf die Registerkarte Encryption.

In den folgenden Beispielen sind die Felder Issuer und Subject ausgefüllt.
Weitere Informationen dazu, warum und wie diese Felder verwendet werden, finden Sie unter Einschränken des zulässigen Zertifikatsausstellers und -subjects.

Für aktiven Proxy:

Für passiven Proxy:

Zabbix Agent

1. Bereiten Sie Dateien mit den CA-Zertifikaten der obersten Ebene, dem Zabbix Agent-Zertifikat bzw. der Zertifikatskette und dem privaten Schlüssel vor, wie im Abschnitt Zabbix Server beschrieben. Bearbeiten Sie anschließend die Parameter TLSCAFile, TLSCertFile und TLSKeyFile in der Konfigurationsdatei des Zabbix Agent entsprechend.

2. Bearbeiten Sie zusätzliche TLS-Parameter in der Konfigurationsdatei des Zabbix Agent:

  • Für aktiven Agent: TLSConnect=cert
  • Für passiven Agent: TLSAccept=cert

Um die Sicherheit des Agent zu verbessern, können Sie die Parameter TLSServerCertIssuer und TLSServerCertSubject festlegen. Weitere Informationen finden Sie unter Einschränken des zulässigen Zertifikatausstellers und -subjekts.

Die TLS-Parameter in der endgültigen Agent-Konfigurationsdatei können wie folgt aussehen. Beachten Sie, dass das Beispiel davon ausgeht, dass der Host von einem Proxy überwacht wird; daher wird er als Zertifikats-Subject angegeben:

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. Konfigurieren Sie die Verschlüsselung im Zabbix Frontend für den von diesem Agent überwachten Host.

  • Gehen Sie zu: Datenerfassung > Hosts.
  • Wählen Sie den Host aus und klicken Sie auf die Registerkarte Verschlüsselung.

Im folgenden Beispiel sind die Felder Issuer und Subject ausgefüllt. Weitere Informationen dazu, warum und wie diese Felder verwendet werden, finden Sie unter Einschränken des zulässigen Zertifikatausstellers und -subjekts.

Zabbix web service

1. Bereiten Sie Dateien mit den CA-Zertifikaten der obersten Ebene, dem Zertifikat/Zertifikats-Chain des Zabbix web service und dem privaten Schlüssel vor, wie im Abschnitt Zabbix server beschrieben.
Bearbeiten Sie anschließend die Parameter TLSCAFile, TLSCertFile und TLSKeyFile in der Zabbix web service configuration file entsprechend.

2. Bearbeiten Sie einen zusätzlichen TLS-Parameter in der Zabbix web service configuration file: TLSAccept=cert

TLS-Parameter in der endgültigen Konfigurationsdatei des web service können wie folgt aussehen:

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

3. Konfigurieren Sie den Zabbix server so, dass er eine Verbindung zum per TLS konfigurierten Zabbix web service herstellt, indem Sie den Parameter WebServiceURL in der Zabbix server configuration file bearbeiten:

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

Einschränkung des zulässigen Zertifikatsausstellers und -subjects

Wenn zwei Zabbix-Komponenten (zum Beispiel Server und Agent) eine TLS-Verbindung herstellen, validieren sie gegenseitig ihre Zertifikate. Wenn ein Peer-Zertifikat von einer vertrauenswürdigen CA signiert ist (mit einem vorkonfigurierten obersten Zertifikat in TLSCAFile), gültig ist, nicht abgelaufen ist und andere Prüfungen besteht, kann die Kommunikation zwischen den Komponenten fortgesetzt werden. In diesem einfachsten Fall werden der Zertifikatsaussteller und das Subject nicht überprüft.

Dies birgt jedoch ein Risiko: Jeder mit einem gültigen Zertifikat kann sich als jemand anderes ausgeben (zum Beispiel könnte ein Host-Zertifikat verwendet werden, um sich als Server auszugeben). Das mag in kleinen Umgebungen akzeptabel sein, in denen Zertifikate von einer dedizierten internen CA signiert werden und das Risiko einer Identitätsvortäuschung gering ist, reicht aber in größeren oder sicherheitskritischeren Umgebungen möglicherweise nicht aus.

Wenn Ihre oberste CA Zertifikate ausstellt, die von Zabbix nicht akzeptiert werden sollen, oder wenn Sie das Risiko einer Identitätsvortäuschung verringern möchten, können Sie zulässige Zertifikate einschränken, indem Sie deren Aussteller und Subject angeben.

Beispiel: In der Konfigurationsdatei des Zabbix Proxy könnten Sie Folgendes angeben:

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

Mit diesen Einstellungen kommuniziert ein aktiver Proxy nicht mit einem Zabbix Server, dessen Zertifikat einen anderen Aussteller oder ein anderes Subject hat. Entsprechend akzeptiert ein passiver Proxy keine Anfragen von einem solchen Server.

Regeln für den Abgleich von Issuer- und Subject-Strings

Die Regeln für den Abgleich von Issuer- und Subject-Strings lauten wie folgt:

  • Issuer- und Subject-Strings werden unabhängig voneinander geprüft. Beide sind optional.
  • Ein nicht angegebener String bedeutet, dass jeder String akzeptiert wird.
  • Strings werden wie angegeben verglichen und müssen exakt übereinstimmen.
  • UTF-8-Zeichen werden unterstützt. Platzhalter (*) oder reguläre Ausdrücke werden jedoch nicht unterstützt.
  • Die folgenden Anforderungen aus RFC 4514 werden implementiert - Zeichen, die ein Escaping erfordern (mit einem '\'-Backslash, U+005C):
    • überall im String: '"' (U+0022), '+' (U+002B), ',' (U+002C), ';' (U+003B), '<' (U+003C), '>' (U+003E), '\\' (U+005C);
    • am Anfang des Strings: Leerzeichen (' ', U+0020) oder Nummernzeichen ('#', U+0023);
    • am Ende des Strings: Leerzeichen (' ', U+0020).
  • Nullzeichen (U+0000) werden nicht unterstützt. Wenn ein Nullzeichen gefunden wird, schlägt der Abgleich fehl.
  • Die Standards RFC 4517 und RFC 4518 werden nicht unterstützt.

Wenn beispielsweise die Organisations- (O) Strings von Issuer und Subject nachgestellte Leerzeichen enthalten und der organisatorische Einheit- (OU) String von Subject doppelte Anführungszeichen enthält, müssen diese Zeichen maskiert werden:

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
Feldreihenfolge und Formatierung

Zabbix folgt den Empfehlungen von RFC 4514, der für diese Felder eine "umgekehrte" Reihenfolge festlegt: beginnend mit den Feldern der niedrigsten Ebene (CN), über die Felder der mittleren Ebene (OU, O) bis hin zu den Feldern der höchsten Ebene (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

Im Gegensatz dazu zeigt OpenSSL die Zeichenfolgen Issuer und Subject standardmäßig in der Reihenfolge von der höchsten zur niedrigsten Ebene an. Im folgenden Beispiel beginnen die Felder Issuer und Subject mit der höchsten Ebene (DC) und enden mit dem Feld der niedrigsten Ebene (CN). Auch die Formatierung mit Leerzeichen und Feldtrennzeichen variiert je nach verwendeten Optionen und entspricht daher nicht dem von Zabbix geforderten Format.

$ 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

Um die Zeichenfolgen Issuer und Subject korrekt für Zabbix zu formatieren, rufen Sie OpenSSL mit den folgenden Optionen auf:

$ 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

Die Ausgabe erfolgt dann in umgekehrter Reihenfolge, durch Kommas getrennt und kann in Zabbix-Konfigurationsdateien und im Frontend verwendet werden:

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

Einschränkungen bei der Verwendung von X.509 v3-Zertifikatserweiterungen

Bei der Implementierung von X.509 v3-Zertifikaten in Zabbix werden bestimmte Erweiterungen möglicherweise nicht vollständig unterstützt oder können zu inkonsistentem Verhalten führen.

Subject Alternative Name-Erweiterung

Zabbix unterstützt die Subject Alternative Name-Erweiterung nicht, die verwendet wird, um alternative DNS-Namen wie IP-Adressen oder E-Mail-Adressen anzugeben. Zabbix kann nur den Wert im Feld Subject des Zertifikats validieren (siehe Einschränkung der zulässigen Zertifikatsaussteller und des Subjects). Wenn Zertifikate das Feld subjectAltName enthalten, kann das Ergebnis der Zertifikatsvalidierung je nach den spezifischen Kryptobibliotheken variieren, die zum Kompilieren der Zabbix-Komponenten verwendet wurden. Infolgedessen kann Zabbix Zertifikate je nach dieser Kombination entweder akzeptieren oder ablehnen.

Extended Key Usage-Erweiterung

Zabbix unterstützt die Extended Key Usage-Erweiterung. Wenn sie jedoch verwendet wird, ist es im Allgemeinen erforderlich, dass sowohl die Attribute clientAuth (für TLS WWW-Clientauthentifizierung) als auch serverAuth (für TLS WWW-Serverauthentifizierung) angegeben sind. Beispiel:

  • Bei passiven Prüfungen, bei denen der Zabbix Agent als TLS-Server arbeitet, muss das Attribut serverAuth im Zertifikat des Agent enthalten sein.
  • Bei aktiven Prüfungen, bei denen der Agent als TLS-Client arbeitet, muss das Attribut clientAuth im Zertifikat des Agent enthalten sein.

Während GnuTLS möglicherweise eine Warnung bei Verstößen gegen die Schlüsselverwendung ausgibt, erlaubt es in der Regel dennoch die Fortsetzung der Kommunikation trotz dieser Warnungen.

Name Constraints-Erweiterung

Die Unterstützung für die Name Constraints-Erweiterung variiert zwischen den Kryptobibliotheken. Stellen Sie sicher, dass die von Ihnen gewählte Bibliothek diese Erweiterung unterstützt. Diese Erweiterung kann Zabbix je nach verwendeter Bibliothek daran hindern, CA-Zertifikate zu laden, wenn dieser Abschnitt als kritisch markiert ist.

Certificate Revocation Lists (CRL)

Wenn ein Zertifikat kompromittiert wurde, kann die Certificate Authority (CA) es widerrufen, indem sie das Zertifikat in eine Certificate Revocation List (CRL) aufnimmt. CRLs werden über Konfigurationsdateien verwaltet und können mithilfe des Parameters TLSCRLFile in den Konfigurationsdateien von Server, Proxy und Agent angegeben werden. Zum Beispiel:

TLSCRLFile=/home/zabbix/zabbix_crl_file.crt

In diesem Fall kann zabbix_crl_file.crt CRLs mehrerer CAs enthalten und könnte folgendermaßen aussehen:

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

Die CRL-Datei wird nur beim Start von Zabbix geladen. Um die CRL zu aktualisieren, starten Sie Zabbix neu.

Wenn Zabbix-Komponenten mit OpenSSL kompiliert wurden und CRLs verwendet werden, stellen Sie sicher, dass jede Root- und Zwischen-CA in den Zertifikatsketten über eine entsprechende CRL verfügt (auch wenn sie leer ist), die in TLSCRLFile enthalten ist.

Behebung von Zertifikatsproblemen

OpenSSL wird mit CRLs verwendet, und für einige CA in der Zertifikatskette ist deren CRL nicht in TLSCRLFile enthalten

Im TLS-Serverprotokoll im Fall eines OpenSSL-Peers:

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"

Im TLS-Serverprotokoll im Fall eines GnuTLS-Peers:

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 abgelaufen oder läuft während des Serverbetriebs ab

[OpenSSL]{.underline}, im Server-Log:

  • vor dem Ablauf:
<!-- -->
kann keine Verbindung zu Proxy "proxy-openssl-1.0.1e" herstellen: TCP erfolgreich, TLS zu [[127.0.0.1]:20004] kann nicht aufgebaut werden:\
    SSL_connect() gab SSL_ERROR_SSL zurück: Datei s3_clnt.c Zeile 1253: Fehler:14090086:\
    SSL routines:ssl3_get_server_certificate:certificate verify failed:\
    TLS write fatal alert "certificate revoked"
  • nach dem Ablauf:
<!-- -->
kann keine Verbindung zu Proxy "proxy-openssl-1.0.1e" herstellen: TCP erfolgreich, TLS zu [[127.0.0.1]:20004] kann nicht aufgebaut werden:\
    SSL_connect() gab SSL_ERROR_SSL zurück: Datei s3_clnt.c Zeile 1253: Fehler:14090086:\
    SSL routines:ssl3_get_server_certificate:certificate verify failed:\
    TLS write fatal alert "certificate expired"

Der Punkt hier ist, dass bei gültiger CRL ein widerrufenes Zertifikat als "certificate revoked" gemeldet wird. Wenn die CRL abläuft, ändert sich die Fehlermeldung zu "certificate expired", was ziemlich irreführend ist.

[GnuTLS]{.underline}, im Server-Log:

  • vor und nach dem Ablauf gleich:
<!-- -->
kann keine Verbindung zu Proxy "proxy-openssl-1.0.1e" herstellen: TCP erfolgreich, TLS zu [[127.0.0.1]:20004] kann nicht aufgebaut werden:\
      ungültiges Peer-Zertifikat: Das Zertifikat ist NICHT vertrauenswürdig. Die Zertifikatskette ist widerrufen.
Selbstsigniertes Zertifikat, unbekannte CA

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

Dies wurde beobachtet, als das Serverzertifikat versehentlich denselben Issuer- und Subject-String hatte, obwohl es von einer CA signiert war. Issuer und Subject sind im CA-Zertifikat der obersten Ebene gleich, dürfen jedoch im Serverzertifikat nicht gleich sein. (Dasselbe gilt für Proxy- und Agent-Zertifikate.)

Um zu prüfen, ob ein Zertifikat dieselben Issuer- und Subject-Einträge enthält, führen Sie Folgendes aus:

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

Für das Root-Zertifikat (Zertifikat der obersten Ebene) ist es zulässig, dass Issuer und Subject identische Werte haben.