Hallo Heiko,
Am 26.01.2020 um 12:51 schrieb Heiko Schlittermann via Exim-users-de:
> Wenn Du Dein System selbst verwalten möchtest,
> solltest Du Dir die Zeit nehmen.
... verwalten muß. Aber hoffentlich nicht allein.
Ich denke, ich brauche mehr Informationen zu TLS/SSL auf einem Server.
Da das wohl auch andere interessiert frage ich hier:
Gib es etwas neueres als das O'Reilly-Buch von 2001?
Zurück zum cert:
>>
>> MAIN_TLS_CERTIFICATE = CONFDIR/exim.crt
>> MAIN_TLS_PRIVATEKEY = CONFDIR/exim.key
>> unter /etc/exim4/ sind exim.crt und exim.key links auf andere Dateien.
>
> Und sind diese Dateien für den Exim-Runtime-User (Debian-exim) lesbar?
> Die Dateien, nicht die Links!
Also:
exim.crt ist ein link auf /etc/letsencrypt/live/
ftp.DOM/fullchain.pem
für den privaten Key gilt entsprechendes
/etc/letsencrypt/live/
ftp.DOM/fullchain.pem ist wiederum ein link auf ../../archive/
ftp.DOM/fullchain1.pem
DOM ist die Domain.
Eigentlich sollte das alles lesbar sein. Aber wenn exim die Ownership verlangt: Owner ist root.
Jetzt habe ich die tatsächlichen Dateien genommen und nach /etc/exim4 kopiert und in conf.d/main/000_... die entsprechenden Namen angegeben.
Als Owner habe ich bei beiden Dateien Debian-exim angegeben.
Tja, und jetzt kann Exim die Dateien lesen.
Aber:
openssl s_client -starttls smtp -connect RECHNER:25 -tls1_2
CONNECTED(00000004)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = ftp.[DOM]
verify return:1
---
Certificate chain
0 s:CN = ftp.[DOM]
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
Das heißt, daß hier der Admin, der das gemacht hat,
ftp.DOM (DOM ist die Domain) als Eintrag für den Servernamen gewählt hat. Das ist einer der CNAMEs des Hosts.
Wenn ich das richtig verstanden habe, sollten unser SSL-Sachen eigentlich unter /etc/ssl/ liegen.
Dort befindet sich aber in certs eine ganze Reihe von certs und in in private und in cersts ssl-cert-snakeoil.key und ssl-cert-snakeoil.pem
Jedenfalls scheint mit der Key irgendwie mindestens unvollständig.
C = US ist ja schon mal Quatsch
Und nein, ich habe nicht verstanden, warum Exim das doppelt verlinkte Zertifikat nicht lesen konnte.
Jetzt kommt die nächste Frage:
Port 465 ist schon ssl-on-connect
Sollte man heutzutage nicht TLS nur anbieten anbieten (MAIN_TLS_ADVERTISE_HOSTS = *) sondern auch für eingehende Verbindungen verlangen?
Wenn ich mir das mainlog ansehe
Und dann habe ich gerade noch etwas gefunden, die älteren Apple-Geräte (MAC OS 10.* und iOS) können alle nur OpenSSL 0.9.8za oder maximal 1.0
Ich habe zwar auf dem testenden Rechner über Macports auch OpenSSL 1.1, aber das wird Mail.app nicht benutzen, da das neuer Openssl aus Macports kommt.
Sieh dazu auch:
https://www.macuser.de/threads/verschluesselungsversion-tls-in-mail-app-beeinflussen-wie.803777/
Alle Leute mit alten Rechnern rauswerfen? - Klingt irgendwie wie "Hast Du kein Geld oder bist Du alt und willst oder kannst nicht ständig Neues kaufen: Geh doch zum Teufel!"
Welche Möglichkeit gibt es, Leute mit alten Rechnern nicht abzuhängen?
Spontan fällt mir ein:
1. Einen Port für die zu reservieren mit anderen Einstellungen
2. Am Port 25 auch Verbindungen ohne TLS zulassen, wenn es mindestens Verbindungen eines bekannten Benutzer mit verschlüsselten Paßwort sind.
3. Port 25 lassen, wie er ist und den restlichen Mailmüll irgendwie anders loswerden
Gruß
Jutta
--
http://www.witch.westfalen.de
