Re: OpenSSL 1.1.1g test failures

[Richard Levitte]

On Fri, 26 Jun 2020 16:01:09 +0200,
David Harris wrote:
> Is there a standard (i.e, approved) way of using the static RTLs instead of 
> the 
> DLL ones? Or is my only option to modify the applink code so that it checks 
> its 
> environment in a different way? The problem with the dynamic RTLs is that my 
> application is often used in environments where the user may not have 
> sufficient 
> rights to install the redistributables - whereas, if I use the static 
> versions, the 
> code is a little bigger, but there's no redistributable installation required 
> and I 
> never run into rights issues.

The standard way of getting /MT is to configure 'no-shared', i.e. not
produce DLLs.

perl Configure VC-WIN64A no-shared

However, if the main issue is *your* application, then the simplest
way is to link with the static library, regardless of configuration.
We do produce alongside static libraries alongside the DLLs since
1.1.1: libcrypto_static.lib.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

RE: Error building OpenSSL-1.1.1g

[mhkelley2017]

Two follow-up issues - someone please tell me if I should have started a new 
thread - these are not really related to the initial point of this one.

While my build and test worked after re-installing MSYS2, the install failed.  
Unfortunately I inadvertently over-wrote the logfile I was keeping about this 
thread.

1) OPENSSLDIR was not correctly set.  In essence, while the documentation leads 
one to assume that the configure option --openssldir is derived from --prefix, 
this was NOT the case.  All of the installs went into the PREFIX I had passed 
to Configure until something barfed when it tried to write to c:\Program 
Files\SSL.  I then re-configured/re-built with both --prefix=PREFIX and 
--openssldir=PReFIX/SSL specified.  This seems to have worked correctly, with 
the relevant files then being put where they should be.

Perhaps this should be reported as a possible bug in the build process?

2) The documentation was not successfully installed.  There appears to be a 
complete file tree for it, but all of the html files are empty.  The failure is:

/c/usr/local/OPENSSL/openssl-1.1.1g/x86_64-8.1.0-posix-seh-rt_v6-rev0/share/doc/openssl/html/man7/X448.html
 -> 
/c/usr/local/OPENSSL/openssl-1.1.1g/x86_64-8.1.0-posix-seh-rt_v6-rev0/share/doc/openssl/html/man7/X25519.html
sh: pod2html: command not found

pod2html is a perl script in C:\msys64\usr\bin\core_perl.  I added that to my 
PATH.

Because I never saw any suggestion to do so, this might also be more 
appropriately submitted as a potential bug in the build process.



-Original Message-
From: mhkelley2...@gmail.com  
Sent: Friday, June 26, 2020 12:09 PM
To: openssl-users@openssl.org
Cc: 'Michael Wojcik' 
Subject: RE: Error building OpenSSL-1.1.1g


Thank you very much.  While my problem has already been resolved,
you raise a couple of issues that are worth noting for
completeness.

> > Can someone point me to sources of information about how to
> > resolve this issue?
> 
> Probably not, because it's not clear how you got into this state
> in the first place. You have a mix of 32- and 64-bit tools in
> your toolchain for this build. I don't know what you did to get
> there; I've never seen that happen with any of my OpenSSL builds.
> 
*** snip ***
> 
> My suggestion: Follow the recommended process by installing nasm
> (it's free) and configuring for that instead of MASM.

Did that as soon I decided to give up on mingw64 and try Visual
Studio.  Granted, my Y-chromosome does give me some challenges
when it comes to reading/following instructions, but that
requirement was clearly enough stated that I noticed and followed
up on it :)

> As Matt
> suggested, start from a "Visual Studio Command Prompt" window for
> the bitness you want to build, and then make sure you configure
> for that bitness. Get rid of any existing build artifacts first -
> probably the easist way is to move your working directory aside
> and extract a fresh one from the tarball.

Actualy repeated that step several times throughout to ensure I
was always starting clean.

> As Matt noted, you can confirm whether you're using the 32- or
> 64-bit version of the Visual Studio toolchain just by running
> cl.exe with no parameters; the banner says "for x86" or "for
> x64".

What cl.exe responded was what I expected, so didn't report it:

C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\Hostx86\x86\cl.exe

It is still a mystery why/how anything related to 32-bit ever arose in the 
build process.  But I no longer care because it was apparently self-inflicted 
and not likely to bother anyone else.

*** snip ***

> Regarding MSYS2 and Perl:
> 
> - Did you read the updated NOTES.WIN that Matt posted a link to?

Yes, found them at the beginning of my efforts, but (in case you
know the old joke about magicians), "the rabbit was already in
the hat" by that point.

*** snip ***

> - You haven't told us what Perl implementation you're
>   using.

My initial post:
   Perl: ActivePerl 5.24.3 Build_2404 (64-bit)

>   Knowing the path to it doesn't help us. (Though, to be
>   honest, knowing which implementation it is probably isn't
>   terribly useful either.) It would be nice if Sergio told us
>   which one *he's* using, since it's known to work with the MSYS2
>   configurations.

I think he did tell is - implicitly.  He used whatever he has
installed with his MSYS2 package.  If I'd had the same one
installed with my package, I'd have missed all this fun.
> 
> - I don't know whether there are Perl implementations for Windows
>   specifically intended to be used with MinGW or MSYS2, and if so
>   whether they work for the OpenSSL build. Oh, wait: I just did a
>   quick search, and apparently there is an MSYS2 Perl package
>   available from repo.msys2.org. Does it work with the OpenSSL
>   build? I don't know, but it seems like it's worth a try.

This is actually an important question.  In response to Matt's
suggestion, I went to MSYS2 to see what 

RE: Error building OpenSSL-1.1.1g

[mhkelley2017]

Thank you very much.  While my problem has already been resolved,
you raise a couple of issues that are worth noting for
completeness.

> > Can someone point me to sources of information about how to
> > resolve this issue?
> 
> Probably not, because it's not clear how you got into this state
> in the first place. You have a mix of 32- and 64-bit tools in
> your toolchain for this build. I don't know what you did to get
> there; I've never seen that happen with any of my OpenSSL builds.
> 
*** snip ***
> 
> My suggestion: Follow the recommended process by installing nasm
> (it's free) and configuring for that instead of MASM.

Did that as soon I decided to give up on mingw64 and try Visual
Studio.  Granted, my Y-chromosome does give me some challenges
when it comes to reading/following instructions, but that
requirement was clearly enough stated that I noticed and followed
up on it :)

> As Matt
> suggested, start from a "Visual Studio Command Prompt" window for
> the bitness you want to build, and then make sure you configure
> for that bitness. Get rid of any existing build artifacts first -
> probably the easist way is to move your working directory aside
> and extract a fresh one from the tarball.

Actualy repeated that step several times throughout to ensure I
was always starting clean.

> As Matt noted, you can confirm whether you're using the 32- or
> 64-bit version of the Visual Studio toolchain just by running
> cl.exe with no parameters; the banner says "for x86" or "for
> x64".

What cl.exe responded was what I expected, so didn't report it:

C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\Hostx86\x86\cl.exe

It is still a mystery why/how anything related to 32-bit ever arose in the 
build process.  But I no longer care because it was apparently self-inflicted 
and not likely to bother anyone else.

*** snip ***

