On 10/26/2022 9:34 AM, Wietse Venema wrote:
Gerald Galster:
just wanted to let you know that Outlook users might run into problems
submitting mails after Microsoft's latest Windows update.
Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from
Oct 15 14:49:42 mx1 postfix/submission/
>>> just wanted to let you know that Outlook users might run into problems
>>> submitting mails after Microsoft's latest Windows update.
>>>
>>> Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from
>>> Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: SSL_accept error from
>>> :
On 10/26/2022 10:56 AM, Viktor Dukhovni wrote:
RAPTOR REMARK: Alert! Please be careful! This email is from an EXTERNAL sender.
Be aware of impersonation and credential theft.
On Wed, Oct 26, 2022 at 03:56:29PM +0200, Gerald Galster wrote:
This issue is resolved by update KB5018496 for Windows
On Wed, Oct 26, 2022 at 03:56:29PM +0200, Gerald Galster wrote:
> This issue is resolved by update KB5018496 for Windows 11 22H2 x64:
>
> https://support.microsoft.com/en-us/topic/october-25-2022-kb5018496-os-build-22621-755-preview-64040bea-1e02-4b6d-bad1-b036200c2cb3
>
> October 25, 2022—KB501
Gerald Galster:
> > just wanted to let you know that Outlook users might run into problems
> > submitting mails after Microsoft's latest Windows update.
> >
> > Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from
> > Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: SSL_accept er
> just wanted to let you know that Outlook users might run into problems
> submitting mails after Microsoft's latest Windows update.
>
> Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from
> Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: SSL_accept error from
> : lost connect
La da da da...
Original message From: Phil Stracchino
Date: 18/10/22 9:51 AM (GMT+12:00) To: postfix-users@postfix.org Subject: Re:
Outlook TLS errors after Microsoft Windows Update On 10/17/22 16:08, Jaroslaw
Rafa wrote:> Dnia 17.10.2022 o godz. 20:35:11 Gerald Gals
On 10/17/22 16:08, Jaroslaw Rafa wrote:
Dnia 17.10.2022 o godz. 20:35:11 Gerald Galster pisze:
Certificates starting with "04" occur since autumn 2019.
After that date it's sometimes "03" and sometimes "04".
This looks exceedingly unlikely to be relevant.
Very far-fetched, I thought somethin
Dnia 17.10.2022 o godz. 20:35:11 Gerald Galster pisze:
> >> Certificates starting with "04" occur since autumn 2019.
> >> After that date it's sometimes "03" and sometimes "04".
> >
> > This looks exceedingly unlikely to be relevant.
>
> Very far-fetched, I thought something might be cached or pi
>> Can you check the certificates' serial numbers?
>> The working one begins with 03 and the problematic one with 04.
>>
>> There are 37 archived certificates for this hostname, 29 begin
>> with "03" and only 8 with "04".
>>
>> Certificates starting with "04" occur since autumn 2019.
>> After tha
On Mon, Oct 17, 2022 at 05:37:47PM +0200, Gerald Galster wrote:
> >> This is very strange and I can confirm it.
> >
> > Can you test the other (working) certificate again? In Outlook set the
> > hostname as per certificate and in local hosts file in Windows force
> > IP of the destination server f
Viktor Dukhovni:
> On Mon, Oct 17, 2022 at 04:09:25PM +0200, GCore GmbH - Gerald Galster wrote:
>
> > > If possible, please ask the other user whether the alternative
> > > certificate again sports a mismatched hostname. It is somewhat
> > > plausible that the Microsoft bug doesn't fire when cert
>> This is very strange and I can confirm it.
>
> Can you test the other (working) certificate again? In Outlook set the
> hostname as per certificate and in local hosts file in Windows force
> IP of the destination server for this hostname. This way Outlook
> should not complain about mismatched
On Mon, Oct 17, 2022 at 04:09:25PM +0200, GCore GmbH - Gerald Galster wrote:
> > If possible, please ask the other user whether the alternative
> > certificate again sports a mismatched hostname. It is somewhat
> > plausible that the Microsoft bug doesn't fire when certificate
> > chain validatio
On Mon, 17 Oct 2022 at 15:48, Gerald Galster wrote:
> This is very strange and I can confirm it.
Can you test the other (working) certificate again? In Outlook set the
hostname as per certificate and in local hosts file in Windows force
IP of the destination server for this hostname. This way Ou
>> The two certificate chains are structurally identical, differing only in
>> minor details, such as: dates, keys, hostnames and signatures.
>
> There is another user (hopefully the URL below won't be blocked by the
> list) with the same observation - only 1 of his servers affected and
> switchin
On Mon, Oct 17, 2022 at 03:00:11PM +0200, Marek Podmaka wrote:
> On Mon, 17 Oct 2022 at 14:57, Wietse Venema wrote:
> >
> > For Postfix submission and smtps we prefer
> >
> > tls_ssl_options = NO_RENEGOTIATION, NO_TICKET
> >
> > Instead of forcing hostname/cert micmatches.
>
> Yes, I am alre
Marek Podmaka:
> On Mon, 17 Oct 2022 at 14:57, Wietse Venema wrote:
> >
> > For Postfix submission and smtps we prefer
> >
> > tls_ssl_options = NO_RENEGOTIATION, NO_TICKET
> >
> > Instead of forcing hostname/cert micmatches.
>
> Yes, I am already using NO_TICKET and it is also recommended by
On Mon, 17 Oct 2022 at 14:57, Wietse Venema wrote:
>
> For Postfix submission and smtps we prefer
>
> tls_ssl_options = NO_RENEGOTIATION, NO_TICKET
>
> Instead of forcing hostname/cert micmatches.
Yes, I am already using NO_TICKET and it is also recommended by the
linked article.
However it i
Marek Podmaka:
> On Sun, 16 Oct 2022 at 02:12, Viktor Dukhovni
> wrote:
> >
> > The two certificate chains are structurally identical, differing only in
> > minor details, such as: dates, keys, hostnames and signatures.
>
> There is another user (hopefully the URL below won't be blocked by the
>
On Sun, 16 Oct 2022 at 02:12, Viktor Dukhovni
wrote:
>
> The two certificate chains are structurally identical, differing only in
> minor details, such as: dates, keys, hostnames and signatures.
There is another user (hopefully the URL below won't be blocked by the
list) with the same observation
On Sun, 16 Oct 2022 at 02:12, Viktor Dukhovni
wrote:
>
> So if presenting an essentially identical certificate, but with the
> wrong hostname makes the client happy, that's rather unexpected.
>
> There's a non-trivial chance your observations are in error, but if
> indeed presenting the wrong name
On Sat, Oct 15, 2022 at 11:50:20PM +0200, Marek Podmaka wrote:
> > > I can provide privately postfix host/port for both working and
> > > non-working certs.
> >
> > Sure.
>
> : for the troubled cert
> : for the working cert (different domain)
The two certificate chains are structurally identical
On Sat, Oct 15, 2022 at 10:58:01PM +0200, Marek Podmaka wrote:
> Sorry for not replying to the original thread, I just subscribed.
>
> We have witnessed the same issue on one of our mailservers. Both
> servers are the same (postfix/debian), with the same config, both have
> letsencrypt certificat
On Sat, Oct 15, 2022 at 09:46:06PM +0200, Gerald Galster wrote:
> > One more PCAP file could shed light on this hypothesis. This would be
> > with tickets enabled on the server, and the client using "pre-update"
> > Windows.
>
> I'll see if I have any pre-update snapshots left.
Turns out that t
On Sat, 15 Oct 2022 at 23:24, Gerald Galster wrote:
>
> I'm just curious, which openssl version are you using?
postfix 3.1.15 and openssl 1.1.0l on debian9 still.
> Educating customers to ignore this kind of warning is not a good idea.
> Try to disable session tickets for submission instead:
I
> We have witnessed the same issue on one of our mailservers. Both
> servers are the same (postfix/debian), with the same config, both have
> letsencrypt certificates.
I'm just curious, which openssl version are you using?
> However we got customer complaints only for 1 server. Renewing the
> c
Sorry for not replying to the original thread, I just subscribed.
We have witnessed the same issue on one of our mailservers. Both
servers are the same (postfix/debian), with the same config, both have
letsencrypt certificates.
However we got customer complaints only for 1 server. Renewing the
ce
>> For the time being I'll disable session tickets (at least) for submission.
>> The performance impact is negligible in my case.
>>
>> Thanks for having a look!
>
> You're welcome. If you have a Microsoft support contract, you should
> ideally file a bug report and refer to:
>
>https://dat
On Sat, Oct 15, 2022 at 08:31:58PM +0200, Gerald Galster wrote:
> > The most likely issue is a Windows regression with zero length session
> > ids. I don't think there's anything that can be done here, the client
> > indicates support for session tickets, and since OpenSSL is then going
> > to is
Any chance you could provide (off-list if you prefer) a PCAP recording
of a good and a problem TLS session?
>>>
>>> I'll send it off-list.
>>
>> Thanks. I hope that'll shed more light on what's going on.
>
> The diff between the "good" and "bad" handshakes is below. The main
> featur
On Sat, Oct 15, 2022 at 12:38:31PM -0400, Viktor Dukhovni wrote:
> > > Any chance you could provide (off-list if you prefer) a PCAP recording
> > > of a good and a problem TLS session?
> >
> > I'll send it off-list.
>
> Thanks. I hope that'll shed more light on what's going on.
The diff betwee
This server does not support TLS 1.3 yet and TLS 1.2 is the only
version currently allowed for submission.
>
> That sounds like a rather old (EOL) version of OpenSSL. TLS 1.3
> support was added in OpenSSL 1.1.1 [11 Sep 2018]. Are you using
> OpenSSL 1.1.0 or the even older 1.0.2?
I
On Sat, Oct 15, 2022 at 06:54:56PM +0200, Gerald Galster wrote:
> >> This server does not support TLS 1.3 yet and TLS 1.2 is the only
> >> version currently allowed for submission.
That sounds like a rather old (EOL) version of OpenSSL. TLS 1.3
support was added in OpenSSL 1.1.1 [11 Sep 2018].
>> With session tickets disabled it logs:
>>
>>Anonymous TLS connection established from : TLSv1.2 with
>>cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
>>
>> This server does not support TLS 1.3 yet and TLS 1.2 is the only
>> version currently allowed for submission.
>
> Do you have
On Sat, Oct 15, 2022 at 06:20:48PM +0200, Gerald Galster wrote:
> With session tickets disabled it logs:
>
> Anonymous TLS connection established from : TLSv1.2 with
> cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
>
> This server does not support TLS 1.3 yet and TLS 1.2 is the only
>
>> Just wanted to let you know that Outlook users might run into problems
>> submitting mails after Microsoft's latest Windows update.
>>
>> Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from
>> Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: SSL_accept error from
>> : lost c
On Sat, Oct 15, 2022 at 03:32:15PM +0200, Gerald Galster wrote:
> Just wanted to let you know that Outlook users might run into problems
> submitting mails after Microsoft's latest Windows update.
>
> Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from
> Oct 15 14:49:42 mx1 postfix
Hi,
just wanted to let you know that Outlook users might run into problems
submitting mails after Microsoft's latest Windows update.
Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: connect from
Oct 15 14:49:42 mx1 postfix/submission/smtpd[25067]: SSL_accept error from
: lost connection
Oct
39 matches
Mail list logo
