Jutta Wrage via Exim-users-de <exim-users-de@???> (So 26 Jan 2020 16:09:48 CET):
>
> ... 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?
Es gibt viele Bücher bei O'Reilly. Von welchem sprichst Du? Falls von
Exim, ja, es gibt ein neuers, Amazon hilft Dir beim Suchen.
> >> 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.
Bitte, lies Dir noch mal die Frage durch. Die Ownership der Files ist
nicht wichtig, wichtig ist, ob Exim als Debian-exim (Runtime User des
Exim-Prozesses) diese Files lesen kann. Bitte nicht raten, sondern im
Zweifelsfall probieren.
> 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.
Das ist aber nur bedingt flexibel, weil die Files sich in wenigen Tagen
ändern werden. Vermutlich kommst Du besser, wenn Dein ACME Client die
Files so anpaßt, daß die o.g. Bedingung erfüllt ist (oder halt die Files
woanders hin kopiert und die Permissions entpsrechend anpasst.)
> 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.
Möglicherweise hat das Zertifikat noch andere SNs (SAN), aber leider
zeigst Du uns nicht, um welchen Host es sich handelt. Mit dieser
Obfuscation kann man Dir leider nicht weiterhelfen.
> 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
Wo die liegen ist egal. Wie und woher verstanden? Wer sagt das? /etc/
kannst Du versuchen, als Read-Only zu betrachten, also hätte der ACME
Client keine Chance, dort die Zertifikate zu erneuern.
> Jedenfalls scheint mit der Key irgendwie mindestens unvollständig.
> C = US ist ja schon mal Quatsch
Key unvollständig? Wie meinst Du das? Wenn der Key unvollständig wäre,
würde das Zertifikat nicht funktioneren - der Server kann es nur
verwenden, wenn er den Key dazu hat. Und das C=US ist kein Quatsch, es
ist beim Issuer drin. Über den normalen Let's Encrypt Weg bekommst Du
keine Zertifikate mit mehr als einem oder mehreren CNs.
> Und nein, ich habe nicht verstanden, warum Exim das doppelt verlinkte Zertifikat nicht lesen konnte.
https://www.tuxcademy.org/download/de/grd1/grd1-de-manual.pdf
> 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?
Ja, aber i.d.R. funktioniert das Erzwingen nur für Verbindungen, auf
denen SMTP-Auth gemacht werden soll. Für normale MTA-MTA Verbindungen
wirst Du einige Mails vermissen, wenn Du TLS erzwingst.
> 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
…
> 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!"
Ja. Wenn die keinen Wert auf Sicherheit legen und Du auch nicht, dann
kannst Du ja den TLS-Zwang ausschalten.
> Spontan fällt mir ein:
> 1. Einen Port für die zu reservieren mit anderen Einstellungen
Und wie stellst Du sicher, daß nur die sich dorthin verbinden?
> 2. Am Port 25 auch Verbindungen ohne TLS zulassen, wenn es mindestens Verbindungen eines bekannten Benutzer mit verschlüsselten Paßwort sind.
Woher weißt Du den Nutzer, bevor er sich angemeldet hat?
> 3. Port 25 lassen, wie er ist und den restlichen Mailmüll irgendwie anders loswerden
Port 25 wird für MTA-MTA verwendet. Bei einigen auch für
SMTP-Submission, aber für letzteres würde ich ohne TLS keine
Authentifizierung anbieten, was effektiv heißt, die können sich dann
nicht anmelden und eben keine Mail versenden, bis sie es geschafft
haben, ihren Client zu aktualisieren.
Ein durschnittliches Setup:
- Port 25/TCP STARTTLS anbieten
SMTP-Auth für SMTP-Submission nur nach erfolgreichem STARTTLS
- Port 465/TCP TLS-On-Connect für SMTP-Submission
- Port 587/TCP STARTTLS erzwingen, und dann ausschließlich
SMTP-Submission zulassen
--
Heiko
