RE: Error building OpenSSL-1.1.1g

[mhkelley2017]

Thank you.  I suspected as much.

Can someone point me to sources of information about how to resolve this issue? 
 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.

A few points that may be useful and then two specific questions.

1. I program exclusively for a Windows environment.  Most of what I develop 
should be portable, but it as almost exclusively for my own use, which is 
presently almost exclusively Windows.  I *may* at some future point go back to 
Linux, but not yet.

2. I have never used (or seen need to use) Visual Studio.  I downloaded a copy 
specifically to get this package installed.  I attempted to install for 64-bit 
use.   But it is not entirely clear to me to know which pars are actually being 
used.  Usually, I would have just used Mingw-w64 along with Windows ports of 
the standard complement of UNIX tools.  While I do have access to Cygwin, my 
preference is to either stick with Windows or make t full change back to UNIX.

3. I have built and installed a significant number of software packages, so am 
not really a newbie, but there are clear gaps in my knowledge and experience.

4. Before installing Visual Studio, 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.

THE SPECIFIC QUESTIONS:

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?

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

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: Error building OpenSSL-1.1.1g

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> mhkelley2...@gmail.com
> Sent: Thursday, June 25, 2020 14:20

> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'x86'

For some reason - I can't tell based on what you sent - your build has told the 
linker to output a 32-bit DLL instead of a 64-bit one. This object is 64-bit, 
and you appear to be trying to build the 64-bit DLL, but the linker thinks it's 
linking for 32-bit.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

Re: Error building OpenSSL-1.1.1g

[Matt Caswell]

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: Error building OpenSSL-1.1.1g

[mhkelley2017]

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?
2) A subsequent fatal error (should this also be submitted as a new
thread?):

Could Not Find
c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.

*** build output ***
cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I "."
/I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ"
-D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
-D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
-D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM"
-D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM"
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
-D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix-
seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes "ms\uplink.c" 2>&1 >
ms\uplink.d
"C:\Perl64\bin\perl.exe" "util\mkdef.pl" crypto 32 > libcrypto.def
IF EXIST .manifest DEL /F /Q .manifest
IF EXIST libcrypto-1_1-x64.dll DEL /F /Q libcrypto-1_1-x64.dll
link /nologo /debug /dll  /nologo /debug  /implib:libcrypto.lib
/out:libcrypto-1_1-x64.dll /def:libcrypto.def
@C:\Users\Owner\AppData\Local\Temp\nm26DC.tmp || (DEL /Q libcrypto-1_1-x64.*
libcrypto.lib && EXIT 1)
crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
'x64' conflicts with target machine type 'x86'
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: Private CA client cert file for iPad for a website

[Tom Browder]

On Thu, Jun 25, 2020 at 10:18 Dirk-Willem van Gulik 
wrote:

> On 25 Jun 2020, at 17:14, Tom Browder  wrote

...

> > Can anyone tell me how to generate an acceptable client cert for an iPad?

...

> Have a play with https://interop.redwax.eu/rs/scep/


Thanks, Dw, that looks like exactly what I'm looking for for Apple devices!

-Tom

Re: Error building OpenSSL-1.1.1g

[Matt Caswell]

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

[Bruce Cloutier]

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).

Bruce

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

RE: Error building OpenSSL-1.1.1g

[Michael Wojcik]

> 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.

> 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

[Michael Wojcik]

> 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

Re: server key exchange signature behavior

[Jakob Bohm via openssl-users]

You may also check out the results of the popular ssllabs.com test here:

https://www.ssllabs.com/ssltest/analyze.html?d=jnior.com=on

Note however that in recent years they have become quite aggressive in
labeling things as "weak" when they are simply "slightly less than the
best that the latestbig-brand browsers support" with no consideration
for servers that try to provide compatibility for older clients in
addition to the latest hype.

As for the signature on the key exchange in SSL3/TLS1.0/TLS1.1/TLS 1.2
and the final signature in TLS1.3, those are the one signature that
causes the certificates to do anything meaningful, so I would expect all
but the most crappy clients to check it and make a very serious error
message "SOMEONE IS HACKING YOUR CONNECTION, PULL THE PLUG NOW!" or
something equally serious.

On 2020-06-25 19:09, Bruce Cloutier wrote:

Sorry,

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.

Bruce

On 6/25/20 1:04 PM, Bruce Cloutier wrote:

Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding
the wrong key. Just need confirmation that there isn't a default key
configuration setting for OpenSSL that might be taking precedence for
who knows why.

I can connect successfully with the browser so I cannot rule out that my
TLS implementation is faulty. However, it validates with every other
site and it validates with the default install of this bitnami stack.
Once we reconfigure for the new key and certificate, this signature in
the server_key_exchange message fails. Nothing else seems to complain.
My code does, well, because I know that I actually do verify that
signature against the supplied certificate.

So to everyone else it appears that we have configured the new
certificates properly (manually achieved Let's Encrypt cert). If OpenSSL
fails to validate this particular digital signature that would be the
case. If in my TLS implementation I skip this check (actually now I just
post a warning) everything negotiates and proceeds just fine.

Obviously, THAT signature is there for a reason. I should expect if to
validate. Just don't know what key it is using?

I am not sure how to get to the Apache people or, might be, the Bitnami
folks?

Bruce

On 6/25/20 12:07 PM, Michael Wojcik wrote:

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

Has anyone thought about this question?

 From your description, it sounds like an Apache issue, not an OpenSSL one. I 
don't know enough about Apache configuration to comment. (I've configured a few 
Apache instances in my day, but never had any real issues with it, so I've 
never done more than search the docs for what I needed and implemented it.)


The site is https://jnior.com if
anyone wants to hit it. For me the digital signature in the
server_key_exchange does not verify.

I just tried openssl s_client, and it didn't complain about anything. 
Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the 
chain.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: server key exchange signature behavior

[Bruce Cloutier]

Sorry,

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.

Bruce

On 6/25/20 1:04 PM, Bruce Cloutier wrote:
> Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding
> the wrong key. Just need confirmation that there isn't a default key
> configuration setting for OpenSSL that might be taking precedence for
> who knows why.
>
> I can connect successfully with the browser so I cannot rule out that my
> TLS implementation is faulty. However, it validates with every other
> site and it validates with the default install of this bitnami stack.
> Once we reconfigure for the new key and certificate, this signature in
> the server_key_exchange message fails. Nothing else seems to complain.
> My code does, well, because I know that I actually do verify that
> signature against the supplied certificate.
>
> So to everyone else it appears that we have configured the new
> certificates properly (manually achieved Let's Encrypt cert). If OpenSSL
> fails to validate this particular digital signature that would be the
> case. If in my TLS implementation I skip this check (actually now I just
> post a warning) everything negotiates and proceeds just fine.
>
> Obviously, THAT signature is there for a reason. I should expect if to
> validate. Just don't know what key it is using?
>
> I am not sure how to get to the Apache people or, might be, the Bitnami
> folks?
>
> Bruce
>
> On 6/25/20 12:07 PM, Michael Wojcik wrote:
>>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>>> Bruce Cloutier
>>> Sent: Thursday, June 25, 2020 10:11
>>>
>>> Has anyone thought about this question?
>> From your description, it sounds like an Apache issue, not an OpenSSL one. I 
>> don't know enough about Apache configuration to comment. (I've configured a 
>> few Apache instances in my day, but never had any real issues with it, so 
>> I've never done more than search the docs for what I needed and implemented 
>> it.)
>>
>>> The site is https://jnior.com if
>>> anyone wants to hit it. For me the digital signature in the
>>> server_key_exchange does not verify.
>> I just tried openssl s_client, and it didn't complain about anything. 
>> Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified 
>> the chain.
>>
>> --
>> Michael Wojcik
>> Distinguished Engineer, Micro Focus
>>
>>
>>
-- 
Sent using Thunderbird on Ubuntu 16.04LTS




signature.asc
Description: OpenPGP digital signature

Re: server key exchange signature behavior

[Bruce Cloutier]

Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding
the wrong key. Just need confirmation that there isn't a default key
configuration setting for OpenSSL that might be taking precedence for
who knows why.

I can connect successfully with the browser so I cannot rule out that my
TLS implementation is faulty. However, it validates with every other
site and it validates with the default install of this bitnami stack.
Once we reconfigure for the new key and certificate, this signature in
the server_key_exchange message fails. Nothing else seems to complain.
My code does, well, because I know that I actually do verify that
signature against the supplied certificate.

So to everyone else it appears that we have configured the new
certificates properly (manually achieved Let's Encrypt cert). If OpenSSL
fails to validate this particular digital signature that would be the
case. If in my TLS implementation I skip this check (actually now I just
post a warning) everything negotiates and proceeds just fine.

Obviously, THAT signature is there for a reason. I should expect if to
validate. Just don't know what key it is using?

I am not sure how to get to the Apache people or, might be, the Bitnami
folks?

Bruce

On 6/25/20 12:07 PM, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>> Bruce Cloutier
>> Sent: Thursday, June 25, 2020 10:11
>>
>> Has anyone thought about this question?
> From your description, it sounds like an Apache issue, not an OpenSSL one. I 
> don't know enough about Apache configuration to comment. (I've configured a 
> few Apache instances in my day, but never had any real issues with it, so 
> I've never done more than search the docs for what I needed and implemented 
> it.)
>
>> The site is https://jnior.com if
>> anyone wants to hit it. For me the digital signature in the
>> server_key_exchange does not verify.
> I just tried openssl s_client, and it didn't complain about anything. 
> Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified 
> the chain.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
-- 
Sent using Thunderbird on Ubuntu 16.04LTS




signature.asc
Description: OpenPGP digital signature

Error building OpenSSL-1.1.1g

[mhkelley2017]

Error:  'ml64' is not recognized as an internal or external command,

operable program or batch file.

 

Platform: Windows 10

Intended context for use: Mingw-64, Qt 5.15

Building with Visual Studio  2019 Community

Perl: ActivePerl 5.24.3 Build_2404 (64-bit)

 

Configuration commands:

perl Configure VC-WIN64A-masm --prefix=%PREFIX%

 

Error output:

 

cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I "."
/I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ"
-D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
-D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
-D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM"
-D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM"
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
-D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix-
seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
"crypto\aes\aes_wrap.c" 2>&1 > crypto\aes\aes_wrap.d

set ASM=ml64

"C:\Perl64\bin\perl.exe" "crypto\aes\asm\aesni-mb-x86_64.pl" masm
crypto\aes\aesni-mb-x86_64.asm

ml64  /c /Cp /Cx /nologo /Zi /Focrypto\aes\aesni-mb-x86_64.obj
"crypto\aes\aesni-mb-x86_64.asm"

'ml64' is not recognized as an internal or external command,

operable program or batch file.

NMAKE : fatal error U1077: 'ml64' : 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.

 

Initial build output:

 

Configuring OpenSSL version 1.1.1g (0x1010107fL) for VC-WIN64A-masm

Using os-specific seed configuration

Creating configdata.pm

Creating makefile

 

**

******

***   OpenSSL has been successfully configured ***

******

***   If you encounter a problem while building, please open an***

***   issue on GitHub   ***

***   and include the output from the following command:   ***

******

***   perl configdata.pm --dump***

******

***   (If you are new to OpenSSL, you might want to consult the***

***   'Troubleshooting' section in the INSTALL file first) ***

******

**

 

c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g>nmake

 

Microsoft (R) Program Maintenance Utility Version 14.26.28806.0

Copyright (C) Microsoft Corporation.  All rights reserved.

 

"C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"
"-omakefile" "include\crypto\bn_conf.h.in" > include\crypto\bn_conf.h

"C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"
"-omakefile" "include\crypto\dso_conf.h.in" > include\crypto\dso_conf.h

"C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"
"-omakefile" "include\openssl\opensslconf.h.in" >
include\openssl\opensslconf.h

"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe" /
depend && "C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe" /
_all

 

Microsoft (R) Program Maintenance Utility Version 14.26.28806.0

Copyright (C) Microsoft Corporation.  All rights reserved.

 

 

Microsoft (R) Program Maintenance Utility Version 14.26.28806.0

Copyright (C) Microsoft Corporation.  All rights reserved.

 

cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2
/I "." /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ"
-D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
-D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
-D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM"
-D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM"
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
-D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix-
seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Foapps\app_rand.obj
"apps\app_rand.c"

app_rand.c

 

*** lots of similar output before fatal error

RE: server key exchange signature behavior

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Bruce Cloutier
> Sent: Thursday, June 25, 2020 10:11
>
> Has anyone thought about this question?

From your description, it sounds like an Apache issue, not an OpenSSL one. I 
don't know enough about Apache configuration to comment. (I've configured a few 
Apache instances in my day, but never had any real issues with it, so I've 
never done more than search the docs for what I needed and implemented it.)

> The site is https://jnior.com if
> anyone wants to hit it. For me the digital signature in the
> server_key_exchange does not verify.

I just tried openssl s_client, and it didn't complain about anything. 
Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the 
chain.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

Re: [EXTERNAL] Re: Unusual certificates

[Angus Robertson - Magenta Systems Ltd]

> The second certificate seems garbaged at the 4th RDN of the 
> issuerName.
> The Base64 edition might have added or deleted some characters.

Sorry, looks like my manual word wrapping lost a character: 

-BEGIN CERTIFICATE-
MIIHbDCCBVSgAwIBAgIIO7L2MrGOOTMwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV
BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy
dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ
MBcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAyMjQyMzAwMDBaFw0yMTAy
MjMyMzAwMDBaMHUxCzAJBgNVBAYTAlBMMRAwDgYDVQQEDAdTa2ltaW5hMRcwFQYD
VQQqDA5KYWNlayBXb2pjaWVjaDEaMBgGA1UEBRMRUE5PUEwtNzQwNjAyMDgyMTQx
HzAdBgNVBAMMFkphY2VrIFdvamNpZWNoIFNraW1pbmEwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDbTjEdIL21ctkfJ88d7EQDegNo5VLyPQXNSp5emoNI
Uf/y+RiL47SrWxS/hqYLGLUlItMsA+VCyP/+Oi42nRXcsJrSZdVgqhZTaWTZca8m
FOeujXy9eVvnAlnDDeofC5zAxYoW4fQI1/aPwmJ437bHWa6NR0iXT9j0caYfK8vr
P+gLlakBJA5RV42mt4CBZMSiNNhA9KMi9UNbtqSzlPEpSJn8Vo2LWUe+yIlUcbCD
gaQ5EVi8K7U0j5BLVQfVparZGi7C50V1ZPwWsYlu7v1PKHMDXPwUzOlwZ//UrxdR
nv/AFgjLjxuS+FNvCOaiyr0EmxccLKFvqycvx6qOxFulAgMBAAGjggLyMIIC7jCB
2wYIKwYBBQUHAQMEgc4wgcswCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5G
AQQwfAYGBACORgEFMHIwNhYwaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0
b3JpdW0vUUNBMV9QRFMucGRmEwJFTjA4FjJodHRwOi8vd3d3LnNpZ2lsbHVtLnBs
L3JlcG96eXRvcml1bS9RQ0ExX1BEU1BMLnBkZhMCUEwwFQYIKwYBBQUHCwIwCQYH
BACL7EkBATATBgYEAI5GAQYwCQYHBACORgEGATBzBggrBgEFBQcBAQRnMGUwPgYI
KwYBBQUHMAKGMmh0dHA6Ly9yZXBvLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9x
Y2ExXzIwMTcuY2VyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zaWdpbGx1bS5w
bDAdBgNVHQ4EFgQUVjnQyGMfM0fhHUvao3qe2tB5ZAMwCQYDVR0TBAIwADAfBgNV
HSMEGDAWgBRC+k+GNoGdKKGeLRq1ULuqJ/KctDCB+QYDVR0gBIHxMIHuMIHrBgoq
hGgBhvg9AAADMIHcMIHZBggrBgEFBQcCAjCBzAyByUt3YWxpZmlrb3dhbnkgY2Vy
dHlmaWthdCBwb2RwaXN1IGVsZWt0cm9uaWN6bmVnbyBwb3dzdGHFgiB3IG9wYXJj
aXUgbyBQb2xpdHlrxJkgVXPFgnVnIFphdWZhbmlhIENVWiBTaWdpbGx1bS4gVHJl
xZvEhyBQb2xpdHlraSBDVVogU2lnaWxsdW0gem5hamR1amUgc2nEmSBwb2QgYWRy
ZXNlbSBodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bTBCBgNVHR8E
OzA5MDegNaAzhjFodHRwOi8vY3JsLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9x
Y2ExXzIwMTcuY3JsMA4GA1UdDwEB/wQEAwIGQDANBgkqhkiG9w0BAQsFAAOCAgEA
Jfef0HktjHsgL403s8XQggtqporvp5w2sZcQ+jCPb3h3xrztTjiUbIhw97No7u5J
5LV4pNuczzBynJYBeGQpYG/Tr37HNoCdQ+I8QfllF37O7MwCNWYbmenFjINIHogQ
utizdHRIUDP5FY+3ZmTG0ZGz4Yi0Bw+6IEvLZM8SF7Ula9Bkyu/oF5SAN/h/f0t5
3PHIkqsiWG7xRUl9aBgyO8Q72r1tiY1aqfT665nRrOewXQHik9h1Fd/XwWtYZpnG
hws8lFKGB/Dfa8BpXpx3hWdVgeUA75Spszt0Pcb0pCJyQ2x3F4VnphGv6p31VN5i
d7M+nd3kUYuKHFjxVBWgiVlgeKrCD+wvM/jqNncW6ti6uXaeLM2WBI0FpLuT5ZD2
G5gtLZ8z3wI5BZsp07gl3ARD8EybcJVmVhxpfAcBgOTCoyhGbPKYIS0fmYYCzwFL
St+I497avrAQtgDqDcCs1WlZWHts4dUudUJ8rV8uKgtVQUu0HofUZPjNPD8dJw6n
3YrVdsLleXQXKAJZCgti56lH+6eCsVs7fUNPAhnu3AHWvsBwFs/3DM3OBBXX5jtn
8miSC46ndNiq2hIsq+cvfVM4Qw57XDYgLWaINhI0QhluUqOAEDJmYitnesTfs3Ih
/CCHBWG9Yw6XkaBk8TCks/OOuo9B9PFGt5wRasty/Ls=
-END CERTIFICATE-


This now reads correctly with OpenSSL.  So the real error here was that
sometimes OpenSSL accepts unwrapped base64, and sometimes not, but
asn1parse never accepts it. 

Angus

Re: Private CA client cert file for iPad for a website

[Dirk-Willem van Gulik]

On 25 Jun 2020, at 17:14, Tom Browder  wrote:

> Can anyone tell me how to generate an acceptable client cert for an iPad?
> 
> I have so far been unable to find out the file format needed.
> 
> I generated client cert files for my classmates over seven years ago in p12 
> format and they still work fine on Linux, Mac, and Windows devices but I want 
> to (1) update all certs to modern standards and (2) add usable certs for iOS 
> and android devices as well as the existing format.
> 
> I am currently running OpenSSL 1.1.1g on Debian Buster.

Have a play with https://interop.redwax.eu/rs/scep/

Dw.

Private CA client cert file for iPad for a website

[Tom Browder]

Can anyone tell me how to generate an acceptable client cert for an iPad?

I have so far been unable to find out the file format needed.

I generated client cert files for my classmates over seven years ago in p12
format and they still work fine on Linux, Mac, and Windows devices but I
want to (1) update all certs to modern standards and (2) add usable certs
for iOS and android devices as well as the existing format.

I am currently running OpenSSL 1.1.1g on Debian Buster.

Any help would be appreciated.

Blessings,

-Tom

Re: server key exchange signature behavior

[Bruce Cloutier]

Has anyone thought about this question? The site is https://jnior.com if
anyone wants to hit it. For me the digital signature in the
server_key_exchange does not verify. Is there a site diagnostic that
might report on this? I suspect that we have not fully configured the
change in certificates. Has us stumped. Could really use a hint.

On 6/23/20 8:03 AM, Bruce Cloutier wrote:
> Hello,
>
> We administer a server (Windows) with a Bitnami stack for a Wordpress
> implementation and that uses Apache Httpd and OpenSSL. Separately I am
> developing the TLS ECC aspect of a controller device implementation and
> note a problematic behavior with the server_key_exchange for ECDHE_RSA.
> The developed device ECDHE_RSA suite works properly and as expected with
> all of the other servers thus far tested. There is likely a
> configuration issue with this Apache installation and I am fishing for a
> hint.
>
> The issue is that the RSA signature as part of the server_key_exchange
> does not decrypt with the supplied certificate public RSA key. It does
> indicate an rsa_pkcs1_sha256 signature.
>
> With a fresh Bitnami install that still uses the default key and
> certificate files, the protocol provides a valid digital signature. When
> we change the server's certificate (and confirm this with the browser)
> the server_key_exchange signature no longer validates. It is as if the
> server continues to use the default key for the signature. I have not
> tried to confirm that specific point.
>
> My immediate question for someone close to the code is where does
> Apache/OpenSSL look for the key file for this signature at this point in
> the protocol?
>
> I am hoping that there is just some additional configuration location
> that needs to be given our new key file and/or certificate. Can anyone
> confirm?
>
> We noted this concern on a production server. We then installed the
> stack on a different machine to confirm the fresh install operation. In
> adding different key and certificate files we confirm that the signature
> then fails. If I ignore the bad signature the secure communications
> succeed.
>
> I have been searching the net for this issue for weeks. That has been
> fruitless. So I am turning to this list.
>
> Bruce
>
>
>
-- 
Sent using Thunderbird on Ubuntu 16.04LTS




signature.asc
Description: OpenPGP digital signature

Re: Unusual certificates

[Jakob Bohm via openssl-users]

On 2020-06-25 13:25, Hubert Kario wrote:
On Thursday, 25 June 2020 12:15:00 CEST, Angus Robertson - Magenta 
Systems Ltd wrote:

A client is having problems reading Polish Centum issued personal
certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier,
mostly.
Using PEM_read_bio_X509 with some of these certificates says
error::lib(0):func(0):reason(0), while the X509 command line
tool says 'unable to load certificate'.  Some certificates work with
both methods.

Using the asn1parse command from any version of OpenSSL says 'Error:
offset out of range', while a Javascript based web tool is able to
decode the ASN1, but is perhaps more tolerant of errors.
So it seems there is something in the creation of these certificates
that OpenSSL has never liked, but until 1.1.1 was tolerated
sufficiently to allow them to be read.
This certificate reads OK in 1.1.1 but fails asn1parse:


works just fine for me with 1.1.1g


This certificate can not be read in 1.1.1 but is OK in 1.1.0.


but this one fails parsing



Is there a more tolerant way to read ASN1 than the asn1parse command? 


asn1parse expects BER encoding, that already is the most lenient, while
still standards-compliant, encoding that is supported.

Given that it errors out with
139628293990208:error:0D07209B:asn1 encoding 
routines:ASN1_get_object:too long:crypto/asn1/asn1_lib.c:91:

I'm guessing a mismatch between utf-8 and string encoding that makes
the lengths inconsistent. Some tools may just ignore them, but that 
doesn't

make the certificate well-formed.
I have tried examining these two certificates with Peter Gutmann's 
dumpasn1.c

and a generic hex dumper.

For the second certificate, dumpasn1.c complains about a badly encoded 
SET at

file offset 0x8E (after Base64 decoding):

0008E   31 19
00090 05 c1 80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c
000A0 8d 4c 0c 0c 0c 4c 0e 4c 0c
000A9                            07 85 c3 4c 4e 4c 0c

My manual attempt to recover from this results in the following
further failures:

Attempt1: Straight BER/DER:
SET {
  NULL-object of a very huge length: The number of bytes is
    0x80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c 8d 4c
      0c 0c 0c 4c 0e 4c 0c 07 85 c3 4c 4e 4c 0c 8c 8d
      0c 8c cc 0c 0c 0c 16 85 c3 4c 8c 4c 0c 8c 8c cc
      8c cc 0c 0c 0c 16 8c 1d 4c 42 cc 02 41 80 d5 41
      01
    -- ERROR: This runs beyond end-of-file
    -- ERROR: This runs beyond end-of-SET (0x19 bytes)
}

Attempt2: Assume length byte for zero length NULL object omitted:
SET { NULL-object with missing length-encoding of its zero length
  private-tag-1 object with indefinite length
    -- ERROR: This runs beyond end-of-SET (0x19 bytes)
}

Attempt3: Treat SET as an opaque blob
SET { -- Contents ignored }
ObjectDescriptor of length 0x151CC bytes
  -- ERROR: This runs beyond end-of-file

Attempt4: Treat preceding string as encoded with length 1 too small
SET {
  SEQUENCE {
    OBJECT IDENTIFIER commonName -- 2.5.4.3
    UTF8String 'CUZ Sigillum - QCA11'
      -- WARNING: One byte beyond declared length of containing SEQUENCE
  }
    -- WARNING: One byte beyond declared length of containing SET
}
GraphicString '\c1\80\d5\41\18'
Application-tag-3 object of length 4 bytes: 0x15 90 55 14
PrintableString 4d 4c 8d 4c 0c 0c 0c 4c 0e 4c 0c
  -- WARNING: Bad characters
ObjectDescriptor of length 0x151CC bytes
  -- ERROR: This runs beyond end-of-file
  -- WARNING: This runs beyond length of containing DN (0x80 bytes)

Attempt5: Treat preceding string as encoded with length 2 too small
SET {
  SEQUENCE {
    OBJECT IDENTIFIER commonName -- 2.5.4.3
UTF8String 'CUZ Sigillum - QCA11\19'
      -- WARNING: 2 bytes beyond declared length of containing SEQUENCE
  }
    -- WARNING: 2 bytes beyond declared length of containing SET
 }
NULL-object of a very huge length: The number of bytes is
  0x80 d5 41 18 43 04 15 90 55 14 13 0b 4d 4c 8d 4c
    0c 0c 0c 4c 0e 4c 0c 07 85 c3 4c 4e 4c 0c 8c 8d
    0c 8c cc 0c 0c 0c 16 85 c3 4c 8c 4c 0c 8c 8c cc
    8c cc 0c 0c 0c 16 8c 1d 4c 42 cc 02 41 80 d5 41
    01
  -- ERROR: This runs beyond end-of-file
  -- WARNING: This runs beyond length of containing DN (0x80 bytes)

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: openssl with Rust

[Jan Danielsson]

On 2020-06-24 10:23, Richard Levitte wrote:
> I have very little knowledge of Rust...  however, there seems to exist
> an openssl crate available already:  https://docs.rs/openssl/0.10.29/openssl/
> 
> Does that help?

   The OP mentioned using "the openssl crate", so I don't think that's
the problem.

   This is kind of a known issue.  On unixy platforms there are plenty
of common, known, ways to find libraries and headers (common locations,
pkg-config, etc).  Windows have no such common mechanisms[*].

   Some crate developers are aware of these issues so they support
building a static library stored locally for the crate.  For instance,
rusqlite supports building its own sqlite3 library, which helps a lot on
Windows.  The problem with OpenSSL is that the build system needs perl.
 This could in theory be solved by build.rs downloading a portable
version of perl, etc.

   Anyway -- this is an openssl crate issue, and not related to the
openssl project itself.


   But I will add:  I suspect the openssl project will be getting more
and more questions about the openssl Rust crate.  Probably a good idea
to have a nice copy/paste reply ready.  And regarding this:


   [*] There is one potential solution to this: vcpkg.  Some crates try
to use vcpkg to find dependencies.  I suggest the OP checks into whether
building openssl with vcpkg will help.  (The openssl crate would need to
be one of the crates that actually supports vcpkg, and I'm unsure if
that is the case.  If it isn't then someone should probably file an
issue with the crate owner about that).



> 
> Cheers,
> Richard
> 
> On Tue, 23 Jun 2020 23:38:38 +0200,
> Ken Goldman wrote:
>>
>> Environment is Windows, Visual Studio Code, the Shining Light openssl
>> build and the openssl crate.
>>
>> Does anyone have experience getting this to link?
>>
>> Environment variables?
>> cargo.toml
>> anything else?
>>


-- 
Kind Regards,
Jan

Re: [EXTERNAL] Re: Unusual certificates

[Erwann Abalea via openssl-users]

The second certificate seems garbaged at the 4th RDN of the issuerName.
The Base64 edition might have added or deleted some characters.

Cordialement,
Erwann Abalea

Le 25/06/2020 16:00, « openssl-users au nom de Angus Robertson - Magenta 
Systems Ltd »  
a écrit :

More information, the original certificates supplied by the end user
had unwrapped base64 blocks, lines 2,500 long.  I wrapped them for
email.  

If I try the asn1parse command on the wrapped certificates, they now
attempt to parse, the OK is fine, the bad one now gives an error
message from asn1parse:

Error in encoding
20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too
long:crypto\asn1\asn1_lib.c:91:

and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode
from PEM_read_bio_X509.  

The RFC says 'Parsers MAY handle other line sizes' but it would be good
if OpenSSL gave a 'PEM line too long' error rather than no error.  I'll
change my library code to check for line ending in the base64 to give
the user a polite message.  

Now the only problem is what is asn1 decoding unhappy with?

Angus

Re: Monolith compile verify.c

[Michael Mueller]

Thank you so much for the replies. I appreciate the effort, time, and
detail.

Turns out the warning is created by:
-Wextra

Only occurs in the older compiler (which we are required to use).

Removing the compiler flag worked.

Thanks again,
Mike

On Thu, Jun 25, 2020, 9:42 AM Michael Wojcik 
wrote:

> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of
> > Matt Caswell
> > Sent: Thursday, June 25, 2020 04:51
> >
> > On 24/06/2020 20:20, Michael Mueller wrote:
> > >
> > > Questions
> > >
> > > 1. Is the fix valid?
> >
> > Seems ok, but it looks like the compiler warning is a bit over zealous.
>
> It's valid, but I'd argue it's not a "fix".
>
> As Rich Salz pointed out, omitting initializers is permitted by the C
> standard. In fact it's endorsed, in the sense that the standard makes this
> behavior explicit (see e.g. ISO 9899-1999 6.7.8 #21 for arrays, or in the
> case of subobjects #19), and the Rationale (I'm referring to 5.10,
> published 2003) does not discourage its use, as it does for e.g. omitting
> braces for compound object initializers and relying on the mandated
> top-down-parse semantics.
>
> In his monumental /The New C Standard: An Economic and Cultural
> Commentary/ (2005), Derek M. Jones comments on this aspect of the language
> by noting some costs involved in requiring all members be explicitly
> initialized, and concludes: " Given these costs and the fact that
> developers are generally aware of the default behavior, there does not
> appear to be a worthwhile benefit in a guideline recommending that the
> behavior be made explicit." (1669) The GCC developers (like all C
> implementors) would have done well to read Jones.
>
> > We have the same pattern in many parts of the code I think without
> problems.
>
> Yes, as it should be.
>
> > > 2.  If fix is valid, what are the chances of getting the change
> accepted?
> >
> > Doubtful.
>
> And I'd say that's appropriate. Some of the GCC developers would prefer
> programmers use a language which is similar to, but distinctly not C,
> eschewing useful constructs and employing various others which are not part
> of the C language. OpenSSL is written in C.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>

OpenSSL version 3.0.0-alpha4 published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


   OpenSSL version 3.0 alpha 4 released
   

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 3.0 is currently in alpha.

   OpenSSL 3.0 alpha 4 has now been made available.

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well
   as known issues are available on the OpenSSL Wiki, here:

https://wiki.openssl.org/index.php/OpenSSL_3.0

   The alpha release is available for download via HTTPS and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-3.0.0-alpha4.tar.gz
  Size: 13884897
  SHA1 checksum:  056194ea4ec57234ce3cb16b944d99c4d2a8b650
  SHA256 checksum:  
d930b650e0899f5baca8b80c50e7401620c129fef6c50198400999776a39bd37

   The checksums were calculated using the following commands:

openssl sha1 openssl-3.0.0-alpha4.tar.gz
openssl sha256 openssl-3.0.0-alpha4.tar.gz

   Please download and check this alpha release as soon as possible.
   To report a bug, open an issue on GitHub:

https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl70rYcACgkQ2cTSbQ5g
RJFWeAf/ZOGaHZbcAUy9Xm/R8x56qPJWD+3D8qGOgjNgKc/5r3kXII3I7NH7lc1j
zFSt/FA9NhqU7dIh/8/SlyZaBbFW/XZBRiczDqRSqAkAfsxhlj5tOq8xZoXuTqlN
it3DICC96jgh2xGo3LJUPgY1o0evsPLX98L/BtRZcZMcZed0ImZEEmJra3vEDr7H
C+Hu4/+gNDlAISDENSDygAE8vDB5hBDmk0YCySPKZpDbWPdV2/WF8oBlgRpNBjY+
zbk/V32xZkhf/x/nhRGNs44CJI8ymsDtp6UyV2e7ZW6LZNMGX7l0M8ZuJvLTFJJM
ZqQo7Xhn1EFdIRwTd+B2CvY2k73Pzw==
=khAk
-END PGP SIGNATURE-

Re: Unusual certificates

[Angus Robertson - Magenta Systems Ltd]

More information, the original certificates supplied by the end user
had unwrapped base64 blocks, lines 2,500 long.  I wrapped them for
email.  

If I try the asn1parse command on the wrapped certificates, they now
attempt to parse, the OK is fine, the bad one now gives an error
message from asn1parse:

Error in encoding
20236:error:0D07209B:asn1 encoding routines:ASN1_get_object:too
long:crypto\asn1\asn1_lib.c:91:

and error:09091064:PEM routines:PEM_read_bio_ex:bad base64 decode
from PEM_read_bio_X509.  

The RFC says 'Parsers MAY handle other line sizes' but it would be good
if OpenSSL gave a 'PEM line too long' error rather than no error.  I'll
change my library code to check for line ending in the base64 to give
the user a polite message.  

Now the only problem is what is asn1 decoding unhappy with?

Angus

RE: Monolith compile verify.c

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Matt Caswell
> Sent: Thursday, June 25, 2020 04:51
>
> On 24/06/2020 20:20, Michael Mueller wrote:
> >
> > Questions
> >
> > 1. Is the fix valid?
>
> Seems ok, but it looks like the compiler warning is a bit over zealous.

It's valid, but I'd argue it's not a "fix".

As Rich Salz pointed out, omitting initializers is permitted by the C standard. 
In fact it's endorsed, in the sense that the standard makes this behavior 
explicit (see e.g. ISO 9899-1999 6.7.8 #21 for arrays, or in the case of 
subobjects #19), and the Rationale (I'm referring to 5.10, published 2003) does 
not discourage its use, as it does for e.g. omitting braces for compound object 
initializers and relying on the mandated top-down-parse semantics.

In his monumental /The New C Standard: An Economic and Cultural Commentary/ 
(2005), Derek M. Jones comments on this aspect of the language by noting some 
costs involved in requiring all members be explicitly initialized, and 
concludes: " Given these costs and the fact that developers are generally aware 
of the default behavior, there does not appear to be a worthwhile benefit in a 
guideline recommending that the behavior be made explicit." (1669) The GCC 
developers (like all C implementors) would have done well to read Jones.

> We have the same pattern in many parts of the code I think without problems.

Yes, as it should be.

> > 2.  If fix is valid, what are the chances of getting the change accepted?
>
> Doubtful.

And I'd say that's appropriate. Some of the GCC developers would prefer 
programmers use a language which is similar to, but distinctly not C, eschewing 
useful constructs and employing various others which are not part of the C 
language. OpenSSL is written in C.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

Re: Unusual certificates

[Hubert Kario]

On Thursday, 25 June 2020 12:15:00 CEST, Angus Robertson - Magenta Systems 
Ltd wrote:

A client is having problems reading Polish Centum issued personal
certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier,
mostly.  


Using PEM_read_bio_X509 with some of these certificates says
error::lib(0):func(0):reason(0), while the X509 command line
tool says 'unable to load certificate'.  Some certificates work with
both methods.

Using the asn1parse command from any version of OpenSSL says 'Error:
offset out of range', while a Javascript based web tool is able to
decode the ASN1, but is perhaps more tolerant of errors.  


So it seems there is something in the creation of these certificates
that OpenSSL has never liked, but until 1.1.1 was tolerated
sufficiently to allow them to be read.  


This certificate reads OK in 1.1.1 but fails asn1parse:


works just fine for me with 1.1.1g

This certificate can not be read in 1.1.1 but is OK in 1.1.0. 



but this one fails parsing



Is there a more tolerant way to read ASN1 than the asn1parse command? 


asn1parse expects BER encoding, that already is the most lenient, while
still standards-compliant, encoding that is supported.

Given that it errors out with
139628293990208:error:0D07209B:asn1 encoding routines:ASN1_get_object:too 
long:crypto/asn1/asn1_lib.c:91:

I'm guessing a mismatch between utf-8 and string encoding that makes
the lengths inconsistent. Some tools may just ignore them, but that doesn't
make the certificate well-formed.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

Unusual certificates

[Angus Robertson - Magenta Systems Ltd]

A client is having problems reading Polish Centum issued personal
certificates with OpenSSL 1.1.1, which read OK with 1.1.0 and earlier,
mostly.  

Using PEM_read_bio_X509 with some of these certificates says
error::lib(0):func(0):reason(0), while the X509 command line
tool says 'unable to load certificate'.  Some certificates work with
both methods.

Using the asn1parse command from any version of OpenSSL says 'Error:
offset out of range', while a Javascript based web tool is able to
decode the ASN1, but is perhaps more tolerant of errors.  

So it seems there is something in the creation of these certificates
that OpenSSL has never liked, but until 1.1.1 was tolerated
sufficiently to allow them to be read.  

This certificate reads OK in 1.1.1 but fails asn1parse:

-BEGIN CERTIFICATE-
MIIHXjCCBUagAwIBAgIIbBjyWVjJUvcwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV
BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy
dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ
MBcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAzMTkwODUxMDBaFw0yMTAz
MTgwODUxMDBaMGcxCzAJBgNVBAYTAlBMMREwDwYDVQQEDAhEWklFRFpJQzEPMA0G
A1UEKgwGUkFGQcWBMRowGAYDVQQFExFQTk9QTC03NDExMDMwMDQ3MTEYMBYGA1UE
AwwPUkFGQcWBIERaSUVEWklDMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAm94BNi+bv2+oUKzN27GV0+95sm1AuDKdiKw7M63HcnjL+YYLoQvhleD7KlZR
7ntZfJ05vpWpQWM0Pt54M1Y8sJQObg+tUDlulVi7nADOrUNb3Tgctq1vbou3OpIp
xaQUtC9qNpQbGXkgJRr09/nh5h09n4vgsvtS6cKlFfMe/o6xtUeWPYm+oVoAq5sG
in+aBSBdnd73v053kbdZcbDPXmOYuCr6O2MHi7p+McPg2KMJy+wfFX4SGSBJIAY2
Owt6mnIOCU6Y/dAUcbUDtNUTwq+gXL+zg7TdwkDDTohpnluNGfrYV5JYocHO63zo
3W/CyF/enCmNiC9QLakA22O04QIDAQABo4IC8jCCAu4wgdsGCCsGAQUFBwEDBIHO
MIHLMAgGBgQAjkYBATALBgYEAI5GAQMCAQowCAYGBACORgEEMHwGBgQAjkYBBTBy
MDYWMGh0dHA6Ly93d3cuc2lnaWxsdW0ucGwvcmVwb3p5dG9yaXVtL1FDQTFfUERT
LnBkZhMCRU4wOBYyaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0v
UUNBMV9QRFNQTC5wZGYTAlBMMBUGCCsGAQUFBwsCMAkGBwQAi+xJAQEwEwYGBACO
RgEGMAkGBwQAjkYBBgEwcwYIKwYBBQUHAQEEZzBlMD4GCCsGAQUFBzAChjJodHRw
Oi8vcmVwby5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0vcWNhMV8yMDE3LmNlcjAj
BggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2lnaWxsdW0ucGwwHQYDVR0OBBYEFDFY
5Q2FMMXaCpCyXFmUT2qgyA0JMAkGA1UdEwQCMAAwHwYDVR0jBBgwFoAUQvpPhjaB
nSihni0atVC7qifynLQwgfkGA1UdIASB8TCB7jCB6wYKKoRoAYb4PQAAAzCB3DCB
2QYIKwYBBQUHAgIwgcwMgclLd2FsaWZpa293YW55IGNlcnR5ZmlrYXQgcG9kcGlz
dSBlbGVrdHJvbmljem5lZ28gcG93c3RhxYIgdyBvcGFyY2l1IG8gUG9saXR5a8SZ
IFVzxYJ1ZyBaYXVmYW5pYSBDVVogU2lnaWxsdW0uIFRyZcWbxIcgUG9saXR5a2kg
Q1VaIFNpZ2lsbHVtIHpuYWpkdWplIHNpxJkgcG9kIGFkcmVzZW0gaHR0cDovL3d3
dy5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0wQgYDVR0fBDswOTA3oDWgM4YxaHR0
cDovL2NybC5zaWdpbGx1bS5wbC9yZXBvenl0b3JpdW0vcWNhMV8yMDE3LmNybDAO
BgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggIBACQ+ancYPWmfVDB/PTrV
D+nK8TX2HPcbgk/JrGJF0vaL+l9gTprg+3yMlfpcQfBXBsm7RwOEAK8LgaaFb7Ta
WPD1635RoGaIZ36k6WgENUjFjANya3RIRSzcOjgpeQWc6SeA++NJjQFNh7J73LMG
V5udFwpVug5yzP+LTlZZ/hoY2rN9xmY7QBn/cbgoNieRyUHbxq4zGifiJoVfKEiT
Fxl/CoUfnngxsVIsvgxFmGdnMT2j0oBODKoXJ1A8oJAcg8KnYTzI7Dnt3a5cGypv
n6V6tGv0IbHxdFu8nnsyNOSp1YhqTcfRzUGXf9NHyj6vyX4UR2ODJPccWC0uSufW
9KYio228yqj0IERG2mr8huJEBW/MEE3STmxT3R6a1OCAsVAPi3gL2yAXfn3Gdiam
MLhj/WO3OD9OyiHqTY6+/md4vOHkHy7GnKlYIJblddtziv8ek9uH/imbOQIKDjLN
Bvw3j9a55GHT/8+fow2vn31OmSfMWvikP4pntEvuMAwG2laTs19+gWdknt4Q3ma5
NTf9UnbQsFJAcW+gw3QWAmts5fZsQT806OyDvjt6jRlkmuIkeYRcYJ/E2Pg9oKx3
RiCIA1BQTImpYvbTJg9Q1DYQpbDGxDB9ENJDAyMNSIs85nBLvrri4rD6FC4Bz/m/
Og4GfIWH02DKEKBds/zPi+L5
-END CERTIFICATE-

This certificate can not be read in 1.1.1 but is OK in 1.1.0. 

-BEGIN CERTIFICATE-
MIIHbDCCBVSgAwIBAgIIO7L2MrGOOTMwDQYJKoZIhvcNAQELBQAwgYAxCzAJBgNV
BAYTAlBMMTgwNgYDVQQKDC9Qb2xza2EgV3l0d8Ozcm5pYSBQYXBpZXLDs3cgV2Fy
dG/Fm2Npb3d5Y2ggUy5BLjEcMBoGA1UEAwwTQ1VaIFNpZ2lsbHVtIC0gUUNBMTEZ
BcGA1UEYQwQVkFUUEwtNTI1MDAwMTA5MDAeFw0xOTAyMjQyMzAwMDBaFw0yMTAyM
jMyMzAwMDBaMHUxCzAJBgNVBAYTAlBMMRAwDgYDVQQEDAdTa2ltaW5hMRcwFQYDV
QQqDA5KYWNlayBXb2pjaWVjaDEaMBgGA1UEBRMRUE5PUEwtNzQwNjAyMDgyMTQxH
zAdBgNVBAMMFkphY2VrIFdvamNpZWNoIFNraW1pbmEwggEiMA0GCSqGSIb3DQEBA
QUAA4IBDwAwggEKAoIBAQDbTjEdIL21ctkfJ88d7EQDegNo5VLyPQXNSp5emoNIU
f/y+RiL47SrWxS/hqYLGLUlItMsA+VCyP/+Oi42nRXcsJrSZdVgqhZTaWTZca8mF
OeujXy9eVvnAlnDDeofC5zAxYoW4fQI1/aPwmJ437bHWa6NR0iXT9j0caYfK8vrP
+gLlakBJA5RV42mt4CBZMSiNNhA9KMi9UNbtqSzlPEpSJn8Vo2LWUe+yIlUcbCDg
aQ5EVi8K7U0j5BLVQfVparZGi7C50V1ZPwWsYlu7v1PKHMDXPwUzOlwZ//UrxdRn
v/AFgjLjxuS+FNvCOaiyr0EmxccLKFvqycvx6qOxFulAgMBAAGjggLyMIIC7jCB2
wYIKwYBBQUHAQMEgc4wgcswCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5GA
QQwfAYGBACORgEFMHIwNhYwaHR0cDovL3d3dy5zaWdpbGx1bS5wbC9yZXBvenl0b
3JpdW0vUUNBMV9QRFMucGRmEwJFTjA4FjJodHRwOi8vd3d3LnNpZ2lsbHVtLnBsL
3JlcG96eXRvcml1bS9RQ0ExX1BEU1BMLnBkZhMCUEwwFQYIKwYBBQUHCwIwCQYHB
ACL7EkBATATBgYEAI5GAQYwCQYHBACORgEGATBzBggrBgEFBQcBAQRnMGUwPgYIK
wYBBQUHMAKGMmh0dHA6Ly9yZXBvLnNpZ2lsbHVtLnBsL3JlcG96eXRvcml1bS9xY
2ExXzIwMTcuY2VyMCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zaWdpbGx1bS5wb
DAdBgNVHQ4EFgQUVjnQyGMfM0fhHUvao3qe2tB5ZAMwCQYDVR0TBAIwADAfBgNVH
SMEGDAWgBRC+k+GNoGdKKGeLRq1ULuqJ/KctDCB+QYDVR0gBIHxMIHuMIHrBgoqh
GgBhvg9AAADMIHcMIHZBggrBgEFBQcCAjCBzAyByUt3YWxpZmlrb3dhbnkgY2Vyd

Re: Monolith compile verify.c

[Matt Caswell]

On 24/06/2020 20:20, Michael Mueller wrote:
> 
> Questions
> 
> 1. Is the fix valid?

Seems ok, but it looks like the compiler warning is a bit over zealous.
We have the same pattern in many parts of the code I think without problems.

> 
> 2.  If fix is valid, what are the chances of getting the change accepted?

Doubtful.

Matt