Environment: Windows 7 (I know, I know - I just hate Windows 10).
Compiler: Visual Studio, have tried both VS2008 Pro and VS2019 Pro
OpenSSL Build: 1.1.1g, retrieved from OpenSSL.org last night
I've been attempting to build OpenSSL 1.1.x since it came out, but each time I
do so,
I find that,
I normally compile OpenSSL with "no-asm", but this time I thought I'd try
installing NASM and seeing what difference, if any, it actually made.
I downloaded NASM from the official site (which I believe to be
http://www.nasm.us) and, as I always do with anything I source from outside my
On 26 Jun 2020 at 11:55, Matt Caswell wrote:
> No - this is not normal output. We would expect the self tests to pass
> on Windows
> > The ONLY
> > non-standard thing I do is change the /MD switch (link to the DLL
> > versions of the runtime libraries) to /MT (static link the runtimes)
> >
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
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
Up front, I'd like to apologize if this is an FAQ or has been answered
elsewhere
on this list: my workload means that I simply can't keep as up-to-date as I
would
like.
I have a situation where my application fails to accept an incoming SSL
handshake on Windows Server 2012, but the identical
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
