Re: [mailop] Increase of SSL/TLS errors

[Camille - Clean Mailbox via mailop]

I confirm it was a SNI issue. Some people were using custom MX names 
pointing to our IPs, and some senders didn't like the default certificate.


Thank you all!

Camille

Le 12/09/2023 à 15:04, Taavi Eomäe via mailop a écrit :

On 12/09/2023 15:33, Bill Cole via mailop wrote:
Your CA (LetsEncrypt) says that is breakage and they offer a fix. 
Take it or leave it, but saying that it isn't broken is wrong. 


It is not wrong.

There's a valid and trusted path, that is sufficient. If your TLS 
client does not build certification paths properly then that's a flaw 
in the software. There is a lot of discussion on this subject so 
there's no point in continuing that here.



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

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

Re: [mailop] Increase of SSL/TLS errors

[Romain via mailop]

I confirm it was a SNI issue. Some people were using custom MX names 
pointing to our IPs, and some senders didn't like the default certificate.


Thank you all!

Camille

Le 12/09/2023 à 15:04, Taavi Eomäe via mailop a écrit :

On 12/09/2023 15:33, Bill Cole via mailop wrote:
Your CA (LetsEncrypt) says that is breakage and they offer a fix. 
Take it or leave it, but saying that it isn't broken is wrong. 


It is not wrong.

There's a valid and trusted path, that is sufficient. If your TLS 
client does not build certification paths properly then that's a flaw 
in the software. There is a lot of discussion on this subject so 
there's no point in continuing that here.



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

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

Re: [mailop] Increase of SSL/TLS errors

[Taavi Eomäe via mailop]

On 12/09/2023 15:33, Bill Cole via mailop wrote:
Your CA (LetsEncrypt) says that is breakage and they offer a fix. Take 
it or leave it, but saying that it isn't broken is wrong. 


It is not wrong.

There's a valid and trusted path, that is sufficient. If your TLS client 
does not build certification paths properly then that's a flaw in the 
software. There is a lot of discussion on this subject so there's no 
point in continuing that here.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[Bill Cole via mailop]

On 2023-09-12 at 02:18:56 UTC-0400 (Tue, 12 Sep 2023 08:18:56 +0200)
Camille - Clean Mailbox via mailop 
is rumored to have said:


Hi Bill,

└─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls 
smtp

[...]
---
Certificate chain
 0 s:CN = clean-mailbox.com
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 30 21:56:24 2023 GMT; NotAfter: Nov 28 21:56:23 
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

 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3



   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 
2024 GMT

---
[...]

I think my certificate chain is fine, no trace of DST.


See '^^^' above.
The DST X3 root cert expired. Your chain as deployed depends on it.

Your CA (LetsEncrypt) says that is breakage and they offer a fix. Take 
it or leave it, but saying that it isn't broken is wrong.





My configuration around certificates:
smtpd_tls_cert_file=/etc/letsencrypt/live/clean-mailbox.com/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/clean-mailbox.com/privkey.pem

Also I think it's normal that the client doesn't like the answer of my 
servers if the client tries to initiate a SSLv3 connection, as I've 
disabled it in Postfix.


In this case, the client alert was very specific about your problem 
being a bad certificate. Read the error message.




Best regards,
Camille

Le 12/09/2023 à 00:26, Bill Cole via mailop a écrit :

On 2023-09-11 at 17:05:00 UTC-0400 (Mon, 11 Sep 2023 23:05:00 +0200)
Camille - Clean Mailbox via mailop 
is rumored to have said:


Dear co-listers,

I'm seeing an increase of SSL/TLS errors for incoming emails to our 
service over the last few weeks.


Example from Mailjet, which is (I suppose) able to send email in TLS 
1.2 or 1.3 instead of SSLv3:
2023-09-11T21:19:31.079142+02:00 mx4 postfix/smtpd[633448]: 
SSL_accept error from o176.p8.mailjet.com[87.253.233.176]: -1
2023-09-11T21:19:31.079696+02:00 mx4 postfix/smtpd[633448]: warning: 
TLS library problem: error:0A000412:SSL routines::sslv3 alert bad 
certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:


That's an indication that the client does not like your certificate.

As for why, see 
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/


TL;DR: you need to fix the chain of trust for your certificate. You 
should remove any reference to the 'DST Root CA X3' certificate. You 
may also need to change how you maintain your certificate.





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



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[Camille - Clean Mailbox via mailop]

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


Hi,

└─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls smtp
CONNECTED(0003)
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:
     - 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   
.qxBk6..
    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 

Re: [mailop] Increase of SSL/TLS errors

[Johann Klasek via mailop]

