SSL_accept error from 213-225-38-118.nat.highway.a1.net[213.225.38.118]: -1 - Nachtrag

[Florian Schaal]

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
> 
>