Sternzeit irgendwas, Logbucheintragung des Captains:

[01.01.70 / 00:00] ✎ Sternzeit irgendwas, Logbucheintragung des Captains:

[02.10.20 / 15:40] ✎ Ich habe vielleicht das Mysterium gelöst, warum ich seit über einem Jahr keine Mails mehr vom root bekomme und auch sonst keine Server-internen Mails. Die letzten zwei Wochen habe ich etwas an meiner Mail-Software gearbeitet und u.a. eine "Alias-Funktion" eingebaut - die Benutzer auf meinem Mailserver können jetzt ihre Alias-Adresse auch zum Senden verwenden (sie wird nur als Bestandteil des persönlichen Namens neben der eigentlichen Mailadresse aufgeführt). Sechs Tage programmieren, drei Tage ausgiebiges Testen - ich bin als ausgebildete Systemtesterin vom Fach.

SMTP connect() failed. https://github.com/PHPMailer/PHPMailer/wiki/Troubleshooting

Die Testmail wurde nicht versendet ... kann es sein, daß ich seit längerer Zeit auf meinem Server überhaupt gar keine Mails mehr versenden kann? Die über die Fehlerausgabe angegebene Internetadresse des PHPMailer-Projektes und die zusätzlich eingeschaltete Debug-Ausgabe im PHP-Skript hilft mir auch nicht unbedingt weiter:

$mailer->SMTPDebug = SMTP::DEBUG_SERVER;

SMTP Error: Could not connect to SMTP host.

Zwei Computermonitore, der linke mit der Webmail-Oberfläche im Browser, der rechte mit einem Fenster des Texteditors (für die PHP-Skripte) und ein offenes Terminalfenster für die SSH-Sitzung als root auf meinem Mailserver. Ein Blick in die laufenden Logfiles des Exim als verwendeter MTA bringt mehr Erkenntnis:

# less /var/log/exim4/mainlog
[...]
2020-10-01 20:16:15 TLS error on connection from mail.oNsOcSmPaAiMl.net (www.oNsOcSmPaAiMl.net) [212.227.193.212] (gnutls_handshake): A TLS fatal alert has been received.

Aha ... ein Fehler im GnuTLS Handshake ... was immer das auch zu bedeuten hat. Ich bin jetzt wenigstens auf der richtigen Spur. Den Exim hatte ich letztes Jahr so konfiguriert, daß er für die TLS-Verschlüsselung einfach die Zertifikate vom Apache übernimmt ... aus dem profanen Grund, die für den Webserver sind die einzigen "nicht selbst signierten" Schlüssel, die ich besitze.

# nano /etc/exim4/conf.d/main/00_exim4-config_localmacros
[...]
MAIN_TLS_ENABLE = yes
MAIN_TLS_CERTIFICATE = /etc/apache2/ssl/oNsOcSmPaAiMl.net_ssl_certificate.cer
MAIN_TLS_PRIVATEKEY = /etc/apache2/ssl/oNsOcSmPaAiMl.net_private_key.key

Ich könnte jetzt einfach die TLS-Verschlüsselung deaktivieren - wozu brauche ich die, wenn der SMTP-Dienst und der Webserver mit dem Webmail auf derselben Maschine laufen? Aber ich weiß, konfiguriere ich mein Webmail so, daß zum Senden der Mails ein fremder SMTP-Server verwendet wird, läuft alles problemlos, auch die TLS-Verschlüsselung. Nur bei mir nicht, auf meinem Server. So schnell gebe ich nicht auf...

Recherche im Internet, das GnuTLS-Projekt. Ich installiere auf meinem Mailserver die passenden Pakete, die auch ein Testprogramm enthalten und starte anschließend einen neuen Verbindungsversuch zum SMTP-Dienst (hier noch auf dem internen Port 25, Port 587 für STARTTLS wird in meiner Konfiguration für externe Mailprogramme, wie dem Thunderbird verwendet).

# apt-get install gnutls-bin
# gnutls-cli -s -p 25 smtp.oNsOcSmPaAiMl.net
Processed 126 CA certificate(s).
Resolving 'smtp.oNsOcSmPaAiMl.net:25'...
Connecting to '212.227.193.212:25'...

- Simple Client Mode:

220 mail.oNsOcSmPaAiMl.net ESMTP Exim 4.92 Thu, 01 Oct 2020 18:25:29 +0200
ehlo boo
250-mail.oNsOcSmPaAiMl.net Hello mail.oNsOcSmPaAiMl.net [212.227.193.212]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH LOGIN PLAIN
250-CHUNKING
250-STARTTLS
250-PRDR
250 HELP
starttls
220 TLS go ahead
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
- subject `CN=*.oNsOcSmPaAiMl.net', issuer `CN=Encryption Everywhere DV TLS CA - G1,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x0d3a7ce1dde5597fa9b415bf288cc097, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-03-07 00:00:00 UTC', expires `2021-03-07 12:00:00 UTC', [...]

- Status: The certificate is NOT trusted. The certificate issuer is unknown.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed

Und wieder ein kleines Stück weiter ... zumindest weiß ich jetzt, woran das Ganze hängt: der Herausgeber des Zertifikats ist unbekannt. Es fehlt möglicherweise nur das Wurzelzertifikat der Zertifizierungsstelle - auf Englisch: "CA - Certificate Authority." [Anm. der Verfasserin: die aufmerksame Leserin erkennt an dem Zeitstempel, daß ich diese Vermutung schon fast zwei Stunden vorher hatte.]

