From a.wass at glas-gasperlmair.at Wed Oct 13 15:51:49 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Wed, 13 Oct 2021 15:51:49 +0200 Subject: mailq auf neuen Mailserver migrieren? Message-ID: Hallo, ist es möglich, die mailq von einem Centos-Postfix Version 2.11.11 auf Debian-Postfix Version  3.5.6 zu migrieren? Wenn ja, wie? -- vg, Andi From p at sys4.de Wed Oct 13 20:37:23 2021 From: p at sys4.de (Patrick Ben Koetter) Date: Wed, 13 Oct 2021 20:37:23 +0200 Subject: mailq auf neuen Mailserver migrieren? In-Reply-To: References: Message-ID: <1ad97455-4b74-678a-63c0-aa66fd9f2217@sys4.de> Am einfachsten sicher mit fallback_relay Am 13.10.21 um 15:51 schrieb Andreas Wass - Glas Gasperlmair: > Hallo, > > ist es möglich, die mailq von einem Centos-Postfix Version 2.11.11 auf > Debian-Postfix Version  3.5.6 zu migrieren? > > Wenn ja, wie? -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 4207 bytes Beschreibung: S/MIME Cryptographic Signature URL : From a.wass at glas-gasperlmair.at Mon Oct 18 17:26:25 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Mon, 18 Oct 2021 17:26:25 +0200 Subject: Postfix-rspamd Problem durch recipient_bcc_maps Message-ID: Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From rs at sys4.de Mon Oct 18 18:03:21 2021 From: rs at sys4.de (Robert Schetterer) Date: Mon, 18 Oct 2021 18:03:21 +0200 Subject: Postfix-rspamd Problem durch recipient_bcc_maps In-Reply-To: References: Message-ID: <06a286ea-ce3a-a6a8-8c0a-ea707edd05b5@sys4.de> Am 18.10.21 um 17:26 schrieb Andreas Wass - Glas Gasperlmair: > Hallo Liste, > > möchten in naher Zukunft auf Postfix mit Dovecot und rspamd (zur Zeit > amavisd) umsteigen. > > 1.)    Alle eingehenden und ausgehenden Mails sollten zusätzlich mit > postfix durch recipient_bcc_maps und sender_bcc_maps an die > Archivpostfächer archiveingang at meinedomain.at und > archivausgang at meinedomain.at weitergeleitet. > > 2.    Soll ein globales Sieve-Script alle Mails, welche header :contains > "X-Spam" "Yes" haben in einen globalen Spam-Ordner redirecten > > 3.)    alle Mails welche header :contains "X-Spamd-Result" > ["FILENAME_BLACKLISTED", "MIME_BAD_ATTACHMENT", "MIME_BAD_EXTENSION"] > haben in einen globalen Banned-Ordner redirecten. > > Das Problem dabei ist, dass auch alle Mails durch recipient_bcc_maps und > sender_bcc_maps durch die Prüfung von rspamd geschickt werden und dann > natürlich doppelt in den spam und banned ordner landen und die Filterung > im Sievescript unnötig erschwert wird. > > Gibt es eine Möglichkeit, die Prüfung dieser E-Mails mit rspamd > auszulassen über die multimaps oder ähnliches, > oder über die master.cf bzw. main.cf in postfix wenn diese per > recipient_bcc_maps und sender_bcc_maps weitergeleitet werden? > > Oder was würdet ihr für so eine Anforderung machen? > > Vg, Andi mit rspamd kenne ich mich nicht aus aber ich hab uber sowas aehnliches mal einen blog geschrieben evtl hilfts ein wenig https://blog.sys4.de/mailarchiv-mit-dovecot-und-postfix-sortiert-nach-datum-mailadressen-und-ein-ausgehend-unterordnern-de.html -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From ml at irmawi.de Mon Oct 18 20:38:55 2021 From: ml at irmawi.de (Markus Winkler) Date: Mon, 18 Oct 2021 20:38:55 +0200 Subject: Postfix-rspamd Problem durch recipient_bcc_maps In-Reply-To: References: Message-ID: <175b1900-83b6-204c-787f-127fa8c447b3@irmawi.de> Hallo Andi, On 18.10.21 17:26, Andreas Wass - Glas Gasperlmair wrote: > möchten in naher Zukunft auf Postfix mit Dovecot und rspamd (zur Zeit > amavisd) umsteigen. > > 1.)    Alle eingehenden und ausgehenden Mails sollten zusätzlich mit > postfix durch recipient_bcc_maps und sender_bcc_maps an die > Archivpostfächer archiveingang at meinedomain.at und > archivausgang at meinedomain.at weitergeleitet. > > 2.    Soll ein globales Sieve-Script alle Mails, welche header :contains > "X-Spam" "Yes" haben in einen globalen Spam-Ordner redirecten > > 3.)    alle Mails welche header :contains "X-Spamd-Result" > ["FILENAME_BLACKLISTED", "MIME_BAD_ATTACHMENT", "MIME_BAD_EXTENSION"] haben > in einen globalen Banned-Ordner redirecten. > > Das Problem dabei ist, dass auch alle Mails durch recipient_bcc_maps und > sender_bcc_maps durch die Prüfung von rspamd geschickt werden und dann > natürlich doppelt in den spam und banned ordner landen und die Filterung im > Sievescript unnötig erschwert wird. bist Du sicher, dass das so ist und die Mails x-fach durch Rspamd laufen? Hast Du das praktisch schon so getestet und gesehen, oder sind das momentan Vorüberlegung für Dein zukünftiges Setup? Denn wenn ich mir das mal schnell im Log anschaue (und mich nicht vergucke ;-)), dann wird eine eingehende Mail nur ein Mal gecheckt und erst dann, wenn das alles erledigt ist, unter Angabe der einzelnen Empfänger per (in meinem Fall) LMTP an Dovecot übergeben und diese Mails dann von Dovecot in die Mailboxen des/der eigentlichen & des bcc-Empfänger(s) abgelegt. Zusätzlich laufen dabei ggf. vorhandene Sieve-Filterungen, das wären bei Dir oben also 2) und 3). Nach meinem Verständnis und wie gesagt auch anhand der Logs zu urteilen, ist in dieser späten Phase der Postfix-Verarbeitung (qmgr) kein Milter/Rspamd mehr beteiligt, nach Übergabe an Dovecot dann sowieso nicht mehr. Das Problem mehrfacher Mails in den Ordnern aus 2) und 3) entsteht wenn, dann m. E. erst am Ende der Verarbeitungskette: Da die Mails nämlich erst _nach_ Rspamd dupliziert werden, haben alle gleichermaßen ggf. Spam-Tags etc. bekommen. Und damit dürftest Du die dann wohl tatsächlich doppelt in den Spam-/Banned-Ordnern drin haben. Das sollte man jedoch mit der Sieve-Extension 'duplicate' von Dovecot-Pigeonhole klären können. Viele Grüße Markus From a.wass at glas-gasperlmair.at Tue Oct 19 09:55:52 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Tue, 19 Oct 2021 09:55:52 +0200 Subject: Postfix-rspamd Problem durch recipient_bcc_maps In-Reply-To: <06a286ea-ce3a-a6a8-8c0a-ea707edd05b5@sys4.de> References: <06a286ea-ce3a-a6a8-8c0a-ea707edd05b5@sys4.de> Message-ID: <20572b15-f10e-daa2-6276-5562e02084b0@glas-gasperlmair.at> Vielen Dank Robert, ich werd's mir anschauen. vg, Andi Am 18.10.2021 um 18:03 schrieb Robert Schetterer: > Am 18.10.21 um 17:26 schrieb Andreas Wass - Glas Gasperlmair: >> Hallo Liste, >> >> möchten in naher Zukunft auf Postfix mit Dovecot und rspamd (zur Zeit >> amavisd) umsteigen. >> >> 1.)    Alle eingehenden und ausgehenden Mails sollten zusätzlich mit >> postfix durch recipient_bcc_maps und sender_bcc_maps an die >> Archivpostfächer archiveingang at meinedomain.at und >> archivausgang at meinedomain.at weitergeleitet. >> >> 2.    Soll ein globales Sieve-Script alle Mails, welche header >> :contains "X-Spam" "Yes" haben in einen globalen Spam-Ordner redirecten >> >> 3.)    alle Mails welche header :contains "X-Spamd-Result" >> ["FILENAME_BLACKLISTED", "MIME_BAD_ATTACHMENT", "MIME_BAD_EXTENSION"] >> haben in einen globalen Banned-Ordner redirecten. >> >> Das Problem dabei ist, dass auch alle Mails durch recipient_bcc_maps >> und sender_bcc_maps durch die Prüfung von rspamd geschickt werden und >> dann natürlich doppelt in den spam und banned ordner landen und die >> Filterung im Sievescript unnötig erschwert wird. >> >> Gibt es eine Möglichkeit, die Prüfung dieser E-Mails mit rspamd >> auszulassen über die multimaps oder ähnliches, >> oder über die master.cf bzw. main.cf in postfix wenn diese per >> recipient_bcc_maps und sender_bcc_maps weitergeleitet werden? >> >> Oder was würdet ihr für so eine Anforderung machen? >> >> Vg, Andi > > mit rspamd kenne ich mich nicht aus > aber ich hab uber sowas aehnliches mal einen blog geschrieben > evtl hilfts ein wenig > > https://blog.sys4.de/mailarchiv-mit-dovecot-und-postfix-sortiert-nach-datum-mailadressen-und-ein-ausgehend-unterordnern-de.html > > From a.wass at glas-gasperlmair.at Tue Oct 19 10:17:21 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Tue, 19 Oct 2021 10:17:21 +0200 Subject: Postfix-rspamd Problem durch recipient_bcc_maps In-Reply-To: <175b1900-83b6-204c-787f-127fa8c447b3@irmawi.de> References: <175b1900-83b6-204c-787f-127fa8c447b3@irmawi.de> Message-ID: Wow, dass ist ja mal eine Antwort! Vielen Dank Markus, für deine ausführliche Analyse und du hast Recht, was rspamd betrifft und das ein Mail nur 1 x gecheckt wird. Und die Vermehrung der Mails im spam- oder banned-Postfach ist natürlich meinem globalem Sievescript geschuldet. Wenn das spam an 3 Empfänger gerichtet ist, dann landen 4 Mails im spam-Postfach (die 3 Empfänger und das vom archivpostfach, welches ja mit recipient_bcc_maps reinkommt. *Vielleicht hat irgendwer noch eine Idee, wie ich die Vermehrung gleich hier in meinem folgenden Script eliminieren könnte. * require "envelope"; # Mails, welche alle flags (bad attachment und spam) haben if allof (header :contains "X-Spamd-Result" ["FILENAME_BLACKLISTED", "MIME_BAD_ATTACHMENT", "MIME_BAD_EXTENSION"], header :contains "X-Spam" "Yes", not envelope "To" "banned at meinedomain.at", not envelope "To" "spam at meinedomain.at") {     redirect "spam at meinedomain.at";     discard;     stop; } # Mails, welche nur das spam flag haben elsif allof (header :contains "X-Spam" "Yes", not header :contains "X-Spamd-Result" ["FILENAME_BLACKLISTED", "MIME_BAD_ATTACHMENT", "MIME_BAD_EXTENSION"], not envelope "To" "spam at meinedomain.at") {     redirect "spam at meinedomain.at";     discard;     stop; } # Mails, welche nur das bad attachment flag haben elsif allof (header :contains "X-Spamd-Result" ["FILENAME_BLACKLISTED", "MIME_BAD_ATTACHMENT", "MIME_BAD_EXTENSION"], not header :contains "X-Spam" "Yes", not envelope "To" "banned at meinedomain.at") {     redirect "banned at meinedomain.at";     discard;     stop; } Sieve-Extension "duplicate" kenne ich (noch) nicht, habt ihr hiermit gute Erfahrungen? PS: Bitte um Entschuldigung an die Liste, dass jetzt ein Postfix-Dovecot-Sieve-Post aus der ursprünglichen Nachricht geworden ist, aber eine neue Fragestellung an dovecot at listen.jpberlin.de war mir jetzt doch zu umständlich. vg, Andi Am 18.10.2021 um 20:38 schrieb Markus Winkler: > Hallo Andi, > > On 18.10.21 17:26, Andreas Wass - Glas Gasperlmair wrote: >> möchten in naher Zukunft auf Postfix mit Dovecot und rspamd (zur Zeit >> amavisd) umsteigen. >> >> 1.)    Alle eingehenden und ausgehenden Mails sollten zusätzlich mit >> postfix durch recipient_bcc_maps und sender_bcc_maps an die >> Archivpostfächer archiveingang at meinedomain.at und >> archivausgang at meinedomain.at weitergeleitet. >> >> 2.    Soll ein globales Sieve-Script alle Mails, welche header >> :contains "X-Spam" "Yes" haben in einen globalen Spam-Ordner redirecten >> >> 3.)    alle Mails welche header :contains "X-Spamd-Result" >> ["FILENAME_BLACKLISTED", "MIME_BAD_ATTACHMENT", "MIME_BAD_EXTENSION"] >> haben in einen globalen Banned-Ordner redirecten. >> >> Das Problem dabei ist, dass auch alle Mails durch recipient_bcc_maps >> und sender_bcc_maps durch die Prüfung von rspamd geschickt werden und >> dann natürlich doppelt in den spam und banned ordner landen und die >> Filterung im Sievescript unnötig erschwert wird. > > bist Du sicher, dass das so ist und die Mails x-fach durch Rspamd > laufen? Hast Du das praktisch schon so getestet und gesehen, oder sind > das momentan Vorüberlegung für Dein zukünftiges Setup? > > Denn wenn ich mir das mal schnell im Log anschaue (und mich nicht > vergucke ;-)), dann wird eine eingehende Mail nur ein Mal gecheckt und > erst dann, wenn das alles erledigt ist, unter Angabe der einzelnen > Empfänger per (in meinem Fall) LMTP an Dovecot übergeben und diese > Mails dann von Dovecot in die Mailboxen des/der eigentlichen & des > bcc-Empfänger(s) abgelegt. Zusätzlich laufen dabei ggf. vorhandene > Sieve-Filterungen, das wären bei Dir oben also 2) und 3). > > Nach meinem Verständnis und wie gesagt auch anhand der Logs zu > urteilen, ist in dieser späten Phase der Postfix-Verarbeitung (qmgr) > kein Milter/Rspamd mehr beteiligt, nach Übergabe an Dovecot dann > sowieso nicht mehr. > > Das Problem mehrfacher Mails in den Ordnern aus 2) und 3) entsteht > wenn, dann m. E. erst am Ende der Verarbeitungskette: > > Da die Mails nämlich erst _nach_ Rspamd dupliziert werden, haben alle > gleichermaßen ggf. Spam-Tags etc. bekommen. Und damit dürftest Du die > dann wohl tatsächlich doppelt in den Spam-/Banned-Ordnern drin haben. > Das sollte man jedoch mit der Sieve-Extension 'duplicate' von > Dovecot-Pigeonhole klären können. > > Viele Grüße > Markus -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From ml at irmawi.de Tue Oct 19 20:40:43 2021 From: ml at irmawi.de (Markus Winkler) Date: Tue, 19 Oct 2021 20:40:43 +0200 Subject: Postfix-rspamd Problem durch recipient_bcc_maps In-Reply-To: References: <175b1900-83b6-204c-787f-127fa8c447b3@irmawi.de> Message-ID: Hallo Andi, On 19.10.21 10:17, Andreas Wass - Glas Gasperlmair wrote: > Vielleicht hat irgendwer noch eine Idee, wie ich die Vermehrung gleich > hier in meinem folgenden Script eliminieren könnte. falls Du das mit der duplicate extension realisieren möchtest: M. W. ist diese per default verfügbar, es kann aber auch nicht schaden, sie in 90-sieve.conf plugin { [...] sieve_extensions = +duplicate [...] } zu aktivieren. In (D)einem Script kann dann etwas in der Art stehen: require "duplicate"; if duplicate { discard; stop; } Hier noch Links zu Config-Optionen der Extension aus der Dovecot-Doku: https://doc.dovecot.org/settings/pigeonhole-ext/duplicate/ https://wiki2.dovecot.org/Pigeonhole/Sieve/Extensions/Duplicate HTH und viele Grüße Markus From a.wass at glas-gasperlmair.at Thu Oct 21 07:44:44 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Thu, 21 Oct 2021 07:44:44 +0200 Subject: Postfix-rspamd Problem durch recipient_bcc_maps In-Reply-To: References: <175b1900-83b6-204c-787f-127fa8c447b3@irmawi.de> Message-ID: Vielen Dank, Markus! Mit duplicate läuft jetzt alles so wie ich mir das vorgestellt habe. vg, Andi Am 19.10.2021 um 20:40 schrieb Markus Winkler: > Hallo Andi, > > On 19.10.21 10:17, Andreas Wass - Glas Gasperlmair wrote: >> Vielleicht hat irgendwer noch eine Idee, wie ich die Vermehrung >> gleich hier in meinem folgenden Script eliminieren könnte. > > falls Du das mit der duplicate extension realisieren möchtest: > > M. W. ist diese per default verfügbar, es kann aber auch nicht > schaden, sie in 90-sieve.conf > > plugin { > [...] > sieve_extensions = +duplicate [...] > } > > zu aktivieren. > > In (D)einem Script kann dann etwas in der Art stehen: > > require "duplicate"; > if duplicate { >     discard; >     stop; > } > > Hier noch Links zu Config-Optionen der Extension aus der Dovecot-Doku: > > https://doc.dovecot.org/settings/pigeonhole-ext/duplicate/ > https://wiki2.dovecot.org/Pigeonhole/Sieve/Extensions/Duplicate > > HTH und viele Grüße > Markus From ml at irmawi.de Thu Oct 21 17:19:36 2021 From: ml at irmawi.de (Markus Winkler) Date: Thu, 21 Oct 2021 17:19:36 +0200 Subject: Postfix-rspamd Problem durch recipient_bcc_maps In-Reply-To: References: <175b1900-83b6-204c-787f-127fa8c447b3@irmawi.de> Message-ID: <74a4c6c9-95e6-f49c-e803-cba29565af1c@irmawi.de> On 21.10.21 07:44, Andreas Wass - Glas Gasperlmair wrote: > Mit duplicate läuft jetzt alles so wie ich mir das vorgestellt habe. Das ist schön zu hören - vielen Dank fürs Feedback. :) VG, Markus From a.wass at glas-gasperlmair.at Mon Oct 25 09:10:24 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Mon, 25 Oct 2021 09:10:24 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 Message-ID: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> Hallo Liste, Obwohl ich ein offizielles aktuelles LetsEncrypt (am 23.10.2021 neu erstellt) Zertifikat für TLS verwende, beobachte ich schon seit längerem folgende Einträge im mail.log. alle ca. 20 Minuten. Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: warning: TLS library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:../ssl/record/rec_layer_s3.c:1543:SSL alert number 46: Zertifikat wurde vorgestern am 23.10.2021 mit folgendem Befehl neu erstellt, da wir auf eine neue Hardware umgezogen sind: (Meldungen kamen aber vorher auf der alten Maschine auch schon) certbot certonly --standalone --rsa-key-size 4096 -d mail1.gasperlmair.at Hab auch keine Beschwerden, dass jemand nicht einliefern könnte. Sollte ich das einfach ignorieren? vg, Andi From Walter.H at mathemainzel.info Mon Oct 25 10:09:37 2021 From: Walter.H at mathemainzel.info (Walter H.) Date: Mon, 25 Oct 2021 10:09:37 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> Message-ID: kannst Dir das Zwischenzertifikat, welches Du mitschickst, mal ansehen? On 25.10.2021 09:10, Andreas Wass - Glas Gasperlmair wrote: > Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: warning: TLS > library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 > alert certificate unknown:../ssl/record/rec_layer_s3.c:1543:SSL alert > number 46: -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 3550 bytes Beschreibung: S/MIME Cryptographic Signature URL : From Walter.H at mathemainzel.info Mon Oct 25 10:02:28 2021 From: Walter.H at mathemainzel.info (Walter H.) Date: Mon, 25 Oct 2021 10:02:28 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 In-Reply-To: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> Message-ID: <6471f710-eefb-d18a-66e7-2fce456f2dee@mathemainzel.info> Hallo, das hat weniger mit dem SSL-Zertifikat als mit den Ciphersuites und TLS versionen bzw. OpenSSL version selbst welche Du konfiguriert hast, zu tun; Walter On 25.10.2021 09:10, Andreas Wass - Glas Gasperlmair wrote: > Hallo Liste, > > Obwohl ich ein offizielles aktuelles LetsEncrypt (am 23.10.2021 neu > erstellt) Zertifikat für TLS verwende, beobachte ich schon seit > längerem folgende Einträge im mail.log. alle ca. 20 Minuten. > > Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: SSL_accept error > from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 > Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: warning: TLS > library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 > alert certificate unknown:../ssl/record/rec_layer_s3.c:1543:SSL alert > number 46: > > Zertifikat wurde vorgestern am 23.10.2021 mit folgendem Befehl neu > erstellt, da wir auf eine neue Hardware umgezogen sind: (Meldungen > kamen aber vorher auf der alten Maschine auch schon) > > certbot certonly --standalone --rsa-key-size 4096 -d mail1.gasperlmair.at > > Hab auch keine Beschwerden, dass jemand nicht einliefern könnte. > > Sollte ich das einfach ignorieren? > > vg, Andi -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 3550 bytes Beschreibung: S/MIME Cryptographic Signature URL : From a.wass at glas-gasperlmair.at Mon Oct 25 11:13:10 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Mon, 25 Oct 2021 11:13:10 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> Message-ID: <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> Am 25.10.2021 um 10:09 schrieb Walter H.: > kannst Dir das Zwischenzertifikat, welches Du mitschickst, mal ansehen? openssl s_client -starttls smtp -connect mail1.glasgasperlmair.at:25 Bringt folgende Ausgabe: CONNECTED(00000003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = mail1.glasgasperlmair.at verify return:1 --- Certificate chain  0 s:CN = mail1.glasgasperlmair.at    i:C = US, O = Let's Encrypt, CN = R3  1 s:C = US, O = Let's Encrypt, CN = R3    i:C = US, O = Internet Security Research Group, CN = ISRG Root X1  2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1    i:O = Digital Signature Trust Co., CN = DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- ..................................... (hab ich rausgeschnitten, damit Nachricht nicht so lang ist) -----END CERTIFICATE----- subject=CN = mail1.glasgasperlmair.at issuer=C = US, O = Let's Encrypt, CN = R3 --- No client certificate CA names sent Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1 Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 5593 bytes and written 808 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- 250 CHUNKING --- Post-Handshake New Session Ticket arrived: SSL-Session:     Protocol  : TLSv1.3     Cipher    : TLS_AES_256_GCM_SHA384     Session-ID: ACEDFFDE7C8E9CE76B54BF923D425B14650C5CA534FB20962DAF2BECB6F5FA3F     Session-ID-ctx:     Resumption PSK: 64DDB3FA7E7CA53B1B9AC72F6F977843385E291FA6C3692CD9045212F99AE91BFA52A759665BDAF97536A993D6CF8C93     PSK identity: None     PSK identity hint: None     SRP username: None     TLS session ticket lifetime hint: 7200 (seconds)     TLS session ticket:     0000 - e5 98 43 58 1a d4 17 9a-f6 61 a8 4b 0d b8 4f bb ..CX.....a.K..O.     0010 - 8c a6 00 2e 96 e0 94 ad-a2 b8 20 e1 95 ba 31 2e .......... ...1.     0020 - 74 fc 8c c4 1b b4 8d 8f-46 fb 64 53 fd ad 6e b0 t.......F.dS..n.     0030 - 4f 8c 99 31 cd 9f 35 87-ea 51 3f af 99 35 55 f6 O..1..5..Q?..5U.     0040 - bc 31 bd 3a c0 56 40 6c-3e 25 cb 51 cf e3 8e ea .1.:.V at l>%.Q....     0050 - f6 04 b0 42 e9 b2 12 e8-1e 23 1c 33 73 82 06 7d ...B.....#.3s..}     0060 - 96 8a 0e 7b 70 69 75 31-4b 20 16 60 66 45 38 67 ...{piu1K .`fE8g     0070 - a3 79 64 0d 5f 62 0d 9d-81 bf 0c 88 9d f5 c4 1d .yd._b..........     0080 - 96 66 35 d9 28 e9 cd b7-5f 00 1f d4 12 5b de f9 .f5.(..._....[..     0090 - 61 1f 46 31 e4 d3 dd e4-1e 16 25 7a 03 cd af 85 a.F1......%z....     00a0 - 20 4e af ee 4d 92 40 0a-10 aa 5b 8b df d8 4c 49 N..M. at ...[...LI     00b0 - 13 e3 c4 88 6b e4 af 1e-eb d9 4c 69 b3 78 88 be ....k.....Li.x..     00c0 - 51 74 b6 43 aa 3a e1 1b-89 a6 f8 09 65 16 33 0b Qt.C.:......e.3.     Start Time: 1635152892     Timeout   : 7200 (sec)     Verify return code: 0 (ok)     Extended master secret: no     Max Early Data: 0 --- read R BLOCK > > On 25.10.2021 09:10, Andreas Wass - Glas Gasperlmair wrote: >> Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: warning: TLS >> library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 >> alert certificate unknown:../ssl/record/rec_layer_s3.c:1543:SSL alert >> number 46: > > From Walter.H at mathemainzel.info Mon Oct 25 14:37:10 2021 From: Walter.H at mathemainzel.info (Walter H.) Date: Mon, 25 Oct 2021 14:37:10 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> Message-ID: <78db8c95-9346-7bcf-426d-e47a77b44291@mathemainzel.info> irgendwie ein Widerspruch wenn ich des bei mir im eingebe, kommt das (nur der interessante Teil) No client certificate CA names sent Server Temp Key: ECDH, prime256v1, 256 bits --- SSL handshake has read 5509 bytes and written 420 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported      <---  bei Dir war das 'IS NOT' Compression: NONE Expansion: NONE SSL-Session:     Protocol  : TLSv1.2     Cipher    : ECDHE-RSA-AES256-GCM-SHA384 beim Submission Port 587 kommt des gleiche wie beim Standardport 25 On 25.10.2021 11:13, Andreas Wass - Glas Gasperlmair wrote: > > Am 25.10.2021 um 10:09 schrieb Walter H.: >> kannst Dir das Zwischenzertifikat, welches Du mitschickst, mal ansehen? > openssl s_client -starttls smtp -connect mail1.glasgasperlmair.at:25 > > Bringt folgende Ausgabe: > > CONNECTED(00000003) > depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 > verify return:1 > depth=1 C = US, O = Let's Encrypt, CN = R3 > verify return:1 > depth=0 CN = mail1.glasgasperlmair.at > verify return:1 > --- > Certificate chain >  0 s:CN = mail1.glasgasperlmair.at >    i:C = US, O = Let's Encrypt, CN = R3 >  1 s:C = US, O = Let's Encrypt, CN = R3 >    i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 >  2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 >    i:O = Digital Signature Trust Co., CN = DST Root CA X3 > --- > Server certificate > -----BEGIN CERTIFICATE----- > ..................................... (hab ich rausgeschnitten, damit > Nachricht nicht so lang ist) > -----END CERTIFICATE----- > subject=CN = mail1.glasgasperlmair.at > > issuer=C = US, O = Let's Encrypt, CN = R3 > > --- > No client certificate CA names sent > Requested Signature Algorithms: > ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1 > Shared Requested Signature Algorithms: > ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512 > Peer signing digest: SHA256 > Peer signature type: RSA-PSS > Server Temp Key: ECDH, P-256, 256 bits > --- > SSL handshake has read 5593 bytes and written 808 bytes > Verification: OK > --- > New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 > Server public key is 4096 bit > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > Early data was not sent > Verify return code: 0 (ok) > --- > 250 CHUNKING > --- > Post-Handshake New Session Ticket arrived: > SSL-Session: >     Protocol  : TLSv1.3 >     Cipher    : TLS_AES_256_GCM_SHA384 >     Session-ID: > ACEDFFDE7C8E9CE76B54BF923D425B14650C5CA534FB20962DAF2BECB6F5FA3F >     Session-ID-ctx: >     Resumption PSK: > 64DDB3FA7E7CA53B1B9AC72F6F977843385E291FA6C3692CD9045212F99AE91BFA52A759665BDAF97536A993D6CF8C93 >     PSK identity: None >     PSK identity hint: None >     SRP username: None >     TLS session ticket lifetime hint: 7200 (seconds) >     TLS session ticket: >     0000 - e5 98 43 58 1a d4 17 9a-f6 61 a8 4b 0d b8 4f bb > ..CX.....a.K..O. >     0010 - 8c a6 00 2e 96 e0 94 ad-a2 b8 20 e1 95 ba 31 2e .......... > ...1. >     0020 - 74 fc 8c c4 1b b4 8d 8f-46 fb 64 53 fd ad 6e b0 > t.......F.dS..n. >     0030 - 4f 8c 99 31 cd 9f 35 87-ea 51 3f af 99 35 55 f6 > O..1..5..Q?..5U. >     0040 - bc 31 bd 3a c0 56 40 6c-3e 25 cb 51 cf e3 8e ea > .1.:.V at l>%.Q.... >     0050 - f6 04 b0 42 e9 b2 12 e8-1e 23 1c 33 73 82 06 7d > ...B.....#.3s..} >     0060 - 96 8a 0e 7b 70 69 75 31-4b 20 16 60 66 45 38 67 ...{piu1K > .`fE8g >     0070 - a3 79 64 0d 5f 62 0d 9d-81 bf 0c 88 9d f5 c4 1d > .yd._b.......... >     0080 - 96 66 35 d9 28 e9 cd b7-5f 00 1f d4 12 5b de f9 > .f5.(..._....[.. >     0090 - 61 1f 46 31 e4 d3 dd e4-1e 16 25 7a 03 cd af 85 > a.F1......%z.... >     00a0 - 20 4e af ee 4d 92 40 0a-10 aa 5b 8b df d8 4c 49 > N..M. at ...[...LI >     00b0 - 13 e3 c4 88 6b e4 af 1e-eb d9 4c 69 b3 78 88 be > ....k.....Li.x.. >     00c0 - 51 74 b6 43 aa 3a e1 1b-89 a6 f8 09 65 16 33 0b > Qt.C.:......e.3. > >     Start Time: 1635152892 >     Timeout   : 7200 (sec) >     Verify return code: 0 (ok) >     Extended master secret: no >     Max Early Data: 0 > --- > read R BLOCK >> >> On 25.10.2021 09:10, Andreas Wass - Glas Gasperlmair wrote: >>> Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: warning: TLS >>> library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 >>> alert certificate unknown:../ssl/record/rec_layer_s3.c:1543:SSL >>> alert number 46: >> >> > -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 3550 bytes Beschreibung: S/MIME Cryptographic Signature URL : From ml at irmawi.de Mon Oct 25 21:38:06 2021 From: ml at irmawi.de (Markus Winkler) Date: Mon, 25 Oct 2021 21:38:06 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> Message-ID: <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> Hi Andi, ich vermute mal, dass das Problem: > Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: warning: TLS library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:../ssl/record/rec_layer_s3.c:1543:SSL alert number 46: (der Client 213-225-38-118.nat.highway.a1.net[213.225.38.118] kann Dein Server-Cert nicht verifizieren) damit zusammenhängt: On 25.10.21 11:13, Andreas Wass - Glas Gasperlmair wrote: > > openssl s_client -starttls smtp -connect mail1.glasgasperlmair.at:25 > > Certificate chain >  0 s:CN = mail1.glasgasperlmair.at >    i:C = US, O = Let's Encrypt, CN = R3 >  1 s:C = US, O = Let's Encrypt, CN = R3 >    i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 >  2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 >    i:O = Digital Signature Trust Co., CN = DST Root CA X3 ------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Wenn man sich die oben aufgeführten Certs, die Dein Server einem Client schickt, im Detail anzeigen lässt, wird beim Root-Cert (oben die Nr. 2) u. a. folgendes angezeigt: Certificate: Data: Version: 3 (0x2) Serial Number: 40:01:77:21:37:d4:e9:42:b8:ee:76:aa:3c:64:0a:b7 Signature Algorithm: sha256WithRSAEncryption Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 Validity Not Before: Jan 20 19:14:03 2021 GMT Not After : Sep 30 18:14:03 2024 GMT Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1 [...] X509v3 Authority Key Identifier: keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10 Und für dessen Issuer 'CN = DST Root CA X3' (Key Identifier: C4:A7:B1 ... 85:89:10) gilt: Validity (Expired) Not Before: Sep 30 21:12:19 2000 GMT Not After : Sep 30 14:01:15 2021 GMT (https://crt.sh/?id=8395) Wenn der einliefernde Client nur dieses Root-Cert nimmt, das Dein Server mitschickt und den Issuer anschaut, dann wird er Deinem Cert nicht trauen. Hat der Client jedoch einen aktuellen CA Root Store und schaut sich den alternativen Cert-Path an, wird er dieses kennen/akzeptieren: https://crt.sh/?id=9314791 womit dann auch das Intermediate 'C = US, O = Let's Encrypt, CN = R3' gültig ist und somit ebenso Dein 'CN = mail1.glasgasperlmair.at' - damit dürften von solchen Client in Deinem Log dann keine Cert-Fehler mehr zu sehen sein. Denke ich mal. ;-) Siehe auch hier: https://letsencrypt.org/certificates/#cross-signing Viele Grüße Markus From a.wass at glas-gasperlmair.at Tue Oct 26 09:47:50 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Tue, 26 Oct 2021 09:47:50 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> Message-ID: <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> Vielen Dank Markus, für deine ausführliche Antwort wieder einmal! Kann ich denn von meiner Seite aus etwas dazu beitragen (Konfiguration oder kostenpflichtiges Zertifikat)? vg, Andi Am 25.10.2021 um 21:38 schrieb Markus Winkler: > Hi Andi, > > ich vermute mal, dass das Problem: > >> Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: warning: TLS >> library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 >> alert certificate unknown:../ssl/record/rec_layer_s3.c:1543:SSL alert >> number 46: > > (der Client 213-225-38-118.nat.highway.a1.net[213.225.38.118] kann > Dein Server-Cert nicht verifizieren) > > damit zusammenhängt: > > On 25.10.21 11:13, Andreas Wass - Glas Gasperlmair wrote: >> >> openssl s_client -starttls smtp -connect mail1.glasgasperlmair.at:25 >> >> Certificate chain >>   0 s:CN = mail1.glasgasperlmair.at >>     i:C = US, O = Let's Encrypt, CN = R3 >>   1 s:C = US, O = Let's Encrypt, CN = R3 >>     i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 >>   2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 >>     i:O = Digital Signature Trust Co., CN = DST Root CA X3 > > ------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Wenn man sich die oben aufgeführten Certs, die Dein Server einem > Client schickt, im Detail anzeigen lässt, wird beim Root-Cert (oben > die Nr. 2) u. a. folgendes angezeigt: > > Certificate: >     Data: >         Version: 3 (0x2) >         Serial Number: >             40:01:77:21:37:d4:e9:42:b8:ee:76:aa:3c:64:0a:b7 >         Signature Algorithm: sha256WithRSAEncryption >         Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 >         Validity >             Not Before: Jan 20 19:14:03 2021 GMT >             Not After : Sep 30 18:14:03 2024 GMT >         Subject: C = US, O = Internet Security Research Group, CN = > ISRG Root X1 > [...] >             X509v3 Authority Key Identifier: > keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10 > > > Und für dessen Issuer 'CN = DST Root CA X3' (Key Identifier: C4:A7:B1 > ... 85:89:10) gilt: > >        Validity (Expired) >             Not Before: Sep 30 21:12:19 2000 GMT >             Not After : Sep 30 14:01:15 2021 GMT > > (https://crt.sh/?id=8395) > > Wenn der einliefernde Client nur dieses Root-Cert nimmt, das Dein > Server mitschickt und den Issuer anschaut, dann wird er Deinem Cert > nicht trauen. Hat der Client jedoch einen aktuellen CA Root Store und > schaut sich den alternativen Cert-Path an, wird er dieses > kennen/akzeptieren: > > https://crt.sh/?id=9314791 > > womit dann auch das Intermediate 'C = US, O = Let's Encrypt, CN = R3' > gültig ist und somit ebenso Dein 'CN = mail1.glasgasperlmair.at' - > damit dürften von solchen Client in Deinem Log dann keine Cert-Fehler > mehr zu sehen sein. > > Denke ich mal. ;-) > > Siehe auch hier: https://letsencrypt.org/certificates/#cross-signing > > Viele Grüße > Markus From Walter.H at mathemainzel.info Tue Oct 26 10:46:44 2021 From: Walter.H at mathemainzel.info (Walter H.) Date: Tue, 26 Oct 2021 10:46:44 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> Message-ID: <2ffe1c72-5b93-8986-0643-7e345d402672@mathemainzel.info> On 26.10.2021 09:47, Andreas Wass - Glas Gasperlmair wrote: > Vielen Dank Markus, für deine ausführliche Antwort wieder einmal! > > Kann ich denn von meiner Seite aus etwas dazu beitragen (Konfiguration > oder kostenpflichtiges Zertifikat)? > > vg, Andi schickt Dein Server außer dem SSL-Zertifikat und dem R3-Zwischenzertifikat, noch eines mit? dann reduzier es auf diese beiden; das genügt; @Markus:  ist es logisch, dass auf dem Server Fehler im Log sind, wenn der Client ein 'Problem' mit der Validierung des SSL-Zertifikates bzw. der Zertifikatskette hätte? -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 3550 bytes Beschreibung: S/MIME Cryptographic Signature URL : From tobster at brain-force.ch Tue Oct 26 11:00:49 2021 From: tobster at brain-force.ch (Tobi) Date: Tue, 26 Oct 2021 11:00:49 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> Message-ID: Das DST Root CA X3 ist abgelaufen, was noch Letsencrypt auch lange im Voraus angekündigt wurde: https://community.letsencrypt.org/t/production-chain-changes/150739 Der sendende Client scheint die neue Chain nicht zu kennen und kann damit dein LE Cert nicht verifizieren. Das sollte aber eigentlich nur recht alte Clients betreffen, welche keine Updates der Trust Stores mehr erhalten. Du kannst auf einen anderen Anbieter wechseln und darauf hoffen, dass der Client dann dessen Chain validieren kann. Oder damit leben, dass gewisse alte Clients keine SSL/TLS Verbindung mehr zu Dir hinbekommen. Sie sollten in dem Fall ja eigentlich auf non-ssl/tls zurückfallen. Gruss tobi On ???, 2021-10-26 at 09:47 +0200, Andreas Wass - Glas Gasperlmair wrote: > Vielen Dank Markus, für deine ausführliche Antwort wieder einmal! > > Kann ich denn von meiner Seite aus etwas dazu beitragen (Konfiguration > oder kostenpflichtiges Zertifikat)? > > vg, Andi > > Am 25.10.2021 um 21:38 schrieb Markus Winkler: > > Hi Andi, > > > > ich vermute mal, dass das Problem: > > > > > Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: warning: TLS > > > library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 > > > alert certificate unknown:../ssl/record/rec_layer_s3.c:1543:SSL > > > alert > > > number 46: > > > > (der Client 213-225-38-118.nat.highway.a1.net[213.225.38.118] kann > > Dein Server-Cert nicht verifizieren) > > > > damit zusammenhängt: > > > > On 25.10.21 11:13, Andreas Wass - Glas Gasperlmair wrote: > > > > > > openssl s_client -starttls smtp -connect > > > mail1.glasgasperlmair.at:25 > > > > > > Certificate chain > > >   0 s:CN = mail1.glasgasperlmair.at > > >     i:C = US, O = Let's Encrypt, CN = R3 > > >   1 s:C = US, O = Let's Encrypt, CN = R3 > > >     i:C = US, O = Internet Security Research Group, CN = ISRG Root > > > X1 > > >   2 s:C = US, O = Internet Security Research Group, CN = ISRG Root > > > X1 > > >     i:O = Digital Signature Trust Co., CN = DST Root CA X3 > > > > ------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Wenn man sich die oben aufgeführten Certs, die Dein Server einem > > die Nr. 2) u. a. folgendes angezeigt: > > > > Certificate: > >     Data: > >         Version: 3 (0x2) > >         Serial Number: > >             40:01:77:21:37:d4:e9:42:b8:ee:76:aa:3c:64:0a:b7 > >         Signature Algorithm: sha256WithRSAEncryption > >         Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 > >         Validity > >             Not Before: Jan 20 19:14:03 2021 GMT > >             Not After : Sep 30 18:14:03 2024 GMT > > ISRG Root X1 > > [...] > >             X509v3 Authority Key Identifier: > > keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10 > > > > > > Und für dessen Issuer 'CN = DST Root CA X3' (Key Identifier: C4:A7:B1 > > ... 85:89:10) gilt: > > > >        Validity (Expired) > >             Not Before: Sep 30 21:12:19 2000 GMT > >             Not After : Sep 30 14:01:15 2021 GMT > > > > (https://crt.sh/?id=8395) > > > > Wenn der einliefernde Client nur dieses Root-Cert nimmt, das Dein > > nicht trauen. Hat der Client jedoch einen aktuellen CA Root Store und > > schaut sich den alternativen Cert-Path an, wird er dieses > > kennen/akzeptieren: > > > > https://crt.sh/?id=9314791 > > > > womit dann auch das Intermediate 'C = US, O = Let's Encrypt, CN = R3' > > gültig ist und somit ebenso Dein 'CN = mail1.glasgasperlmair.at' - > > damit dürften von solchen Client in Deinem Log dann keine Cert-Fehler > > mehr zu sehen sein. > > > > Denke ich mal. ;-) > > > > Siehe auch hier: https://letsencrypt.org/certificates/#cross-signing > > > > Viele Grüße > > Markus From mailinglist at schaal-24.de Tue Oct 26 11:49:26 2021 From: mailinglist at schaal-24.de (Florian Schaal) Date: Tue, 26 Oct 2021 11:49:26 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> Message-ID: Du kannst auch das abgelaufene Root-Zertifkat auf dem Server löschen. Das sollte reichen. Sonst kannst Du das noch über smtpd_tls_CAfile mitschicken Am 26.10.2021 um 11:00 schrieb Tobi: > Das DST Root CA X3 ist abgelaufen, was noch Letsencrypt auch lange im > Voraus angekündigt wurde: > https://community.letsencrypt.org/t/production-chain-changes/150739 > > Der sendende Client scheint die neue Chain nicht zu kennen und kann > damit dein LE Cert nicht verifizieren. Das sollte aber eigentlich nur > recht alte Clients betreffen, welche keine Updates der Trust Stores > mehr erhalten. > > Du kannst auf einen anderen Anbieter wechseln und darauf hoffen, dass > der Client dann dessen Chain validieren kann. Oder damit leben, dass > gewisse alte Clients keine SSL/TLS Verbindung mehr zu Dir hinbekommen. > Sie sollten in dem Fall ja eigentlich auf non-ssl/tls zurückfallen. > > Gruss > > tobi > > On ???, 2021-10-26 at 09:47 +0200, Andreas Wass - Glas Gasperlmair > wrote: >> Vielen Dank Markus, für deine ausführliche Antwort wieder einmal! >> >> Kann ich denn von meiner Seite aus etwas dazu beitragen (Konfiguration >> oder kostenpflichtiges Zertifikat)? >> >> vg, Andi >> >> Am 25.10.2021 um 21:38 schrieb Markus Winkler: >>> Hi Andi, >>> >>> ich vermute mal, dass das Problem: >>> >>>> Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: warning: TLS >>>> library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 >>>> alert certificate unknown:../ssl/record/rec_layer_s3.c:1543:SSL >>>> alert >>>> number 46: >>> >>> (der Client 213-225-38-118.nat.highway.a1.net[213.225.38.118] kann >>> Dein Server-Cert nicht verifizieren) >>> >>> damit zusammenhängt: >>> >>> On 25.10.21 11:13, Andreas Wass - Glas Gasperlmair wrote: >>>> >>>> openssl s_client -starttls smtp -connect >>>> mail1.glasgasperlmair.at:25 >>>> >>>> Certificate chain >>>>   0 s:CN = mail1.glasgasperlmair.at >>>>     i:C = US, O = Let's Encrypt, CN = R3 >>>>   1 s:C = US, O = Let's Encrypt, CN = R3 >>>>     i:C = US, O = Internet Security Research Group, CN = ISRG Root >>>> X1 >>>>   2 s:C = US, O = Internet Security Research Group, CN = ISRG Root >>>> X1 >>>>     i:O = Digital Signature Trust Co., CN = DST Root CA X3 >>> >>> ------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> Wenn man sich die oben aufgeführten Certs, die Dein Server einem >>> die Nr. 2) u. a. folgendes angezeigt: >>> >>> Certificate: >>>     Data: >>>         Version: 3 (0x2) >>>         Serial Number: >>>             40:01:77:21:37:d4:e9:42:b8:ee:76:aa:3c:64:0a:b7 >>>         Signature Algorithm: sha256WithRSAEncryption >>>         Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 >>>         Validity >>>             Not Before: Jan 20 19:14:03 2021 GMT >>>             Not After : Sep 30 18:14:03 2024 GMT >>> ISRG Root X1 >>> [...] >>>             X509v3 Authority Key Identifier: >>> keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10 >>> >>> >>> Und für dessen Issuer 'CN = DST Root CA X3' (Key Identifier: C4:A7:B1 >>> ... 85:89:10) gilt: >>> >>>        Validity (Expired) >>>             Not Before: Sep 30 21:12:19 2000 GMT >>>             Not After : Sep 30 14:01:15 2021 GMT >>> >>> (https://crt.sh/?id=8395) >>> >>> Wenn der einliefernde Client nur dieses Root-Cert nimmt, das Dein >>> nicht trauen. Hat der Client jedoch einen aktuellen CA Root Store und >>> schaut sich den alternativen Cert-Path an, wird er dieses >>> kennen/akzeptieren: >>> >>> https://crt.sh/?id=9314791 >>> >>> womit dann auch das Intermediate 'C = US, O = Let's Encrypt, CN = R3' >>> gültig ist und somit ebenso Dein 'CN = mail1.glasgasperlmair.at' - >>> damit dürften von solchen Client in Deinem Log dann keine Cert-Fehler >>> mehr zu sehen sein. >>> >>> Denke ich mal. ;-) >>> >>> Siehe auch hier: https://letsencrypt.org/certificates/#cross-signing >>> >>> Viele Grüße >>> Markus > > From ml at irmawi.de Tue Oct 26 13:09:26 2021 From: ml at irmawi.de (Markus Winkler) Date: Tue, 26 Oct 2021 13:09:26 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <2ffe1c72-5b93-8986-0643-7e345d402672@mathemainzel.info> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <2ffe1c72-5b93-8986-0643-7e345d402672@mathemainzel.info> Message-ID: <4824f680-073e-791f-249a-4cce0e0a9396@irmawi.de> Hallo Walther, On 26.10.21 10:46, Walter H. wrote: > schickt Dein Server außer dem SSL-Zertifikat und dem R3-Zwischenzertifikat, > noch eines mit? ja, er schickt neben dem Server- und dem R3-Intermediate- auch das Root-Cert mit. Ist bei den mir bekannten ACME-Clients so, dass die Letzteres in die chain bzw. fullchain-Files standardmäßig mit rein packen. > dann reduzier es auf diese beiden; das genügt; Ja, das Root-Cert kann raus. Mache ich z. B. auch bei Webservern immer so - der Client kann und sollte das gegen die Root-Certs in seinem eigenen Cert-Store prüfen. Allerdings würde das im vorliegenden Fall nicht helfen. Denn ein älterer Client hätte in seinem nicht mehr aktualisierten Cert-Store für die Prüfung des Issuers des R3-Intermediates dann auch nur das eben Ende September abgelaufene Root-Cert der 'DST Root CA X3' und (noch) nicht das Self-signed 'ISRG Root X1' vom Juni 2015. Die Verantwortung für das Problem liegt m. E. klar beim Client, dort besteht Handlungsbedarf. Let's Encrypt hat übrigens eine kleine Übersicht zu problematischen Clients veröffentlicht: https://letsencrypt.org/docs/certificate-compatibility/ > @Markus:  ist es logisch, dass auf dem Server Fehler im Log sind, wenn der > Client ein 'Problem' > mit der Validierung des SSL-Zertifikates bzw. der Zertifikatskette hätte? Ob es logisch ist, kann ich nicht sagen. ;-) Es m. W. jedenfalls so, dass der SSL-Stack des Clients diese fehlgeschlagene Verifizierung des Server-Certs mit einem Alert signalisiert, und den sieht man dann im Log des Servers. Viele Grüße Markus From ml at irmawi.de Tue Oct 26 13:15:05 2021 From: ml at irmawi.de (Markus Winkler) Date: Tue, 26 Oct 2021 13:15:05 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> Message-ID: <03804e30-9e1c-428c-0db4-24ae42f616b4@irmawi.de> Hallo Andi, On 26.10.21 09:47, Andreas Wass - Glas Gasperlmair wrote: > Kann ich denn von meiner Seite aus etwas dazu beitragen (Konfiguration oder > kostenpflichtiges Zertifikat)? siehe auch meine Antwort an Walter. Ein Cert einer anderen CA könnte "helfen", aber das wäre in meinen Augen nur Kurieren des Symptoms. Denn auch bei einer anderen CA laufen Root-Certs ab, und dann steht man bei irgendwelchen hornalten, nicht mehr gepflegten Clients irgendwann auch vor diesem Problem. Der aus meiner Sicht einzig sinnvolle Weg: Wichtige Clients/Mailpartner auf das Problem hinweisen, alle anderen ignorieren, wenn sie sich über die Pflege und Aktualisierung ihrer Systeme keine Gedanken machen ... ;-) Viele Grüße Markus From a.wass at glas-gasperlmair.at Tue Oct 26 13:33:08 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Tue, 26 Oct 2021 13:33:08 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> Message-ID: Vielen Dank Leute für eure sehr hilfreichen Antworten. Anbei noch meine Kommentare zwischen den Zeilen Am 26.10.2021 um 11:49 schrieb Florian Schaal: > Du kannst auch das abgelaufene Root-Zertifkat auf dem Server löschen. > Das sollte reichen. Auf meinem neuen Server dürfte es kein abgelaufenes Root-Zertifikat geben, da die neuen Zertifikate ja erst letzten Samstag erstellt wurden? Da gab es vorher noch keine Zertifikate. > > Sonst kannst Du das noch über smtpd_tls_CAfile mitschicken > > Am 26.10.2021 um 11:00 schrieb Tobi: >> Das DST Root CA X3 ist abgelaufen, was noch Letsencrypt auch lange im >> Voraus angekündigt wurde: >> https://community.letsencrypt.org/t/production-chain-changes/150739 >> >> Der sendende Client scheint die neue Chain nicht zu kennen und kann >> damit dein LE Cert nicht verifizieren. Das sollte aber eigentlich nur >> recht alte Clients betreffen, welche keine Updates der Trust Stores >> mehr erhalten. OK, und somit sein Problem. >> >> Du kannst auf einen anderen Anbieter wechseln und darauf hoffen, dass >> der Client dann dessen Chain validieren kann. Oder damit leben, dass >> gewisse alte Clients keine SSL/TLS Verbindung mehr zu Dir hinbekommen. >> Sie sollten in dem Fall ja eigentlich auf non-ssl/tls zurückfallen. Genau, wenn schon keine verschlüsselte Verbindung dann eben ohne, Dank smtpd_tls_security_level = may. >> >> Gruss >> >> tobi >> >> On ???, 2021-10-26 at 09:47 +0200, Andreas Wass - Glas Gasperlmair >> wrote: >>> Vielen Dank Markus, für deine ausführliche Antwort wieder einmal! >>> >>> Kann ich denn von meiner Seite aus etwas dazu beitragen (Konfiguration >>> oder kostenpflichtiges Zertifikat)? >>> >>> vg, Andi >>> >>> Am 25.10.2021 um 21:38 schrieb Markus Winkler: >>>> Hi Andi, >>>> >>>> ich vermute mal, dass das Problem: >>>> >>>>> Oct 25 08:59:14 mail postfix/submission/smtpd[33873]: warning: TLS >>>>> library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 >>>>> alert certificate unknown:../ssl/record/rec_layer_s3.c:1543:SSL >>>>> alert >>>>> number 46: >>>> >>>> (der Client 213-225-38-118.nat.highway.a1.net[213.225.38.118] kann >>>> Dein Server-Cert nicht verifizieren) >>>> >>>> damit zusammenhängt: >>>> >>>> On 25.10.21 11:13, Andreas Wass - Glas Gasperlmair wrote: >>>>> >>>>> openssl s_client -starttls smtp -connect >>>>> mail1.glasgasperlmair.at:25 >>>>> >>>>> Certificate chain >>>>>    0 s:CN = mail1.glasgasperlmair.at >>>>>      i:C = US, O = Let's Encrypt, CN = R3 >>>>>    1 s:C = US, O = Let's Encrypt, CN = R3 >>>>>      i:C = US, O = Internet Security Research Group, CN = ISRG Root >>>>> X1 >>>>>    2 s:C = US, O = Internet Security Research Group, CN = ISRG Root >>>>> X1 >>>>>      i:O = Digital Signature Trust Co., CN = DST Root CA X3 >>>> >>>> ------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> >>>> Wenn man sich die oben aufgeführten Certs, die Dein Server einem >>>> die Nr. 2) u. a. folgendes angezeigt: >>>> >>>> Certificate: >>>>      Data: >>>>          Version: 3 (0x2) >>>>          Serial Number: >>>>              40:01:77:21:37:d4:e9:42:b8:ee:76:aa:3c:64:0a:b7 >>>>          Signature Algorithm: sha256WithRSAEncryption >>>>          Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 >>>>          Validity >>>>              Not Before: Jan 20 19:14:03 2021 GMT >>>>              Not After : Sep 30 18:14:03 2024 GMT >>>> ISRG Root X1 >>>> [...] >>>>              X509v3 Authority Key Identifier: >>>> keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10 >>>> >>>> >>>> Und für dessen Issuer 'CN = DST Root CA X3' (Key Identifier: C4:A7:B1 >>>> ... 85:89:10) gilt: >>>> >>>>         Validity (Expired) >>>>              Not Before: Sep 30 21:12:19 2000 GMT >>>>              Not After : Sep 30 14:01:15 2021 GMT >>>> >>>> (https://crt.sh/?id=8395) >>>> >>>> Wenn der einliefernde Client nur dieses Root-Cert nimmt, das Dein >>>> nicht trauen. Hat der Client jedoch einen aktuellen CA Root Store und >>>> schaut sich den alternativen Cert-Path an, wird er dieses >>>> kennen/akzeptieren: >>>> >>>> https://crt.sh/?id=9314791 >>>> >>>> womit dann auch das Intermediate 'C = US, O = Let's Encrypt, CN = R3' >>>> gültig ist und somit ebenso Dein 'CN = mail1.glasgasperlmair.at' - >>>> damit dürften von solchen Client in Deinem Log dann keine Cert-Fehler >>>> mehr zu sehen sein. >>>> >>>> Denke ich mal. ;-) >>>> >>>> Siehe auch hier: https://letsencrypt.org/certificates/#cross-signing >>>> >>>> Viele Grüße >>>> Markus >> >> > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From mailinglist at schaal-24.de Tue Oct 26 15:06:07 2021 From: mailinglist at schaal-24.de (Florian Schaal) Date: Tue, 26 Oct 2021 15:06:07 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> Message-ID: <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> Am 26.10.2021 um 13:33 schrieb Andreas Wass - Glas Gasperlmair: > Vielen Dank Leute für eure sehr hilfreichen Antworten. > Anbei noch meine Kommentare zwischen den Zeilen > > Am 26.10.2021 um 11:49 schrieb Florian Schaal: >> Du kannst auch das abgelaufene Root-Zertifkat auf dem Server löschen. >> Das sollte reichen. > Auf meinem neuen Server dürfte es kein abgelaufenes Root-Zertifikat > geben, da die neuen Zertifikate ja erst letzten Samstag erstellt wurden? > Da gab es vorher noch keine Zertifikate. Das ist Deinem Server ja mal herzlich egal. Ich meinte sowas wie sed -i "s/^mozilla\/DST_Root_CA_X3\.crt/\!mozilla\/DST_Root_CA_X3\.crt/g" /etc/ca-certificates.conf update-ca-certificates From ml at irmawi.de Tue Oct 26 15:33:37 2021 From: ml at irmawi.de (Markus Winkler) Date: Tue, 26 Oct 2021 15:33:37 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> Message-ID: <00534f91-479c-9c66-8bb2-6d161a5c79f4@irmawi.de> Hi Andreas, On 26.10.21 13:33, Andreas Wass - Glas Gasperlmair wrote: > Am 26.10.2021 um 11:49 schrieb Florian Schaal: >> Du kannst auch das abgelaufene Root-Zertifkat auf dem Server löschen. Das >> sollte reichen. > Auf meinem neuen Server dürfte es kein abgelaufenes Root-Zertifikat geben, > da die neuen Zertifikate ja erst letzten Samstag erstellt wurden? doch - gibt es, siehe meine Mail von gestern Abend. ;-) Kurzform: Das im Zuge der Neuaustellung Deines Server-Certs in die chain/fullchain-Datei eingefügte Root-Cert wurde mit einem am 30.09.2021 ausgestellten und somit nun abgelaufenen Cert von 'DST Root CA X3'signiert. Siehe den Link zum LE-Dokument bzgl. Cross Signing. Für (neuere) Clients, die den alternativen Zertifizierungspfad über das 'ISRG Root X1' vom Juni 2015 haben/kennen, ist das kein Problem. Für alle anderen, die dieses nicht haben, schon. Und für Letztere reicht halt auch das Löschen dieses Certs auf Deinem Server nicht wirklich. Aber wie bereits geschrieben: Ich würde mich (vielleicht abgesehen Ausnahmefällen) nicht darum kümmern: Problem der Clients, fertig. ;-) Viele Grüße Markus From a.wass at glas-gasperlmair.at Tue Oct 26 16:03:19 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Tue, 26 Oct 2021 16:03:19 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <03804e30-9e1c-428c-0db4-24ae42f616b4@irmawi.de> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <03804e30-9e1c-428c-0db4-24ae42f616b4@irmawi.de> Message-ID: <9d275017-37fc-539b-f26f-c63c6f43f1f8@glas-gasperlmair.at> Vielen Dank Markus, Am 26.10.2021 um 13:15 schrieb Markus Winkler: > Hallo Andi, > > On 26.10.21 09:47, Andreas Wass - Glas Gasperlmair wrote: >> Kann ich denn von meiner Seite aus etwas dazu beitragen >> (Konfiguration oder kostenpflichtiges Zertifikat)? > > siehe auch meine Antwort an Walter. Ein Cert einer anderen CA könnte > "helfen", aber das wäre in meinen Augen nur Kurieren des Symptoms. > Denn auch bei einer anderen CA laufen Root-Certs ab, und dann steht > man bei irgendwelchen hornalten, nicht mehr gepflegten Clients > irgendwann auch vor diesem Problem. > > Der aus meiner Sicht einzig sinnvolle Weg: Wichtige > Clients/Mailpartner auf das Problem hinweisen, alle anderen > ignorieren, wenn sie sich über die Pflege und Aktualisierung ihrer > Systeme keine Gedanken machen ... ;-) Genau so sehe ich das auch :-) > > Viele Grüße > Markus From a.wass at glas-gasperlmair.at Tue Oct 26 16:25:04 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Tue, 26 Oct 2021 16:25:04 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> Message-ID: Ah, jetzt hab ich verstanden,... Am 26.10.2021 um 15:06 schrieb Florian Schaal: > Am 26.10.2021 um 13:33 schrieb Andreas Wass - Glas Gasperlmair: >> Vielen Dank Leute für eure sehr hilfreichen Antworten. >> Anbei noch meine Kommentare zwischen den Zeilen >> >> Am 26.10.2021 um 11:49 schrieb Florian Schaal: >>> Du kannst auch das abgelaufene Root-Zertifkat auf dem Server >>> löschen. Das sollte reichen. >> Auf meinem neuen Server dürfte es kein abgelaufenes Root-Zertifikat >> geben, da die neuen Zertifikate ja erst letzten Samstag erstellt >> wurden? Da gab es vorher noch keine Zertifikate. > > Das ist Deinem Server ja mal herzlich egal. Ich meinte sowas wie > > sed -i > "s/^mozilla\/DST_Root_CA_X3\.crt/\!mozilla\/DST_Root_CA_X3\.crt/g" > /etc/ca-certificates.conf > update-ca-certificates ...das könnt ich mal probieren. vg, Andi From ml at irmawi.de Tue Oct 26 19:49:35 2021 From: ml at irmawi.de (Markus Winkler) Date: Tue, 26 Oct 2021 19:49:35 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> Message-ID: <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> Hallo noch mal Andi, On 26.10.21 16:25, Andreas Wass - Glas Gasperlmair wrote: >>>> Du kannst auch das abgelaufene Root-Zertifkat auf dem Server löschen. >>>> Das sollte reichen. >>> Auf meinem neuen Server dürfte es kein abgelaufenes Root-Zertifikat >>> geben, da die neuen Zertifikate ja erst letzten Samstag erstellt wurden? >>> Da gab es vorher noch keine Zertifikate. >> >> Das ist Deinem Server ja mal herzlich egal. Ich meinte sowas wie >> >> sed -i "s/^mozilla\/DST_Root_CA_X3\.crt/\!mozilla\/DST_Root_CA_X3\.crt/g" >> /etc/ca-certificates.conf >> update-ca-certificates > ...das könnt ich mal probieren. das "schadet" zwar nicht, dürfte bei deinem Thema allerdings keinerlei Effekt haben. ;-) Was zeigt denn ein: postconf -n | egrep 'smtpd_tls.*file' bei Dir? Ich vermute, dass da u. a. etwas in der Art auftaucht: smtpd_tls_cert_file = /etc/letsencrypt/live/mail1.glasgasperlmair.at/fullchain.pem (smtpd_tls_chain_files ... könnte zusätzlich oder alternativ erscheinen, da bei neueren Postfix-Versionen das der bevorzugte Parameter ist) Stimmt das? Wenn ja: In dem/den dort referenzierten File(s) findest Du die drei Certs, die Dein Postfix einem Client beim Verbindungsaufbau übergibt. Und eines von denen ist (ich wiederhole mich ;-)) das Root-Cert 'CN = ISRG Root X1', das vom nun nicht mehr gültigen 'DST Root CA X3' signiert wurde. Das nur noch mal zum Hintergrund. Du kannst zwar dieses Root-Cert aus dem File '.../fullchain.pem' (oder wo auch immer es bei Dir unterhalb von /etc/letsencrypt gespeichert ist) löschen. Aber auch das wird Dir bei irgendwelchen Uraltclients aus den schon in den früheren Mails genannten Gründen nichts bringen. Viele Grüße Markus From a.wass at glas-gasperlmair.at Wed Oct 27 07:39:14 2021 From: a.wass at glas-gasperlmair.at (Andreas Wass - Glas Gasperlmair) Date: Wed, 27 Oct 2021 07:39:14 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> Message-ID: <65f9bf23-2da4-e35b-c86e-ff5e3c55b008@glas-gasperlmair.at> Hallo Markus, postconf -n | egrep 'smtpd_tls.*file' smtp_tls_cert_file = $smtpd_tls_cert_file smtp_tls_key_file = $smtpd_tls_key_file smtpd_tls_cert_file = /etc/letsencrypt/live/mail1.glasgasperlmair.at/fullchain.pem smtpd_tls_dh1024_param_file = /etc/postfix/dh_2048.pem smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem smtpd_tls_key_file = /etc/letsencrypt/live/mail1.glasgasperlmair.at/privkey.pem Vielen Dank für deine sehr aufschlussreichen Informationen. :-) By the way: Sollte ich auch noch ein dh_1024.pem und ein dh_4096.pm für PFS erstellen? Vg, Andi Am 26.10.2021 um 19:49 schrieb Markus Winkler: > Hallo noch mal Andi, > > On 26.10.21 16:25, Andreas Wass - Glas Gasperlmair wrote: >>>>> Du kannst auch das abgelaufene Root-Zertifkat auf dem Server >>>>> löschen. Das sollte reichen. >>>> Auf meinem neuen Server dürfte es kein abgelaufenes Root-Zertifikat >>>> geben, da die neuen Zertifikate ja erst letzten Samstag erstellt >>>> wurden? Da gab es vorher noch keine Zertifikate. >>> >>> Das ist Deinem Server ja mal herzlich egal. Ich meinte sowas wie >>> >>> sed -i >>> "s/^mozilla\/DST_Root_CA_X3\.crt/\!mozilla\/DST_Root_CA_X3\.crt/g" >>> /etc/ca-certificates.conf >>> update-ca-certificates >> ...das könnt ich mal probieren. > > das "schadet" zwar nicht, dürfte bei deinem Thema allerdings keinerlei > Effekt haben. ;-) > > Was zeigt denn ein: > > postconf -n | egrep 'smtpd_tls.*file' > > bei Dir? > > Ich vermute, dass da u. a. etwas in der Art auftaucht: > > smtpd_tls_cert_file = > /etc/letsencrypt/live/mail1.glasgasperlmair.at/fullchain.pem > > (smtpd_tls_chain_files ... könnte zusätzlich oder alternativ > erscheinen, da bei neueren Postfix-Versionen das der bevorzugte > Parameter ist) > > Stimmt das? Wenn ja: In dem/den dort referenzierten File(s) findest Du > die drei Certs, die Dein Postfix einem Client beim Verbindungsaufbau > übergibt. Und eines von denen ist (ich wiederhole mich ;-)) das > Root-Cert 'CN = ISRG Root X1', das vom nun nicht mehr gültigen 'DST > Root CA X3' signiert wurde. > > Das nur noch mal zum Hintergrund. > > Du kannst zwar dieses Root-Cert aus dem File '.../fullchain.pem' (oder > wo auch immer es bei Dir unterhalb von /etc/letsencrypt gespeichert > ist) löschen. Aber auch das wird Dir bei irgendwelchen Uraltclients > aus den schon in den früheren Mails genannten Gründen nichts bringen. > > Viele Grüße > Markus From ml at irmawi.de Wed Oct 27 10:03:19 2021 From: ml at irmawi.de (Markus Winkler) Date: Wed, 27 Oct 2021 10:03:19 +0200 Subject: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag In-Reply-To: <65f9bf23-2da4-e35b-c86e-ff5e3c55b008@glas-gasperlmair.at> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> <65f9bf23-2da4-e35b-c86e-ff5e3c55b008@glas-gasperlmair.at> Message-ID: <606bc862-70da-34dc-5bde-944afceff30e@irmawi.de> Hallo Andi, On 27.10.21 07:39, Andreas Wass - Glas Gasperlmair wrote: > smtpd_tls_cert_file = > /etc/letsencrypt/live/mail1.glasgasperlmair.at/fullchain.pem > smtpd_tls_dh1024_param_file = /etc/postfix/dh_2048.pem > smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem > smtpd_tls_key_file = > /etc/letsencrypt/live/mail1.glasgasperlmair.at/privkey.pem alles klar, vielen Dank. > By the way: Sollte ich auch noch ein dh_1024.pem und ein dh_4096.pm für PFS > erstellen? Zunächst: Die Zeile oben mit: smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem kannst Du normalerweise aus Deiner main.cf entfernen - Export Grade Ciphers werden nicht mehr verwendet, es sei denn, Du hast das irgendwo explizit definiert. Diese Option: smtpd_tls_dh1024_param_file = /etc/postfix/dh_2048.pem kannst Du so belassen, gilt nach wie vor als best-practice. Ich selber habe zwar an dieser Stelle ein dh_4096.pem in Verwendung, aber das kann die Performance und auch das Zusammenspiel mit anderen Clients beeinflussen. Bislang jedoch konnte ich dahingehend bei mir keine Probleme beobachten. Von daher: einfach mal statt dem dh_2048.pem ein dh_4096.pem testen. ;-) Wenn Dich die Qualität Seiner TLS-Settings interessiert, kannst Du übrigens mal das hier anschauen: https://tls.imirhil.fr/smtp/mail1.glasgasperlmair.at BTW: Zumindest TLSv1 würde ich heutzutage abschalten. ;-) Viele Grüße Markus From postfix-users-de at list-post.mks-mail.de Wed Oct 27 11:14:26 2021 From: postfix-users-de at list-post.mks-mail.de (=?UTF-8?Q?Markus_Sch=c3=b6nhaber?=) Date: Wed, 27 Oct 2021 11:14:26 +0200 Subject: TLSv1 abschalten (was: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag) In-Reply-To: <606bc862-70da-34dc-5bde-944afceff30e@irmawi.de> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> <65f9bf23-2da4-e35b-c86e-ff5e3c55b008@glas-gasperlmair.at> <606bc862-70da-34dc-5bde-944afceff30e@irmawi.de> Message-ID: <6aaf1d86-db8c-4146-9170-589e485810f4@list-post.mks-mail.de> Am 27.10.21 um 10:03 schrieb Markus Winkler: > BTW: Zumindest TLSv1 würde ich heutzutage abschalten. ;-) Warum? Auf Submission, wo Du Deinen Kunden gewisse Vorgaben machen kannst, mag das sinnvoll sein. Aber auf dem MX zwingt das ältere Clients, die maximal TLSv1 beherrschen, dazu, ganz unverschlüsselt zu senden. Ich sehe da keinen Sicherheitsgewinn. -- Gruß mks From Walter.H at mathemainzel.info Wed Oct 27 13:18:18 2021 From: Walter.H at mathemainzel.info (Walter H.) Date: Wed, 27 Oct 2021 13:18:18 +0200 Subject: TLSv1 abschalten In-Reply-To: <6aaf1d86-db8c-4146-9170-589e485810f4@list-post.mks-mail.de> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> <65f9bf23-2da4-e35b-c86e-ff5e3c55b008@glas-gasperlmair.at> <606bc862-70da-34dc-5bde-944afceff30e@irmawi.de> <6aaf1d86-db8c-4146-9170-589e485810f4@list-post.mks-mail.de> Message-ID: On 27.10.2021 11:14, Markus Schönhaber wrote: > Am 27.10.21 um 10:03 schrieb Markus Winkler: > >> BTW: Zumindest TLSv1 würde ich heutzutage abschalten. ;-) > > Warum? > Auf Submission, wo Du Deinen Kunden gewisse Vorgaben machen kannst, > mag das sinnvoll sein. Aber auf dem MX zwingt das ältere Clients, die > maximal TLSv1 beherrschen, dazu, ganz unverschlüsselt zu senden. Ich > sehe da keinen Sicherheitsgewinn. > ist hier auch die Frage: braucht man die Mails die da evtl. unverschlüsselt ankommen würden, und blockiert man unverschlüsselten Empfang von Mails nicht gleich komplett ... (auch eine Art Vorauswahl und Reduktion unerwünschter Mails) jedes nicht empfangene Mail mit Schadsoftware ist ein Sicherheitsgewinn ;-) -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 3550 bytes Beschreibung: S/MIME Cryptographic Signature URL : From ml at irmawi.de Wed Oct 27 22:59:16 2021 From: ml at irmawi.de (Markus Winkler) Date: Wed, 27 Oct 2021 22:59:16 +0200 Subject: TLSv1 abschalten (was: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag) In-Reply-To: <6aaf1d86-db8c-4146-9170-589e485810f4@list-post.mks-mail.de> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> <65f9bf23-2da4-e35b-c86e-ff5e3c55b008@glas-gasperlmair.at> <606bc862-70da-34dc-5bde-944afceff30e@irmawi.de> <6aaf1d86-db8c-4146-9170-589e485810f4@list-post.mks-mail.de> Message-ID: On 27.10.21 11:14, Markus Schönhaber wrote: > Am 27.10.21 um 10:03 schrieb Markus Winkler: > >> BTW: Zumindest TLSv1 würde ich heutzutage abschalten. ;-) > > Warum? Ein Grund: https://tools.ietf.org/html/rfc8996 TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. > Aber auf dem MX zwingt das ältere Clients, die maximal TLSv1 > beherrschen, dazu, ganz unverschlüsselt zu senden. Ich sehe da keinen > Sicherheitsgewinn. Es geht mir ein Stück weit ums Prinzip. Ein Client, der am Ende des Jahres 2021 Software einsetzt, die gerade mal TLSv1 beherrscht, hat m. E. keine angeblich auf dem Transportweg "verschlüsselten" Mails mehr zu versenden. Dort ist der Betreiber des Systems in der Pflicht. Und ich behaupte mal, dass TLSv1 nur eines von vielen Problemen auf Systemen dieser Art sein dürfte ... Wenn dort nicht Druck aufgebaut wird, ändert sich da nie was. ;-) Außerdem sind in Bereichen, wo z. B. DSGVO-relevante Daten übertragen werden ist, diese alten Protokollversionen ohnehin nicht mehr einsetzbar. Obendrein sollte man wirklich, wie Walter schon schrieb, langsam darüber nachdenken, unverschlüsselte Mails zu blocken. Zumindest in Umgebungen, wo man sich das leisten kann. In 99,9 % der Fälle wären die nicht mehr ankommenden Mails solche, die man eh nicht will ... Außerdem würde ein regulärer Absender aus den 0,1 % ja darüber informiert und könnte seinem Provider mal auf die Füße treten. ;-) Aber um nicht falsch verstanden zu werden: Ich bin mir der generellen Problematik, was man noch toleriert und was nicht, durchaus bewusst und finde Postels "Be liberal in what you accept and conservative in what you send" immer noch gut. Trotzdem bleibt die Welt nicht stehen, und irgendwann muss man alte Zöpfe auch einfach mal abschneiden - _IMHO_. Und deswegen schrieb ich ja oben auch, dass _ich_ das heutzutage abschalten würde (und das auch mache). ;-) Viele Grüße Markus From tobster at brain-force.ch Fri Oct 29 14:35:17 2021 From: tobster at brain-force.ch (tobster at brain-force.ch) Date: Fri, 29 Oct 2021 14:35:17 +0200 Subject: TLSv1 abschalten (was: SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag) In-Reply-To: References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> <65f9bf23-2da4-e35b-c86e-ff5e3c55b008@glas-gasperlmair.at> <606bc862-70da-34dc-5bde-944afceff30e@irmawi.de> <6aaf1d86-db8c-4146-9170-589e485810f4@list-post.mks-mail.de> Message-ID: On Wed, 2021-10-27 at 22:59 +0200, Markus Winkler wrote: > Obendrein sollte man wirklich, wie Walter schon schrieb, langsam > darüber > nachdenken, unverschlüsselte Mails zu blocken. Zumindest in > Umgebungen, wo > man sich das leisten kann. eigentlich full-ack on that, wenn da nicht die RFC wären ;-) Strenggenommen darf ein MX kein STARTTLS erzwingen oder er verletzt die RFC A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. sind zwar Steinzeit-RFC, aber trotzdem gültige RFC ;-)  Cheers tobi -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From ml at irmawi.de Sat Oct 30 10:35:30 2021 From: ml at irmawi.de (Markus Winkler) Date: Sat, 30 Oct 2021 10:35:30 +0200 Subject: TLSv1 abschalten In-Reply-To: References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> <65f9bf23-2da4-e35b-c86e-ff5e3c55b008@glas-gasperlmair.at> <606bc862-70da-34dc-5bde-944afceff30e@irmawi.de> <6aaf1d86-db8c-4146-9170-589e485810f4@list-post.mks-mail.de> Message-ID: Hi Tobi, On 29.10.21 14:35, tobster at brain-force.ch wrote: > sind zwar Steinzeit-RFC, aber trotzdem gültige RFC ;-) ja, Du hast natürlich recht. :-) Der 3207 ist eindeutig und lässt da keinen Spielraum. Aber wie Du schon sagst: Seither sind fast 20 Jahre vergangen, und vielleicht sollte man bei solchen Punkten tatsächlich überlegen, ob man das heutzutage noch so definieren kann/muss. Ich persönlich tendiere jedenfalls schon dazu, dass man den Betreibern der Empfängerserver mittlerweile die Freiheit geben sollte, eben auch nur verschlüsselte Übertragungswege akzeptieren zu wollen. Schaun mer mal, was die Zeit bringt. Aber wenn ich mir Statistiken wie diese anschaue: https://transparencyreport.google.com/safer-email/overview dann bleiben irgendwann keine relevanten Systeme mehr übrig, die nicht auf der Höhe der Zeit sind - hoffentlich. ;-) Viele Grüße Markus From postfix-users-de at list-post.mks-mail.de Sat Oct 30 14:42:14 2021 From: postfix-users-de at list-post.mks-mail.de (=?UTF-8?Q?Markus_Sch=c3=b6nhaber?=) Date: Sat, 30 Oct 2021 14:42:14 +0200 Subject: TLSv1 abschalten In-Reply-To: References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> <65f9bf23-2da4-e35b-c86e-ff5e3c55b008@glas-gasperlmair.at> <606bc862-70da-34dc-5bde-944afceff30e@irmawi.de> <6aaf1d86-db8c-4146-9170-589e485810f4@list-post.mks-mail.de> Message-ID: <039af15f-1c7f-e79d-0108-642f9484c1f2@list-post.mks-mail.de> 30.10.21, 10:35 +0200, Markus Winkler: > Ich persönlich tendiere jedenfalls schon dazu, dass man den Betreibern der > Empfängerserver mittlerweile die Freiheit geben sollte, eben auch nur > verschlüsselte Übertragungswege akzeptieren zu wollen. Jeder kann natürlich (schon immer) seinen Server so konfigurieren, wie sie es für richtig hält. Wer keine unverschlüsselt eingelieferte Mail mehr annehmen will, soll das eben lassen. Ich bleibe allerdings dabei: Ich sehe keinen Sicherheitsgewinn darin, TLSv1 abzuschalten. BTW: Lustigerweise gibt es gerade heute auf der englischen Postfix-Liste eine ähnliche Diskussion. Ich zitiere mal[1]: 30.10.21, 07:57 +0200, Viktor Dukhovni: > On Fri, Oct 29, 2021 at 10:39:50PM -0700, Dan Mahoney wrote: >> I'm just going by the way ssllabs seems to score things for HTTPS, >> which seems to be where a lot of these cipher recommendations are >> based. You're still supporting TLS1.1? NOT WORTHY. > > The crypto maximalists are misguided. We need *widely-used* crypto > more than we need ludicrously storng crypto, especially if it is > ludicrously strong or else NOTHING. See RFC7435. [1]: https://marc.info/?l=postfix-users&m=163557349520026&w=2 Natürlich ändert das nichts an "Dein Server - Deine Regeln". Aber jemand, der sich fragt, ob er gewisse Postfix-Defaults ändern oder Verschlüsselungsprotokolle abschalten soll, ist m. E. verdammt gut beraten, Viktors Meinung nicht zu ignorieren, sondern zumindest in Betracht zu ziehen. -- Gruß mks From ml at irmawi.de Sat Oct 30 20:30:45 2021 From: ml at irmawi.de (Markus Winkler) Date: Sat, 30 Oct 2021 20:30:45 +0200 Subject: TLSv1 abschalten In-Reply-To: <039af15f-1c7f-e79d-0108-642f9484c1f2@list-post.mks-mail.de> References: <500077bd-10e6-4b4e-88d9-95afacbee4b9@glas-gasperlmair.at> <328d934d-1c25-71d6-cc65-e0949ecb6e38@glas-gasperlmair.at> <017f33cf-399f-fe88-3541-ab1b3bca25d5@irmawi.de> <54aa8078-b50f-5f48-03b6-7c70c1f22280@glas-gasperlmair.at> <9c8ea8c2-f433-734e-c6d1-16743db3b16e@schaal-24.de> <407d969a-5921-2269-0bca-040e72595f7f@irmawi.de> <65f9bf23-2da4-e35b-c86e-ff5e3c55b008@glas-gasperlmair.at> <606bc862-70da-34dc-5bde-944afceff30e@irmawi.de> <6aaf1d86-db8c-4146-9170-589e485810f4@list-post.mks-mail.de> <039af15f-1c7f-e79d-0108-642f9484c1f2@list-post.mks-mail.de> Message-ID: On 30.10.21 14:42, Markus Schönhaber wrote: > 30.10.21, 10:35 +0200, Markus Winkler: > >> Ich persönlich tendiere jedenfalls schon dazu, dass man den Betreibern der >> Empfängerserver mittlerweile die Freiheit geben sollte, eben auch nur >> verschlüsselte Übertragungswege akzeptieren zu wollen. > > Jeder kann natürlich (schon immer) seinen Server so konfigurieren, wie sie > es für richtig hält. Wer keine unverschlüsselt eingelieferte Mail mehr > annehmen will, soll das eben lassen. Logisch - aber darum ging es in meinem Satz oben ja gar nicht, sondern lediglich darum, dass man mit der Ablehnung unverschlüsselter Mails den nach wie vor gültigen RFC verletzt. Und bzgl. dieses Punkts könnte man ja mal darüber nachdenken, den Betreibern von Mailservern zukünftig evtl. diese Entscheidungsfreiheit rein formal einzuräumen, ohne dass diese dann gleich als RFC-ignorant dastehen. > Ich bleibe allerdings dabei: Ich sehe keinen Sicherheitsgewinn darin, TLSv1 > abzuschalten. [...] > [1]: https://marc.info/?l=postfix-users&m=163557349520026&w=2 > > Natürlich ändert das nichts an "Dein Server - Deine Regeln". Aber jemand, > der sich fragt, ob er gewisse Postfix-Defaults ändern oder > Verschlüsselungsprotokolle abschalten soll, ist m. E. verdammt gut beraten, > Viktors Meinung nicht zu ignorieren, sondern zumindest in Betracht zu ziehen. Vielen Dank für den Link zur englischen Liste. Es ist immer gut, sich mit anderen Meinungen auseinanderzusetzen. ;-) Meine eigene habe ich ja schon dargelegt, u. a. zum aus dem RFC 8996 abgeleiteten Gewinn an Sicherheit, wenn solche überholten Protokolle nicht mehr eingesetzt und damit auch nicht mehr als Angriffsvektor genutzt werden können. Hier haben wir beide eben eine andere Sicht auf das Thema. Viktors Meinung nehme ich ebenso zur Kenntnis, teile sie in der Form jedoch nicht und finde auch seine Wortwahl etwas, naja, eigenartig. Und im Unterschied zur englischen Postfix-Liste ging es ja in diesem Thread hier ursprünglich gerade _nicht_ um irgendwelche Maximalforderungen à la "ab sofort soll nur noch TLSv1.3 verwendet werden". Der Ausgangspunkt der Diskussion war, das Andis Server noch TLSv1 unterstützt und ich aus meiner Sicht eben dessen Deaktivieren vorgeschlagen hatte (noch nicht mal von TLSv1.1 ;-)). Dass man nicht mal eben einen der ältesten Dienste des Internets technisch umkrempeln kann, liegt selbstverständlich auf der Hand. Aber selbst solche hornalten Systeme wie beispielsweise Exchange 2010 / W2K8R2 lassen sich problemlos TLSv1.2 beibringen. Vor diesem Hintergrund kann ich daher, ehrlich gesagt, nicht ganz nachvollziehen, wieso 2021 noch darüber diskutiert wird, ob TLSv1 weiterhin akzeptabel ist, oder nicht. Warum nicht einfach endlich die Sicherheit nutzen, die schon _seit Jahren_ verfügbar ist? Es gibt nun mal Anwender, die aus eigenem Sicherheitsinteresse oder weil sie von irgendwelchen Vorgaben her (z. B. sich an BSI-Richtlinien wie die TR-02102-2 halten müssen) gezwungen sind, nach heutigem Stand sichere und noch dazu technisch einfach anzuwendende Technologien einsetzen wollen und/oder müssen. Aber klar: Das kann, soll und wird natürlich jeder sehen, wie er mag und ggf. auch muss. ;-) Viele Grüße Markus