I think I figured out what's happening after increasing the TLS debug logs.

Some incoming connections are initiated using a FQDN for which I don't have a valid SSL certificate (another address than mx.clean-mailbox.com).

I'll investigate & keep you posted.

Best regards,
Camille

Le 12/09/2023 à 12:54, Ken O'Driscoll via mailop a écrit :
If it works without your MTA being involved then it may a configuration setting on your side or theirs.

Can you turn up the TLS debug log level on your MTA? That should point to where in the negotiation it’s failing for future connections.

Ken.




On 12 Sep 2023, at 12:28, Camille - Clean Mailbox via mailop <mailop@mailop.org> wrote:

Hi,

└─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls smtp
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 = clean-mailbox.com
verify return:1
---
Certificate chain
 0 s:CN = clean-mailbox.com
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep 12 07:45:16 2023 GMT; NotAfter: Dec 11 07:45:15 2023 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFBjCCA+6gAwIBAgISA6li7OMYlTzGpZPo8y7VjLXqMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzA5MTIwNzQ1MTZaFw0yMzEyMTEwNzQ1MTVaMBwxGjAYBgNVBAMT
EWNsZWFuLW1haWxib3guY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA7XXa5wPxfTa8yFoGx3MsIHX8cQs3na4nj79VOz48VNsm1H4+QmJBz1VMlsUj
gvK1+bSX/j5AP8G6vEyLy7dSUuax1bBWmkc7a0OrmhF4NpmrRqNMKc2kSmb9B1kU
ImBc0uiJ7UJY8fRac2/HaeTgok4hDX9CHgxx/fWhOD8Am0Y5Pd7IdamAzUMsTx0/
DTs8SbDReWclvR9c9E6IpCYsEsR8DPSBhf6pQfvqFcgVFtNp+RV+z7C5Vnlgf6qu
2zelm0WM5JuHGb2k7HaigEo0RKnYzJhrej6Ouo0yjd24aWggcfCFGB7hXpo87dHE
UKpOEKzEhCz2/MPYyzyNK76+9wIDAQABo4ICKjCCAiYwDgYDVR0PAQH/BAQDAgWg
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0G
A1UdDgQWBBR7iMNTN4gUm7dML6GWvwpOQZj29zAfBgNVHSMEGDAWgBQULrMXt1hW
y65QCUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6
Ly9yMy5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iu
b3JnLzAxBgNVHREEKjAoghMqLmNsZWFuLW1haWxib3guY29tghFjbGVhbi1tYWls
Ym94LmNvbTATBgNVHSAEDDAKMAgGBmeBDAECATCCAQYGCisGAQQB1nkCBAIEgfcE
gfQA8gB3AHoyjFTYty22IOo44FIe6YQWcDIThU070ivBOlejUutSAAABioiQ+MAA
AAQDAEgwRgIhAKZScx5nFG7300E2EHNXW2Wda9z1WDo4YQmd819QMvqNAiEA93tU
ekgzD7zm0hAxImMcPnCl8RtvFY1ZHjHZEzRJvRAAdwDoPtDaPvUGNTLnVyi8iWvJ
A9PL0RFr7Otp4Xd9bQa9bgAAAYqIkPiuAAAEAwBIMEYCIQDZgirehk02bRIA6rne
r8pbAnX5AxPGnz4QX2CWunwqRwIhAPsWGUgr6JAZXH1AN4FG9t4aKuSKeojGQsui
zCGsutOPMA0GCSqGSIb3DQEBCwUAA4IBAQCntzUqsb7emkAa3LqToXw8/vwQSkNE
7dabrgk8cru2kfU2R0k+vlk2S5JbOMoHMVaanlIOfbsW045kz4YFUjB9mC/d6CzF
mAegE7/sHXK7WRe/wLMnYZQSFvb3OcVb30gf/YNj40KvNu+jI+Cu3eZVIbe+P48t
CMPTG9reBHI0nsTw2/vmhjcGcM3dHmAfbIgs9+DfpLJeJLad/4rfUM7uq9p4Wtzd
OoJ2jGyuthP/N9y+meHi8MFY9HL7KS3Gmav1LYlIOlnXCWeHoVnaKYE4iscisSus
Kp8k9kmbGRxaBv6bSlsC3a7HIT/abOYd8zCLTDW2ihokdUym2s/N1ece
-----END CERTIFICATE-----
subject=CN = clean-mailbox.com
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3383 bytes and written 439 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 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: 00D6CAA4EE949C3557B08565B51D7C6306178845943C34DC22813BAD705EE3C4
    Session-ID-ctx:
    Resumption PSK: B6A07E5E0CDE73C09258D47D7BCE560F692F84D0FAECEA0C708BBD23AD8E0F32EAD86A72896612D2E9E1F5DA13E5225F
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 8f ba 03 a8 ee 0a 5b 26-95 94 a2 1b 97 cb 15 b9   ......[&........     0010 - 7e f4 94 66 cd df f1 3a-98 f7 12 45 fd d3 ef 09   ~..f...:...E....     0020 - 0b be ba bd 6f 67 ea 22-5e 3e 2d 27 09 45 ff ad   ....og."^>-'.E..     0030 - cf 5c 10 3f 28 c6 ad 89-4e df 6a 8e 43 1a 0d 1e   .\.?(...N.j.C...     0040 - 9d 88 58 e3 52 93 76 c2-98 41 06 b7 e8 7c 97 3a   ..X.R.v..A...|.:     0050 - 2b a5 08 aa d1 25 da 8e-0c 71 38 bc d4 5f 60 26   +....%...q8.._`&     0060 - be 09 9e af f5 71 78 42-92 e2 e4 e7 6b 36 b7 98   .....qxB....k6..     0070 - ea 09 38 be 96 44 60 ed-90 06 5b 28 ca 1f 8e 70   ..8..D`...[(...p     0080 - e5 fe 1e 8c 49 8a 0c 53-3b 8d 56 0b ed 15 d3 af   ....I..S;.V.....     0090 - 61 d6 fb 2d 72 1f 4c 74-c6 3e 1f 52 b7 90 11 45   a..-r.Lt.>.R...E     00a0 - 31 09 68 e5 51 73 30 05-e9 01 d8 4c 50 8d 25 e8   1.h.Qs0....LP.%.     00b0 - a0 0b f9 12 fe 4d bd 61-65 24 f3 8e b0 82 a1 f2   .....M.ae$......     00c0 - 69 26 69 a9 3d e9 c8 6f-ab 46 8b 20 fc 2e e8 f4   i&i.=..o.F. ....     00d0 - cf 54 b5 70 c5 24 70 0d-f7 29 82 b1 2e 42 c5 1b   .T.p.$p..)...B..     00e0 - b9 08 71 2a f8 4e bc b0-69 d7 b6 f6 cc 32 88 55   ..q*.N..i....2.U

    Start Time: 1694514461
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

Camille

Le 12/09/2023 à 12:21, Ken O'Driscoll via mailop a écrit :

What do you see when you run openssl s_client -connect… against the the MTAs that are associated with this specific error in your logs?

Ken.


On 12 Sep 2023, at 10:50, Camille - Clean Mailbox via mailop <mailop@mailop.org> wrote:

Ok I'm now running RSA without DST cert:
# openssl crl2pkcs7 -nocrl -certfile /etc/letsencrypt/live/clean-mailbox.com/fullchain.pem <http://clean-mailbox.com/fullchain.pem>| openssl pkcs7 -print_certs -noout
subject=CN =clean-mailbox.com <http://clean-mailbox.com/>
issuer=C = US, O = Let's Encrypt, CN = R3

subject=C = US, O = Let's Encrypt, CN = R3
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1

Still:

2023-09-12T10:48:56.708719+02:00 mx2 postfix/smtpd[406672]: SSL_accept error fromm240-158.my-hammer.de <http://m240-158.my-hammer.de/>[159.112.240.158]: -1 2023-09-12T10:48:56.710166+02:00 mx2 postfix/smtpd[406672]: warning: TLS library problem: error:0A000412:SSL routines::sslv3 alert bad certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:

Camille

Le 12/09/2023 à 10:15, Slavko via mailop a écrit :
Ahoj,

Dňa Tue, 12 Sep 2023 09:25:59 +0200 Geert Hendrickx via mailop
<mailop@mailop.org> napísal:

The reason is likely the certificate itself, not the chain; this
server offers (only) an ECC certificate, and while the vast majority
of clients are compatible with this today, some still only support
RSA.
Yes, i can confirm this. My MX's stats shows that one sender still
requires RSA. Unfortunately it is my bank, thus i use dual certs ;-)

In other words, the MX is only one my service with dual certs. When i
start to use EC, i had dual certs for MSA too, but after some time, i
abandon the RSA, as all clients was happy with EC...

regards


_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Reply via email to