Binaries Openssl

0 views
Skip to first unread message

Midas Souza

unread,
Aug 4, 2024, 4:33:38 PM8/4/24
to poecesrisign
Ihave a question about how and what is the version of OpenSSl that I must install in Windows to later create certificates.Install a one version (openssl-1.0.2d-fips-2.0.10) found in SourceForge but it does not generate the files correctly.There is also the official website , but I do not know how to install it and how, so that when it comes to generating the keys and .pem file, it works.Generate some environment variables that point to the folder where I unzipped the downloaded, I do not know if it is the correct way.

I also wanted to create OPEN SSL for Windows 10. An easy way to do it without running into a risk of installing unknown software from 3rd party websites and risking entries of viruses, is by using the openssl.exe that comes inside your Git for Windows installation. In my case, I found the open SSL in the following location of Git for Windows Installation.


If you also want instructions on how to use OPENSSL to generate and use Certificates, here is a write-up on my blog. The step by step instructions first explains how to use Microsoft Windows Default Tool and also OPEN SSL and explains the difference between them.


The point is that many who've implemented WSL may not realize they can call upon ANY linux command (within their underlying WSL linux vm) right from the DOS or powershell command-line this way. (It's easy to fall into thinking the point of WSL is to use it to "shell into the vm", which is indeed an option, but the power to just run linux commands from Windows is a real value-add of WSL.)


And to be clear, in doing the command as above, whatever file names or folders you may point to (or create) will be relative to the Windows folder from which you run the command. So doing for example, openssl req to create a self-signed cert, where you may name -keyout selfsigned.key -out selfsigned.crt, those two files will be created in the Windows folder where you ran the command.


That said, there are ways this could fall down for some openssl command examples one may find, such as if they tried to use various bash-specific arguments, in which case "shelling into wsl" to run the command may well be the better choice. You could still direct things to be found or placed on the host, but I don't mean this answer to become overly-focused on such WSL aspects. I just wanted to propose it as another alternative to installing openssl.


I recently needed to document how to get a version of it installed, so I've copied my steps here, as the other answers were using different sources from what I recommend, which is Cygwin. I like Cygwin because it is well maintained and provides a wealth of other utilities for Windows. Cygwin also allows you to easily update the versions as needed when vulnerabilities are fixed. Please update your version of OpenSSL often!


I installed openssl 3.0.0 from then I go to windows start ->openssl->Win64 OpenSSL Command Prompt, it opens a window like regular dos window, all I need is to go to the installation folder of openssl.


However, the user skill level can vary a lot. Even just selecting a dialog to choose the directory where openssl is placed may be too hard for some, but I will have to solve that by either auto detection or good help/manual.


The standard location selected by OpenSSL on Unix and Unix-like operating systems is /usr/local/ssl. Header files are located in /usr/local/ssl/include, and library files are located in /usr/local/ssl/lib. Also see the INSTALL file and Compilation and Installation on the OpenSSL wiki.


For OpenSSL, the library is not Universal Binary safe, and its technically not feasible to build with multiple architectures. For the first item, not Universal Binary safe, that's because each configuration of OpenSSL produces a unique . For the second item, technically not feasible, you can't specify -arch i386 -arch x86_64 because it causes a compile failure due to the recipe to build the static archives.


Both can be worked around, but I'm not aware of a reference on the subject. I work closely with the libraries, so I happen to know about the problems and the fixes. I was just talking to some of the OpenSSL devs about creating a wiki page on Universal Binaries for Apple platforms.


The way to do such universal binary is to compile for each archtitecture separately. Then you can merge the libray files with the lipo tool into one.The header files which are different you can rename these files.


I have been able to successfully build openssl 1.1.1.9 in windows 10 following the instructions in the release. I am using Microsoft visual studio 2019 + strawberry perl + nasm. I ran the following config command using the x64 native tools command prompt for vs 2019:


I was once able to do this following the above steps for an older version of python. That version shipped with openssl 1.1.3 (could be 4) and I built the dlls for 1.1.6 (could be 7) and replaced them and python had no issues. Is it possible that the default configuration scripts have changed over these versions such that the default windows x64 configuration no longer builds openssl in a way that works with python and I therefore need to use custom settings?


