Jutta Wrage via Exim-users-de <[email protected]> (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
signature.asc
Description: PGP signature
_______________________________________________ Exim-users-de mailing list [email protected] https://lists.exim.org/mailman/listinfo/exim-users-de
