这是一封自动回复邮件。已经收到您的来信，我会尽快回复。
On Wed, Oct 26, 2022 at 11:50:16AM -0400, Viktor Dukhovni wrote:
> On Wed, Oct 26, 2022 at 11:15:25AM +0100, Matt Caswell wrote:
>
> > > I'm not promising anything. But if you send me the captures I can take a
> > > look at them.
> >
> > I've taken a look at the captures for the working and
这是一封自动回复邮件。已经收到您的来信，我会尽快回复。
On Wed, Oct 26, 2022 at 11:15:25AM +0100, Matt Caswell wrote:
> > I'm not promising anything. But if you send me the captures I can take a
> > look at them.
>
> I've taken a look at the captures for the working and non-working scenarios.
>
> Do I understand correctly that your application is
On 24/10/2022 10:17, Matt Caswell wrote:
On 22/10/2022 16:02, David Harris wrote:
On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote:
That was my initial thought too, except that if it were
firewall-related, the initial port 587 connection would be blocked,
and it isn't -
On 22/10/2022 16:02, David Harris wrote:
On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote:
That was my initial thought too, except that if it were
firewall-related, the initial port 587 connection would be blocked,
and it isn't - the failure doesn't happen until after
> From: openssl-users On Behalf Of David
> Harris
> Sent: Saturday, 22 October, 2022 09:02
>
> I now have wireshark captures showing the exchanges between the working
> instance and the non-working instance respectively; the problem is definitely
> happening after STARTTLS has been issued and
On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote:
> > That was my initial thought too, except that if it were
> > firewall-related, the initial port 587 connection would be blocked,
> > and it isn't - the failure doesn't happen until after STARTTLS has
> > been issued.
>
> Not
> From: David Harris
> Sent: Friday, 21 October, 2022 01:42
>
> On 20 Oct 2022 at 20:04, Michael Wojcik wrote:
>
> > I think more plausible causes of this failure are things like OpenSSL
> > configuration and interference from other software such as an endpoint
> > firewall. Getting SYSCALL from
On 21 Oct 2022 at 7:27, Richard Levitte wrote:
> Let me ask you this: on what Windows version was your application
> built? Common wisdom would be to build on the oldest version...
My application is a very traditional Win32 application, and at the moment (and
until circumstances *force* me to
On 20 Oct 2022 at 20:04, Michael Wojcik wrote:
> OpenSSL 1.1.1 uses Windows cryptographic routines in two areas I'm
> aware of: rand_win.c and the CAPI engine. I don't offhand see a way
> that a problem with the calls in rand_win.c would cause the particular
> symptom you described. My guess is
Hi David,
I just did a check to see what Windows libraries the openssl.exe app
depends on, going back to look in 1.0.2, and looking at the current
development branch (master).
1.0.2:
ws2_32.lib(cond: no-sock)
gdi32.lib advapi32.lib crypt32.lib user32.lib
> From: openssl-users On Behalf Of David
> Harris
> Sent: Wednesday, 19 October, 2022 18:54
>
> Do recent versions of OpenSSL 1.1.1 have dependencies on some Windows
> facility (winsock and wincrypt seem likely candidates) that might work on
> Server 2019 but fail on Server 2012?
OpenSSL on
13 matches
Mail list logo
