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 validation bails out early due to the mismatched hostname.
>
> Attached is the pcap of another server where Outlook is able to
> send emails with session tickets enabled.
>
> This server (<redacted1>) and the other (<redacted2>)
> are running the same software stack:
>
> - CentOS 7
> - postfix-3.4.16 (self compiled)
> - openssl-1.0.2k-25.el7_9.x86_64
> - certbot-1.11.0-1.el7.noarch
>
> (no hostname mismatch anywhere)
>
> Letsencrypt chain cerfiticates are identical on both servers. Only
> difference is that <redacted1> cert has three SANs (active/active with
> dovecot replication). But this does not matter from a ssl perspective.
Yes, indeed session ticket ACKed by server. Assuming the Windows client
was indeed patched, the only visible difference is minor cert defailts
(3 SANs).
> I think it's Microsoft's turn to check what's going on.
This bug feels like uninitialised data, which is influenced by whatever
random thing lands in memory as a result of previous computations.
--
Viktor.
