Ich habe einen Heimserver und habe das Systemlaufwerk auf eine SSD aktualisiert, da es sich für /home und /var auf einer Kombination aus USB und HDD befand. Da sich auf dem USB eine frühere Version von Debian befand, habe ich eine Neuinstallation durchgeführt, die mich auch auf Version 4.95 von EXIM aktualisiert hat, vorher war ich auf 4.94.2.
Trotz gleicher Smarthost-Konfiguration wird beim Verwenden des SMTP-Servers meines Internetdienstanbieters kein TLS mehr verwendet und ein Validierungsfehler ausgegeben.
/var/log/exim4/mainlog:
2022-04-12 03:30:25 1ne6I7-000AHw-MF TLS session: (certificate verification failed): delivering unencrypted to H=<DOMAIN> [<IP>] (not in hosts_require_tls)
Die E-Mail wird immer noch unverschlüsselt akzeptiert, aber jetzt werden E-Mails von Cron-Jobs von meinem ISP als Spam markiert. Die einzige Änderung besteht darin, dass Nachrichten einen ReceivedHeader haben, der von . with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)auf nur with esmtp (Exim 4.95). geändert wurde. Vermutlich ist dieser Unterschied der Grund, warum sie besonders aufmerksam markiert werden.
Ich habe denselben selbstsignierten Schlüssel und dasselbe Zertifikat (mit einem Zeitstempel von 2013) wie bei der vorherigen Installation verwendet. Ich habe auch versucht, ein neues Paar zu generieren, mit ähnlich wirkungsloser Wirkung.
Nachdem ich online nach Rat gesucht hatte, wurde mir vorgeschlagen, eine Letsencrypt-Konfiguration zu verwenden, damit sie validiert werden kann. Ich verwende das bereits, aber es verursachte das gleiche Verhalten in EXIM.
Das ist meine Konfiguration
/etc/exim4/update-exim4.conf.conf:
dc_eximconfig_configtype='smarthost'
dc_other_hostnames='<LOCAL DOMAIN>'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='<ISP DOMAIN>:587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'
/etc/exim4/etc/exim4/conf.d/main/00_local_settings:
MAIN_TLS_ENABLE = yes
MAIN_TLS_CERTIFICATE = /etc/letsencrypt/live/<LOCAL DOMAIN>/fullchain.pem
MAIN_TLS_PRIVATEKEY = /etc/letsencrypt/live/<LOCAL DOMAIN>/privkey.pem
/etc/letsencrypt/archive/<LOKALE DOMÄNE>/*15.*
-rw-r--r-- 1 root Debian-exim 1870 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/cert15.pem
-rw-r--r-- 1 root Debian-exim 3749 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/chain15.pem
-rw-r--r-- 1 root Debian-exim 5619 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/fullchain15.pem
-rw------- 1 root Debian-exim 1708 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/privkey15.pem
Ich habe auch /etc/exim4/passwd.clienteine Datei mit meinen SMTP-Anmeldedaten, die offensichtlich funktioniert, damit überhaupt E-Mails gesendet werden können.
ist eine Domäne, die auf meine private IP-Adresse verweist.
Die Einträge zu den Letsencrypt-Schlüsseln in 00_local_settings verweisen auf deren Symlinks, die zu den aktuellen Versionen führen. Bei diesen habe ich die Gruppeneigentümerschaft geändert, sodass EXIM den privaten Schlüssel sehen kann, die Berechtigungen aber unverändert gelassen.
Meine vorherige funktionierende Konfiguration war dieselbe, aber mit den selbstsignierten exim.crtund exim.keyDateien in /etc/exim4und daher ohne die letzten beiden Zeilen in meiner Datei 00_local_settings.
Ich habe auch versucht, die Letsencrypt-Dateien zu kopieren /etc/exim4und zu benennen, exim.certund exim.keyzwar mit denselben Berechtigungen von 640 und nichts in 00_local_settings, aber es hat nichts geändert.
Besonders ärgerlich ist, dass ich als letzten Test die Schlüssel einfach gelöscht habe, ohne sie zu konfigurieren, um zu sehen, was passiert. Ich habe den gleichen Fehler erhalten und kann daher nicht sagen, ob es ein Problem mit den von mir verwendeten Schlüsseln gibt oder ob sie einfach überhaupt nicht angezeigt werden.
Antwort1
Ich habe weitergeforscht und eine Art Antwort gefunden. Mir war nicht klar, wessen Zertifikat überprüft wurde. Ich hatte angenommen, es sei meines, aber mir wurde klar, dass es das des Remote-SMTP-Servers sein könnte.
Durch Hinzufügen des folgenden Eintrags wird /etc/exim4/etc/exim4/conf.d/main/00_local_settingsdie Überprüfung deaktiviert und die Verwendung von TLS ermöglicht.
REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = !*
Dies kann in einem Nachrichtenkopf bestätigt werden, der nun den Empfang anzeigtwith esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)
Ich gehe davon aus, dass dies schon früher passiert ist und dass entweder Debian oder Exim seit meiner ersten Konfiguration die Standardeinstellung so geändert haben, dass eine Überprüfung erforderlich ist.
Wenn der Remote-Server ein selbst generiertes Zertifikat verwendet, kann dieses vermutlich nicht überprüft werden?