Re: [openssl-users] The default cipher of executable 'openssl'
> From: openssl-users On Behalf Of Viktor Dukhovni > Sent: Friday, June 12, 2015 02:47 > > 1) 1.0.1l > > ./apps/openssl s_server -ssl3 -cert certdb/ssl_server.pem -WWW -CAfile > > certdb/cafile.pem > > Using default temp DH parameters > > Using default temp ECDH parameters > > ACCEPT > > With SSL 3.0, no extension support, thus no supported curves > extension, thus ideally no EDCHE support. If ECDHE happened anyway > with earlier releases, that was a bug that is perhaps now fixed. > That is it. I'm not sure a bug, but I'd agree not ideal. 4492 says client SHOULD send the curves and pointformats extensions, but if it doesn't the server "is free to choose any one of [4492 named curves]" (no BCP14 verb). OpenSSL's old behavior of using a particular curve is permitted. I'm not sure it was an intentional change. <=1.0.1 had all the logic in ssl3_choose_cipher, with (large clumsy) code blocks of the form "if ECC suite is in intersection of client and server lists and we have ECC key&cert, but client specified curves and our curve isn't among them, don't use ECC suite", and similarly for pointformats. If client didn't send the extensions the "don't use" branch wasn't taken. 1.0.2 has new APIs for both client and server apps to restrict curves, and ssl3_choose_cipher is rearranged into several new routines, using I think some new data, with result that if the client doesn't send extensions ECC is NOT selected (and in the OPs case DHE is). > > 2) 1.0.2 > > ./apps/openssl s_server -ssl3 -cert certdb/ssl_server.pem -WWW -CAfile > > certdb/cafile.pem > > Using default temp DH parameters > > ACCEPT > > > > Note that, in 1.0.2, openssl doesn't print out 'Using default temp ECDH > > parameters'. > That's a red herring. That code was also refactored; s_server still defaults to P256, it just doesn't say so. If I run 1.0.2* s_server -ssl3 then s_client allowing at least 1.0, it sends clienthello containing ECC suites in cipherlist (by default), with applicable extensions including two for ECC; receiving this, server negotiates version=3.0, but DOES select ECDHE-RSA (given RSA cert&key) and client agrees. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
On 6/19/2015 12:51 PM, Jay Foster wrote: On 6/19/2015 10:52 AM, Jay Foster wrote: On 6/19/2015 8:55 AM, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jay Foster Sent: Friday, June 19, 2015 11:49 I started over from a clean directory and the build completed. On linux, I would end up with two libraries (libssl, libcrypto). I don't see these on Windows in the out32dll directory. Does Windows create different library names? I'm looking for the equivalent static libraries for libssl and libcrypto to link with my application. The Windows static libraries are named libeay32.lib and ssleay32.lib, for historical reasons. At any rate, that's what I have in my Windows build directory; I believe those are the standard names. Thanks, I see those. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users I got my application to compile and link. It seemed to run OK, but when I tried to run it on a different Windows machine, it failed with a pop up dialog complaining it could not find LIBEAY32.dll. I 'thought' I was statically linking this library, but apparently not. I have no idea how it worked on the one machine. What is the magic incantation to get Visual Studio to statically link the OpenSSL libraries? Jay Use nt.mak, not ntdll.mak. You can search the Internets for Windows binaries. Also, Dependency Walker is very useful for identifying what DLLs a DLL or EXE depends on. In my opinion, you shouldn't really link against static versions if you can avoid it. Static linking makes it harder for end-users to stay up to date. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
From: Jay Foster Sent: Friday, June 19, 2015 15:51 I got my application to compile and link. It seemed to run OK, but > when I tried to run it on a different Windows machine, it failed > with a pop up dialog complaining it could not find LIBEAY32.dll. I > 'thought' I was statically linking this library, but apparently not. > I have no idea how it worked on the one machine. What is the magic > incantation to get Visual Studio to statically link the OpenSSL > libraries? You'd save us a lot of guesswork, and probably get where you want to be more quickly, if you would 1) tell us what version of OpenSSL you're trying to build 2) tell us what build environment you're using (presumably some command prompt started from VS) 3) tell us the exact sequence of commands you're executing to build it, starting from the tarball Have you read INSTALL.W32? It's probably well out of date in detail, but still valuable to point you in the right direction. As long as you're using the nt.mak makefile, you should get static libraries. Regards, jjf -- J. J. Farrell ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
> I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL > 1.0.2c for Windows, but get a linking error > My goal is to obtain a static library(ies) and associated header files > that I can use to compile my application that uses OpenSSL on Windows. > Where can I obtain these pre-built binaries? > What is the magic incantation to get Visual Studio to statically link the > OpenSSL libraries? > The OpenSSL libraries have to be built as static libraries. Dear Jay, We have been building OpenSSL on Windows, both statically and dynamically, for some time now without issues. We don't use Visual Studio though. The question is: does OpenSSL have to be built using Visual Studio only? If the answer is 'no', we could render some assistance. Just let us know. Cheers. Sergio. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Jay Foster > Sent: Friday, June 19, 2015 17:31 > > I see OpenSSL build output that looks like this: > > cl /Fotmp32dll\a_sign.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 > -DOPENSSL > _THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo - > DOPENSSL_SYSNAME_WIN32 > -DWIN32_L > EAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE - > DOPENSSL_USE_APPLINK > -I. -DO > PENSSL_NO_IDEA -DOPENSSL_NO_RC2 -DOPENSSL_NO_RC5 - > DOPENSSL_NO_MD2 > -DOPENSSL_NO_S > SL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE > -DOPENSSL_NO_STATIC_E > NGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c > .\crypto\asn > 1\a_sign.c > a_sign.c > > Should the "/MD" be "/MT"? Probably not. This depends on other considerations that are outside the scope of statically or dynamically linking OpenSSL itself. /MD tells VC to put a reference to the DLL version of the Microsoft C Runtime (CRT) into the object file; /MT tells VC to put a reference to the static version of the CRT in. Usually even static libraries should be linked with the DLL version of the CRT, unless you know the final executable will always be linked with the static CRT. > Is -DOPENSSL_BUILD_SHLIBCRYPTO right? Not sure. > is -D_WINDLL right? Probably. Again, even with OpenSSL built for static linking, it's usually best to tell VC that you're building for eventual dynamic linking, if the final executable will have a mix of static and dynamic objects. > Do I need to specify enable-static-engine No, unless you know you're using one or more engines, and you know you need them linked statically rather than loaded dynamically. Start by assuming no. The engine feature supports external cryptographic providers. Those can be software systems like Microsoft's Crypto API, or hardware systems like card readers that use the PKCS#11 API. Modern versions of OpenSSL load engines dynamically, on request; enable-static-engine links them in statically instead. > or no-dso? I don't know what that option does, off the top of my head. Doesn't look like our build uses it. -- Michael Wojcik Technology Specialist, Micro Focus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Jay Foster > Sent: Friday, June 19, 2015 17:09 > > > > I think "no-shared" is the Configure option you need. We actually have a > > script that changes some of the OpenSSL makefiles after configuring, so our > > process is a bit different from yours. > > > That sounds like what I'm running into. I rebuilt the OpenSSL libraries > with the "no-shared" option, but this made no difference. Does that work > for Windows? Hmm. I thought it did, but as I said we're using a customized process. We run Configure but then make some changes. You can check to see whether a LIB file is an import or static library using the "lib" tool that's included with Visual Studio. "lib /list libeay32.lib" will show a bunch of object file names if it's a static library; if it's an import library, it will just print "libeay32.dll" a bunch of times. The static library will also be a lot bigger. My libeay32.lib is around 14 MB. I don't have an import one here, but it should be much smaller, since it's basically just a list of function signatures. Is it possible your build created both static and dynamic versions? Do you have two different versions of libeay32.lib in the build directory? What version of OpenSSL are you building? -- Michael Wojcik Technology Specialist, Micro Focus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
On 6/19/2015 2:09 PM, Jay Foster wrote: On 6/19/2015 1:11 PM, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jay Foster Sent: Friday, June 19, 2015 15:51 I got my application to compile and link. It seemed to run OK, but when I tried to run it on a different Windows machine, it failed with a pop up dialog complaining it could not find LIBEAY32.dll. I 'thought' I was statically linking this library, but apparently not. I have no idea how it worked on the one machine. What is the magic incantation to get Visual Studio to statically link the OpenSSL libraries? The OpenSSL libraries have to be built as static libraries. If you configure the OpenSSL build for static libraries, that's what you'll get. If you configure it for dynamic libraries, you'll get libeay32.dll and ssleay32.dll, and a pair of "import libraries" named libeay32.lib and ssleay32.lib. You won't get static libraries at all. Note the static libraries and the import libraries have the same name. When you link a library to a Windows executable, you provide either a static library or an import library. In the latter case, the executable will do an implicit load of the corresponding DLL at startup. So if you want to statically link with OpenSSL, you have to configure it for static linkage and build it that way. Then the libeay32.lib and ssleay32.lib you get should be true static libraries and not import libraries. I think "no-shared" is the Configure option you need. We actually have a script that changes some of the OpenSSL makefiles after configuring, so our process is a bit different from yours. That sounds like what I'm running into. I rebuilt the OpenSSL libraries with the "no-shared" option, but this made no difference. Does that work for Windows? Jay ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users I see OpenSSL build output that looks like this: cl /Fotmp32dll\a_sign.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL _THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_L EAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DO PENSSL_NO_IDEA -DOPENSSL_NO_RC2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_S SL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_E NGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn 1\a_sign.c a_sign.c Should the "/MD" be "/MT"? Is -DOPENSSL_BUILD_SHLIBCRYPTO right? is -D_WINDLL right? Do I need to specify enable-static-engine or no-dso? Jay ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
On 6/19/2015 1:11 PM, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jay Foster Sent: Friday, June 19, 2015 15:51 I got my application to compile and link. It seemed to run OK, but when I tried to run it on a different Windows machine, it failed with a pop up dialog complaining it could not find LIBEAY32.dll. I 'thought' I was statically linking this library, but apparently not. I have no idea how it worked on the one machine. What is the magic incantation to get Visual Studio to statically link the OpenSSL libraries? The OpenSSL libraries have to be built as static libraries. If you configure the OpenSSL build for static libraries, that's what you'll get. If you configure it for dynamic libraries, you'll get libeay32.dll and ssleay32.dll, and a pair of "import libraries" named libeay32.lib and ssleay32.lib. You won't get static libraries at all. Note the static libraries and the import libraries have the same name. When you link a library to a Windows executable, you provide either a static library or an import library. In the latter case, the executable will do an implicit load of the corresponding DLL at startup. So if you want to statically link with OpenSSL, you have to configure it for static linkage and build it that way. Then the libeay32.lib and ssleay32.lib you get should be true static libraries and not import libraries. I think "no-shared" is the Configure option you need. We actually have a script that changes some of the OpenSSL makefiles after configuring, so our process is a bit different from yours. That sounds like what I'm running into. I rebuilt the OpenSSL libraries with the "no-shared" option, but this made no difference. Does that work for Windows? Jay ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Jay Foster > Sent: Friday, June 19, 2015 15:51 > > > I got my application to compile and link. It seemed to run OK, but when > I tried to run it on a different Windows machine, it failed with a pop > up dialog complaining it could not find LIBEAY32.dll. I 'thought' I was > statically linking this library, but apparently not. I have no idea how > it worked on the one machine. What is the magic incantation to get > Visual Studio to statically link the OpenSSL libraries? The OpenSSL libraries have to be built as static libraries. If you configure the OpenSSL build for static libraries, that's what you'll get. If you configure it for dynamic libraries, you'll get libeay32.dll and ssleay32.dll, and a pair of "import libraries" named libeay32.lib and ssleay32.lib. You won't get static libraries at all. Note the static libraries and the import libraries have the same name. When you link a library to a Windows executable, you provide either a static library or an import library. In the latter case, the executable will do an implicit load of the corresponding DLL at startup. So if you want to statically link with OpenSSL, you have to configure it for static linkage and build it that way. Then the libeay32.lib and ssleay32.lib you get should be true static libraries and not import libraries. I think "no-shared" is the Configure option you need. We actually have a script that changes some of the OpenSSL makefiles after configuring, so our process is a bit different from yours. -- Michael Wojcik Technology Specialist, Micro Focus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
On 6/19/2015 10:52 AM, Jay Foster wrote: On 6/19/2015 8:55 AM, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jay Foster Sent: Friday, June 19, 2015 11:49 I started over from a clean directory and the build completed. On linux, I would end up with two libraries (libssl, libcrypto). I don't see these on Windows in the out32dll directory. Does Windows create different library names? I'm looking for the equivalent static libraries for libssl and libcrypto to link with my application. The Windows static libraries are named libeay32.lib and ssleay32.lib, for historical reasons. At any rate, that's what I have in my Windows build directory; I believe those are the standard names. Thanks, I see those. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users I got my application to compile and link. It seemed to run OK, but when I tried to run it on a different Windows machine, it failed with a pop up dialog complaining it could not find LIBEAY32.dll. I 'thought' I was statically linking this library, but apparently not. I have no idea how it worked on the one machine. What is the magic incantation to get Visual Studio to statically link the OpenSSL libraries? Jay ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
On 6/19/2015 8:55 AM, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jay Foster Sent: Friday, June 19, 2015 11:49 I started over from a clean directory and the build completed. On linux, I would end up with two libraries (libssl, libcrypto). I don't see these on Windows in the out32dll directory. Does Windows create different library names? I'm looking for the equivalent static libraries for libssl and libcrypto to link with my application. The Windows static libraries are named libeay32.lib and ssleay32.lib, for historical reasons. At any rate, that's what I have in my Windows build directory; I believe those are the standard names. Thanks, I see those. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Jay Foster > Sent: Friday, June 19, 2015 11:49 > > > I started over from a clean directory and the build completed. On > linux, I would end up with two libraries (libssl, libcrypto). I don't > see these on Windows in the out32dll directory. Does Windows create > different library names? I'm looking for the equivalent static > libraries for libssl and libcrypto to link with my application. The Windows static libraries are named libeay32.lib and ssleay32.lib, for historical reasons. At any rate, that's what I have in my Windows build directory; I believe those are the standard names. -- Michael Wojcik Technology Specialist, Micro Focus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
On 6/19/2015 8:30 AM, Jay Foster wrote: On 6/18/2015 7:55 PM, Thomas J. Hruska wrote: On 6/18/2015 4:46 PM, Jay Foster wrote: I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL 1.0.2c for Windows, but get a linking error tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' I googled for this error, but the solutions mention changing parameters in the VC Studio project, but I'm building from the command line with nmake. I'm configuring for 32-bit (perl Configure VC-WIN32 ...). I think the Windows system I'm compiling on is a 64-bit OS. I know I have built 32-bit applications on it in the past from VC Studio. Is there some obvious fix? Jay What Command Prompt are you running? You have to use the correct "Native Tools" for the target hardware type. If you are building VC-WIN32, then you are targeting 32-bit hardware and need to run the x86 Native Tools Command Prompt (not the x64 version). You can't mix and match targets. If you don't want to build it yourself, there are also prebuilt binaries and libraries. I tried again, but it then failed trying to compile an assembly file (i586 something). It complained about an unknown operand. I tried again adding "no-asm" to my configuration. It seemed to compile fine, but again failed at the link with several undefined symbols: _OPENSSL_ia32cap_P, _OPENSSL_ia32_cpuid, _md5_block_asm_data_order, _sha1_block_data_order, _sha256_block_data_order, and _sha512_block_data_order. My goal is to obtain a static library(ies) and associated header files that I can use to compile my application that uses OpenSSL on Windows. Where can I obtain these pre-built binaries? Jay ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users I started over from a clean directory and the build completed. On linux, I would end up with two libraries (libssl, libcrypto). I don't see these on Windows in the out32dll directory. Does Windows create different library names? I'm looking for the equivalent static libraries for libssl and libcrypto to link with my application. Jay ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
On 6/18/2015 7:55 PM, Thomas J. Hruska wrote: On 6/18/2015 4:46 PM, Jay Foster wrote: I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL 1.0.2c for Windows, but get a linking error tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' I googled for this error, but the solutions mention changing parameters in the VC Studio project, but I'm building from the command line with nmake. I'm configuring for 32-bit (perl Configure VC-WIN32 ...). I think the Windows system I'm compiling on is a 64-bit OS. I know I have built 32-bit applications on it in the past from VC Studio. Is there some obvious fix? Jay What Command Prompt are you running? You have to use the correct "Native Tools" for the target hardware type. If you are building VC-WIN32, then you are targeting 32-bit hardware and need to run the x86 Native Tools Command Prompt (not the x64 version). You can't mix and match targets. If you don't want to build it yourself, there are also prebuilt binaries and libraries. I tried again, but it then failed trying to compile an assembly file (i586 something). It complained about an unknown operand. I tried again adding "no-asm" to my configuration. It seemed to compile fine, but again failed at the link with several undefined symbols: _OPENSSL_ia32cap_P, _OPENSSL_ia32_cpuid, _md5_block_asm_data_order, _sha1_block_data_order, _sha256_block_data_order, and _sha512_block_data_order. My goal is to obtain a static library(ies) and associated header files that I can use to compile my application that uses OpenSSL on Windows. Where can I obtain these pre-built binaries? Jay ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Windows Compile Fails
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Thomas J. Hruska > Sent: Thursday, June 18, 2015 22:56 > > On 6/18/2015 4:46 PM, Jay Foster wrote: > > I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL > > 1.0.2c for Windows, but get a linking error > > What Command Prompt are you running? You have to use the correct > "Native Tools" for the target hardware type. If you are building > VC-WIN32, then you are targeting 32-bit hardware and need to run the x86 > Native Tools Command Prompt (not the x64 version). You can't mix and > match targets. More generally, the compiler bitness has to match the bitness you configure the OpenSSL build for. The Visual Studio "command prompt" shortcuts set up the appropriate environment, but you can also do it using the various batch files supplied with VS (vcvars32.bat, etc), or by setting the appropriate paths and other environment variables manually. (I build OpenSSL for Windows from a Cygwin bash shell, using Visual Studio, and I have bash functions that set up the appropriate build environments.) The bitness of the OS doesn't matter. You can cross-compile x64 binaries on 32-bit Windows and vice versa. When we build OpenSSL for Windows as part of our integration / automated build process, we have our own wrapper scripts that build both bitnesses in separate build directories, using the same build machine. A quick check is to run "cl" with no parameters from the command line you're using for OpenSSL. It will say something like "Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for x86" or "... for x64". -- Michael Wojcik Technology Specialist, Micro Focus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Bug 1.0.1f - selfsign ignores email_in_dn setting
When the CSR contains an email address and the email_in_dn setting in the config file is set to "no" the email address is actually present in the issuer DN but not in the subject DN. This causes errors when verifying certificate chains since the subject hash is used to identify a cert but the issuer hash is different. A dirty workaround is to 1) link the subject hash to the cert file and additionally 2) link the issuer hash to the same cert file ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