Ich suche auf der Internetseite des Anbieters für die Zertifikate (https://www.digicert.com/kb/digicert-root-certificates.htm) nach dem passenden Wurzelzertifikat mit dem Titel "Encryption Everywhere DV TLS CA - G1" - warum dieses Zertifikat nicht in dem Debian-Paket ca-certificates enthalten ist, weiß ich nicht. Vielleicht ist es zu alt, vielleicht ist die Schlüssellänge nicht ausreichend, vielleicht wurde es kompromittiert oder steht irgendwo auf einer ominösen certificate revocation list. Egal, jetzt ist es auf meinem Server (ich quelle geradezu über vor "Selbstexpertise", ohne wirklich Ahnung zu haben ... ich hab' studiert).

# mv /home/andrea/EncryptionEverywhereDVTLSCA-G1.pem /usr/share/ca-certificates/
# mv EncryptionEverywhereDVTLSCA-G1.pem EncryptionEverywhereDVTLSCA-G1.crt
# chown root:root EncryptionEverywhereDVTLSCA-G1.crt
# dpkg-reconfigure ca-certificates

Letzterer Befehl macht irgendwie dasselbe wie der Befehl: "update-ca-certificates" - nur muß das Zertifikat mit dem öffentlichen Schlüssel im lesbaren PEM-Format vorliegen und die Dateiendung ".crt" besitzen, um in die Gemeinde aufgenommen zu werden. Ein Blick in das Verzeichnis auf dem Mailserver und die Überprüfung der Konfigurationsdatei bestätigt die erfolgreiche Installation:

# ls -l /etc/ssl/certs/
[...]
lrwxrwxrwx 1 root root 34 Oct 1 22:11 44a62f50.0 -> EncryptionEverywhereDVTLSCA-G1.pem
lrwxrwxrwx 1 root root 61 Oct 1 22:11 EncryptionEverywhereDVTLSCA-G1.pem -> /usr/share/ca-certificates/EncryptionEverywhereDVTLSCA-G1.crt

# nano /etc/ca-certificates.conf
[...]
EncryptionEverywhereDVTLSCA-G1.crt

(Zertifikat in der Datei ohne '!' am Zeilenanfang.)

Wird es funktionieren? Ich bin aufgeregt und starte den zweiten Versuch mit dem Testprogramm für die verschlüsselte Verbindung zum SMTP-Dienst auf meinem Mailserver:

# gnutls-cli -s -p 25 smtp.oNsOcSmPaAiMl.net
Processed 127 CA certificate(s).
Resolving 'smtp.oNsOcSmPaAiMl.net:25'...
Connecting to '212.227.193.212:25'...

- Simple Client Mode:

220 mail.oNsOcSmPaAiMl.net ESMTP Exim 4.92 Thu, 01 Oct 2020 22:18:55 +0200
ehlo boo
250-mail.oNsOcSmPaAiMl.net Hello mail.oNsOcSmPaAiMl.net [212.227.193.212]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH LOGIN PLAIN
250-CHUNKING
250-STARTTLS
250-PRDR
250 HELP
starttls
220 TLS go ahead
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
- subject `CN=*.oNsOcSmPaAiMl.net', issuer `CN=Encryption Everywhere DV TLS CA - G1,OU=www.digicert.com,O=DigiCert Inc,C=US', serial 0x0d3a7ce1dde5597fa9b415bf288cc097, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-03-07 00:00:00 UTC', expires `2021-03-07 12:00:00 UTC', [...]

- Status: The certificate is trusted.
- Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Options:
quit
221 mail.oNsOcSmPaAiMl.net closing connection
- Peer has closed the GnuTLS connection

Es hat funktioniert ... darauf erst mal zu kommen, daß es nur an dem fehlenden Wurzelzertifikat liegt! Gespannt verfolge ich im Terminalfenster die Ausgabe der Logfiles des Exim und sende erneut über mein Webmail eine Nachricht an mein anderes, externes Mail-Konto und "cc" eine Kopie an mich auf meinem Mailserver ... mit der Alias-Adresse als persönlicher Name.

# tail -f /var/log/exim4/mainlog
2020-10-01 22:37:34 1kO5KW-000U05-Ks <= andrea@oNsOcSmPaAiMl.net H=mail.oNsOcSmPaAiMl.net (www.oNsOcSmPaAiMl.net) [212.227.193.212] [...] id=lcyTg2P3RiTxy0u5wNB60kheQe5hOsXZLWXWCQKzx0@www.oNsOcSmPaAiMl.net
2020-10-01 22:37:34 1kO5KW-000U05-Ks => morgana@oscilloworld.de R=dnslookup T=remote_smtp [...] C="250 Requested mail action okay, completed: id=1MMX5T-1k5Att2ldf-00JlLB"
2020-10-01 22:37:34 1kO5KW-000U05-Ks Completed

"Juhu! Die Webmistress hat mir eine Mail geschickt!" In der Absenderadresse der eingegangen Mail taucht tatsächlich der Alias auf (was im übrigen vollkommen irrelevant für den SMTP ist):

"webmistress@oNsOcSmPaAiMl.net" <andrea@oNsOcSmPaAiMl.net>

Jetzt muß ich nur noch beobachten, ob die nächsten Tage und Wochen wieder neue Statusmeldungen intern über den Mailserver an mich gesendet werden (mit ganz viel "hochinteressanten" Lesestoff, so etwas wie exim paniclog und alles, was an root gesendet wurde).

Eine spannende Detektivgeschichte...

(Update zwei Wochen später, um 3 Uhr nachts: Ich glaube, jetzt habe ich es wirklich herausgefunden. Ich hatte letztes Jahr unbedarft die system_aliases aus der exim4-config herausgeschmissen ... natürlich konnte dann die Datei /etc/aliases nicht mehr gelesen werden und die systeminternen Nachrichten an root wurden seitdem nie wieder an meine Mailadresse weitergeleitet.)