Lösungen und Tipps von den mpex Profis

mpex Techblog

21.07.2020

rsyslogd – Problem: Fehlermeldung z.B. in /var/log/syslog auf einem rsyslog Client

In Zusammenhang mit /var/log/syslog kommt es auf einem rsylogd-Client zu einer Fehlermeldung.

Problem

Fehlermeldung z.B. in /var/log/syslog auf einem rsyslog Client
Apr 8 16:05:29 example.com rsyslogd: not permitted to talk to peer, certificate invalid: insecure algorithm [v8.1901.0] Apr 8 16:05:29 example.com rsyslogd: invalid cert info: peer provided 1 certificate(s). Certificate 1 info: certificate valid from Tue Apr 11 16:48:08 2017 to Mon Apr 11 16:48:08 2022; Certificate public key: RSA; DN: CN=logserver.example.com; Issuer DN: CN=My CA: my-ca.example.com; [v8.1901.0]

Auf dem gegenüberliegenden System (Logserver), ggf. folgende Meldungen
Apr 8 16:05:29 logserver.example.com liblogging-stdlog: netstream session 0x7f23c144dbb0 from <IP> will be closed due to error [v8.24.0 try http://www.rsyslog.com/e/2078 ] Apr 8 16:05:29 logserver.example.com liblogging-stdlog: unexpected GnuTLS error -110 in nsd_gtls.c:536: The TLS connection was non-properly terminated. [v8.24.0 try http://www.rsyslog.com/e/2078 ]

Analyse

Prüfung der relevanten SSL Parameter

  1. Prüfe Korrektheit der konfigurierten Zertifikate auf beiden Seiten, in der rsyslog.conf zu finden unter den Optionen:
    $DefaultNetstreamDriverCAFile ca.pem $DefaultNetstreamDriverCertFile cert.pem $DefaultNetstreamDriverKeyFile key.pem

    Sichtprüfen der Dateien (bis auf Key) z.B. mit openssl Ausgabe
    openssl x509 -noout -text -in cert.pem

    Vor allem auch: Stimmen die CAs auf beiden Seiten überein?

  2. Für ein erweitertes Debugging, rsyslog z.B. in den Debug Mode versetzen
    # Setze Debugging Logfile und Level echo 'global(debug.gnutls="10" debug.logFile="/var/log/rsyslogdebug")' > /etc/rsyslog.d/tmp-debug.conf /etc/init.d/rsyslog stop rsyslog -dn # Startet im Vordergrund! # STRG+C zum Abbruch wenn genug Daten gesammelt rm /etc/rsyslog.d/tmp-debug.conf /etc/init.d/rsyslog start


  3. Alternativ: Verbindung je nach aktiviertem ssl Modul prüfen
    • Wenn DefaultNetstreamDriverCertFile gtls (gnutls)
      apt-get install gnutls-bin gnutls-cli -p <Logserver Port> <Logserver FQDN> --x509keyfile=key.pem --x509certfile=cert.pem --x509cafile=ca.pem

      Falls der Test mit der extra Option --verify-allow-broken --insecure funktioniert, ist ein Algorithmus vermutlich veraltet. Prüfen auf erlaubte Algorithmen mit gnutls-cli --list
    • Wenn DefaultNetstreamDriverCertFile ossl (openssl)
      openssl s_client -connect <Zielhost>:<Port> -cert cert.pem -key key.pem -CAfile ca.pem
  • Im Idealfall zeigt die Verbindung auf diesem Weg einen konkreteren Fehler auf. In dem bei uns aufgetretenen Fall war damit Folgendes mit gnutls in der Ausgabe zu sehen:
    ...signed using RSA-SHA1 (broken!)... - Status: The certificate is NOT trusted. The certificate chain uses insecure algorithm. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate.

    Vermutlich verwendet die Gegenseite ein Zertifikat das mit einem zu alten Algorithmus signiert wurde.

Lösung

  • Inkorrekte Zertifikate / CA Chain: Die Zertifikate korrigieren.
  • Fehler bei der SSL Verbindung: Diese müssen im Einzelfall genauer geprüft und gelöst werden
    • Fehler signed using RSA-SHA1 (broken!):
      • Zertifikat der Gegenseite mit einem neueren Algorithmus ausstellen

Kann mpex weiterhelfen?

Mit über 20 Jahren Erfahrung im Bereich Managed Hosting haben wir ein umfangreiches Repertoire an Problemlösungen angesammelt, die uns beim Betrieb von Serverumgebungen auf höchstem technischen Niveau geholfen haben. Unsere Systeme bauen komplett auf Open-Source-Technologien auf. Damit sind wir flexibel und können bei technischen Schwierigkeiten direkt selbst eingreifen. Analog zur Open-Source-Idee haben wir uns für diesen Techblog entschieden, um unsere Expertise und Problemlösungen mit dir zu teilen. Dazu zählen Technologien wie Bacula, Debian, Pacemaker, Puppet, diverse allgemeine Serverprobleme und noch vieles darüber hinaus. Wenn du mehr über unsere individuellen Business-Lösungen erfahren und dich als Admin auf deine Kernkompetenzen konzentrieren möchtest, sprich uns einfach an. Wir realisieren das Managed Hosting deiner Anwendung und kümmern uns in Zukunft um all solche Probleme.

Zum Kontaktformular
mpex GmbH
Weitere Blog Artikel
06.01.2021

Bacula – Problem: Fehlermeldung "Unable to authenticate with Storage daemon"

Fehlermeldung beim Verbindungsversuch mit bacula-sd: "Unable to authenticate with Storage daemon".

Artikel lesen
23.12.2020

vServer – Problem: vServer hängt fest

Der vServer hängt fest, enter ist nicht möglich, wird aber noch angezeigt in vserver-stat.

Artikel lesen

Kontaktformular - Sprechen Sie uns an!

Sprechen Sie uns an!

Sie wollen mehr über uns und unsere Leistungen erfahren? Lernen Sie uns im persönlichen Gespräch kennen!

Telefon: +49 30 780 97 180
E-Mail: info@mpex.de