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