SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1
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
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
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:
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@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.@...[...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:
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@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.@...[...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:
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
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:
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
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
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:
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
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?
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
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
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:
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
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
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:
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
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
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:
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
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
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
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
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
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
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.
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 ;-)
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
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
Hi Tobi,
On 29.10.21 14:35, tobster@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
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.
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.
[...]
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
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
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
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
participants (7)
-
Andreas Wass - Glas Gasperlmair -
Florian Schaal -
Markus Schönhaber -
Markus Winkler -
Tobi -
tobster＠brain-force.ch
-
Walter H.