However, you may need to patch one file in OpenSSL, which will be the bit that looks for its current executable to load the function table (either in uplink.c or applink.c, I forget right now). In CPython, this table is in _ssl.pyd, so we have a little patch that looks there as well. cpython/openssl.vcxproj at 1e5d33e9b9b8631b36f061103a30208b206fd03a python/cpython GitHub


As long as you do not use any fancy config options, you can just swap out libcrypto and libssl with a newer version. OpenSSL patch releases are ABI backwards compatible. Some options affect ABI, e.g. OpenSSL builds without TLS 1.0.


It would be great if you could automatically update the underlying openssl version using a pip command or something similar. That would decouple the act of updating openssl from updating the python version itself. openssl security updates can then be delivered as soon as they are available without needing to wait until a new python release, and users can update openssl without being forced to update their python version.


what we did till now for python is , got the source code of 3.9.2 and built it on Vs 2017 and generated all pyd, dlls etc. Next step we thought we need to link it to openssl 1.0.2 by replacing the include dir and libs in vcproj of _ssl.vcproj and rebuild again


Adding /usr/bin/openssl before anaconda in $PATH environment variable didn't work since it requires to specify the whole bin directory in $PATH not just the executable openssl. Adding /usr/bin directory to $PATH before /home/user/anaconda3/bin creates another issue for me since it causes the python version of system installation to take precedence over the anaconda python version something that I'm avoiding due to my setup.


The application documentation claims that all I need to do is update the libeay32.dll and openssl32.dll files in the installation directory and "For more information on obtaining and building OpenSSL DLLS, visit the OpenSSL web site at www.openssl.org "


However I have looked around the website, downloaded the latest version and looked through the files, even searched the FAQ section, but I cannot for the life of me find where these files are available. I understand that they have since been re-named, however I cannot find them under the new names either.


Back in the day the process was to download the source (Luke), untar and unzip it, run a command to look at your local environment to find what it needs and it would set up a bunch of configuration files including a whole lot of paths so you could then execute a build. The last part of doing a build is to link against your libraries. That is the approach I would refer to had I had to do it.


My point is that simply replacing a .DLL may give your application matching entry points by name, but anything like a different list of arguments will cause the application going into the library to trip and fall or something subtle.


My application is up to date, I am not sure why it does not ship with the latest encryption algorithms. I will see if this is perhaps something our MSP can help us with, and if not, look into another solution for my current requirement. Thank you!


Most of us are been taking care of getting to TLS 1.2-only and modern PCI compliance. Back around 2012 we went to 2048 bit keys and somewhere about 2014 we started writing off SSL 2.0, 3.0, TLS 1.0 and 1.1 and phasing out SHA1 and doing SHA2 / SHA256. There is a whole long list of ciphers.


As much of the world as I have seen, support for SSL is either Schannel from Microsoft-- built into your version of Windows. Or if it is Linux / or open source based the implementation is usually openssl. Might be something from Google.


Anyhow if it is an application and you have the source, you could re-build it. But better yet, go to the project website and get the newest version. If it is more than a year old, you are not current. Last summer is when we all had to go TLS1.2-only for PCI reasons.


If its firmware on a device, its the same story. You either need the latest firmware or replace the device. Of course, many vendors require you to have a support contract or such. One thing about TLS 1.0/1.1 and the older is that I did see vendors write patches that outright removed the support for those old versions of TLS or at least changed the default configuration value to off rather than on.


it fails with the message "unable to find local issuer certificate". I understand this happens because the new version of openssl cannot find certificates against which it should verify profiles. So my question is


If this does not point to /usr/bin/openssl, you could probably try verifying that the "original" (most likely) openssl still exists in /usr/bin/openssl by executing "file /usr/bin/openssl". This should return something like the following:


If your "which" command points to another location then /usr/bin, and the file command verifies that the original binary is still in place, you could probably try to verify your mobile provisioning files with that.

3a8082e126
Reply all
Reply to author
Forward
0 new messages