> Regarding MSYS2 and Perl:
> 
> - Did you read the updated NOTES.WIN that Matt posted a link to?

Yes, found them at the beginning of my efforts, but (in case you
know the old joke about magicians), "the rabbit was already in
the hat" by that point.

*** snip ***

> - You haven't told us what Perl implementation you're
>   using.

My initial post:
   Perl: ActivePerl 5.24.3 Build_2404 (64-bit)

>   Knowing the path to it doesn't help us. (Though, to be
>   honest, knowing which implementation it is probably isn't
>   terribly useful either.) It would be nice if Sergio told us
>   which one *he's* using, since it's known to work with the MSYS2
>   configurations.

I think he did tell is - implicitly.  He used whatever he has
installed with his MSYS2 package.  If I'd had the same one
installed with my package, I'd have missed all this fun.
> 
> - I don't know whether there are Perl implementations for Windows
>   specifically intended to be used with MinGW or MSYS2, and if so
>   whether they work for the OpenSSL build. Oh, wait: I just did a
>   quick search, and apparently there is an MSYS2 Perl package
>   available from repo.msys2.org. Does it work with the OpenSSL
>   build? I don't know, but it seems like it's worth a try.

This is actually an important question.  In response to Matt's
suggestion, I went to MSYS2 to see what packages they have.
Their list of packages *did not* include a choice like "the one
we include with our initial installation in case you have somehow
lost it". Instead, they list the two give in one of my more
recent posts.  One listed is explicitly designed for use with
mingw-64.  It fails for OpenSSL the same way as ActivePerl.

Bottom line:  MSYS2 *does* include perl in its basic installation
(at least the most recent version) and it works.  Don't mess that
one up or your in for some fun.

Thanks to all.


-Original Message-
From: openssl-users  On Behalf Of Michael 
Wojcik
Sent: Friday, June 26, 2020 11:25 AM
To: openssl-users@openssl.org
Subject: RE: Error building OpenSSL-1.1.1g

[Removed the top-posted mess of history from this reply.]

In response to various questions posed in this thread:

> Can someone point me to sources of information about how to resolve this 
> issue?

Probably not, because it's not clear how you got into this state in the first 
place. You have a mix of 32- and 64-bit tools in your toolchain for this build. 
I don't know what you did to get there; I've never seen that happen with any of 
my OpenSSL builds.

> I simply don't believe I'm the only one who wants to build OpenSSL for use in 
> a
> Windows 10 environment - someone must have been successful and be able to 
> point
> me to additional information.

That's good, because that would be a silly thing to believe. We have multiple 
teams that routinely build OpenSSL for Windows (and other platforms). I've 
built it myself any number of times. We build both 32- and 64-bit variants, 
without problems.

My suggestion: Follow the recommended process by installing nasm (it's free) 
and configuring for that instead of MASM. As 

RE: Error building OpenSSL-1.1.1g

[mhkelley2017]

Thank you both, Matt and Sergio (and maybe Michael who just now weighed in but 
whose post I have not read).  You finally gave me clues sufficient to solve my 
problems. At present, OpenSSL is crunching through its tests and hasn't turned 
up a problem, so I think I can safely declare victory.

Thanks in particular to Sergio for giving me the assurance that OpenSSL *could* 
successfully build under Mingw-w6.
And thanks in particular to Matt for the key question that "It may well be that 
your MSYS2 environment already has perl available".

I simply re-installed MSYS2 and that solved all problem of which I was aware.

More complete response: I was running msys2-x86_64-20180531.exe, which I 
installed about 2 years ago.  Id *did not* include a version of perl.  It is 
hard to believe I would have deleted it, because that is a tool I use very 
frequently (though I'm generally in a standard windows command shell instead of 
MSYS2).  At some point, I installed and have relied on ActivePerl.

I deleted that version of MSYS2 and installed  msys2-base-x86_64-20200602.  
This was a raw install - I still need to re-configure a bunch of add-on 
packages, but that is for later.  First thing I did after MSYS2 configured 
itself was re-run my build script - didn't change anything, just re-ran it.

Problem solved.

Again, thanks for sticking we me to success!

Mke


-Original Message-
From: openssl-users  On Behalf Of Matt 
Caswell
Sent: Friday, June 26, 2020 9:56 AM
To: openssl-users@openssl.org
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:30, Matt Caswell wrote:
>> C:\Perl64\bin\perl.exe

Try *removing* this perl from your %PATH%. It may well be that your
MSYS2 environment already has perl available but this version is taking
priority.

Matt



>> $ perl Configure mingw --prefix=$PREFIX
>> **
>> This perl implementation doesn't produce Unix like paths (with forward slash
>> directory separators).  Please use an implementation that matches your
>> building platform.
>>
>> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>> **
> 
> For msys2 based builds you must use the msys2 provided perl version, not
> a native perl. Make sure msys2 has the perl package installed and remove
> this one from your path.
> 
> Maybe we should add an FAQ section of common faults and how to fix them.
> 
> Matt
> 
> 
> 
> 
>> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
>> Using os-specific seed configuration
>> --
>>
>>
>> -Original Message-
>> From: openssl-users  On Behalf Of Matt 
>> Caswell
>> Sent: Friday, June 26, 2020 3:04 AM
>> To: openssl-users@openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 26/06/2020 00:47, mhkelley2...@gmail.com wrote:
>>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit 
>>> version and which options, or environmental variables, or specific PATH 
>>> elements do I need to pay attention to in order to accomplish that?
>>
>> My windows environment died on my recently, so I can't check the actual
>> output. IIRC just typing "cl" at the command line should give you
>> details about the compiler being used and whether it is for 32 or 64 bits.
>>
>> Visual Studio has a number of "developer command prompts" available with
>> it. If you start one of those it should have all the right environment
>> variables set up for you. There should be different command prompts for
>> 32 bit vs 64 bit.
>>
>> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>>
>> Alternatively there is the vcvarsall.bat script which comes with VS that
>> enables you to setup all the environment variables - you can specify as
>> an argument to script whether you are targeting 32 bit or 64 bit.
>>
>> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>>
>> As well as the VS tools environment variables you will need to make sure
>> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
>> %PATH%.
>>
>>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 
>>> environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>>
>>
>> There are details in the newly rewritten instructions for Windows:
>>
>> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>>
>> Matt
>>
>>
>>>
>>> I'd really appreciate any useful information or pointers to such.
>>>
>>> Thanks. 
>>>
>>>
>>> -Original Message-
>>> From: openssl-users  On Behalf Of Matt 
>>> Caswell
>>> Sent: Thursday, June 25, 2020 2:03 PM
>>> To: 

RE: Error building OpenSSL-1.1.1g

[Michael Wojcik]

[Removed the top-posted mess of history from this reply.]

In response to various questions posed in this thread:

> Can someone point me to sources of information about how to resolve this 
> issue?

Probably not, because it's not clear how you got into this state in the first 
place. You have a mix of 32- and 64-bit tools in your toolchain for this build. 
I don't know what you did to get there; I've never seen that happen with any of 
my OpenSSL builds.

> I simply don't believe I'm the only one who wants to build OpenSSL for use in 
> a
> Windows 10 environment - someone must have been successful and be able to 
> point
> me to additional information.

