Re: [mailop] Authentication Bounces by Gmail

[Brandon Long via mailop]

Looking at the messages from that IP getting that rejection message, I'm
seeing a lot of DKIM body hash did not verify, I'd also verify that your
system isn't modifying the messages that it is forwarding.

Brandon

On Tue, Sep 12, 2023 at 8:20 PM Brandon Long  wrote:

> That message did not have a DKIM header ... or was so garbled that we
> didn't extract it.
>
> Due to DKIM replay, we may spam reject forwarded messages that DKIM verify
> but not SPF, but those would not have that rejection message.
>
> And yes, we are continuing to ramp no auth, no entry.
>
> I'm sure I've had a long explanation on here in the past year, but the
> short answer is if the message is not DKIM valid and you're forwarding, you
> should rewrite
> the MAIL FROM to a domain you own that will SPF authn the message... and
> try not to forward spam.
>
> Brandon
>
> On Tue, Sep 12, 2023 at 6:00 PM Jason R Cowart via mailop <
> mailop@mailop.org> wrote:
>
>> We are seeing an increasing number of bounces by Gmail related to failed
>> authentication checks.  The bounces include language like:
>>
>> <<< 550-5.7.26 This mail is unauthenticated, which poses a security risk
>> to
>> the
>> <<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender
>> must
>> <<< 550-5.7.26 authenticate with at least one of SPF or DKIM. For this
>> message,
>> <<< 550-5.7.26 DKIM checks did not pass and SPF check for [mcn.org] did
>> not
>> pass
>> <<< 550-5.7.26 with ip: [67.231.157.125]. The sender should visit
>> <<< 550-5.7.26
>> https://support.google.com/mail/answer/81126#authentication
>> for
>> <<< 550 5.7.26 instructions on setting up authentication.
>> z6-20020a05622a028600b00403a8e58423si1377805qtw.448 - gsmtp
>> 554 5.0.0 Service unavailable
>>
>>
>>
>> This is occurring in situations where our users forward their mail to a
>> personal Gmail account.  SPF checks will of course fail in the scenario,
>> but DKIM checks should pass.  In fact, they most often do pass—users
>> impacted by this are only seeing a small subset of their mail from a given
>> sender bounced (which often times will be a Gmail sender).  In cases where
>> the user retains a copy locally we’ve been able to verify that the DKIM
>> signature was present and was successfully validated by our system.
>>
>> Is anyone else experiencing this?
>>
>> Is anyone from Google could reach out to me off-list to discuss that
>> would be much appreciated.
>>
>>
>>
>> Best,
>>
>> Jason Cowart
>>
>> Stanford University IT
>> ___
>> 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] Authentication Bounces by Gmail

[Brandon Long via mailop]

That message did not have a DKIM header ... or was so garbled that we
didn't extract it.

Due to DKIM replay, we may spam reject forwarded messages that DKIM verify
but not SPF, but those would not have that rejection message.

And yes, we are continuing to ramp no auth, no entry.

I'm sure I've had a long explanation on here in the past year, but the
short answer is if the message is not DKIM valid and you're forwarding, you
should rewrite
the MAIL FROM to a domain you own that will SPF authn the message... and
try not to forward spam.

Brandon

On Tue, Sep 12, 2023 at 6:00 PM Jason R Cowart via mailop 
wrote:

> We are seeing an increasing number of bounces by Gmail related to failed
> authentication checks.  The bounces include language like:
>
> <<< 550-5.7.26 This mail is unauthenticated, which poses a security risk
> to
> the
> <<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender
> must
> <<< 550-5.7.26 authenticate with at least one of SPF or DKIM. For this
> message,
> <<< 550-5.7.26 DKIM checks did not pass and SPF check for [mcn.org] did
> not
> pass
> <<< 550-5.7.26 with ip: [67.231.157.125]. The sender should visit
> <<< 550-5.7.26 https://support.google.com/mail/answer/81126#authentication
>
> for
> <<< 550 5.7.26 instructions on setting up authentication.
> z6-20020a05622a028600b00403a8e58423si1377805qtw.448 - gsmtp
> 554 5.0.0 Service unavailable
>
>
>
> This is occurring in situations where our users forward their mail to a
> personal Gmail account.  SPF checks will of course fail in the scenario,
> but DKIM checks should pass.  In fact, they most often do pass—users
> impacted by this are only seeing a small subset of their mail from a given
> sender bounced (which often times will be a Gmail sender).  In cases where
> the user retains a copy locally we’ve been able to verify that the DKIM
> signature was present and was successfully validated by our system.
>
> Is anyone else experiencing this?
>
> Is anyone from Google could reach out to me off-list to discuss that would
> be much appreciated.
>
>
>
> Best,
>
> Jason Cowart
>
> Stanford University IT
> ___
> 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] Authentication Bounces by Gmail

[Jason R Cowart via mailop]

We are seeing an increasing number of bounces by Gmail related to failed 
authentication checks.  The bounces include language like:

<<< 550-5.7.26 This mail is unauthenticated, which poses a security risk to
the
<<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender must
<<< 550-5.7.26 authenticate with at least one of SPF or DKIM. For this
message,
<<< 550-5.7.26 DKIM checks did not pass and SPF check for [mcn.org] did not
pass
<<< 550-5.7.26 with ip: [67.231.157.125]. The sender should visit
<<< 550-5.7.26 https://support.google.com/mail/answer/81126#authentication
for
<<< 550 5.7.26 instructions on setting up authentication.
z6-20020a05622a028600b00403a8e58423si1377805qtw.448 - gsmtp
554 5.0.0 Service unavailable