On Tue, Sep 12, 2023 at 09:25:54AM +0200, Camille - Clean Mailbox via mailop 
wrote:
> Hi,
> 
> I didn't changed anything in Postfix configuration. But yes, over the last
> months, we upgraded from Debian 11 (OpenSSL 1.1.1n) to Debian 12 (OpenSSL
> 3.0.9).
> I don't see anything in openssl.cnf that could restrict something, if you
> have any idea.

I had a maybe similar issue after upgrading to Ubuntu 22.04.
It could be resolved with
https://discourse.ubuntu.com/t/default-to-tls-v1-2-in-all-tls-libraries-in-20-04-lts/12464/8

We have internal servers with TLS1.0 only which aren't reachable. :(

You can restrict the "security level" downgrade to a specific service if
the OpenSSL configuration is set via a environment variable, pointing to
a specific OpenSSL configuration file.


Johann

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

Re: [mailop] Increase of SSL/TLS errors

[Ken O'Driscoll via mailop]

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 
>  wrote:
> 
> Hi,
> 
> └─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls smtp
> CONNECTED(0003)
> 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:
>  - 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   .qxBk6..
> 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.Qs0LP.%.
> 00b0 - a0 0b 

Re: [mailop] Increase of SSL/TLS errors

[Slavko via mailop]

Ahoj,

Dňa Tue, 12 Sep 2023 12:28:13 +0200 Camille - Clean Mailbox via mailop
 napísal:

> └─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls smtp

I can do TLS1.0, TLS1.2 & TLS1.3 handshake with your server and GnuTLS
reports certificate as valid, thus the certificate itself seems to not
be the root of problem.

Perhaps some administrative restrictions on sender side...

regards

-- 
Slavko
https://www.slavino.sk


pgpazp7ylUKeZ.pgp
Description: Digitálny podpis OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[Camille - Clean Mailbox via mailop]

Hi,

└─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls smtp
CONNECTED(0003)
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:
     - 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 .qxBk6..
    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.Qs0LP.%.
    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=..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..i2.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 

Re: [mailop] Increase of SSL/TLS errors

[Ken O'Driscoll via mailop]

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 
>  wrote:
> 
> Ok I'm now running RSA without DST cert:
> # openssl crl2pkcs7 -nocrl -certfile 
> /etc/letsencrypt/live/clean-mailbox.com/fullchain.pem 
>  | openssl pkcs7 -print_certs -noout
> subject=CN = 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 
> from 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
>>  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

Re: [mailop] Increase of SSL/TLS errors

[Camille - Clean Mailbox via mailop]

Ok I'm now running RSA without DST cert:
# openssl crl2pkcs7 -nocrl -certfile 
/etc/letsencrypt/live/clean-mailbox.com/fullchain.pem | openssl pkcs7 
-print_certs -noout

subject=CN = 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 from 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
 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

Re: [mailop] Increase of SSL/TLS errors

[Slavko via mailop]

Ahoj,

Dňa Tue, 12 Sep 2023 09:25:59 +0200 Geert Hendrickx via mailop
 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

-- 
Slavko
https://www.slavino.sk


pgpV03nFlqpEL.pgp
Description: Digitálny podpis OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[Camille - Clean Mailbox via mailop]

Hi,

Just changed it to RSA, still have the same kind of errors:

2023-09-12T09:32:42.528685+02:00 mx1 postfix/smtpd[903460]: SSL_accept 
error from o167.p8.mailjet.com[87.253.233.167]: -1
2023-09-12T09:32:42.528920+02:00 mx1 postfix/smtpd[903460]: warning: TLS 
library problem: error:0A000412:SSL routines::sslv3 alert bad 
certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:


Best regards,
Camille

Le 12/09/2023 à 09:06, Geert Hendrickx a écrit :

On Mon, Sep 11, 2023 at 18:26:18 -0400, Bill Cole via mailop wrote:

That's an indication that the client does not like your certificate.

As for why, see
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

TL;DR: you need to fix the chain of trust for your certificate. You should
remove any reference to the 'DST Root CA X3' certificate. You may also need
to change how you maintain your certificate.



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.

Whether you care about those clients is another question.


Geert



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

Re: [mailop] Increase of SSL/TLS errors

[Camille - Clean Mailbox via mailop]

Hi James,

I'm using certbot 2.1.0 (provided with Debian 12). I don't have anything 
like this in my renewal configuration file:

[renewalparams]
account = [my ID]
authenticator = dns-cloudflare
dns_cloudflare_propagation_seconds = 30
dns_cloudflare_credentials = /etc/letsencrypt/cloudflare-clean-mailbox.ini
server = https://acme-v02.api.letsencrypt.org/directory
key_type = ecdsa

I'm not sure how I can get rid of this DST Root CA X3.

Best regards,
Camille

Le 12/09/2023 à 08:42, James Renken via mailop a écrit :

Hi, Camille,

On 2023-09-12 06:18, Camille - Clean Mailbox via mailop wrote:
I think my certificate chain is fine, no trace of DST.  It's hiding 
there in the last certificate in the chain you pasted, 
which I also see when I connect: > 2 s:C = US, O = Internet Security 
Research Group, CN = ISRG Root X1

>   i:O = Digital Signature Trust Co., CN = DST Root CA X3

You're serving Let's Encrypt's "long chain," which includes a copy of 
ISRG Root X1 that's cross-signed by the expired DST Root CA X3. Taavi 
Eomäe correctly pointed out that clients are supposed to accept this, 
so this may not really be the cause of the problem you're seeing - but 
we do live in a world with many imperfect clients.
I recommend you first check to make sure you're using an up-to-date 
version of Certbot. Then, check your renewal data file in 
`/etc/letsencrypt/renewal/clean-mailbox.com.conf`. If there's a line 
like `preferred_chain = "DST Root CA X3"`, remove it, then run 
`certbot renew --cert-name clean-mailbox.com --force-renewal` (just 
once, so that you don't hit Let's Encrypt's rate limits).

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

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

Re: [mailop] Increase of SSL/TLS errors

[Geert Hendrickx via mailop]

On Mon, Sep 11, 2023 at 18:26:18 -0400, Bill Cole via mailop wrote:
> That's an indication that the client does not like your certificate.
> 
> As for why, see
> https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
> 
> TL;DR: you need to fix the chain of trust for your certificate. You should
> remove any reference to the 'DST Root CA X3' certificate. You may also need
> to change how you maintain your certificate.
> 


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.

Whether you care about those clients is another question.


Geert


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

Re: [mailop] Increase of SSL/TLS errors

[Camille - Clean Mailbox via mailop]

Hi,

I didn't changed anything in Postfix configuration. But yes, over the 
last months, we upgraded from Debian 11 (OpenSSL 1.1.1n) to Debian 12 
(OpenSSL 3.0.9).
I don't see anything in openssl.cnf that could restrict something, if 
you have any idea.


Best regards,
Camille

Le 12/09/2023 à 07:54, ml+mailop--- via mailop a écrit :

On Mon, Sep 11, 2023, Camille - Clean Mailbox via mailop wrote:


2023-09-11T22:47:26.496119+02:00 mx1 postfix/smtpd[850937]: warning: TLS
library problem: error:0AC1:SSL routines::no shared
cipher:../ssl/statem/statem_srvr.c:2220:

Did you change the default TLS settings (of postfix), e.g.,
made any restrictions?
Or did you recently upgrade to OpenSSL 3 (which loads a default
openssl.cnf file which probably changes the defaults)?


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

Re: [mailop] Increase of SSL/TLS errors

[Slavko via mailop]

Dňa 12. septembra 2023 6:18:56 UTC používateľ Camille - Clean Mailbox via 
mailop  napísal:

>Also I think it's normal that the client doesn't like the answer of my servers 
>if the client tries to initiate a SSLv3 connection, as I've disabled it in 
>Postfix.

While i am not familiar with postfix (and its error reporting), the
openssl errors can be really confusing. If error message contains
sslv3, that can be not indication that SSLv3 was initiated, but only
(old) function name which process particular cipher(suite). Do
not forget, that TLS up to 1.2 shares some cipher(suite)s with
SSLv3.

IMO, one cannot be sure without some debug, eg. packet
capture, or so.

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[Slavko via mailop]

Dňa 12. septembra 2023 6:12:16 UTC používateľ "Taavi Eomäe via mailop" 
 napísal:

>No. The chain may contain an expired root certificate. A client must only 
>validate the chain until the first trusted root. LetsEncrypt's should be 
>trusted first, certificate chain must be validated until that and accepted.

AFAIK, modern openssl versions yes, but old (<1.0.1 or so) will fail...

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[James Renken via mailop]

Hi, Camille,

On 2023-09-12 06:18, Camille - Clean Mailbox via mailop wrote:
I think my certificate chain is fine, no trace of DST.  It's hiding there in the last certificate in the chain you pasted, 
which I also see when I connect: > 2 s:C = US, O = Internet Security 
Research Group, CN = ISRG Root X1

>   i:O = Digital Signature Trust Co., CN = DST Root CA X3

You're serving Let's Encrypt's "long chain," which includes a copy of 
ISRG Root X1 that's cross-signed by the expired DST Root CA X3. Taavi 
Eomäe correctly pointed out that clients are supposed to accept this, so 
this may not really be the cause of the problem you're seeing - but we 
do live in a world with many imperfect clients.
I recommend you first check to make sure you're using an up-to-date 
version of Certbot. Then, check your renewal data file in 
`/etc/letsencrypt/renewal/clean-mailbox.com.conf`. If there's a line 
like `preferred_chain = "DST Root CA X3"`, remove it, then run `certbot 
renew --cert-name clean-mailbox.com --force-renewal` (just once, so that 
you don't hit Let's Encrypt's rate limits).

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

Re: [mailop] Increase of SSL/TLS errors

[Taavi Eomäe via mailop]

> Can you check on your side that communication is OK with my servers? 
Do I understand correctly that the servers of senders are guilty, and 
it's not something on my side?


Looks correct to me and Hardenize. If anything, TLSv1.0 should probably 
be disabled at this point.


https://www.hardenize.com/report/clean-mailbox.com/1694499180#email_tls



OpenPGP_0x348B4BDC6047AF45.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[Camille - Clean Mailbox via mailop]

Hi Bill,

└─# openssl s_client -connect mx.clean-mailbox.com:25 -starttls smtp
[...]
---
Certificate chain
 0 s:CN = clean-mailbox.com
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 30 21:56:24 2023 GMT; NotAfter: Nov 28 21:56:23 
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

 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 
2024 GMT

---
[...]

I think my certificate chain is fine, no trace of DST.

My configuration around certificates:
smtpd_tls_cert_file=/etc/letsencrypt/live/clean-mailbox.com/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/clean-mailbox.com/privkey.pem

Also I think it's normal that the client doesn't like the answer of my 
servers if the client tries to initiate a SSLv3 connection, as I've 
disabled it in Postfix.


Best regards,
Camille

Le 12/09/2023 à 00:26, Bill Cole via mailop a écrit :

On 2023-09-11 at 17:05:00 UTC-0400 (Mon, 11 Sep 2023 23:05:00 +0200)
Camille - Clean Mailbox via mailop 
is rumored to have said:


Dear co-listers,

I'm seeing an increase of SSL/TLS errors for incoming emails to our 
service over the last few weeks.


Example from Mailjet, which is (I suppose) able to send email in TLS 
1.2 or 1.3 instead of SSLv3:
2023-09-11T21:19:31.079142+02:00 mx4 postfix/smtpd[633448]: 
SSL_accept error from o176.p8.mailjet.com[87.253.233.176]: -1
2023-09-11T21:19:31.079696+02:00 mx4 postfix/smtpd[633448]: warning: 
TLS library problem: error:0A000412:SSL routines::sslv3 alert bad 
certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:


That's an indication that the client does not like your certificate.

As for why, see 
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/


TL;DR: you need to fix the chain of trust for your certificate. You 
should remove any reference to the 'DST Root CA X3' certificate. You 
may also need to change how you maintain your certificate.





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

Re: [mailop] Increase of SSL/TLS errors

[Taavi Eomäe via mailop]

> TL;DR: you need to fix the chain of trust for your certificate. You 
should remove any reference to the 'DST Root CA X3' certificate. You may 
also need to change how you maintain your certificate.


No. The chain may contain an expired root certificate. A client must 
only validate the chain until the first trusted root. LetsEncrypt's 
should be trusted first, certificate chain must be validated until that 
and accepted.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[ml+mailop--- via mailop]

On Mon, Sep 11, 2023, Camille - Clean Mailbox via mailop wrote:

> 2023-09-11T22:47:26.496119+02:00 mx1 postfix/smtpd[850937]: warning: TLS
> library problem: error:0AC1:SSL routines::no shared
> cipher:../ssl/statem/statem_srvr.c:2220:

Did you change the default TLS settings (of postfix), e.g.,
made any restrictions?
Or did you recently upgrade to OpenSSL 3 (which loads a default
openssl.cnf file which probably changes the defaults)?

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase of SSL/TLS errors

[Bill Cole via mailop]

On 2023-09-11 at 17:05:00 UTC-0400 (Mon, 11 Sep 2023 23:05:00 +0200)
Camille - Clean Mailbox via mailop 
is rumored to have said:


Dear co-listers,

I'm seeing an increase of SSL/TLS errors for incoming emails to our 
service over the last few weeks.


Example from Mailjet, which is (I suppose) able to send email in TLS 
1.2 or 1.3 instead of SSLv3:
2023-09-11T21:19:31.079142+02:00 mx4 postfix/smtpd[633448]: SSL_accept 
error from o176.p8.mailjet.com[87.253.233.176]: -1
2023-09-11T21:19:31.079696+02:00 mx4 postfix/smtpd[633448]: warning: 
TLS library problem: error:0A000412:SSL routines::sslv3 alert bad 
certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:


That's an indication that the client does not like your certificate.

As for why, see 
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/


TL;DR: you need to fix the chain of trust for your certificate. You 
should remove any reference to the 'DST Root CA X3' certificate. You may 
also need to change how you maintain your certificate.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop