openssl windows compile: VS2012 Pro vs VS2019 Community

[Michael Mueller]

Compile on Openssl 1.1.1k on W2008R2 with VS2019 Community was successful.

Compile of my app that uses openssl dlls on the same platform was successful.

"openssl.exe version" works correctly

Running my app I get "No OPENSSL_Applink"

This is new since running VS2019 compiled binaries.

I included ms\applink.c in the source list and recompiled my app. Working now.

Anyone have insight why applink.c is needed with VS2019 Community
compile and not a VS2012 Pro compile?

Should all MS apps linking the openssl dlls always have applink.c to
the sources?

Thanks for reading.
Mike

manual edit: i2d_PKCS7_bio

[Michael Mueller]

https://www.openssl.org/docs/man1.1.1/man3/i2d_PKCS7_bio.html

current:

i2d_TYPE_fp() is similar to i2d_TYPE() except it writes the encoding of the
structure a to BIO bp and it returns 1 for success and 0 for failure.

Suggested edit:

i2d_TYPE_fp() is similar to i2d_TYPE() except it writes the encoding of the
structure a to FILE pointer fp and it returns 1 for success and 0 for
failure.

 Mike

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

Monolith compile verify.c

[Michael Mueller]

I'm compiling verify.c as a monolith from 1.1.1g.

Using gcc 4.8.5 I have no problems.

Using gcc 4.3.4 I get a warning which we treat as an error:

gcc -c -Wall -Werror -Wextra -idirafter ../../inc -idirafter
../../../../OPENSSL/include/SUSE-Linux -DMONOLITH -DNO_ASN1_OLD -DLINUX -o
../../obj/verify.o ../../src/verify.c

cc1: warnings being treated as errors

../../src/verify.c:64: error: missing initializer

../../src/verify.c:64: error: (near initialization for
‘verify_options[45].retval’)



I found the source of my problem and created a fix that I could toggle when
testing with different compilers. The fix compiles cleanly with both gcc
compilers mentioned above.

I have not tried it with Visual Studio yet.


const OPTIONS verify_options[] = {

{OPT_HELP_STR, 1, '-', "Usage: %s [options] cert.pem...\n"},

{OPT_HELP_STR, 1, '-', "Valid options are:\n"},

{"help", OPT_HELP, '-', "Display this summary"},

{"verbose", OPT_VERBOSE, '-',

"Print extra information about the operations being performed."},

{"CApath", OPT_CAPATH, '/', "A directory of trusted certificates"},

{"CAfile", OPT_CAFILE, '<', "A file of trusted certificates"},

{"no-CAfile", OPT_NOCAFILE, '-',

 "Do not load the default certificates file"},

{"no-CApath", OPT_NOCAPATH, '-',

 "Do not load certificates from the default certificates directory"},

{"untrusted", OPT_UNTRUSTED, '<', "A file of untrusted certificates"},

{"trusted", OPT_TRUSTED, '<', "A file of trusted certificates"},

{"CRLfile", OPT_CRLFILE, '<',

"File containing one or more CRL's (in PEM format) to load"},

{"crl_download", OPT_CRL_DOWNLOAD, '-',

"Attempt to download CRL information for this certificate"},

{"show_chain", OPT_SHOW_CHAIN, '-',

"Display information about the certificate chain"},

{"nameopt", OPT_NAMEOPT, 's', "Various certificate name options"},

OPT_V_OPTIONS,

#ifndef OPENSSL_NO_ENGINE

{"engine", OPT_ENGINE, 's', "Use engine, possibly a hardware device"},

#endif

#if 0

{NULL, -1, 'Q', "unused end of list"} this is the change I’d like to
offer

#else

{NULL} this is the current code

#endif

};


Questions

1. Is the fix valid?

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

Thanks

Mike

Re: CMS in openssl

[Michael Mueller]

On Wed, Apr 22, 2020, 2:56 PM Michael Richardson  wrote:

>
> Michael Mueller  wrote:
> >> Michael Mueller  wrote:
> >> > We've implemented what I gather can be called a CMS on Linux and
> >> Windows
> >> > using openssl evp functions.
> >>
> >> I'm not sure why you say it this way.
> >> OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0.
> >> Did you implement RFC3369, or something else?
> >>
> >> You don't say if this is email or something else.
> >>
>
> > My bad. I thought CMS could be used as a generic reference to
> packaging
> > encrypted messages.
>
> > We are not implementing CMS as specified by IETF.
>
> > We used the openssl evp functions to quickly improve the security of
> an
> > existing proprietary data exchange system.
>
> > Now we are being asked if our evp based solution can interoperate
> with a
> > system that may support PKCS7. The thought is PKCS7 would be used to
> > envelope data in a manner similar to how the evp functions operate.
>
> I don't think you will find any compatibility.
>
> You can use the PKCS7 functions to process that kind of data.
> Or future proof and use CMS functions to read, and figure out how you will
> write/send messages
>