That's good, because that would be a silly thing to believe. We have multiple 
teams that routinely build OpenSSL for Windows (and other platforms). I've 
built it myself any number of times. We build both 32- and 64-bit variants, 
without problems.

My suggestion: Follow the recommended process by installing nasm (it's free) 
and configuring for that instead of MASM. As Matt suggested, start from a 
"Visual Studio Command Prompt" window for the bitness you want to build, and 
then make sure you configure for that bitness. Get rid of any existing build 
artifacts first - probably the easist way is to move your working directory 
aside and extract a fresh one from the tarball.

As Matt noted, you can confirm whether you're using the 32- or 64-bit version 
of the Visual Studio toolchain just by running cl.exe with no parameters; the 
banner says "for x86" or "for x64". Note that it's important to let Visual 
Studio set up the environment (using one of those "Visual Studio Command 
Prompt" options) rather than trying to set it up manually - the latter is 
possible (I do it for my Cygwin bash sessions), but it's a pain to get it right.

> I messed around quite a bit trying to figure out how I might modify the build
> process to work with my usual set of tools - mostly UNIX-tools ported to 
> Windows
> environment.  My preference would be to find pointers to information of how to
> accomplish that.

Unless your usual set of tools matches what OpenSSL wants for the MinGW+MSYS2 
configuration option, I'd strongly recommend not trying to do this unless and 
until you understand the OpenSSL build process very well.

Regarding MSYS2 and Perl:

- Did you read the updated NOTES.WIN that Matt posted a link to?

- Perl implementations for Windows vary widely in their idiosyncracies, and 
OpenSSL is finicky about them. For years we used Cygwin Perl, but had to run it 
under a wrapper program which altered the command-line arguments. These days, 
we use Strawberry Perl. ActiveState Perl has also worked, but has licensing 
issues when used to build commercial software; that probably doesn't apply in 
your case. Note Strawberry and ActiveState have Windows-native behavior, and 
thus can be expected to work for the Visual Studio configurations but probably 
not for the MSYS2 configurations.
   In my experience, getting Perl to cooperate is the biggest hurdle in 
building OpenSSL on Windows, and historically for us has been the most fragile 
aspect. As the OpenSSL build process has made heavier use of Perl, it's become 
more picky about getting a Perl it likes. (This is probably my least favorite 
aspect of OpenSSL. People complain about the OpenSSL source, but I'd much 
rather debug that than the Perl build scripts.)

- You haven't told us what Perl implementation you're using. Knowing the path 
to it doesn't help us. (Though, to be honest, knowing which implementation it 
is probably isn't terribly useful either.) It would be nice if Sergio told us 
which one *he's* using, since it's known to work with the MSYS2 configurations.

- I don't know whether there are Perl implementations for Windows specifically 
intended to be used with MinGW or MSYS2, and if so whether they work for the 
OpenSSL build. Oh, wait: I just did a quick search, and apparently there is an 
MSYS2 Perl package available from repo.msys2.org. Does it work with the OpenSSL 
build? I don't know, but it seems like it's worth a try.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

RE: Error building OpenSSL-1.1.1g

[mhkelley2017]

Sadly, I'm pretty sure MSYS2 comes without perl.  At any rate, without some 
PATH element that has a perl, MSYS2 can't find one.

It has been a while since I installed MSYS2, and I no longer recall (or have 
good enough notes) whether I made a poor choice at installation time - but I 
can check that out.

Mike

-Original Message-
From: openssl-users  On Behalf Of Matt 
Caswell
Sent: Friday, June 26, 2020 9:56 AM
To: openssl-users@openssl.org
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:30, Matt Caswell wrote:
>> C:\Perl64\bin\perl.exe

Try *removing* this perl from your %PATH%. It may well be that your
MSYS2 environment already has perl available but this version is taking
priority.

Matt



>> $ perl Configure mingw --prefix=$PREFIX
>> **
>> This perl implementation doesn't produce Unix like paths (with forward slash
>> directory separators).  Please use an implementation that matches your
>> building platform.
>>
>> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>> **
> 
> For msys2 based builds you must use the msys2 provided perl version, not
> a native perl. Make sure msys2 has the perl package installed and remove
> this one from your path.
> 
> Maybe we should add an FAQ section of common faults and how to fix them.
> 
> Matt
> 
> 
> 
> 
>> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
>> Using os-specific seed configuration
>> --
>>
>>
>> -Original Message-
>> From: openssl-users  On Behalf Of Matt 
>> Caswell
>> Sent: Friday, June 26, 2020 3:04 AM
>> To: openssl-users@openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 26/06/2020 00:47, mhkelley2...@gmail.com wrote:
>>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit 
>>> version and which options, or environmental variables, or specific PATH 
>>> elements do I need to pay attention to in order to accomplish that?
>>
>> My windows environment died on my recently, so I can't check the actual
>> output. IIRC just typing "cl" at the command line should give you
>> details about the compiler being used and whether it is for 32 or 64 bits.
>>
>> Visual Studio has a number of "developer command prompts" available with
>> it. If you start one of those it should have all the right environment
>> variables set up for you. There should be different command prompts for
>> 32 bit vs 64 bit.
>>
>> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>>
>> Alternatively there is the vcvarsall.bat script which comes with VS that
>> enables you to setup all the environment variables - you can specify as
>> an argument to script whether you are targeting 32 bit or 64 bit.
>>
>> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>>
>> As well as the VS tools environment variables you will need to make sure
>> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
>> %PATH%.
>>
>>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 
>>> environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>>
>>
>> There are details in the newly rewritten instructions for Windows:
>>
>> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>>
>> Matt
>>
>>
>>>
>>> I'd really appreciate any useful information or pointers to such.
>>>
>>> Thanks. 
>>>
>>>
>>> -Original Message-
>>> From: openssl-users  On Behalf Of Matt 
>>> Caswell
>>> Sent: Thursday, June 25, 2020 2:03 PM
>>> To: openssl-users@openssl.org
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 20:20, mhkelley2...@gmail.com wrote:
 Thanks! That helped, but I have two follow-ups.

 1) To whom would I suggest minor changes to the available installation
 instructions to help avoid future such misunderstandings?
>>>
>>> You can raise on issue on Github. Or even better raise a PR with your
>>> suggested changes. However, as it so happens the Windows instructions
>>> have very recently been significantly updated - so some of your
>>> suggestions may already have been included:
>>>
>>> https://github.com/openssl/openssl/pull/12098
>>>
 crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
 'x64' conflicts with target machine type 'x86'
>>>
>>> This usually occurs when attempting to build 64-bit OpenSSL using the
>>> 32-bit VisualStudio tools.
>>>
>>> Matt
>>>
>>>
>>>
 Could Not Find
 c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
 NMAKE : fatal error U1077: 'link' : return 

Re: Error building OpenSSL-1.1.1g

[Matt Caswell]

On 26/06/2020 14:30, Matt Caswell wrote:
>> C:\Perl64\bin\perl.exe

Try *removing* this perl from your %PATH%. It may well be that your
MSYS2 environment already has perl available but this version is taking
priority.

Matt



>> $ perl Configure mingw --prefix=$PREFIX
>> **
>> This perl implementation doesn't produce Unix like paths (with forward slash
>> directory separators).  Please use an implementation that matches your
>> building platform.
>>
>> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>> **
> 
> For msys2 based builds you must use the msys2 provided perl version, not
> a native perl. Make sure msys2 has the perl package installed and remove
> this one from your path.
> 
> Maybe we should add an FAQ section of common faults and how to fix them.
> 
> Matt
> 
> 
> 
> 
>> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
>> Using os-specific seed configuration
>> --
>>
>>
>> -Original Message-
>> From: openssl-users  On Behalf Of Matt 
>> Caswell
>> Sent: Friday, June 26, 2020 3:04 AM
>> To: openssl-users@openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 26/06/2020 00:47, mhkelley2...@gmail.com wrote:
>>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit 
>>> version and which options, or environmental variables, or specific PATH 
>>> elements do I need to pay attention to in order to accomplish that?
>>
>> My windows environment died on my recently, so I can't check the actual
>> output. IIRC just typing "cl" at the command line should give you
>> details about the compiler being used and whether it is for 32 or 64 bits.
>>
>> Visual Studio has a number of "developer command prompts" available with
>> it. If you start one of those it should have all the right environment
>> variables set up for you. There should be different command prompts for
>> 32 bit vs 64 bit.
>>
>> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>>
>> Alternatively there is the vcvarsall.bat script which comes with VS that
>> enables you to setup all the environment variables - you can specify as
>> an argument to script whether you are targeting 32 bit or 64 bit.
>>
>> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>>
>> As well as the VS tools environment variables you will need to make sure
>> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
>> %PATH%.
>>
>>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 
>>> environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>>
>>
>> There are details in the newly rewritten instructions for Windows:
>>
>> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>>
>> Matt
>>
>>
>>>
>>> I'd really appreciate any useful information or pointers to such.
>>>
>>> Thanks. 
>>>
>>>
>>> -Original Message-
>>> From: openssl-users  On Behalf Of Matt 
>>> Caswell
>>> Sent: Thursday, June 25, 2020 2:03 PM
>>> To: openssl-users@openssl.org
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 20:20, mhkelley2...@gmail.com wrote:
 Thanks! That helped, but I have two follow-ups.

 1) To whom would I suggest minor changes to the available installation
 instructions to help avoid future such misunderstandings?
>>>
>>> You can raise on issue on Github. Or even better raise a PR with your
>>> suggested changes. However, as it so happens the Windows instructions
>>> have very recently been significantly updated - so some of your
>>> suggestions may already have been included:
>>>
>>> https://github.com/openssl/openssl/pull/12098
>>>
 crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
 'x64' conflicts with target machine type 'x86'
>>>
>>> This usually occurs when attempting to build 64-bit OpenSSL using the
>>> 32-bit VisualStudio tools.
>>>
>>> Matt
>>>
>>>
>>>
 Could Not Find
 c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
 NMAKE : fatal error U1077: 'link' : return code '0x1'
 Stop.
 NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
 Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
 : return code '0x2'
 Stop.

 -Original Message-
 From: openssl-users  On Behalf Of Matt
 Caswell
 Sent: Thursday, June 25, 2020 12:15 PM
 To: openssl-users@openssl.org
 Subject: Re: Error building OpenSSL-1.1.1g



 On 25/06/2020 18:32, Michael Wojcik wrote:

RE: Error building OpenSSL-1.1.1g

[mhkelley2017]

Thanks.

 

But apparently you missed one of my earlier posts.

 

I have a fair bit of experience building apps from source.  My general
experience is that the instructions provided are nearly correct, but that
the user must do a little tweaking of the process - presumably because the
underlying process is quite complex and depends a *very many* case-specific
system configuration details.  Hence, I am quite comfortable debugging most
installation processes to get them to work.

 

Following your suggestion, I get (and reported) the following result:

 




Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw64

Using os-specific seed configuration

 


**

This perl implementation doesn't produce Unix like paths (with forward slash

directory separators).  Please use an implementation that matches your

building platform.

 

This Perl version: 5.28.0 for MSWin32-x64-multi-thread


**




 

So clearly, either 1) you have done something different from just enter the
configure command, or 2) I have something in my programming environment that
is different from yours.

 

I'm simply trying to figure out one of those differences.

 

Mike

 

From: Sergio NNX  
Sent: Friday, June 26, 2020 8:59 AM
To: openssl-users@openssl.org
Cc: mhkelley2...@gmail.com
Subject: Re: Error building OpenSSL-1.1.1g

 

It is so easy to build OpenSSL using MinGW/MSYS!

 

Just type: ./Configure mingw64 ... 

  make all

 



 

How much experience do you have building apps from source on Windows? VS
didn't work, MinGW didn't work either!

We are more than happy to assist you.

 

Have fun.

 

  _  

From: openssl-users mailto:openssl-users-boun...@openssl.org> > on behalf of Matt Caswell
mailto:m...@openssl.org> >
Sent: Friday, 26 June 2020 11:30 PM
To: openssl-users@openssl.org 
mailto:openssl-users@openssl.org> >
Subject: Re: Error building OpenSSL-1.1.1g 

 



On 26/06/2020 14:27, mhkelley2...@gmail.com 
wrote:
> Matt,
> 
> Thanks for your suggestion ...
> 
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
> 
> That was one of the first things I tried.  After exploring a few rabbit
holes, I gave up and downloaded Visual Studio..
> 
> Here is how far I got  I have been unable to even figure out where this
error comes from ...
> 
>

--
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
>

**
> This perl implementation doesn't produce Unix like paths (with forward
slash
> directory separators).  Please use an implementation that matches your
> building platform.
> 
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>

**

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
>

--
> 
> 
> -Original Message-
> From: openssl-users mailto:openssl-users-boun...@openssl.org> > On Behalf Of Matt Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: openssl-users@openssl.org  
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 26/06/2020 00:47, mhkelley2...@gmail.com
  wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or
64-bit version and which options, or environmental variables, or specific
PATH elements do I need to pay attention to in order to accomplish that?
> 
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
> 
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 

Re: Error building OpenSSL-1.1.1g

[Sergio NNX]

It is so easy to build OpenSSL using MinGW/MSYS!

Just type: ./Configure mingw64 ... 
  make all

[cid:244b0963-a277-473a-95fe-9419d8ef84d0]

How much experience do you have building apps from source on Windows? VS didn't 
work, MinGW didn't work either!
We are more than happy to assist you.

Have fun.


From: openssl-users  on behalf of Matt 
Caswell 
Sent: Friday, 26 June 2020 11:30 PM
To: openssl-users@openssl.org 
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:27, mhkelley2...@gmail.com wrote:
> Matt,
>
> Thanks for your suggestion ...
>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>
> That was one of the first things I tried.  After exploring a few rabbit 
> holes, I gave up and downloaded Visual Studio..
>
> Here is how far I got  I have been unable to even figure out where this error 
> comes from ...
>
> --
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
> **
> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.
>
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
> **

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
> --
>
>
> -Original Message-
> From: openssl-users  On Behalf Of Matt 
> Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: openssl-users@openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
>
>
>
> On 26/06/2020 00:47, mhkelley2...@gmail.com wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit 
>> version and which options, or environmental variables, or specific PATH 
>> elements do I need to pay attention to in order to accomplish that?
>
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
>
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
>
> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
>
> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
>
>
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment 
>> *without* need for visual studio?
>
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
>
>
> There are details in the newly rewritten instructions for Windows:
>
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>
> Matt
>
>
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks.
>>
>>
>> -Original Message-
>> From: openssl-users  On Behalf Of Matt 
>> Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 20:20, mhkelley2...@gmail.com wrote:
>>> Thanks! That helped, but I have two follow-ups.
>>>
>>> 1) To whom would I suggest minor changes to the available installation
>>> instructions to help avoid future such misunderstandings?
>>
>> You can raise on issue on Github. Or even better raise a PR with your
>> suggested changes. However, as it so happens the Windows instructions
>> have very recently been significantly updated - so some of your
>> suggestions may already have been included:
>>
>> 

RE: Error building OpenSSL-1.1.1g

[mhkelley2017]

Matt,

I fear I my wear out my welcome before I manage to get a working OpenSSL ...

> Make sure msys2 has the perl package installed and remove
> this one from your path.

OK, I'll bite.

As near as I can tell, this suggestion means one of two things.

1) use one of the "completion"  functions named "perl" that apparently came 
with the original MSYS2 installation (both in folder 
msys64\usr\share\bash-completion\completions).  Since neither seemed to do 
anything useful here, I presume you mean

2) install a perl package from MSYS2 for use with MSYS2.  If this is what you 
meant, I still have two apparently relevant choices.

a) mingw-w64-perl
b) perl (seems specific to Cygwin and Linux)

The former gives me the same error as ActivePerl
The latter seems to be just ignored.

I'm clearly missing something, but must be too dense to figure out what.

Mike

-Original Message-
From: openssl-users  On Behalf Of Matt 
Caswell
Sent: Friday, June 26, 2020 7:31 AM
To: openssl-users@openssl.org
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:27, mhkelley2...@gmail.com wrote:
> Matt,
> 
> Thanks for your suggestion ...
> 
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
> 
> That was one of the first things I tried.  After exploring a few rabbit 
> holes, I gave up and downloaded Visual Studio..
> 
> Here is how far I got  I have been unable to even figure out where this error 
> comes from ...
> 
> --
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
> **
> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.
> 
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
> **

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
> --
> 
> 
> -Original Message-
> From: openssl-users  On Behalf Of Matt 
> Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: openssl-users@openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 26/06/2020 00:47, mhkelley2...@gmail.com wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit 
>> version and which options, or environmental variables, or specific PATH 
>> elements do I need to pay attention to in order to accomplish that?
> 
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
> 
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
> 
> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
> 
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
> 
> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
> 
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
> 
> 
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment 
>> *without* need for visual studio?
> 
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
> 
> 
> There are details in the newly rewritten instructions for Windows:
> 
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
> 
> Matt
> 
> 
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks. 
>>
>>
>> -Original Message-
>> From: openssl-users  On Behalf Of Matt 
>> Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: openssl-users@openssl.org
>> Subject: Re: 

Re: OpenSSL 1.1.1g test failures

[David Harris]

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)
> > because I don't want to have external dependencies in my production
> > environments
> 
> How exactly do you make this change? By editing the Makefile? Have you
> tried it without doing this? My guess is that this is exactly the
> cause of the problem. AppLink is all about dealing with differences in
> MS runtimes.

Assumption, as they say, is the mother of all fu??ups...

In this case, the failed assumption was that a non-standard modification I had 
been making for many years would continue to work simply because it had in 
the past.

Matt is, of course, quite right. When I changed the "/MT" back to "/MD" in 
CNF_CFLAGS and rebuilt everything, it all worked like clockwork.

My thanks to you Matt - you've solved my problem.

Is there a standard (i.e, approved) way of using the static RTLs instead of the 
DLL ones? Or is my only option to modify the applink code so that it checks its 
environment in a different way? The problem with the dynamic RTLs is that my 
application is often used in environments where the user may not have 
sufficient 
rights to install the redistributables - whereas, if I use the static versions, 
the 
code is a little bigger, but there's no redistributable installation required 
and I 
never run into rights issues.

Again, thank you for the assistance, Matt - I appreciate it.

Cheers!

-- David --

Re: Error building OpenSSL-1.1.1g

[Matt Caswell]

On 26/06/2020 14:27, mhkelley2...@gmail.com wrote:
> Matt,
> 
> Thanks for your suggestion ...
> 
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
> 
> That was one of the first things I tried.  After exploring a few rabbit 
> holes, I gave up and downloaded Visual Studio..
> 
> Here is how far I got  I have been unable to even figure out where this error 
> comes from ...
> 
> --
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
> **
> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.
> 
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
> **

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
> --
> 
> 
> -Original Message-
> From: openssl-users  On Behalf Of Matt 
> Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: openssl-users@openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 26/06/2020 00:47, mhkelley2...@gmail.com wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit 
>> version and which options, or environmental variables, or specific PATH 
>> elements do I need to pay attention to in order to accomplish that?
> 
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
> 
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
> 
> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
> 
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
> 
> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
> 
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
> 
> 
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment 
>> *without* need for visual studio?
> 
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
> 
> 
> There are details in the newly rewritten instructions for Windows:
> 
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
> 
> Matt
> 
> 
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks. 
>>
>>
>> -Original Message-
>> From: openssl-users  On Behalf Of Matt 
>> Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 20:20, mhkelley2...@gmail.com wrote:
>>> Thanks! That helped, but I have two follow-ups.
>>>
>>> 1) To whom would I suggest minor changes to the available installation
>>> instructions to help avoid future such misunderstandings?
>>
>> You can raise on issue on Github. Or even better raise a PR with your
>> suggested changes. However, as it so happens the Windows instructions
>> have very recently been significantly updated - so some of your
>> suggestions may already have been included:
>>
>> https://github.com/openssl/openssl/pull/12098
>>
>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>> 'x64' conflicts with target machine type 'x86'
>>
>> This usually occurs when attempting to build 64-bit OpenSSL using the
>> 32-bit VisualStudio tools.
>>
>> Matt
>>
>>
>>
>>> Could Not Find
>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>> Stop.
>>> NMAKE : fatal error 

RE: Error building OpenSSL-1.1.1g

[mhkelley2017]

Matt,

Thanks for your suggestion ...

>> 
>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>> 10 environment *without* need for visual studio?
>
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.

That was one of the first things I tried.  After exploring a few rabbit holes, 
I gave up and downloaded Visual Studio..

Here is how far I got  I have been unable to even figure out where this error 
comes from ...

--
$ where perl
C:\Perl64\bin\perl.exe
$ perl Configure mingw --prefix=$PREFIX
**
This perl implementation doesn't produce Unix like paths (with forward slash
directory separators).  Please use an implementation that matches your
building platform.

This Perl version: 5.24.3 for MSWin32-x64-multi-thread
**
Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
Using os-specific seed configuration
--


-Original Message-
From: openssl-users  On Behalf Of Matt 
Caswell
Sent: Friday, June 26, 2020 3:04 AM
To: openssl-users@openssl.org
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 00:47, mhkelley2...@gmail.com wrote:
> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit 
> version and which options, or environmental variables, or specific PATH 
> elements do I need to pay attention to in order to accomplish that?

My windows environment died on my recently, so I can't check the actual
output. IIRC just typing "cl" at the command line should give you
details about the compiler being used and whether it is for 32 or 64 bits.

Visual Studio has a number of "developer command prompts" available with
it. If you start one of those it should have all the right environment
variables set up for you. There should be different command prompts for
32 bit vs 64 bit.

https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs

Alternatively there is the vcvarsall.bat script which comes with VS that
enables you to setup all the environment variables - you can specify as
an argument to script whether you are targeting 32 bit or 64 bit.

https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017

As well as the VS tools environment variables you will need to make sure
both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
%PATH%.


> 
> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment 
> *without* need for visual studio?

You can do this using the MinGW compilers and the MSys2 shell. Note the
MinGW compilers target *native* windows. So although you use Msys2 to
build it, the resulting binaries are fully native.


There are details in the newly rewritten instructions for Windows:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN

Matt


> 
> I'd really appreciate any useful information or pointers to such.
> 
> Thanks. 
> 
> 
> -Original Message-
> From: openssl-users  On Behalf Of Matt 
> Caswell
> Sent: Thursday, June 25, 2020 2:03 PM
> To: openssl-users@openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 25/06/2020 20:20, mhkelley2...@gmail.com wrote:
>> Thanks! That helped, but I have two follow-ups.
>>
>> 1) To whom would I suggest minor changes to the available installation
>> instructions to help avoid future such misunderstandings?
> 
> You can raise on issue on Github. Or even better raise a PR with your
> suggested changes. However, as it so happens the Windows instructions
> have very recently been significantly updated - so some of your
> suggestions may already have been included:
> 
> https://github.com/openssl/openssl/pull/12098
> 
>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>> 'x64' conflicts with target machine type 'x86'
> 
> This usually occurs when attempting to build 64-bit OpenSSL using the
> 32-bit VisualStudio tools.
> 
> Matt
> 
> 
> 
>> Could Not Find
>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>> : return code '0x2'
>> Stop.
>>
>> -Original Message-
>> From: openssl-users  On Behalf Of Matt
>> Caswell
>> Sent: Thursday, June 25, 2020 12:15 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 18:32, Michael Wojcik wrote:
 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf

Re: server key exchange signature behavior

[Bruce Cloutier]

Thank you JJK and everyone!!

Jan, that was it! Never thought to check the key size. Just too close to
it I guess. I could handle the 2,048 bit keys but set a fixed maximum
register size of 4,096 bits. Well, it needs 6,144 bits to do the 3,072
bit math. My bad as they say. I do have a ToDo in the comments to
implement dynamic sizing. After all, my target is just a
micro-controller based device at 100 MHz. Security needs to be
functional and, well, not necessarily strong. Most neglect to move away
from default passwords. Ugh.

I'll probably roll jnior.com back to 2,048. I did not purposely set the
larger key size. Must have been someone's idea of a good default.

Oh... and it was Ethereal before Wireshark. I had to look it up.
Starting to get concerned about my memory. But, I do have valid 30-year
old backups of past systems and am certain I can I actually pull a
version off that if I really wanted.

I was just adding Elliptic Curve capabilities to my TLS as something to
do during this pandemic. Yeah, finally. It is an academic endeavor in
keeping with my DIY edict.

Thank you all. And, Jan you are a star!!

Bruce

On 6/26/20 6:23 AM, Bruce Cloutier wrote:
> Jan,
>
> Use Wireshark all of the time. In fact I've used it since before it was
> Wireshark. But now... I can't remember what it was called before. Great
> tool.
>
> You, though, may have hit on something in pointing out the 3072 bit key.
> I will check on that. It was a design decision in developing this
> controller that no 3rd party code be used. Consequently I have authored
> every byte of the OS including the stack. So the multi-precision math is
> all mine and... it does have a limit. I may have set it with the 2,048
> bit keys in mind. This would absolutely fit with the symptoms. Let me
> verify.
>
> Thank you!
>
> Bruce
>
> On 6/26/20 3:52 AM, Jan Just Keijser wrote:
>> On 25/06/20 20:02, Bruce Cloutier wrote:
>>> I agree that I am not being explicit regarding my terminology. I don't
>>> mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
>>> need to reach out.
>>>
>>> Specifically, the Signature covering the EC Diffe-Hellman Server Params
>>> in the server_key_exchange message that I eventually receive in making
>>> an outgoing client connection from my TLS implementation, does not
>>> decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
>>> That is happening with this one server installation using Apache in a
>>> Bitnami stack (Windows machine). My TLS code is running as part of the
>>> operating system on our separate single board computer controller
>>> (JNIOR).
>>>
>>> I use the public key extracted from the supplied certificate to decrypt
>>> and then compare the calculated hash. This procedure has been successful
>>> (and signatures verify/validate/match) in every other connection attempt
>>> to other servers (including google.com). It also works with this Apache
>>> server before we move away from the default key and certificate files.
>>> Basically, our server is using some other key for this. Maybe still the
>>> default. After we point configuration to a new certificate and key.
>>>
>>> Yeah, I had at first thought that there was an intrusion. But in testing
>>> with a clean sandboxed server we see the same results. Yes, it is most
>>> likely an Apache configuration issue but, we've dug through all of that
>>> and nothing jumps out.
>>>
>>> So either we haven't configured every possible corner of this Apache
>>> server correctly, or there is some odd extension to TLS that I've
>>> missed. But as you all know, debugging in this area is difficult.
>>>
>>> jnior.com is obviously public and we need to know if we have it
>>> improperly configured. But, I need to know why in this one instance my
>>> TLS implementation fails. In either case, it is an symptom that
>>> shouldn't be ignored as you would agree.
>>>
>>> The good news is that if there were an OpenSSL bug somewhat associated
>>> with this, you all would have already mentioned it (I assume).
>>>
>> I'd suggest to run something like wireshark and capture the TLS
>> handshake - if I do that against jnior.com I see that the jnior.com
>> certificate has a X509 cert extension unknown to my rather old
>> Wireshark version, but that should not matter much. Wireshark will
>> give you detailed info about the EC Diffie-Hellman Server Params that
>> were sent over the wire, including the signature. Wireshark does not
>> indicate any problems there, although I am not sure if it *would* , if
>> there was a problem.
>>
>> However, it will give you an easy method to see what wireshark thinks
>> the signature is compared to what your code thinks the signature is.
>>
>> As a side-remark: I did notice your server cert is using 3072 bit RSA
>> whereas the CAs are based on 2048bit RSA - nothing wrong with that,
>> but do make sure your code can handle that (under normal circumstances
>> it would not be an issue).
>>
>> HTH,
>>
>> JJK
>>
>>> On 6/25/20 1:32 PM, 

Re: OpenSSL 1.1.1g test failures

[Matt Caswell]

On 26/06/2020 10:45, David Harris wrote:

> Is this just the way it is? I would have thought that 50% self-test failure 
> would be 
> ringing alarm bells everywhere if it were common, so I can only conclude that 
> there's 
> something odd about my environment, or that I'm doing something wrong, but 
> this is 
> about as vanilla a build process as I can possibly make it.

No - this is not normal output. We would expect the self tests to pass
on Windows (and they do), e.g.

https://ci.appveyor.com/project/openssl/openssl/builds/33676970


> I follow the steps for 
> Win32 in INSTALL, and as I said at the start of this message, the nmake 
> process 
> goes cleanly, not a single warning or error. 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) because I don't want to have external dependencies 
> in my 
> production environments (I lived in "DLL Hell" for so long that I'm now quite 
> paranoid 
> about that). This change has never caused problems in the past, and doesn't 
> seem 
> to be relevant to the problems I'm seeing.
> 

How exactly do you make this change? By editing the Makefile? Have you
tried it without doing this? My guess is that this is exactly the cause
of the problem. AppLink is all about dealing with differences in MS
runtimes.

Matt

Re: server key exchange signature behavior

[Bruce Cloutier]

Jan,

Use Wireshark all of the time. In fact I've used it since before it was
Wireshark. But now... I can't remember what it was called before. Great
tool.

You, though, may have hit on something in pointing out the 3072 bit key.
I will check on that. It was a design decision in developing this
controller that no 3rd party code be used. Consequently I have authored
every byte of the OS including the stack. So the multi-precision math is
all mine and... it does have a limit. I may have set it with the 2,048
bit keys in mind. This would absolutely fit with the symptoms. Let me
verify.

Thank you!

Bruce

On 6/26/20 3:52 AM, Jan Just Keijser wrote:
> On 25/06/20 20:02, Bruce Cloutier wrote:
>> I agree that I am not being explicit regarding my terminology. I don't
>> mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
>> need to reach out.
>>
>> Specifically, the Signature covering the EC Diffe-Hellman Server Params
>> in the server_key_exchange message that I eventually receive in making
>> an outgoing client connection from my TLS implementation, does not
>> decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
>> That is happening with this one server installation using Apache in a
>> Bitnami stack (Windows machine). My TLS code is running as part of the
>> operating system on our separate single board computer controller
>> (JNIOR).
>>
>> I use the public key extracted from the supplied certificate to decrypt
>> and then compare the calculated hash. This procedure has been successful
>> (and signatures verify/validate/match) in every other connection attempt
>> to other servers (including google.com). It also works with this Apache
>> server before we move away from the default key and certificate files.
>> Basically, our server is using some other key for this. Maybe still the
>> default. After we point configuration to a new certificate and key.
>>
>> Yeah, I had at first thought that there was an intrusion. But in testing
>> with a clean sandboxed server we see the same results. Yes, it is most
>> likely an Apache configuration issue but, we've dug through all of that
>> and nothing jumps out.
>>
>> So either we haven't configured every possible corner of this Apache
>> server correctly, or there is some odd extension to TLS that I've
>> missed. But as you all know, debugging in this area is difficult.
>>
>> jnior.com is obviously public and we need to know if we have it
>> improperly configured. But, I need to know why in this one instance my
>> TLS implementation fails. In either case, it is an symptom that
>> shouldn't be ignored as you would agree.
>>
>> The good news is that if there were an OpenSSL bug somewhat associated
>> with this, you all would have already mentioned it (I assume).
>>
>
> I'd suggest to run something like wireshark and capture the TLS
> handshake - if I do that against jnior.com I see that the jnior.com
> certificate has a X509 cert extension unknown to my rather old
> Wireshark version, but that should not matter much. Wireshark will
> give you detailed info about the EC Diffie-Hellman Server Params that
> were sent over the wire, including the signature. Wireshark does not
> indicate any problems there, although I am not sure if it *would* , if
> there was a problem.
>
> However, it will give you an easy method to see what wireshark thinks
> the signature is compared to what your code thinks the signature is.
>
> As a side-remark: I did notice your server cert is using 3072 bit RSA
> whereas the CAs are based on 2048bit RSA - nothing wrong with that,
> but do make sure your code can handle that (under normal circumstances
> it would not be an issue).
>
> HTH,
>
> JJK
>
>> On 6/25/20 1:32 PM, Michael Wojcik wrote:
 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
 Behalf Of
 Bruce Cloutier
 Sent: Thursday, June 25, 2020 12:10

 By "If OpenSSL fails to validate this particular digital signature
 that
 would be the case." I meant to question whether or not OpenSSL is in
 fact doing the validation? In the case that the signature is being
 ignored then clients wouldn't complain. They wouldn't notice.
>>> s_client should be verifying the signature.[1] That is, it should be
>>> verifying every signature that's part of the actual TLS protocol. I
>>> admit it's not entirely clear to me which signature isn't being
>>> verified successfully by your client.
>>>
>>>
>>> [1] I'm not sure "validate" is the proper term here, technically
>>> speaking. In my experience, the literature usually uses "verify" for
>>> confirming a signature. "Validate" is generally used for more
>>> complex protocols, such as certificate validation, which involves a
>>> large number of steps with various types of checks.
>>>
>>> -- 
>>> Michael Wojcik
>>> Distinguished Engineer, Micro Focus
>>>
>>>
>>>
>
>
>
-- 
Sent using Thunderbird on Ubuntu 16.04LTS




signature.asc
Description: OpenPGP digital signature

OpenSSL 1.1.1g test failures

[David Harris]

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, while it compiles and links cleanly, it fails about 50% of its 
self tests when 
I perform "nmake test". It has been this way for several releases. By "fail" I 
mean 
that there's a stream of "dubious..." outputs that look like this excerpt:

-- Cut here 
...
test\recipes\03-test_internal_siphash.t . ok
test\recipes\03-test_internal_sm2.t . ok
test\recipes\03-test_internal_sm4.t . ok
test\recipes\03-test_internal_ssl_cert_table.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
test\recipes\03-test_internal_x509.t  ok
test\recipes\03-test_ui.t ... ok
test\recipes\04-test_asn1_decode.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
test\recipes\04-test_asn1_encode.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests 
...
-- Cut here 

Each time I went through the process, I saw the long string of self-test 
failures and 
decided I'd put off migrating to 1.1.1 until it was sorted out, but it's been 
the same for 
at least four releases now. I finally decided I needed to track down what was 
going 
on, so I extrapolated how to run the failing tests manually with more verbose 
output 
from the OpenSSL wiki pages (which are just a little out of date).

It appears that for at least the first twenty or thirty of these failures, the 
reason is 
because the test application has been compiled without including the required 
Applink code - a verbose output typically looks like this:

-- Cut here 
O:\ >perl test\recipes\05-test_idea.t
1..1
OPENSSL_Uplink(5C790330,08): no OPENSSL_Applink
..\ideatest.exe => 1
not ok 1 - running ideatest
#   Failed test 'running ideatest'
#   at util/perl/OpenSSL/Test/Simple.pm line 77.
# Looks like you failed 1 test of 1.
-- Cut here 

Is this just the way it is? I would have thought that 50% self-test failure 
would be 
ringing alarm bells everywhere if it were common, so I can only conclude that 
there's 
something odd about my environment, or that I'm doing something wrong, but this 
is 
about as vanilla a build process as I can possibly make it. I follow the steps 
for 
Win32 in INSTALL, and as I said at the start of this message, the nmake process 
goes cleanly, not a single warning or error. 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) because I don't want to have external dependencies 
in my 
production environments (I lived in "DLL Hell" for so long that I'm now quite 
paranoid 
about that). This change has never caused problems in the past, and doesn't 
seem 
to be relevant to the problems I'm seeing.

I've been building OpenSSL myself for a number of years, most recently with the 
end-of-life v1.0.2 builds, which always go without a hitch. As I remarked, I've 
been 
putting off moving to v1.1.1 because I'm so uneasy about these self-test 
failures, but 
I can't continue doing that any longer as TLS3 starts coming on stream.

Anyone have any insights into what I'm doing wrong, or what I can do about 
this? I'm 
very reluctant to use the software in production if it can't pass its own 
self-test 
regime, even if it appears to work normally otherwise.

Comments most welcome.

Cheers!

-- David --

Re: Error building OpenSSL-1.1.1g

[Matt Caswell]

On 26/06/2020 00:47, mhkelley2...@gmail.com wrote:
> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit 
> version and which options, or environmental variables, or specific PATH 
> elements do I need to pay attention to in order to accomplish that?

My windows environment died on my recently, so I can't check the actual
output. IIRC just typing "cl" at the command line should give you
details about the compiler being used and whether it is for 32 or 64 bits.

Visual Studio has a number of "developer command prompts" available with
it. If you start one of those it should have all the right environment
variables set up for you. There should be different command prompts for
32 bit vs 64 bit.

https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs

Alternatively there is the vcvarsall.bat script which comes with VS that
enables you to setup all the environment variables - you can specify as
an argument to script whether you are targeting 32 bit or 64 bit.

https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017

As well as the VS tools environment variables you will need to make sure
both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
%PATH%.


> 
> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment 
> *without* need for visual studio?

You can do this using the MinGW compilers and the MSys2 shell. Note the
MinGW compilers target *native* windows. So although you use Msys2 to
build it, the resulting binaries are fully native.


There are details in the newly rewritten instructions for Windows:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN

Matt


> 
> I'd really appreciate any useful information or pointers to such.
> 
> Thanks. 
> 
> 
> -Original Message-
> From: openssl-users  On Behalf Of Matt 
> Caswell
> Sent: Thursday, June 25, 2020 2:03 PM
> To: openssl-users@openssl.org
> Subject: Re: Error building OpenSSL-1.1.1g
> 
> 
> 
> On 25/06/2020 20:20, mhkelley2...@gmail.com wrote:
>> Thanks! That helped, but I have two follow-ups.
>>
>> 1) To whom would I suggest minor changes to the available installation
>> instructions to help avoid future such misunderstandings?
> 
> You can raise on issue on Github. Or even better raise a PR with your
> suggested changes. However, as it so happens the Windows instructions
> have very recently been significantly updated - so some of your
> suggestions may already have been included:
> 
> https://github.com/openssl/openssl/pull/12098
> 
>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>> 'x64' conflicts with target machine type 'x86'
> 
> This usually occurs when attempting to build 64-bit OpenSSL using the
> 32-bit VisualStudio tools.
> 
> Matt
> 
> 
> 
>> Could Not Find
>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>> : return code '0x2'
>> Stop.
>>
>> -Original Message-
>> From: openssl-users  On Behalf Of Matt
>> Caswell
>> Sent: Thursday, June 25, 2020 12:15 PM
>> To: openssl-users@openssl.org
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 18:32, Michael Wojcik wrote:
 From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of mhkelley2...@gmail.com
 Sent: Thursday, June 25, 2020 11:54
>>>
 Error:  'ml64' is not recognized as an internal or external command,
 operable program or batch file.
>>>
>>> It's part of Visual C. The VC-WIN64A-masm configuration
>> (Configurations/50-masm.conf) specifies it as the assembler.
>>
>> Note that using masm to compile OpenSSL is no longer supported by us
>> (although it might still work).
>>
>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>
>> If you use the Developer Studio command prompt (64-bit) it should have
>> all the environment variables set up already to find the various VS tools.
>>
>> Matt
>>
>>
>>>
 Building with Visual Studio  2019 Community
>>>
>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>> maybe it's part of some optional component?
>>>
>>> In VS2017 Professional, which is what I have configured at the moment on
>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>> to VS's gratuitously complicated directory layout.
>>>
>>> --
>>> Michael Wojcik
>>> Distinguished Engineer, Micro Focus
>>>
>>>
>>>
>>
> 

Re: server key exchange signature behavior

[Jan Just Keijser]

On 25/06/20 20:02, Bruce Cloutier wrote:

I agree that I am not being explicit regarding my terminology. I don't
mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
need to reach out.

Specifically, the Signature covering the EC Diffe-Hellman Server Params
in the server_key_exchange message that I eventually receive in making
an outgoing client connection from my TLS implementation, does not
decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
That is happening with this one server installation using Apache in a
Bitnami stack (Windows machine). My TLS code is running as part of the
operating system on our separate single board computer controller (JNIOR).

I use the public key extracted from the supplied certificate to decrypt
and then compare the calculated hash. This procedure has been successful
(and signatures verify/validate/match) in every other connection attempt
to other servers (including google.com). It also works with this Apache
server before we move away from the default key and certificate files.
Basically, our server is using some other key for this. Maybe still the
default. After we point configuration to a new certificate and key.

Yeah, I had at first thought that there was an intrusion. But in testing
with a clean sandboxed server we see the same results. Yes, it is most
likely an Apache configuration issue but, we've dug through all of that
and nothing jumps out.

So either we haven't configured every possible corner of this Apache
server correctly, or there is some odd extension to TLS that I've
missed. But as you all know, debugging in this area is difficult.

jnior.com is obviously public and we need to know if we have it
improperly configured. But, I need to know why in this one instance my
TLS implementation fails. In either case, it is an symptom that
shouldn't be ignored as you would agree.

The good news is that if there were an OpenSSL bug somewhat associated
with this, you all would have already mentioned it (I assume).



I'd suggest to run something like wireshark and capture the TLS 
handshake - if I do that against jnior.com I see that the jnior.com 
certificate has a X509 cert extension unknown to my rather old Wireshark 
version, but that should not matter much. Wireshark will give you 
detailed info about the EC Diffie-Hellman Server Params that were sent 
over the wire, including the signature. Wireshark does not indicate any 
problems there, although I am not sure if it *would* , if there was a 
problem.


However, it will give you an easy method to see what wireshark thinks 
the signature is compared to what your code thinks the signature is.


As a side-remark: I did notice your server cert is using 3072 bit RSA 
whereas the CAs are based on 2048bit RSA - nothing wrong with that, but 
do make sure your code can handle that (under normal circumstances it 
would not be an issue).


HTH,

JJK


On 6/25/20 1:32 PM, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Bruce Cloutier
Sent: Thursday, June 25, 2020 12:10

By "If OpenSSL fails to validate this particular digital signature that
would be the case." I meant to question whether or not OpenSSL is in
fact doing the validation? In the case that the signature is being
ignored then clients wouldn't complain. They wouldn't notice.

s_client should be verifying the signature.[1] That is, it should be verifying 
every signature that's part of the actual TLS protocol. I admit it's not 
entirely clear to me which signature isn't being verified successfully by your 
client.


[1] I'm not sure "validate" is the proper term here, technically speaking. In my experience, the 
literature usually uses "verify" for confirming a signature. "Validate" is generally used 
for more complex protocols, such as certificate validation, which involves a large number of steps with 
various types of checks.

--
Michael Wojcik
Distinguished Engineer, Micro Focus