This is occurring in situations where our users forward their mail to a 
personal Gmail account.  SPF checks will of course fail in the scenario, but 
DKIM checks should pass.  In fact, they most often do pass—users impacted by 
this are only seeing a small subset of their mail from a given sender bounced 
(which often times will be a Gmail sender).  In cases where the user retains a 
copy locally we’ve been able to verify that the DKIM signature was present and 
was successfully validated by our system.

Is anyone else experiencing this?

Is anyone from Google could reach out to me off-list to discuss that would be 
much appreciated.

Best,
Jason Cowart
Stanford University IT
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] The info on Validity's charging for FBL access (Was Re: New Validity policy for paid FBL (ARF))

[Mark Fletcher via mailop]

On Tue, Sep 12, 2023 at 3:09 PM Anne Mitchell via mailop 
wrote:

>
> From what I read into this, it likely means you are already on a paid
> package, and that package includes the individual reports, and also that
> now they are offering aggregated reports and you will be able to get
> thosealso  with your paid package (because hey, that's now the free tier
> anyways).
>
>
We have never paid Validity anything.

In reference to the other thread, I have very conflicted feelings about
FBLs in general (acknowledging that we are a mailing list host and not a
transactional or marketing email service). I believe that the vast majority
of the FBL reports that we get are mistakes, people hitting the spam button
without that intent and/or automatic spam filters causing mail to be routed
to spam folders and triggering FBL reports (it does happen). Also, I have
never seen any information saying whether acting on FBL reports positively
affects our overall deliverability or not.

With that lack of information, from the beginning we implemented a system
that unsubscribed people from their mailing lists upon an FBL report (we
also send them a one click resubscribe email). Our users _hate_ this. We
did this out of fear, mainly; fear that if we didn't, we would be blocked
from sending list messages to our users. Is that a valid fear? Like I said,
I have no idea.

So I guess what I'm saying is that if this causes FBLs to diminish, I will
not be shedding any tears. And also, I have no desire to pay Validity for
this.

Thanks,
Mark
-- 
Groups.io
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] The info on Validity's charging for FBL access (Was Re: New Validity policy for paid FBL (ARF))

[Anne Mitchell via mailop]

> On Sep 12, 2023, at 2:30 PM, Mark Fletcher  wrote:
> 
>> We just wrote up everything that we know about this, including  how much it 
>> will cost, what it actually means, what's still free, etc. It's too long to 
>> quote here (and it contains quotes from Validity) but here it is in case you 
>> want all of that info:
>> 
>> https://www.isipp.com/blog/validity-fbl-charging-how-much-cost/
>> 
> 
> Thank you for writing this up, it's been confusing. We only receive 
> individual reports and not the aggregated data (or if we do it's not sent to 
> us). We received a slightly different email from Validity. It includes the 
> 'login method update' but it makes no mention of upgrading our account; 
> instead this was included:
> 
> Product Enhancement: You will now have access to aggregated data insights 
> within the application, enabling you to gain a broader understanding of 
> overall trends, patterns, and customer sentiments.
> You will receive an additional reminder one week before the launch with 
> additional information to ensure that you are well-prepared for the 
> transition and have all the information you need to securely log in to your 
> account.
>  
> So maybe we won't be subject to the new fees? Like I said, it's been 
> confusing.

From what I read into this, it likely means you are already on a paid package, 
and that package includes the individual reports, and also that now they are 
offering aggregated reports and you will be able to get thosealso  with your 
paid package (because hey, that's now the free tier anyways).

BUT, I didn't hear that directly from anyone at Validity, it's just the most 
common sense reading of the email that you guys got, knowing what I know about 
the rest of it.

Anne

---
Our Good Senders List™ email certification is honored by inbox providers and 
spam filters around the world so that the email you send goes to the inbox, not 
the spam folder.  Always free to query.
Learn more at gettotheinbox.com

Anne P. Mitchell, Esq.
Email Law & Policy Attorney
CEO Get to the Inbox by SuretyMail
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing law)
Board of Directors, Denver Internet Exchange




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

Re: [mailop] Was Re: New Validity policy for paid FBL (ARF)

[Mark Fletcher via mailop]

On Tue, Sep 12, 2023 at 11:19 AM Anne Mitchell via mailop 
wrote:

>
> We just wrote up everything that we know about this, including  how much
> it will cost, what it actually means, what's still free, etc. It's too long
> to quote here (and it contains quotes from Validity) but here it is in case
> you want all of that info:
>
> https://www.isipp.com/blog/validity-fbl-charging-how-much-cost/
>
>
Thank you for writing this up, it's been confusing. We only receive
individual reports and not the aggregated data (or if we do it's not sent
to us). We received a slightly different email from Validity. It includes
the 'login method update' but it makes no mention of upgrading our account;
instead this was included:

Product Enhancement: You will now have access to aggregated data insights
> within the application, enabling you to gain a broader understanding of
> overall trends, patterns, and customer sentiments.
> You will receive an additional reminder one week before the launch with
> additional information to ensure that you are well-prepared for the
> transition and have all the information you need to securely log in to your
> account.


So maybe we won't be subject to the new fees? Like I said, it's been
confusing.

Mark
--
Groups.io
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Was Re: New Validity policy for paid FBL (ARF)

[Anne Mitchell via mailop]

We just wrote up everything that we know about this, including  how much it 
will cost, what it actually means, what's still free, etc. It's too long to 
quote here (and it contains quotes from Validity) but here it is in case you 
want all of that info:

https://www.isipp.com/blog/validity-fbl-charging-how-much-cost/

--- 
Anne P. Mitchell
Attorney at Law
Email Law & Policy Attorney
CEO Institute for Social Internet Public Policy (ISIPP)
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing law)
Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Counsel Emeritus, eMail Abuse Prevention System (MAPS)

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