Today we learned that we have PKCS7 1.5 & 1.6 and RFC 3852 are available on
the "older" system.

Also was guided to CMS specs, and the CMS tools and functions in openssl.

We'll experiment with the openssl cms functions on linux and the older
system independently. If that works, we'll try interworking linux with the
older system. If that works, we'll toggle from evp to cms if the older
system is involved.

Thank you all for your help.


> > I suspect that evp functions are not compatible with PKCS7, but I
> don't
> > know how to easily confirm this. I also suspect it will be difficult
> to
> > explain why they are incompatible.
>
> > If evp and PKCS7 are incompatible, we might be asked if we can use
> PKCS7
> > enveloping instead of evp.
>
> > Any insights, thoughts, advice, code to read, etc would be
> appreciated.
>
> I think you should consider if you want to move to PKCS7.
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works|IoT
> architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>

Re: CMS in openssl

[Michael Mueller]

On Tue, Apr 21, 2020, 9:46 PM Michael Richardson  wrote:

>
> Michael Mueller  wrote:
> > We've implemented what I gather can be called a CMS on Linux and
> Windows
> > using openssl evp functions.
>
> I'm not sure why you say it this way.
> OpenSSL includes CMS (RFC3369) support, but I think not until 1.1.0.
> Did you implement RFC3369, or something else?
>
> You don't say if this is email or something else.
>

My bad. I thought CMS could be used as a generic reference to packaging
encrypted messages.

We are not implementing CMS as specified by IETF.

We used the openssl evp functions to quickly improve the security of an
existing proprietary data exchange system.

Now we are being asked if our evp based solution can interoperate with a
system that may support PKCS7. The thought is PKCS7 would be used to
envelope data in a manner similar to how the evp functions operate.

The request came up because the word "envelope" is used to describe evp and
PKCS7 functionality.

I suspect that evp functions are not compatible with PKCS7, but I don't
know how to easily confirm this. I also suspect it will be difficult to
explain why they are incompatible.

If evp and PKCS7 are incompatible, we might be asked if we can use PKCS7
enveloping instead of evp.

Any insights, thoughts, advice, code to read, etc would be appreciated.


> > We need to expand this CMS to other systems, on which we have not
> been able
> > to build openssl. These other systems have a vendor supplied security
> > application. This application supports PKCS7.
>
> > We are being asked if our evp CMS is interoperable with PKCS7.
>
> CMS (RFC3369/2630) is an upward revision to PKCS7 (RFC2315) 1.5.
> CMS can read PKCS7 messages, but converse is not true.
>
> I think it is possible to configure the CMS routines to produce PKCS7
> messages, but I didn't do this in my RFC8366 support. I just forklift
> upgraded to CMS.
>
> > If it is possible and more information is required to answer this
> question,
> > I'll provide such information.
>
> > If not, advice on how to present that argument to management would be
> > appreciated.
>
> You will understand them, but they won't understand you.
>
> You may be able to configure your end to generate PKCS7 easily, and it may
> have little effect.  This might degenerate until just using PKCS7
> everywhere.
>
> The major difference is the eContentType that is lacking in PKCS7.
> And algorithms: I think that there are few modern algorithms defined for
> PKCS7.
>
> You could easily run in PKCS7 mode until you receive a CMS message from the
> peer, and then upgrade to CMS.  But this winds up in a bid-down attack if
> both parties run this algorithm, so you'd want to insert some extension
> that
> said: "I can do CMS" into your PKCS7 messages.
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works|IoT
> architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
>

Re: secure_getenv

[Michael Mueller]

IGNORE

cockpit error

I failed to compile openssl on the lowest revision release that we
support.  The error occurred when I tried to build our app on the low
rev system with openssl 1.1.1g that was built on a higher revision
linux system.

TIL secure_getenv()

On Tue, Apr 21, 2020 at 11:18 AM Michael Mueller  wrote:
>
> anybody else compiling apps against openssl 1.1.1g in Linux and
> getting link errors for secure_getenv?
>
> ../../../../OPENSSL/bin/SUSE-Linux/libcrypto.a(getenv.o): In function
> `ossl_safe_getenv': getenv.c:(.text+0x1): undefined reference to
> `secure_getenv
>
> secure_getenv() is a GNU extension
>
> Mike

secure_getenv

[Michael Mueller]

anybody else compiling apps against openssl 1.1.1g in Linux and
getting link errors for secure_getenv?

../../../../OPENSSL/bin/SUSE-Linux/libcrypto.a(getenv.o): In function
`ossl_safe_getenv': getenv.c:(.text+0x1): undefined reference to
`secure_getenv

secure_getenv() is a GNU extension

Mike

CMS in openssl

[Michael Mueller]

Greetings esteemed openssl users,

We've implemented what I gather can be called a CMS on Linux and Windows
using openssl evp functions.

We need to expand this CMS to other systems, on which we have not been able
to build openssl. These other systems have a vendor supplied security
application. This application supports PKCS7.

We are being asked if our evp CMS is interoperable with PKCS7.

If it is possible and more information is required to answer this question,
I'll provide such information.

If not, advice on how to present that argument to management would be
appreciated.

Thank you for your assistance
Mike

Re: Problems porting Openssl 1.1.1d to zos.

[Michael Mueller]

This is a very helpful post. Thank you.

We lacked Perl and had no clear path to getting it. Can't say this
deficiency caused our project to miss generous targets, but it certainly
contributed.


On Wed, Mar 4, 2020, 6:07 AM Patrick Steuer  wrote:

> > I stumbled across this mails when looking for information regarding
> OpenSSL
> > on zOS. Currently, I am working on getting OpenSSL 1.1.1c running on
> zOS. So
> > far I created my own config "target" inside 10-main.conf based on the old
> > configuration that was used pre OpenSSL 1.1.0.
>
> > Still, I was not able to get that far yet and was wondering how you
> > proceeded regarding this issue? Apart from some github issues and the
> likes
> > regarding EBCDIC patches I was unable to find much advice on how to
> > configure the build and how to tackle common issues. One config target
> for
> > zOS OS390 was created a while back but then removed again from OpenSSL
> > 1.1.1. With my config target I made it to the compile step but still face
> > build issues. Reaching a complete build like Wendell Nichols would
> already
> > by a great step.
>
> Regarding z/OS, the build environment is usually the hard part:
> We build from EBCDIC sources (gunzip the tar file, use pax to extract
> from tar) using xplink linkage, 64 bit and a perl version that works
> with EBCDIC.
>
> Relevant parts from the config files that we are using:
>
> 10-main.conf
> 
>   "OS390-Unix" => {
>   inherit_from => [ "BASE_unix", asm("zos_asm") ],
>   cc   => "./tools/c99.sh",
>   cflags   => "-O -Wc,dll,XPLINK,exportall,hgpr,lp64
> -Wa,'GOFF,SYSPARM(USE_XPLINK)' -qlongname -qlanglvl=extc99 -DB_ENDIAN
> -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -D_ALL_SOURCE -D_OPEN_THREADS=2
> -D_POSIX_SOURCE  -D_OPEN_MSGQ_EXT",
>   module_ldflags   => "-Wl,XPLINK,LP64",
>   shared_ldflags   => "-Wl,dll,XPLINK,LP64",
>   bn_ops   => "THIRTY_TWO_BIT RC4_CHAR",
>   thread_scheme=> "(unknown)",
>   perlasm_scheme   => "zOS64",
>   },
> 
>
> 00-base-templates.conf
> 
> # Either comment out all the asm below, or use a no-asm build.
>  zos_asm => {
>  template=> 1,
>  cpuid_asm_src   => "s390xcap.c s390xcpuid.s",
>  bn_asm_src  => "bn_asm.c", # s390x-gf2m.s",
>  ec_asm_src  => "ecp_s390x_nistp.c",
>  aes_asm_src => "aes-s390x.s aes-ctr.fake aes-xts.fake",
>  sha1_asm_src=> "sha1-s390x.s sha256-s390x.s sha512-s390x.s",
>  rc4_asm_src => "rc4-s390x.s",
>  modes_asm_src   => "ghash-s390x.s",
> #   chacha_asm_src  => "chacha-s390x.s",
> #   poly1305_asm_src => "poly1305-s390x.s",
>  keccak1600_asm_src  => "keccak1600-s390x.s",
> 
>
> tools/c99.sh
> 
> #!/bin/sh -k
> #
> # Re-order arguments so that -L comes first
> #
> opts=""
> lopts=""
>
> for arg in $* ; do
>case $arg in
>  -L*) lopts="$lopts $arg" ;;
>  *) opts="$opts $arg" ;;
>esac
> done
>
> c99 -Wl,dll $lopts $opts
> 
>
>
> > Are any of you aware of zOS specific OpenSSL development branches that I
> > have yet to find? Or is this mainly done in private repositories/branches
> > and not offered for PRs to the OpenSSL repository?
>
> We are working on porting OpenSSL for z/OS internally right now and will
> share the work in progress (via a PR to the OpenSSL repo) as soon as it
> makes sense, probably in the near future.
>
> Best,
> Patrick
>

Re: Problems porting Openssl 1.1.1d to zos.

[Michael Mueller]

We recently abandoned our effort to port 1.1.1d to zos. Attempting to use
GSK now. Lack of a zos dev community is a hurdle.

M

On Mon, Mar 2, 2020, 6:04 AM K Lengauer  wrote:

> Dear all,
>
> I stumbled across this mails when looking for information regarding OpenSSL
> on zOS. Currently, I am working on getting OpenSSL 1.1.1c running on zOS.
> So
> far I created my own config "target" inside 10-main.conf based on the old
> configuration that was used pre OpenSSL 1.1.0.
>
> Still, I was not able to get that far yet and was wondering how you
> proceeded regarding this issue? Apart from some github issues and the likes
> regarding EBCDIC patches I was unable to find much advice on how to
> configure the build and how to tackle common issues. One config target for
> zOS OS390 was created a while back but then removed again from OpenSSL
> 1.1.1. With my config target I made it to the compile step but still face
> build issues. Reaching a complete build like Wendell Nichols would already
> by a great step.
>
> Are any of you aware of zOS specific OpenSSL development branches that I
> have yet to find? Or is this mainly done in private repositories/branches
> and not offered for PRs to the OpenSSL repository?
>
> Any advice is greatly appreciated.
>
>
>
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
>

Re: OpenSSL compilation errors in Windows

[Michael Mueller]

We compile using Visual Studio. We don't use 'warnings as errors' and
selected a warning level that minimized warnings. The 'make test' runs
cleanly.



On Mon, Sep 30, 2019, 3:16 AM Nagalakshmi V J 
wrote:

> Hi,
>
> I am using openssl 1.1.c from our product code. While compiling the code,
> I am getting the errors which can be suppressed as warnings using
> -fpermissive flag in Linux (gcc/g++). In windows, I am getting the same
> compilation errors in visual studio (2005). Would like to know the
> alternative of -fpermissive flag that can be used in visual studio to
> suppress the errors.
>
> I tried adding the flags such as '/fpermissive' , '/Ze' in module
> properties->C/C++->command Line->Additional options. But it did not resolve
> the problem.
>
> *Getting the errors like below. ssl/packet_locl.h(429) : error C2440: '='
> : cannot convert from 'void *' to 'unsigned char **'Conversion from 'void**'
> to pointer to non-'void' requires an explicit cast*
>
>
>
> Since it is giving error in Openssl code, we cannot make any code changes
> there. Has anyone faced this kind of issue?
>
> Please let me know how to resolve this issue.
>
>
>
>
>
>
>
> *Thanks and regards,*
>
> *Nagalakshmi*
>
>
> =
> Please refer to https://northamerica.altran.com/email-disclaimer
> for important disclosures regarding this electronic communication.
> =
>

Re: Issue Building OpenSSL version 1.1.1b using batch files Missing do_win64a/nt.mak/nt-dbg.mak

[Michael Mueller]

On Fri, Jul 26, 2019, 5:44 AM manoj upadhyay 
wrote:

>
This what we changed to. Will this method not work for you?

>
>
> P.S: I am able to build the code  using the standard method below.
>perl Configure VC-WIN64A
> nmake
> nmake test
> nmake install
>

Re: Issue Building OpenSSL version 1.1.1b using batch files Missing do_win64a/nt.mak/nt-dbg.mak

[Michael Mueller]

Found similar issues with our Windows 1.0.2 to 1.1.1c upgrade.

Had to change our build process per INSTALL doc.

The dll files are named differently which impacted our package and install
process.

Th

On Fri, Jul 26, 2019, 5:44 AM manoj upadhyay 
wrote:

> Hi All,
>
> I need help in building the OpenSSL 1.1.1b using the batch files.
> I have existing batch files to build OpenSSL  "1.0.2p". It uses following
> files to build OpenSSL.
>
>1. ms\do_win64a
>2. nt.mak
>3. nt-dbg.mak
>
> But above files are missing from 1.1.1b.  For reference I am adding code
> snippet from my batch file.
>
> Code snippet from Batch file.
>
>  set VERSION=openssl-1.1.1b
>
>  cd %VERSION%
>
>  perl Configure VC-WIN64A no-asm
>
>  call ms\do_win64a
>
>  sed -e s/out32/out64/g ms\nt.mak | sed -e s/tmp32/tmp64/g | sed -e
> s/inc32/inc64/g > ms\nt-64.mak
>
>  nmake -f ms\nt-64.mak clean
>
>  nmake -f ms\nt-64.mak
>
>  
>
>  .
>
>  ...
>
>  cd %VERSION%
>
>  perl util\mk1mf.pl debug no-asm VC-WIN64A >ms\nt-dbg.mak
>
>  sed -e s/out32/out64/g ms\nt-dbg.mak | sed -e s/tmp32/tmp64/g | sed -e
> s/inc32/inc64/g > ms\nt-dbg-64.mak
>
>  nmake -f ms\nt-dbg-64.mak clean
>
>  nmake -f ms\nt-dbg-64.mak
>
>
> Errors during running Batch scripts: (File Not Found)
>
>  Configuring OpenSSL version 1.1.1b (0x1010102fL) for VC-WIN64A
>
>  Using os-specific seed configuration
>
>
>  It looks like you don't have either nmake.exe or dmake.exe on your PATH,
>
>  so you will not be able to execute the commands from a Makefile.  You can
>
>  install dmake.exe with the Perl Package Manager by running:
>
>
>   ppm install dmake
>
>
>  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) ***
>
>  ******
>
>  **
>
>  'ms\do_win64a' is not recognized as an internal or external command,
>
> operable program or batch file.
>
>
>
>  Configuring OpenSSL version 1.1.1b (0x1010102fL) for VC-WIN64A
>
>  sed: can't read ms\nt.mak: No such file or directory
>
>
>
>  Microsoft (R) Program Maintenance Utility Version 14.16.27031.1
>
>  Copyright (C) Microsoft Corporation.  All rights reserved.
>
>
>
>  NMAKE : fatal error U1073: don't know how to make 'clean'
>
>  Stop.
>
>
>  Can't open perl script "util\mk1mf.pl": No such file or directory
>
>
>
> Please help me in getting these files generated and build the code using
> the batch-files.
>
> P.S: I am able to build the code  using the standard method below.
>perl Configure VC-WIN64A
> nmake
> nmake test
> nmake install
>

Re: Openssl binary with statically linked libssl and libcrypto

[Michael Mueller]

On Wed, Jul 24, 2019, 7:00 AM K Lengauer  wrote:

>
So if I understand you correctly you also use the
> "build.info" file to specify the static libraries as dependencies for the
> 'openssl' binary.
>

Negative. We use the following method:

./config  \
no-hw  \
no-zlib \
no-shared \
no-ssl2 \
no-ssl3 \
--prefix=$INSTALL_D \
--openssldir=$INSTALL_D


> Do you encounter any segmentation faults when running the tests provided by
> OpenSSL in the openssl/test/recipes, i.e. when running "make test"?


Tests run cleanly. Some tests are skipped.


>
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
>

Re: Openssl binary with statically linked libssl and libcrypto

[Michael Mueller]

We are doing this for Linux. See below. Don't recall changing anything
related to static build in transition from 1.0.2 to 1.1.1.

For Windows we use the dlls. Noticed that new windows compile creates
static libs, so we might convert to using the static libs.

dev@turmeric:/NAS/dev/projectx/OPENSSL/bin/SUSE-Linux> ldd openssl

linux-vdso.so.1 (0x7ffe023e4000)

libdl.so.2 => /lib64/libdl.so.2 (0x7f551e24e000)

libpthread.so.0 => /lib64/libpthread.so.0
(0x7f551e031000)

libc.so.6 => /lib64/libc.so.6 (0x7f551dc8a000)

/lib64/ld-linux-x86-64.so.2 (0x7f551e452000)

dev@turmeric:/NAS/dev/projectx/OPENSSL/bin/SUSE-Linux> ./openssl version

OpenSSL 1.1.1c  28 May 2019



On Tue, Jul 23, 2019, 5:02 AM K Lengauer  wrote:

> Hi all,
>
> I am trying to build the 'openssl' binary with libssl and libcrypto linked
> statically because the end product may be used on a system where they are
> not available. I recently upgraded to OpenSSL v1.1.1c and previously used
> 1.0.2s which allowed me to get the 'openssl' binary with statically linked
> libssl and libcrypto.
>
> I went through several questions and boards already and tried different
> things:
> 1) Using "no-shared" and "-static" for that matter with ./config is not an
> option as I still require the libcrypto.so and libssl.so for some other
> tests that are part of the whole component to which OpenSSL belongs in my
> use-case.
> 2) My "solution" so far is to change the "build.info" in /openssl/apps in
> the following way:
>
> source:   DEPEND[openssl]=libapps.a ../libssl
> changed to: DEPEND[openssl]=libapps.a ../libssl.a ../libcrypto.a
>
> This way I am able to build both the openssl binary with statically linked
> libraries as well as keep building the shared libraries.
>
> However, here comes the catch. In doing so I break several of the OpenSSL
> unit tests (notably all 70-* recipe tests such as 70-test_comp.t, etc.) and
> they encounter a segmentation fault. I could provide a backtrace of the
> core
> for such a segfault.
> If I dont link the libraries statically and instead use the config to point
> it to the built .so files the tests run just fine.
>
> Is there a (better) way to achieve my goal to build the 'openssl' binary
> with statically linked libcrypto and libssl? I read in a recent question
> that statically linking is not recommended but still ask you kindly for any
> advice you can give me on this matter.
>
> I am sorry for this lengthy question but I tried to offer some insight in
> my
> thought process so far. Furhter, I apologize if my error is obvious as I am
> still learning the topics related to OpenSSL and especially the changes
> that
> occured since OpenSSL v1.1.0.
>
>
>
>
>
>
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
>

1.1.1c build on z/OS, OS 390

[Michael Mueller]

(apologies if this email is redundant, but my first send originated from
email account not registered on this list)

We need to compile openssl 1.1.1c for z/OS, OS 390
Has anyone been down this path? This link provided hope:

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

We use static libs so the shared lib issue is not an immediate concern.

Some older emails helped generate possible config targets.

dev@turmeric:~/wrk/openssl_build/1.1.1c/openssl-1.1.1c> perl ./Configure
LIST | grep "390"

linux32-s390x

linux64-s390x
Is Perl on z/OS required? Might be a hurdle for us.

Thanks
Mike

OpenSSL, Windows, Perl

[Michael Mueller]

Happy Linux OpenSSL user here. Moving to Windowsville. Haven't been there
in over a decade. Read INSTALL.W32 and INSTALL.W64. Read Configure. Read
crypto/asm/*.pl. Clearly Perl is needed to compile openssl with Visual
Studio - which we will be using.

Does OpenSSL need Perl at runtime?

Thanks,
Mike

Re: ./config and -no-zlib

[Michael Mueller]

i compiled openssl with no-zlib

here is ldd of my client:

 ldd client
linux-vdso.so.1 =  (0x7fff059ff000)
libssl.so.1.0.0 = /lib64/libssl.so.1.0.0 (0x7fefccdc9000)
libcrypto.so.1.0.0 = /lib64/libcrypto.so.1.0.0 (0x7fefcca17000)
libpthread.so.0 = /lib64/libpthread.so.0 (0x7fefcc7fa000)
libc.so.6 = /lib64/libc.so.6 (0x7fefcc48d000)
libdl.so.2 = /lib64/libdl.so.2 (0x7fefcc289000)
libz.so.1 = /lib64/libz.so.1 (0x7fefcc071000)
/lib64/ld-linux-x86-64.so.2 (0x7fefcd025000)

it is still using the default libraries; when the client runs in this
environment, it suggests 2 compression methods in the handshake (NULL, and
)

then I change the LD_LIBRARY_PATH env and run again:

 export LD_LIBRARY_PATH=/home/mike02/wrk/openssl/lib
 ldd client
linux-vdso.so.1 =  (0x7fff42cfa000)

libssl.so.1.0.0 = /home/mike02/wrk/openssl/lib/libssl.so.1.0.0
(0x7f76caf15000)
libcrypto.so.1.0.0 =
/home/mike02/wrk/openssl/lib/libcrypto.so.1.0.0 (0x7f76cab34000)

libpthread.so.0 = /lib64/libpthread.so.0 (0x7f76ca917000)

libc.so.6 = /lib64/libc.so.6 (0x7f76ca5aa000)

libdl.so.2 = /lib64/libdl.so.2 (0x7f76ca3a6000)

/lib64/ld-linux-x86-64.so.2 (0x7f76cb17f000)

and in this environment (note that libz is missing), the client only
suggests 1 compression method (NULL) in the handshake.

So, compiling with no-zlib is not sufficient for turning off compression.
 It is also required to take specific actions to use the openssl libraries
compiled with the no-zlib option at runtime.

I expect that by using SSL_OP_NO_COMPRESSION, compression will suppressed
regardless of the linkage of zlib, but I haven't tested that proposal yet.


On Tue, Dec 25, 2012 at 12:27 PM, Jeffrey Walton noloa...@gmail.com wrote:

 Hi All,

 Is it sufficient to use -no-zlib to turn off SSL/TLS compression? Or
 is compression available through other libraries?

 Jeff
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: ./config and -no-zlib

[Michael Mueller]

i was going to do this:

SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_COMPRESSION);


On Fri, Dec 28, 2012 at 3:14 PM, Jeffrey Walton noloa...@gmail.com wrote:

 On Fri, Dec 28, 2012 at 7:48 AM, Michael Mueller abaci@gmail.com
 wrote:
  i compiled openssl with no-zlib
 
  ldd client
  linux-vdso.so.1 =  (0x7fff059ff000)
  libssl.so.1.0.0 = /lib64/libssl.so.1.0.0 (0x7fefccdc9000)
  libcrypto.so.1.0.0 = /lib64/libcrypto.so.1.0.0
 (0x7fefcca17000)
  libpthread.so.0 = /lib64/libpthread.so.0 (0x7fefcc7fa000)
  libc.so.6 = /lib64/libc.so.6 (0x7fefcc48d000)
  libdl.so.2 = /lib64/libdl.so.2 (0x7fefcc289000)
  libz.so.1 = /lib64/libz.so.1 (0x7fefcc071000)
  /lib64/ld-linux-x86-64.so.2 (0x7fefcd025000)
 
  it is still using the default libraries; when the client runs in this
  environment, it suggests 2 compression methods in the handshake (NULL,
 and
  )
 
  then I change the LD_LIBRARY_PATH env and run again:
 
  export LD_LIBRARY_PATH=/home/mike02/wrk/openssl/lib
  ldd client
  linux-vdso.so.1 =  (0x7fff42cfa000)
  libssl.so.1.0.0 = /home/mike02/wrk/openssl/lib/libssl.so.1.0.0
  (0x7f76caf15000)
  libcrypto.so.1.0.0 =
  /home/mike02/wrk/openssl/lib/libcrypto.so.1.0.0 (0x7f76cab34000)
  libpthread.so.0 = /lib64/libpthread.so.0 (0x7f76ca917000)
  libc.so.6 = /lib64/libc.so.6 (0x7f76ca5aa000)
  libdl.so.2 = /lib64/libdl.so.2 (0x7f76ca3a6000)
  /lib64/ld-linux-x86-64.so.2 (0x7f76cb17f000)
 
  and in this environment (note that libz is missing), the client only
  suggests 1 compression method (NULL) in the handshake.
 
  So, compiling with no-zlib is not sufficient for turning off compression.
  It is also required to take specific actions to use the openssl libraries
  compiled with the no-zlib option at runtime.
 
  I expect that by using SSL_OP_NO_COMPRESSION, compression will suppressed
  regardless of the linkage of zlib, but I haven't tested that proposal
 yet.
 This is bad news I believe the redefinition is because I built the
 FIPS Object Module first according to the Security Policy (give or
 take). That meant no knob turning whatsoever, and I had to invoke
 'configure' with no arguments.

 Then, when it came time for FIPS Capable OpenSSL:

 ./config --openssldir=/usr/local/ssl/iphoneos/
 --with-fipsdir=/usr/local/ssl/iphoneos/ -no-dtls -no-hw -no-zlib
 -no-shared -no-dso -DSSL_OP_NO_COMPRESSION

 which eventually results in:

 ...
 ../../util/domd ../.. -MD

 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-gcc
 -M -- -DOPENSSL_THREADS -D_REENTRANT -DSSL_OP_NO_COMPRESSION -arch
 armv7 -O3 -isysroot

 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk
 -fomit-frame-pointer -fno-common -I.. -I../.. -I../modes -I../asn1
 -I../evp -I../../include  -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_DTLS
 -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE
 -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779
 -DOPENSSL_NO_SCTP -DOPENSSL_NO_STORE --  srp_lib.c srp_vfy.c
 making depend in crypto/cmac...
 ../../util/domd ../.. -MD

 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-gcc
 -M -- -DOPENSSL_THREADS -D_REENTRANT -DSSL_OP_NO_COMPRESSION -arch
 armv7 -O3 -isysroot

 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk
 -fomit-frame-pointer -fno-common -I.. -I../.. -I../modes -I../asn1
 -I../evp -I../../include  -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_DTLS
 -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE
 -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779
 -DOPENSSL_NO_SCTP -DOPENSSL_NO_STORE --  cmac.c cm_ameth.c cm_pmeth.c
 making depend in ssl...
 In file included from ssl_locl.h:165,
  from s2_meth.c:59:
 ../include/openssl/ssl.h:583:1: error: SSL_OP_NO_COMPRESSION redefined
 command-line: error: this is the location of the previous definition
 In file included from ssl_locl.h:165,
  from s2_srvr.c:112:
 ../include/openssl/ssl.h:583:1: error: SSL_OP_NO_COMPRESSION redefined
 command-line: error: this is the location of the previous definition
 In file included from ssl_locl.h:165,
  from s2_clnt.c:112:
 ../include/openssl/ssl.h:583:1: error: SSL_OP_NO_COMPRESSION redefined
 command-line: error: this is the location of the previous definition
 In file included from ssl_locl.h:165,
  from s2_lib.c:112:
 ../include/openssl/ssl.h:583:1: error: SSL_OP_NO_COMPRESSION redefined
 command-line: error: this is the location of the previous definition
 ...
 [30 or 50 or so duplicate errors removed]
 ...

 command-line: error: this is the location of the previous definition
 make[1]: *** [depend] Error 1
 make: *** [depend] Error 1

  On Tue

Re: extensions in certifications

[Michael Mueller]

On Tue, Dec 11, 2012 at 7:10 PM, Michael Mueller abaci@gmail.comwrote:

 On Tue, Dec 11, 2012 at 6:10 PM, Dave Thompson dthomp...@prinpay.comwrote:

 From: owner-openssl-us...@openssl.org On Behalf Of Michael Mueller
 Sent: Tuesday, 11 December, 2012 15:45

 Could I get a nudge. I'd like to get the SANs to show up in my certs.

 snip



 If you are the CA, and you are using openssl 'ca' commandline,
 configure copy_extensions as per the man page (and read the warning).
 If you don't have man pages on your system e.g. Windows
 http://www.openssl.org/docs/apps/ca.html

 snip


It worked:

[ ca ]
default_ca  = exampleca

[ exampleca ]
copy_extensions = copy  # copy extensions from request

[ certificate_extensions ]
basicConstraints= CA:false # per WARNING

Thanks again

extensions in certifications

[Michael Mueller]

Could I get a nudge. I'd like to get the SANs to show up in my certs.

in my request:

Requested Extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Subject Alternative Name:
DNS:ossvirt4, DNS:gws001

what I get in the resulting certificate:

X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE

Let me know if I need to provide more info.

(I'm watching the other SAN thread too.)

Thanks much,
Mike

Re: extensions in certifications

[Michael Mueller]

On Tue, Dec 11, 2012 at 6:10 PM, Dave Thompson dthomp...@prinpay.comwrote:

 From: owner-openssl-us...@openssl.org On Behalf Of Michael Mueller
 Sent: Tuesday, 11 December, 2012 15:45

 Could I get a nudge. I'd like to get the SANs to show up in my certs.

 in my request: snip BC, KU, SAN

 what I get in the resulting certificate: snip only BC

 It depends on the CA, i.e. the person or organization who issues the certs.

 If you are the CA, and you are using openssl 'ca' commandline,
 configure copy_extensions as per the man page (and read the warning).
 If you don't have man pages on your system e.g. Windows
 http://www.openssl.org/docs/apps/ca.html

 Right now, I am the CA using 'openssl ca' in a closed environment.

I think copy_extensions will do the trick; I'll give it a try tomorrow AM.


 If you are the CA using openssl 'x509 -req', you can't take
 it from the CSR, but you can supply this (or any other) extension
 directly at issue time. If you do both the CSR and the issue
 yourself, a few seconds apart, this difference may not matter.

 This sounds like what my CA will be doing - they told me to list my SANs
in an email along with my reqs because they had to add it in.


 If the CA is somebody else, ask them. Maybe you can click
 a form. Maybe you must sacrifice a goat. It's up to the CA.


I'll keep the goat advice handy just in case.  Hope it doesn't come to that.

Big thanks.