Build and Install
This document describes installation on all supported operating
systems (the Unix/Linux family, including macOS), OpenVMS,
and Windows).
Table of Contents
- Prerequisites
- Notational Conventions
- Quick Installation Guide
- Building OpenSSL
- Installing OpenSSL
- Configuration Options
- API Level
- Cross Compile Prefix
- Build Type
- Directories
- Compiler Warnings
- Compression Algorithm Flags
- Seeding the Random Generator
- Setting the FIPS HMAC key
- Enable and Disable Features
- Displaying configuration data
- Installation Steps in Detail
- Configure
- Build
- Test
- Install
- Advanced Build Options
- Environment Variables
- Makefile Targets
- Running Selected Tests
- Troubleshooting
- Configuration Problems
- Build Failures
- Test Failures
- Notes
- Notes on multi-threading
- Notes on shared libraries
- Notes on random number generation
- Notes on assembler modules compilation
Prerequisites
To install OpenSSL, you will need:
- A «make» implementation
- Perl 5 with core modules (please read NOTES-PERL.md)
- The Perl module
Text::Template(please read NOTES-PERL.md) - an ANSI C compiler
- a development environment in the form of development libraries and C
header files - a supported operating system
For additional platform specific requirements, solutions to specific
issues and other details, please read one of these:
- Notes for UNIX-like platforms
- Notes for Android platforms
- Notes for Windows platforms
- Notes for the DOS platform with DJGPP
- Notes for the OpenVMS platform
- Notes on Perl
- Notes on Valgrind
Notational conventions
Throughout this document, we use the following conventions.
Commands
Any line starting with a dollar sign is a command line.
The dollar sign indicates the shell prompt and is not to be entered as
part of the command.
Choices
Several words in curly braces separated by pipe characters indicate a
mandatory choice, to be replaced with one of the given words.
For example, the line
$ echo { WORD1 | WORD2 | WORD3 }
represents one of the following three commands
$ echo WORD1
- or -
$ echo WORD2
- or -
$ echo WORD3
One or several words in square brackets separated by pipe characters
denote an optional choice. It is similar to the mandatory choice,
but it can also be omitted entirely.
So the line
$ echo [ WORD1 | WORD2 | WORD3 ]
represents one of the four commands
$ echo WORD1
- or -
$ echo WORD2
- or -
$ echo WORD3
- or -
$ echo
Arguments
Optional Arguments are enclosed in square brackets.
A trailing ellipsis means that more than one could be specified.
Quick Installation Guide
If you just want to get OpenSSL installed without bothering too much
about the details, here is the short version of how to build and install
OpenSSL. If any of the following steps fails, please consult the
Installation in Detail section below.
Building OpenSSL
Use the following commands to configure, build and test OpenSSL.
The testing is optional, but recommended if you intend to install
OpenSSL for production use.
Unix / Linux / macOS
$ ./Configure
$ make
$ make test
OpenVMS
Use the following commands to build OpenSSL:
$ perl Configure
$ mms
$ mms test
Windows
If you are using Visual Studio, open a Developer Command Prompt and
issue the following commands to build OpenSSL.
$ perl Configure
$ nmake
$ nmake test
As mentioned in the Choices section, you need to pick one
of the four Configure targets in the first command.
Most likely you will be using the VC-WIN64A target for 64bit Windows
binaries (AMD64) or VC-WIN32 for 32bit Windows binaries (X86).
The other two options are VC-WIN64I (Intel IA64, Itanium) and
VC-CE (Windows CE) are rather uncommon nowadays.
Installing OpenSSL
The following commands will install OpenSSL to a default system location.
Danger Zone: even if you are impatient, please read the following two
paragraphs carefully before you install OpenSSL.
For security reasons the default system location is by default not writable
for unprivileged users. So for the final installation step administrative
privileges are required. The default system location and the procedure to
obtain administrative privileges depends on the operating system.
It is recommended to compile and test OpenSSL with normal user privileges
and use administrative privileges only for the final installation step.
On some platforms OpenSSL is preinstalled as part of the Operating System.
In this case it is highly recommended not to overwrite the system versions,
because other applications or libraries might depend on it.
To avoid breaking other applications, install your copy of OpenSSL to a
different location which is not in
the global search path for system libraries.
Finally, if you plan on using the FIPS module, you need to read the
Post-installation Notes further down.
Unix / Linux / macOS
Depending on your distribution, you need to run the following command as
root user or prepend sudo to the command:
By default, OpenSSL will be installed to
More precisely, the files will be installed into the subdirectories
/usr/local/bin
/usr/local/lib
/usr/local/include
...
depending on the file type, as it is custom on Unix-like operating systems.
OpenVMS
Use the following command to install OpenSSL.
By default, OpenSSL will be installed to
Windows
If you are using Visual Studio, open the Developer Command Prompt elevated
and issue the following command.
The easiest way to elevate the Command Prompt is to press and hold down both
the <CTRL> and <SHIFT> keys while clicking the menu item in the task menu.
The default installation location is
for native binaries, or
C:Program Files (x86)OpenSSL
for 32bit binaries on 64bit Windows (WOW64).
Installing to a different location
To install OpenSSL to a different location (for example into your home
directory for testing purposes) run Configure as shown in the following
examples.
The options --prefix and --openssldir are explained in further detail in
Directories below, and the values used here are mere examples.
On Unix:
$ ./Configure --prefix=/opt/openssl --openssldir=/usr/local/ssl
On OpenVMS:
$ perl Configure --prefix=PROGRAM:[INSTALLS] --openssldir=SYS$MANAGER:[OPENSSL]
Note: if you do add options to the configuration command, please make sure
you’ve read more than just this Quick Start, such as relevant NOTES-* files,
the options outline below, as configuration options may change the outcome
in otherwise unexpected ways.
Configuration Options
There are several options to ./Configure to customize the build (note that
for Windows, the defaults for --prefix and --openssldir depend on what
configuration is used and what Windows implementation OpenSSL is built on.
For more information, see the Notes for Windows platforms.
API Level
Build the OpenSSL libraries to support the API for the specified version.
If no-deprecated is also given, don’t build with support
for deprecated APIs in or below the specified version number. For example,
adding
--api=1.1.0 no-deprecated
will remove support for all APIs that were deprecated in OpenSSL version
1.1.0 or below. This is a rather specialized option for developers.
If you just intend to remove all deprecated APIs up to the current version
entirely, just specify no-deprecated.
If --api isn’t given, it defaults to the current (minor) OpenSSL version.
Cross Compile Prefix
--cross-compile-prefix=<PREFIX>
The <PREFIX> to include in front of commands for your toolchain.
It is likely to have to end with dash, e.g. a-b-c- would invoke GNU compiler
as a-b-c-gcc, etc. Unfortunately cross-compiling is too case-specific to put
together one-size-fits-all instructions. You might have to pass more flags or
set up environment variables to actually make it work. Android and iOS cases
are discussed in corresponding Configurations/15-*.conf files. But there are
cases when this option alone is sufficient. For example to build the mingw64
target on Linux --cross-compile-prefix=x86_64-w64-mingw32- works. Naturally
provided that mingw packages are installed. Today Debian and Ubuntu users
have option to install a number of prepackaged cross-compilers along with
corresponding run-time and development packages for «alien» hardware. To give
another example --cross-compile-prefix=mipsel-linux-gnu- suffices in such
case.
For cross compilation, you must configure manually.
Also, note that --openssldir refers to target’s file system, not one you are
building on.
Build Type
Build OpenSSL with debugging symbols and zero optimization level.
Build OpenSSL without debugging symbols. This is the default.
Directories
libdir
The name of the directory under the top of the installation directory tree
(see the --prefix option) where libraries will be installed. By default
this is lib. Note that on Windows only static libraries (*.lib) will
be stored in this location. Shared libraries (*.dll) will always be
installed to the bin directory.
Some build targets have a multilib postfix set in the build configuration.
For these targets the default libdir is lib<multilib-postfix>. Please use
--libdir=lib to override the libdir if adding the postfix is undesirable.
openssldir
Directory for OpenSSL configuration files, and also the default certificate
and key store. Defaults are:
Unix: /usr/local/ssl
Windows: C:Program FilesCommon FilesSSL
OpenVMS: SYS$COMMON:[OPENSSL-COMMON]
For 32bit Windows applications on Windows 64bit (WOW64), always replace
C:Program Files by C:Program Files (x86).
prefix
The top of the installation directory tree. Defaults are:
Unix: /usr/local
Windows: C:Program FilesOpenSSL
OpenVMS: SYS$COMMON:[OPENSSL]
Compiler Warnings
This is a developer flag that switches on various compiler options recommended
for OpenSSL development. It only works when using gcc or clang as the compiler.
If you are developing a patch for OpenSSL then it is recommended that you use
this option where possible.
Compression Algorithm Flags
with-brotli-include
--with-brotli-include=DIR
The directory for the location of the brotli include files (i.e. the location
of the brotli include directory). This option is only necessary if
enable-brotli is used and the include files are not already
on the system include path.
with-brotli-lib
On Unix: this is the directory containing the brotli libraries.
If not provided, the system library path will be used.
The names of the libraries are:
- libbrotlicommon.a or libbrotlicommon.so
- libbrotlidec.a or libbrotlidec.so
- libbrotlienc.a or libbrotlienc.so
On Windows: this is the directory containing the brotli libraries.
If not provided, the system library path will be used.
The names of the libraries are:
- brotlicommon.lib
- brotlidec.lib
- brotlienc.lib
with-zlib-include
The directory for the location of the zlib include file. This option is only
necessary if zlib is used and the include file is not
already on the system include path.
with-zlib-lib
On Unix: this is the directory containing the zlib library.
If not provided the system library path will be used.
On Windows: this is the filename of the zlib library (with or
without a path). This flag must be provided if the
zlib-dynamic option is not also used. If zlib-dynamic is used
then this flag is optional and defaults to ZLIB1 if not provided.
On VMS: this is the filename of the zlib library (with or without a path).
This flag is optional and if not provided then GNV$LIBZSHR, GNV$LIBZSHR32
or GNV$LIBZSHR64 is used by default depending on the pointer size chosen.
with-zstd-include
The directory for the location of the Zstd include file. This option is only
necessary if enable-std is used and the include file is not
already on the system include path.
OpenSSL requires Zstd 1.4 or greater. The Linux kernel source contains a
zstd.h file that is not compatible with the 1.4.x Zstd distribution, the
compilation will generate an error if the Linux zstd.h is included before
(or instead of) the Zstd distribution header.
with-zstd-lib
On Unix: this is the directory containing the Zstd library.
If not provided the system library path will be used.
On Windows: this is the filename of the Zstd library (with or
without a path). This flag must be provided if the
enable-zstd-dynamic option is not also used.
If zstd-dynamic is used then this flag is optional and defaults
to LIBZSTD if not provided.
Seeding the Random Generator
--with-rand-seed=seed1[,seed2,...]
A comma separated list of seeding methods which will be tried by OpenSSL
in order to obtain random input (a.k.a «entropy») for seeding its
cryptographically secure random number generator (CSPRNG).
The current seeding methods are:
os
Use a trusted operating system entropy source.
This is the default method if such an entropy source exists.
getrandom
Use the getrandom(2) or equivalent system call.
devrandom
Use the first device from the DEVRANDOM list which can be opened to read
random bytes. The DEVRANDOM preprocessor constant expands to
"/dev/urandom","/dev/random","/dev/srandom"
on most unix-ish operating systems.
egd
Check for an entropy generating daemon.
This source is ignored by the FIPS provider.
rdcpu
Use the RDSEED or RDRAND command on x86 or RNDRRS command on aarch64
if provided by the CPU.
librandom
Use librandom (not implemented yet).
This source is ignored by the FIPS provider.
none
Disable automatic seeding. This is the default on some operating systems where
no suitable entropy source exists, or no support for it is implemented yet.
This option is ignored by the FIPS provider.
For more information, see the section Notes on random number generation
at the end of this document.
Setting the FIPS HMAC key
As part of its self-test validation, the FIPS module must verify itself
by performing a SHA-256 HMAC computation on itself. The default key is
the SHA256 value of «the holy handgrenade of antioch» and is sufficient
for meeting the FIPS requirements.
To change the key to a different value, use this flag. The value should
be a hex string no more than 64 characters.
Enable and Disable Features
Feature options always come in pairs, an option to enable feature
xxxx, and an option to disable it:
[ enable-xxxx | no-xxxx ]
Whether a feature is enabled or disabled by default, depends on the feature.
In the following list, always the non-default variant is documented: if
feature xxxx is disabled by default then enable-xxxx is documented and
if feature xxxx is enabled by default then no-xxxx is documented.
no-afalgeng
Don’t build the AFALG engine.
This option will be forced on a platform that does not support AFALG.
enable-ktls
Build with Kernel TLS support.
This option will enable the use of the Kernel TLS data-path, which can improve
performance and allow for the use of sendfile and splice system calls on
TLS sockets. The Kernel may use TLS accelerators if any are available on the
system. This option will be forced off on systems that do not support the
Kernel TLS data-path.
enable-asan
Build with the Address sanitiser.
This is a developer option only. It may not work on all platforms and should
never be used in production environments. It will only work when used with
gcc or clang and should be used in conjunction with the no-shared
option.
enable-acvp-tests
Build support for Automated Cryptographic Validation Protocol (ACVP)
tests.
This is required for FIPS validation purposes. Certain ACVP tests require
access to algorithm internals that are not normally accessible.
Additional information related to ACVP can be found at
https://github.com/usnistgov/ACVP.
no-asm
Do not use assembler code.
This should be viewed as debugging/troubleshooting option rather than for
production use. On some platforms a small amount of assembler code may still
be used even with this option.
no-async
Do not build support for async operations.
no-autoalginit
Don’t automatically load all supported ciphers and digests.
Typically OpenSSL will make available all of its supported ciphers and digests.
For a statically linked application this may be undesirable if small executable
size is an objective. This only affects libcrypto. Ciphers and digests will
have to be loaded manually using EVP_add_cipher() and EVP_add_digest()
if this option is used. This option will force a non-shared build.
no-autoerrinit
Don’t automatically load all libcrypto/libssl error strings.
Typically OpenSSL will automatically load human readable error strings. For a
statically linked application this may be undesirable if small executable size
is an objective.
enable-brotli
Build with support for brotli compression/decompression.
enable-brotli-dynamic
Like the enable-brotli option, but has OpenSSL load the brotli library dynamically
when needed.
This is only supported on systems where loading of shared libraries is supported.
no-autoload-config
Don’t automatically load the default openssl.cnf file.
Typically OpenSSL will automatically load a system config file which configures
default SSL options.
enable-buildtest-c++
While testing, generate C++ buildtest files that simply check that the public
OpenSSL header files are usable standalone with C++.
Enabling this option demands extra care. For any compiler flag given directly
as configuration option, you must ensure that it’s valid for both the C and
the C++ compiler. If not, the C++ build test will most likely break. As an
alternative, you can use the language specific variables, CFLAGS and CXXFLAGS.
—banner=text
Use the specified text instead of the default banner at the end of
configuration.
—w
On platforms where the choice of 32-bit or 64-bit architecture
is not explicitly specified, Configure will print a warning
message and wait for a few seconds to let you interrupt the
configuration. Using this flag skips the wait.
no-bulk
Build only some minimal set of features.
This is a developer option used internally for CI build tests of the project.
no-cached-fetch
Never cache algorithms when they are fetched from a provider. Normally, a
provider indicates if the algorithms it supplies can be cached or not. Using
this option will reduce run-time memory usage but it also introduces a
significant performance penalty. This option is primarily designed to help
with detecting incorrect reference counting.
no-capieng
Don’t build the CAPI engine.
This option will be forced if on a platform that does not support CAPI.
no-cmp
Don’t build support for Certificate Management Protocol (CMP)
and Certificate Request Message Format (CRMF).
no-cms
Don’t build support for Cryptographic Message Syntax (CMS).
no-comp
Don’t build support for SSL/TLS compression.
If this option is enabled (the default), then compression will only work if
the zlib or zlib-dynamic options are also chosen.
enable-crypto-mdebug
This now only enables the failed-malloc feature.
enable-crypto-mdebug-backtrace
This is a no-op; the project uses the compiler’s address/leak sanitizer instead.
no-ct
Don’t build support for Certificate Transparency (CT).
no-deprecated
Don’t build with support for deprecated APIs up until and including the version
given with --api (or the current version, if --api wasn’t specified).
no-dgram
Don’t build support for datagram based BIOs.
Selecting this option will also force the disabling of DTLS.
no-dso
Don’t build support for loading Dynamic Shared Objects (DSO)
enable-devcryptoeng
Build the /dev/crypto engine.
This option is automatically selected on the BSD platform, in which case it can
be disabled with no-devcryptoeng.
no-dynamic-engine
Don’t build the dynamically loaded engines.
This only has an effect in a shared build.
no-ec
Don’t build support for Elliptic Curves.
no-ec2m
Don’t build support for binary Elliptic Curves
enable-ec_nistp_64_gcc_128
Enable support for optimised implementations of some commonly used NIST
elliptic curves.
This option is only supported on platforms:
- with little-endian storage of non-byte types
- that tolerate misaligned memory references
- where the compiler:
- supports the non-standard type
__uint128_t - defines the built-in macro
__SIZEOF_INT128__
- supports the non-standard type
enable-egd
Build support for gathering entropy from the Entropy Gathering Daemon (EGD).
no-engine
Don’t build support for loading engines.
no-err
Don’t compile in any error strings.
enable-external-tests
Enable building of integration with external test suites.
This is a developer option and may not work on all platforms. The following
external test suites are currently supported:
- GOST engine test suite
- Python PYCA/Cryptography test suite
- krb5 test suite
See the file test/README-external.md
for further details.
no-filenames
Don’t compile in filename and line number information (e.g. for errors and
memory allocation).
enable-fips
Build (and install) the FIPS provider
no-fips-securitychecks
Don’t perform FIPS module run-time checks related to enforcement of security
parameters such as minimum security strength of keys.
enable-fuzz-libfuzzer, enable-fuzz-afl
Build with support for fuzzing using either libfuzzer or AFL.
These are developer options only. They may not work on all platforms and
should never be used in production environments.
See the file fuzz/README.md for further details.
no-gost
Don’t build support for GOST based ciphersuites.
Note that if this feature is enabled then GOST ciphersuites are only available
if the GOST algorithms are also available through loading an externally supplied
engine.
no-legacy
Don’t build the legacy provider.
Disabling this also disables the legacy algorithms: MD2 (already disabled by default).
no-makedepend
Don’t generate dependencies.
no-module
Don’t build any dynamically loadable engines.
This also implies no-dynamic-engine.
no-multiblock
Don’t build support for writing multiple records in one go in libssl
Note: this is a different capability to the pipelining functionality.
no-nextprotoneg
Don’t build support for the Next Protocol Negotiation (NPN) TLS extension.
no-ocsp
Don’t build support for Online Certificate Status Protocol (OCSP).
no-padlockeng
Don’t build the padlock engine.
no-hw-padlock
As synonym for no-padlockeng. Deprecated and should not be used.
no-pic
Don’t build with support for Position Independent Code.
no-pinshared
Don’t pin the shared libraries.
By default OpenSSL will attempt to stay in memory until the process exits.
This is so that libcrypto and libssl can be properly cleaned up automatically
via an atexit() handler. The handler is registered by libcrypto and cleans
up both libraries. On some platforms the atexit() handler will run on unload of
libcrypto (if it has been dynamically loaded) rather than at process exit. This
option can be used to stop OpenSSL from attempting to stay in memory until the
process exits. This could lead to crashes if either libcrypto or libssl have
already been unloaded at the point that the atexit handler is invoked, e.g. on a
platform which calls atexit() on unload of the library, and libssl is unloaded
before libcrypto then a crash is likely to happen. Applications can suppress
running of the atexit() handler at run time by using the
OPENSSL_INIT_NO_ATEXIT option to OPENSSL_init_crypto().
See the man page for it for further details.
no-posix-io
Don’t use POSIX IO capabilities.
no-psk
Don’t build support for Pre-Shared Key based ciphersuites.
no-rdrand
Don’t use hardware RDRAND capabilities.
no-rfc3779
Don’t build support for RFC3779, «X.509 Extensions for IP Addresses and
AS Identifiers».
sctp
Build support for Stream Control Transmission Protocol (SCTP).
no-shared
Do not create shared libraries, only static ones.
See Notes on shared libraries below.
no-sock
Don’t build support for socket BIOs.
no-srp
Don’t build support for Secure Remote Password (SRP) protocol or
SRP based ciphersuites.
no-srtp
Don’t build Secure Real-Time Transport Protocol (SRTP) support.
no-sse2
Exclude SSE2 code paths from 32-bit x86 assembly modules.
Normally SSE2 extension is detected at run-time, but the decision whether or not
the machine code will be executed is taken solely on CPU capability vector. This
means that if you happen to run OS kernel which does not support SSE2 extension
on Intel P4 processor, then your application might be exposed to «illegal
instruction» exception. There might be a way to enable support in kernel, e.g.
FreeBSD kernel can be compiled with CPU_ENABLE_SSE, and there is a way to
disengage SSE2 code paths upon application start-up, but if you aim for wider
«audience» running such kernel, consider no-sse2. Both the 386 and no-asm
options imply no-sse2.
no-ssl-trace
Don’t build with SSL Trace capabilities.
This removes the -trace option from s_client and s_server, and omits the
SSL_trace() function from libssl.
Disabling ssl-trace may provide a small reduction in libssl binary size.
no-static-engine
Don’t build the statically linked engines.
This only has an impact when not built «shared».
no-stdio
Don’t use anything from the C header file stdio.h that makes use of the FILE
type. Only libcrypto and libssl can be built in this way. Using this option will
suppress building the command line applications. Additionally, since the OpenSSL
tests also use the command line applications, the tests will also be skipped.
no-tests
Don’t build test programs or run any tests.
enable-tfo
Build with support for TCP Fast Open (RFC7413). Supported on Linux, macOS and FreeBSD.
enable-quic
Build with QUIC support. This is currently just for developers as the
implementation is by no means complete and usable.
no-threads
Don’t build with support for multi-threaded applications.
threads
Build with support for multi-threaded applications. Most platforms will enable
this by default. However, if on a platform where this is not the case then this
will usually require additional system-dependent options!
See Notes on multi-threading below.
no-thread-pool
Don’t build with support for thread pool functionality.
thread-pool
Build with thread pool functionality. If enabled, OpenSSL algorithms may
use the thread pool to perform parallel computation. This option in itself
does not enable OpenSSL to spawn new threads. Currently the only supported
thread pool mechanism is the default thread pool.
no-default-thread-pool
Don’t build with support for default thread pool functionality.
default-thread-pool
Build with default thread pool functionality. If enabled, OpenSSL may create
and manage threads up to a maximum number of threads authorized by the
application. Supported on POSIX compliant platforms and Windows.
enable-trace
Build with support for the integrated tracing api.
See manual pages OSSL_trace_set_channel(3) and OSSL_trace_enabled(3) for details.
no-ts
Don’t build Time Stamping (TS) Authority support.
enable-ubsan
Build with the Undefined Behaviour sanitiser (UBSAN).
This is a developer option only. It may not work on all platforms and should
never be used in production environments. It will only work when used with
gcc or clang and should be used in conjunction with the -DPEDANTIC option
(or the --strict-warnings option).
no-ui-console
Don’t build with the User Interface (UI) console method
The User Interface console method enables text based console prompts.
enable-unit-test
Enable additional unit test APIs.
This should not typically be used in production deployments.
no-uplink
Don’t build support for UPLINK interface.
enable-weak-ssl-ciphers
Build support for SSL/TLS ciphers that are considered «weak»
Enabling this includes for example the RC4 based ciphersuites.
zlib
Build with support for zlib compression/decompression.
zlib-dynamic
Like the zlib option, but has OpenSSL load the zlib library dynamically
when needed.
This is only supported on systems where loading of shared libraries is supported.
enable-zstd
Build with support for Zstd compression/decompression.
enable-zstd-dynamic
Like the enable-zstd option, but has OpenSSL load the Zstd library dynamically
when needed.
This is only supported on systems where loading of shared libraries is supported.
386
In 32-bit x86 builds, use the 80386 instruction set only in assembly modules
The default x86 code is more efficient, but requires at least an 486 processor.
Note: This doesn’t affect compiler generated code, so this option needs to be
accompanied by a corresponding compiler-specific option.
no-{protocol}
no-{ssl|ssl3|tls|tls1|tls1_1|tls1_2|tls1_3|dtls|dtls1|dtls1_2}
Don’t build support for negotiating the specified SSL/TLS protocol.
If no-tls is selected then all of tls1, tls1_1, tls1_2 and tls1_3
are disabled.
Similarly no-dtls will disable dtls1 and dtls1_2. The no-ssl option is
synonymous with no-ssl3. Note this only affects version negotiation.
OpenSSL will still provide the methods for applications to explicitly select
the individual protocol versions.
no-{protocol}-method
no-{ssl3|tls1|tls1_1|tls1_2|dtls1|dtls1_2}-method
Analogous to no-{protocol} but in addition do not build the methods for
applications to explicitly select individual protocol versions. Note that there
is no no-tls1_3-method option because there is no application method for
TLSv1.3.
Using individual protocol methods directly is deprecated. Applications should
use TLS_method() instead.
enable-{algorithm}
Build with support for the specified algorithm.
no-{algorithm}
no-{aria|bf|blake2|camellia|cast|chacha|cmac|
des|dh|dsa|ecdh|ecdsa|idea|md4|mdc2|ocb|
poly1305|rc2|rc4|rmd160|scrypt|seed|
siphash|siv|sm2|sm3|sm4|whirlpool}
Build without support for the specified algorithm.
The ripemd algorithm is deprecated and if used is synonymous with rmd160.
Compiler-specific options
-Dxxx, -Ixxx, -Wp, -lxxx, -Lxxx, -Wl, -rpath, -R, -framework, -static
These system specific options will be recognised and passed through to the
compiler to allow you to define preprocessor symbols, specify additional
libraries, library directories or other compiler options. It might be worth
noting that some compilers generate code specifically for processor the
compiler currently executes on. This is not necessarily what you might have
in mind, since it might be unsuitable for execution on other, typically older,
processor. Consult your compiler documentation.
Take note of the Environment Variables documentation
below and how these flags interact with those variables.
Additional options that are not otherwise recognised are passed through as
they are to the compiler as well. Unix-style options beginning with a
- or + and Windows-style options beginning with a / are recognised.
Again, consult your compiler documentation.
If the option contains arguments separated by spaces, then the URL-style
notation %20 can be used for the space character in order to avoid having
to quote the option. For example, -opt%20arg gets expanded to -opt arg.
In fact, any ASCII character can be encoded as %xx using its hexadecimal
encoding.
Take note of the Environment Variables documentation
below and how these flags interact with those variables.
Environment Variables
Assign the given value to the environment variable VAR for Configure.
These work just like normal environment variable assignments, but are supported
on all platforms and are confined to the configuration scripts only.
These assignments override the corresponding value in the inherited environment,
if there is one.
The following variables are used as «make variables» and can be used as an
alternative to giving preprocessor, compiler and linker options directly as
configuration. The following variables are supported:
AR The static library archiver.
ARFLAGS Flags for the static library archiver.
AS The assembler compiler.
ASFLAGS Flags for the assembler compiler.
CC The C compiler.
CFLAGS Flags for the C compiler.
CXX The C++ compiler.
CXXFLAGS Flags for the C++ compiler.
CPP The C/C++ preprocessor.
CPPFLAGS Flags for the C/C++ preprocessor.
CPPDEFINES List of CPP macro definitions, separated
by a platform specific character (':' or
space for Unix, ';' for Windows, ',' for
VMS). This can be used instead of using
-D (or what corresponds to that on your
compiler) in CPPFLAGS.
CPPINCLUDES List of CPP inclusion directories, separated
the same way as for CPPDEFINES. This can
be used instead of -I (or what corresponds
to that on your compiler) in CPPFLAGS.
HASHBANGPERL Perl invocation to be inserted after '#!'
in public perl scripts (only relevant on
Unix).
LD The program linker (not used on Unix, $(CC)
is used there).
LDFLAGS Flags for the shared library, DSO and
program linker.
LDLIBS Extra libraries to use when linking.
Takes the form of a space separated list
of library specifications on Unix and
Windows, and as a comma separated list of
libraries on VMS.
RANLIB The library archive indexer.
RC The Windows resource compiler.
RCFLAGS Flags for the Windows resource compiler.
RM The command to remove files and directories.
These cannot be mixed with compiling/linking flags given on the command line.
In other words, something like this isn’t permitted.
$ ./Configure -DFOO CPPFLAGS=-DBAR -DCOOKIE
Backward compatibility note:
To be compatible with older configuration scripts, the environment variables
are ignored if compiling/linking flags are given on the command line, except
for the following:
AR, CC, CXX, CROSS_COMPILE, HASHBANGPERL, PERL, RANLIB, RC, and WINDRES
For example, the following command will not see -DBAR:
$ CPPFLAGS=-DBAR ./Configure -DCOOKIE
However, the following will see both set variables:
$ CC=gcc CROSS_COMPILE=x86_64-w64-mingw32- ./Configure -DCOOKIE
If CC is set, it is advisable to also set CXX to ensure both the C and C++
compiler are in the same «family». This becomes relevant with
enable-external-tests and enable-buildtest-c++.
Reconfigure
Reconfigure from earlier data.
This fetches the previous command line options and environment from data
saved in configdata.pm and runs the configuration process again, using
these options and environment. Note: NO other option is permitted together
with reconf. Note: The original configuration saves away values for ALL
environment variables that were used, and if they weren’t defined, they are
still saved away with information that they weren’t originally defined.
This information takes precedence over environment variables that are
defined when reconfiguring.
Displaying configuration data
The configuration script itself will say very little, and finishes by
creating configdata.pm. This perl module can be loaded by other scripts
to find all the configuration data, and it can also be used as a script to
display all sorts of configuration data in a human readable form.
For more information, please do:
$ ./configdata.pm --help # Unix
or
$ perl configdata.pm --help # Windows and VMS
Installation Steps in Detail
Configure OpenSSL
Automatic Configuration
In previous version, the config script determined the platform type and
compiler and then called Configure. Starting with this release, they are
the same.
Unix / Linux / macOS
$ ./Configure [options...]
OpenVMS
$ perl Configure [options...]
Windows
$ perl Configure [options...]
Manual Configuration
OpenSSL knows about a range of different operating system, hardware and
compiler combinations. To see the ones it knows about, run
$ ./Configure LIST # Unix
or
$ perl Configure LIST # All other platforms
For the remainder of this text, the Unix form will be used in all examples.
Please use the appropriate form for your platform.
Pick a suitable name from the list that matches your system. For most
operating systems there is a choice between using cc or gcc.
When you have identified your system (and if necessary compiler) use this
name as the argument to Configure. For example, a linux-elf user would
run:
$ ./Configure linux-elf [options...]
Creating your own Configuration
If your system isn’t listed, you will have to create a configuration
file named Configurations/YOURFILENAME.conf (replace YOURFILENAME
with a filename of your choosing) and add the correct
configuration for your system. See the available configs as examples
and read Configurations/README.md and
Configurations/README-design.md
for more information.
The generic configurations cc or gcc should usually work on 32 bit
Unix-like systems.
Configure creates a build file (Makefile on Unix, makefile on Windows
and descrip.mms on OpenVMS) from a suitable template in Configurations/,
and defines various macros in include/openssl/configuration.h (generated
from include/openssl/configuration.h.in.
If none of the generated build files suit your purpose, it’s possible to
write your own build file template and give its name through the environment
variable BUILDFILE. For example, Ninja build files could be supported by
writing Configurations/build.ninja.tmpl and then configure with BUILDFILE
set like this (Unix syntax shown, you’ll have to adapt for other platforms):
$ BUILDFILE=build.ninja perl Configure [options...]
Out of Tree Builds
OpenSSL can be configured to build in a build directory separate from the
source code directory. It’s done by placing yourself in some other
directory and invoking the configuration commands from there.
Unix example
$ mkdir /var/tmp/openssl-build
$ cd /var/tmp/openssl-build
$ /PATH/TO/OPENSSL/SOURCE/Configure [options...]
OpenVMS example
$ set default sys$login:
$ create/dir [.tmp.openssl-build]
$ set default [.tmp.openssl-build]
$ perl D:[PATH.TO.OPENSSL.SOURCE]Configure [options...]
Windows example
$ C:
$ mkdir temp-openssl
$ cd temp-openssl
$ perl d:PATHTOOPENSSLSOURCEConfigure [options...]
Paths can be relative just as well as absolute. Configure will do its best
to translate them to relative paths whenever possible.
Build OpenSSL
Build OpenSSL by running:
$ make # Unix
$ mms ! (or mmk) OpenVMS
$ nmake # Windows
This will build the OpenSSL libraries (libcrypto.a and libssl.a on
Unix, corresponding on other platforms) and the OpenSSL binary
(openssl). The libraries will be built in the top-level directory,
and the binary will be in the apps/ subdirectory.
If the build fails, take a look at the Build Failures
subsection of the Troubleshooting section.
Test OpenSSL
After a successful build, and before installing, the libraries should
be tested. Run:
$ make test # Unix
$ mms test ! OpenVMS
$ nmake test # Windows
Warning: you MUST run the tests from an unprivileged account (or disable
your privileges temporarily if your platform allows it).
See test/README.md for further details how run tests.
See test/README-dev.md for guidelines on adding tests.
Install OpenSSL
If everything tests ok, install OpenSSL with
$ make install # Unix
$ mms install ! OpenVMS
$ nmake install # Windows
Note that in order to perform the install step above you need to have
appropriate permissions to write to the installation directory.
The above commands will install all the software components in this
directory tree under <PREFIX> (the directory given with --prefix or
its default):
Unix / Linux / macOS
bin/ Contains the openssl binary and a few other
utility scripts.
include/openssl
Contains the header files needed if you want
to build your own programs that use libcrypto
or libssl.
lib Contains the OpenSSL library files.
lib/engines Contains the OpenSSL dynamically loadable engines.
share/man/man1 Contains the OpenSSL command line man-pages.
share/man/man3 Contains the OpenSSL library calls man-pages.
share/man/man5 Contains the OpenSSL configuration format man-pages.
share/man/man7 Contains the OpenSSL other misc man-pages.
share/doc/openssl/html/man1
share/doc/openssl/html/man3
share/doc/openssl/html/man5
share/doc/openssl/html/man7
Contains the HTML rendition of the man-pages.
OpenVMS
‘arch’ is replaced with the architecture name, ALPHA or IA64,
‘sover’ is replaced with the shared library version (0101 for 1.1), and
‘pz’ is replaced with the pointer size OpenSSL was built with:
[.EXE.'arch'] Contains the openssl binary.
[.EXE] Contains a few utility scripts.
[.include.openssl]
Contains the header files needed if you want
to build your own programs that use libcrypto
or libssl.
[.LIB.'arch'] Contains the OpenSSL library files.
[.ENGINES'sover''pz'.'arch']
Contains the OpenSSL dynamically loadable engines.
[.SYS$STARTUP] Contains startup, login and shutdown scripts.
These define appropriate logical names and
command symbols.
[.SYSTEST] Contains the installation verification procedure.
[.HTML] Contains the HTML rendition of the manual pages.
Additional Directories
Additionally, install will add the following directories under
OPENSSLDIR (the directory given with --openssldir or its default)
for you convenience:
certs Initially empty, this is the default location
for certificate files.
private Initially empty, this is the default location
for private key files.
misc Various scripts.
The installation directory should be appropriately protected to ensure
unprivileged users cannot make changes to OpenSSL binaries or files, or
install engines. If you already have a pre-installed version of OpenSSL as
part of your Operating System it is recommended that you do not overwrite
the system version and instead install to somewhere else.
Package builders who want to configure the library for standard locations,
but have the package installed somewhere else so that it can easily be
packaged, can use
$ make DESTDIR=/tmp/package-root install # Unix
$ mms/macro="DESTDIR=TMP:[PACKAGE-ROOT]" install ! OpenVMS
The specified destination directory will be prepended to all installation
target paths.
Compatibility issues with previous OpenSSL versions
COMPILING existing applications
Starting with version 1.1.0, OpenSSL hides a number of structures that were
previously open. This includes all internal libssl structures and a number
of EVP types. Accessor functions have been added to allow controlled access
to the structures’ data.
This means that some software needs to be rewritten to adapt to the new ways
of doing things. This often amounts to allocating an instance of a structure
explicitly where you could previously allocate them on the stack as automatic
variables, and using the provided accessor functions where you would previously
access a structure’s field directly.
Some APIs have changed as well. However, older APIs have been preserved when
possible.
Post-installation Notes
With the default OpenSSL installation comes a FIPS provider module, which
needs some post-installation attention, without which it will not be usable.
This involves using the following command:
See the openssl-fipsinstall(1) manual for details and examples.
Advanced Build Options
Environment Variables
A number of environment variables can be used to provide additional control
over the build process. Typically these should be defined prior to running
Configure. Not all environment variables are relevant to all platforms.
AR
The name of the ar executable to use.
BUILDFILE
Use a different build file name than the platform default
("Makefile" on Unix-like platforms, "makefile" on native Windows,
"descrip.mms" on OpenVMS). This requires that there is a
corresponding build file template.
See [Configurations/README.md](Configurations/README.md)
for further information.
CC
The compiler to use. Configure will attempt to pick a default
compiler for your platform but this choice can be overridden
using this variable. Set it to the compiler executable you wish
to use, e.g. gcc or clang.
CROSS_COMPILE
This environment variable has the same meaning as for the
"--cross-compile-prefix" Configure flag described above. If both
are set then the Configure flag takes precedence.
HASHBANGPERL
The command string for the Perl executable to insert in the
#! line of perl scripts that will be publicly installed.
Default: /usr/bin/env perl
Note: the value of this variable is added to the same scripts
on all platforms, but it's only relevant on Unix-like platforms.
KERNEL_BITS
This can be the value `32` or `64` to specify the architecture
when it is not "obvious" to the configuration. It should generally
not be necessary to specify this environment variable.
NM
The name of the nm executable to use.
OPENSSL_LOCAL_CONFIG_DIR
OpenSSL comes with a database of information about how it
should be built on different platforms as well as build file
templates for those platforms. The database is comprised of
".conf" files in the Configurations directory. The build
file templates reside there as well as ".tmpl" files. See the
file [Configurations/README.md](Configurations/README.md)
for further information about the format of ".conf" files
as well as information on the ".tmpl" files.
In addition to the standard ".conf" and ".tmpl" files, it is
possible to create your own ".conf" and ".tmpl" files and
store them locally, outside the OpenSSL source tree.
This environment variable can be set to the directory where
these files are held and will be considered by Configure
before it looks in the standard directories.
PERL
The name of the Perl executable to use when building OpenSSL.
Only needed if builing should use a different Perl executable
than what is used to run the Configure script.
RANLIB
The name of the ranlib executable to use.
RC
The name of the rc executable to use. The default will be as
defined for the target platform in the ".conf" file. If not
defined then "windres" will be used. The WINDRES environment
variable is synonymous to this. If both are defined then RC
takes precedence.
WINDRES
See RC.
Makefile Targets
The Configure script generates a Makefile in a format relevant to the specific
platform. The Makefiles provide a number of targets that can be used. Not all
targets may be available on all platforms. Only the most common targets are
described here. Examine the Makefiles themselves for the full list.
all
The target to build all the software components and
documentation.
build_sw
Build all the software components.
THIS IS THE DEFAULT TARGET.
build_docs
Build all documentation components.
clean
Remove all build artefacts and return the directory to a "clean"
state.
depend
Rebuild the dependencies in the Makefiles. This is a legacy
option that no longer needs to be used since OpenSSL 1.1.0.
install
Install all OpenSSL components.
install_sw
Only install the OpenSSL software components.
install_docs
Only install the OpenSSL documentation components.
install_man_docs
Only install the OpenSSL man pages (Unix only).
install_html_docs
Only install the OpenSSL HTML documentation.
install_fips
Install the FIPS provider module configuration file.
list-tests
Prints a list of all the self test names.
test
Build and run the OpenSSL self tests.
uninstall
Uninstall all OpenSSL components.
reconfigure
reconf
Re-run the configuration process, as exactly as the last time
as possible.
update
This is a developer option. If you are developing a patch for
OpenSSL you may need to use this if you want to update
automatically generated files; add new error codes or add new
(or change the visibility of) public API functions. (Unix only).
Running Selected Tests
You can specify a set of tests to be performed
using the make variable TESTS.
See the section Running Selected Tests of
test/README.md.
Troubleshooting
Configuration Problems
Selecting the correct target
The ./Configure script tries hard to guess your operating system, but in some
cases it does not succeed. You will see a message like the following:
$ ./Configure
Operating system: x86-whatever-minix
This system (minix) is not supported. See file INSTALL.md for details.
Even if the automatic target selection by the ./Configure script fails,
chances are that you still might find a suitable target in the Configurations
directory, which you can supply to the ./Configure command,
possibly after some adjustment.
The Configurations/ directory contains a lot of examples of such targets.
The main configuration file is 10-main.conf, which contains all targets that
are officially supported by the OpenSSL team. Other configuration files contain
targets contributed by other OpenSSL users. The list of targets can be found in
a Perl list my %targets = ( ... ).
my %targets = (
...
"target-name" => {
inherit_from => [ "base-target" ],
CC => "...",
cflags => add("..."),
asm_arch => '...',
perlasm_scheme => "...",
},
...
)
If you call ./Configure without arguments, it will give you a list of all
known targets. Using grep, you can lookup the target definition in the
Configurations/ directory. For example the android-x86_64 can be found in
Configurations/15-android.conf.
The directory contains two README files, which explain the general syntax and
design of the configuration files.
- Configurations/README.md
- Configurations/README-design.md
If you need further help, try to search the openssl-users mailing list
or the GitHub Issues for existing solutions. If you don’t find anything,
you can raise an issue to ask a question yourself.
More about our support resources can be found in the SUPPORT file.
Configuration Errors
If the ./Configure or ./Configure command fails with an error message,
read the error message carefully and try to figure out whether you made
a mistake (e.g., by providing a wrong option), or whether the script is
working incorrectly. If you think you encountered a bug, please
raise an issue on GitHub to file a bug report.
Along with a short description of the bug, please provide the complete
configure command line and the relevant output including the error message.
Note: To make the output readable, please add a ‘code fence’ (three backquotes
``` on a separate line) before and after your output:
```
./Configure [your arguments...]
[output...]
```
Build Failures
If the build fails, look carefully at the output. Try to locate and understand
the error message. It might be that the compiler is already telling you
exactly what you need to do to fix your problem.
There may be reasons for the failure that aren’t problems in OpenSSL itself,
for example if the compiler reports missing standard or third party headers.
If the build succeeded previously, but fails after a source or configuration
change, it might be helpful to clean the build tree before attempting another
build. Use this command:
$ make clean # Unix
$ mms clean ! (or mmk) OpenVMS
$ nmake clean # Windows
Assembler error messages can sometimes be sidestepped by using the no-asm
configuration option. See also notes.
Compiling parts of OpenSSL with gcc and others with the system compiler will
result in unresolved symbols on some systems.
If you are still having problems, try to search the openssl-users mailing
list or the GitHub Issues for existing solutions. If you think you
encountered an OpenSSL bug, please raise an issue to file a bug report.
Please take the time to review the existing issues first; maybe the bug was
already reported or has already been fixed.
Test Failures
If some tests fail, look at the output. There may be reasons for the failure
that isn’t a problem in OpenSSL itself (like an OS malfunction or a Perl issue).
You may want increased verbosity, that can be accomplished as described in
section Test Failures of test/README.md.
You may also want to selectively specify which test(s) to perform. This can be
done using the make variable TESTS as described in section Running
Selected Tests of test/README.md.
If you find a problem with OpenSSL itself, try removing any
compiler optimization flags from the CFLAGS line in the Makefile and
run make clean; make or corresponding.
To report a bug please open an issue on GitHub, at
https://github.com/openssl/openssl/issues.
Notes
Notes on multi-threading
For some systems, the OpenSSL Configure script knows what compiler options
are needed to generate a library that is suitable for multi-threaded
applications. On these systems, support for multi-threading is enabled
by default; use the no-threads option to disable (this should never be
necessary).
On other systems, to enable support for multi-threading, you will have
to specify at least two options: threads, and a system-dependent option.
(The latter is -D_REENTRANT on various systems.) The default in this
case, obviously, is not to include support for multi-threading (but
you can still use no-threads to suppress an annoying warning message
from the Configure script.)
OpenSSL provides built-in support for two threading models: pthreads (found on
most UNIX/Linux systems), and Windows threads. No other threading models are
supported. If your platform does not provide pthreads or Windows threads then
you should use Configure with the no-threads option.
For pthreads, all locks are non-recursive. In addition, in a debug build,
the mutex attribute PTHREAD_MUTEX_ERRORCHECK is used. If this is not
available on your platform, you might have to add
-DOPENSSL_NO_MUTEX_ERRORCHECK to your Configure invocation.
(On Linux PTHREAD_MUTEX_ERRORCHECK is an enum value, so a built-in
ifdef test cannot be used.)
Notes on shared libraries
For most systems the OpenSSL Configure script knows what is needed to
build shared libraries for libcrypto and libssl. On these systems
the shared libraries will be created by default. This can be suppressed and
only static libraries created by using the no-shared option. On systems
where OpenSSL does not know how to build shared libraries the no-shared
option will be forced and only static libraries will be created.
Shared libraries are named a little differently on different platforms.
One way or another, they all have the major OpenSSL version number as
part of the file name, i.e. for OpenSSL 1.1.x, 1.1 is somehow part of
the name.
On most POSIX platforms, shared libraries are named libcrypto.so.1.1
and libssl.so.1.1.
on Cygwin, shared libraries are named cygcrypto-1.1.dll and cygssl-1.1.dll
with import libraries libcrypto.dll.a and libssl.dll.a.
On Windows build with MSVC or using MingW, shared libraries are named
libcrypto-1_1.dll and libssl-1_1.dll for 32-bit Windows,
libcrypto-1_1-x64.dll and libssl-1_1-x64.dll for 64-bit x86_64 Windows,
and libcrypto-1_1-ia64.dll and libssl-1_1-ia64.dll for IA64 Windows.
With MSVC, the import libraries are named libcrypto.lib and libssl.lib,
while with MingW, they are named libcrypto.dll.a and libssl.dll.a.
On VMS, shareable images (VMS speak for shared libraries) are named
ossl$libcrypto0101_shr.exe and ossl$libssl0101_shr.exe. However, when
OpenSSL is specifically built for 32-bit pointers, the shareable images
are named ossl$libcrypto0101_shr32.exe and ossl$libssl0101_shr32.exe
instead, and when built for 64-bit pointers, they are named
ossl$libcrypto0101_shr64.exe and ossl$libssl0101_shr64.exe.
Notes on random number generation
Availability of cryptographically secure random numbers is required for
secret key generation. OpenSSL provides several options to seed the
internal CSPRNG. If not properly seeded, the internal CSPRNG will refuse
to deliver random bytes and a «PRNG not seeded error» will occur.
The seeding method can be configured using the --with-rand-seed option,
which can be used to specify a comma separated list of seed methods.
However, in most cases OpenSSL will choose a suitable default method,
so it is not necessary to explicitly provide this option. Note also
that not all methods are available on all platforms. The FIPS provider will
silently ignore seed sources that were not validated.
I) On operating systems which provide a suitable randomness source (in
form of a system call or system device), OpenSSL will use the optimal
available method to seed the CSPRNG from the operating system’s
randomness sources. This corresponds to the option --with-rand-seed=os.
II) On systems without such a suitable randomness source, automatic seeding
and reseeding is disabled (--with-rand-seed=none) and it may be necessary
to install additional support software to obtain a random seed and reseed
the CSPRNG manually. Please check out the manual pages for RAND_add(),
RAND_bytes(), RAND_egd(), and the FAQ for more information.
Notes on assembler modules compilation
Compilation of some code paths in assembler modules might depend on whether the
current assembler version supports certain ISA extensions or not. Code paths
that use the AES-NI, PCLMULQDQ, SSSE3, and SHA extensions are always assembled.
Apart from that, the minimum requirements for the assembler versions are shown
in the table below:
| ISA extension | GNU as | nasm | llvm |
|---|---|---|---|
| AVX | 2.19 | 2.09 | 3.0 |
| AVX2 | 2.22 | 2.10 | 3.1 |
| ADCX/ADOX | 2.23 | 2.10 | 3.3 |
| AVX512 | 2.25 | 2.11.8 | 3.6 (*) |
| AVX512IFMA | 2.26 | 2.11.8 | 6.0 (*) |
| VAES | 2.30 | 2.13.3 | 6.0 (*) |
(*) Even though AVX512 support was implemented in llvm 3.6, prior to version 7.0
an explicit -march flag was apparently required to compile assembly modules. But
then the compiler generates processor-specific code, which in turn contradicts
the idea of performing dispatch at run-time, which is facilitated by the special
variable OPENSSL_ia32cap. For versions older than 7.0, it is possible to work
around the problem by forcing the build procedure to use the following script:
#!/bin/sh
exec clang -no-integrated-as "$@"
instead of the real clang. In which case it doesn’t matter what clang version
is used, as it is the version of the GNU assembler that will be checked.
В эпоху кибервойн единственная разумная позиция – быть параноиком, а это означает, помимо прочего, быть параноиком по поводу обновлений программного обеспечения.
Взять к примеру OpenSSL.
Эта криптографическая библиотека с открытым исходным кодом, которая реализует протоколы Transport Layer Security (TLS) и Secure Sockets Layer (SSL), разработана для «защиты связи по компьютерным сетям от перехвата», но угадайте, что?
С самого начала она была пронизана ошибками.
Это может быть неизбежно, в определенной степени – в конце концов, мы говорим о программном обеспечении.
Несмотря на то, что вы не можете ничего сделать с ошибками, которые еще предстоит идентифицировать, вы можете по крайней мере защитить свои системы от тех ошибок, которые уже исправлены и задокументированы.
Жаль, что официальный сайт OpenSSL предлагает только исходники для Linux.
Хотя дистрибутивы Linux обычно поставляются с OpenSSL, это не никак относится к Windows … или, скажем, «дистрибутивам Windows».
Если вы хотите запустить его, вам нужен бинарник под Windows, и если вы не хотите его собирать самостоятельно, вы должны найти другой вариант.
В этой статье я покажу,как можно настроить OpenSSL в Windows, не имея дело при этом дела со сборкой из исходников.
Содержание
- Шаг 1. Скачать бинарник
- Шаг 2. Запустите установщик
- Шаг 3. Запустите бинарный файл OpenSSL
Шаг 1. Скачать бинарник
Поиск бинарных файлов OpenSSL для Windows – непростая задача, но не отчаивайтесь.
Они существуют.
Чтобы загрузить нужный, перейдите по ссылке:
https://slproweb.com/products/Win32OpenSSL.html
Не дайте себя одурачить ни строкой Win32 в URL-адресе, ни навигацией, указывающей на казалось бы древнюю страницу загрузки еще с 2004 года.
Прокрутите страницу вниз до раздела «Download Win32 OpenSSL».
Теперь вам нужно выбрать правильный файл из этого списка.
Для каждой версии есть два основных типа: light и full.
Загрузите файл под названием «Win64 OpenSSL v1.1.0f» (или версию с более новой версией, как только она станет доступна), чтобы скачать фулл установщик.
Текущая версия на момент написания этой статьи (OpenSSL 1.1.0h) сильно отличается от предыдущих версий.
Это совсем не одно и то же, поэтому обратите внимание на номера релизов!
Худшее, что вы можете сделать, – это использовать старую версию, в которой есть задокументированные ошибки.
Шаг 2. Запустите установщик
Мы рекомендуем установить OpenSSL вне вашей системной директории Windows.
Следуйте инструкциям по установке через GUI.
Шаг 3. Запустите бинарный файл OpenSSL
Чтобы начать работу с OpenSSL, вы можете просто щелкнуть по нему правой кнопкой мыши в проводнике Windows в месте его установки, например в моем случае:
C:OpenSSL-Win64bin
затем выберите «Запуск от имени администратора».
Откроется окно cmd с командной строкой OpenSSL:
Теперь вы можете начать создавать ключи OpenSSL. (Кстати, пользователи утилиты удаленного доступа PuTTY могут экспортировать ключ OpenSSH из PuTTYgen.)
При использовании OpenSSL в Windows таким способом вы просто пропускаете команду openssl, которую видите в приглашении.
Например, чтобы создать пару ключей с помощью OpenSSL в Windows, вы можете ввести:
openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem
и следуйте инструкциям на экране, как обычно.
Чтобы просмотреть сертификат:
openssl x509 -text -noout -in certificate.pem
What is OpenSSL?
OpenSSL is a single-system image clustering system that is open-source. It allows a group of computers to be viewed as a single colossal system, giving programs running on any one machine access to all of the cluster’s resources. [It is the culmination of a long development process that began with the development of LOCUS in the early 1980s.
OpenSSL allows a group of separate computers (nodes) to be regarded as one massive system. Processes running on any node have full access to all node resources.
Functionalities can be automatically transferred from node to node to balance system utilization. Alternatively, the cluster might be set up so that each node has direct access to the file system.
Step 1 Download OpenSSL Binaries
Link to Download OpenSSL binaries files: https://sourceforge.net/projects/openssl/files/
In our article, we are downloading
https://sourceforge.net/projects/openssl/files/openssl-1.0.2j-fips-x86_64/
Step 2 Unpack OpenSSL Zip files
Unpack the content of (openssl-1.0.2j-fips-x86_64.zip) zip file into your desired location in our example we are using (D:OpenSSL) folder
This comes with three folders (bin, include & lib) as shown in the image
Step 3: Set OpenSSL Path in Windows path
We have extracted OpenSSL files in directory D:OpenSSLbin
So our OpenSSL path is D:OpenSSLbin
Open explorer and right-mouse click on This PC icon as shown in the image
Under System About window click on the Advanced system settings button
Under the System Property window click on the Environment Variables button
Under the Advanced Environment window select Path and then click on the Edit button
Under the Environment Variable window click on the New button
Paste the path of OpenSSL (D:OpenSSLbin) and click the OK button
Step 4: Set System Variable for OPENSSL_CONF
Now to set system variable for OPENSSL_CONF
Click on the New button under the System Variable window
Now add system variable values as given, the path to your openssl.conf file location as shown below, and click on the OK button
Name: OPENSSL_CONF
Value: D:OpenSSLbinopenssl.cnf
Now you can see that the system variable is set
For window 10 and 11 you don’t have to restart your system to effect changes, else you need to restart the system
Step5: Test OpenSSL
To test OpenSSL installed properly open the terminal and check the OpenSSL version
cmd: openssl version
If it displays the OpenSSL version then OpenSSL is installed properly.
Important Commands for Open SSL
Creating a Private Key
Private Key is very important it is required for all operations in SSL, this Private key is required to create a CSR file.
openssl genrsa -des3 -out mydomain-com.key 2048It will ask for the password, please keep the password in a safe place because it is required in many places.
1. Create CSR Creating a Certificate Signing Request
CSR file is required to generate an SSL certificate.
This CSR file contains information about the certificate and private key
openssl req -key mydomain-com.key -new -out mydomain-com.csrInformation required by CSR:
Enter pass phrase for mydomain-com.key:
Country Name (2 letter code) [AU]:IN
State or Province Name (full name) [Some-State]:Haryana
Locality Name (eg, city) []:Gurgaon
Organization Name (eg, company) [Internet Widgits Pty Ltd]:myDomain
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:www.mydomain.com
Email Address []:contact@mydomain.com
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Important: Common Name is the Fully Qualified Domain Name for which you want an SSL certificate.
This CSR file is used by different SSL certificate companies to generate SSL Certificate
Generate Private key and CSR with Single command.
openssl req -newkey rsa:2048 -keyout mydomain-com.key -out mydomain-com.csrCreating a Self-Signed Certificate
A self-Signed Certificate is an SSL certificate is generated by using your own private key, it is not used for commercial purposes because it shows a warning that says the certificate is not trusted.
So self-signed certificate can be used for development and testing purposes.
openssl x509 -signkey mydomain-com.key -in mydomain-com.csr -req -days 365 -out mydomain-com.crt
Convert CRT file to PFX file
The .pfx file is required to install an SSL certificate in the windows system, this file contains Private Key and SSL certificate.
openssl pkcs12 -export -out mydomain-com.pfx -inkey mydomain-com.key -in mydomain-com.crtGenerate SHA265 Key from .crt file
openssl x509 -in mydomain.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64Output:
XXXXXXxxXXXXXXXXXXXXXXXxXXXXxXXXX121XX=Generate PF12 file .crt file
openssl pkcs12 -export -out yourdomain.com.p12 -inkey yourdomain.com.key -in yourdomain.crt -certfile CACert.crtyourdomain.com.key: is the key file, it get generated when we create .CSR file
CACert.crt : root certificate, it comes with SSL certificate bundel file.
yourdomain.crt: is the main certificate file
Here’s a solution that may delight those who have implemented WSL (Windows Subsystem for Linux). You can just use:
wsl openssl ...whatever_args...
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.
In this post I explain how to install OpenSSL on Windows 10. OpenSSL is a full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It is licensed under an Apache-style license. This tutorial will help you to install OpenSSL on Windows operating systems.
Download OpenSSL Binary
Download the latest OpenSSL windows installer file from the following download page. Click the below link to visit OpenSSL download page:
http://slproweb.com/products/Win32OpenSSL.html
Run OpenSSL Installer
Now run the OpenSSL installer on your system. The OpenSSL required Microsoft Visual C++ to be installed on your system. If your system doesn’t have Microsoft Visual C++ installed, the installer will show your message like:
Click Yes to download and install required Microsoft Visual C++ package on your system.
Then again run the OpenSSL installer and follow the wizard.
Setup Environment Variables
Now set the environment variables to function OpenSSL properly on your system. You are required to set OPENSSL_CONF and Path environment variables.
Firstly, start to open Settings from the menu Windows and search for environment.
Secondly, select the option “Edit the system environment variables“.
Thirdly, at the bottom of this window, click on Environment Variables…
So, in the section titled “System variables“, click to New to add a new variable. The first one is OPENSSL_CONF. Click on Browse Files to select openssl.cfg in the OpenSSL directory (by default C:Program FilesOpenSSL-Win64bin).
Now, double click on the variable called “Path“.
Finally, click on New and browse your computer to the OpenSSL directory and select bin folder. Click Ok and save.
Run OpenSSL Binary
Finally, open a command prompt or PowerShell and type openssl to get OpenSSL prompt. Then run version command on OpenSSL proper to view installed OpenSSL version.
Conclusion
In conclusion, this is how to install OpenSSL on Windows 10. If you have any question, please use our Forum.
The following page is a combination of the INSTALL file provided with the OpenSSL library and notes from the field. If you have questions about what you are doing or seeing, then you should consult INSTALL since it contains the commands and specifies the behavior by the development team.
OpenSSL uses a custom build system to configure the library. Configuration will allow the library to set up the recursive makefiles from makefile.org. Once configured, you use make to build the library. You should avoid custom build systems because they often miss details, like each architecture and platform has a unique opensslconf.h and bn.h generated by Configure.
You must use a C compiler to build the OpenSSL library. You cannot use a C++ compiler. Later, once the library is built, it is OK to create user programs with a C++ compiler. But the library proper must be built with a C compiler.
There are two generations of build system. First is the build system used in OpenSSL 1.0.2 and below. The instructions below apply to it. Second is the build system for OpenSSL 1.1.0 and above. The instructions are similar, but not the same. For example, the second generation abandons the monolithic Configure and places individual configurations in the Configurations directory. Also, the second generation is more platform agnostic and uses templates to produce a final, top level build file (Makefile, descrip.mms, what have you).
After you configure and build the library, you should always perform a make test to ensure the library performs as expected under its self tests. If you are building OpenSSL 1.1.0 and above, then you will also need PERL 5.10 or higher (see README.PERL for details).
OpenSSL’s build system does not rely upon autotools or libtool. Also see Why aren’t tools like ‘autoconf’ and ‘libtool’ used? in the OpenSSL FAQ.
Retrieve source code[edit]
The OpenSSL source code can be downloaded from OpenSSL Source Tarballs or any suitable ftp mirror. There are various versions including stable as well as unstable versions.
The source code is managed via Git. It’s referred to as Master. The repository is
- git://git.openssl.org/openssl.git
The source is also available via a GitHub mirror. This repository is updated every 15 minutes.
- Accessing OpenSSL source code via Git
Configuration[edit]
OpenSSL is configured for a particular platform with protocol and behavior options using Configure and config.
You should avoid custom build systems because they often miss details, like each architecture and platform has a unique opensslconf.h and bn.h generated by Configure.
Supported Platforms[edit]
You can run Configure LIST to see a list of available platforms.
$ ./Configure LIST BC-32 BS2000-OSD BSD-generic32 BSD-generic64 BSD-ia64 BSD-sparc64 BSD-sparcv8 BSD-x86 BSD-x86-elf BSD-x86_64 Cygwin Cygwin-x86_64 DJGPP ...
If your platform is not listed, then use a similar platform and tune the $cflags and $ldflags by making a copy of the configure line and giving it its own name. $cflags and $ldflags correspond to fields 2 and 6 in a configure line. An example of using a similar configure line is presented in Using RPATHs.
Configure & Config[edit]
You use Configure and config to tune the compile and installation process through options and switches. The difference between is Configure properly handles the host-arch-compiler triplet, and config does not. config attempts to guess the triplet, so it’s a lot like autotool’s config.guess.
You can usually use config and it will do the right thing (from Ubuntu 13.04, x64):
$ ./config
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring for linux-x86_64
no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
...
Mac OS X can have issues (it’s often a neglected platform), and you will have to use Configure:
./Configure darwin64-x86_64-cc
Configuring for darwin64-x86_64-cc
no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
...
You can also configure on Darwin by exporting KERNEL_BITS:
$ export KERNEL_BITS=64
$ ./config shared no-ssl2 no-ssl3 enable-ec_nistp_64_gcc_128 --openssldir=/usr/local/ssl/macosx-x64/
Operating system: i686-apple-darwinDarwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64
Configuring for darwin64-x86_64-cc
Configuring for darwin64-x86_64-cc
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
...
If you provide a option not known to configure or ask for help, then you get a brief help message:
$ ./Configure --help Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [experimental-<cipher> ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [sctp] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]
And if you supply an unknown triplet:
$ ./Configure darwin64-x86_64-clang Configuring for darwin64-x86_64-clang Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [experimental-<cipher> ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [sctp] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags] pick os/compiler from: BC-32 BS2000-OSD BSD-generic32 BSD-generic64 BSD-ia64 BSD-sparc64 BSD-sparcv8 BSD-x86 BSD-x86-elf BSD-x86_64 Cygwin Cygwin-pre1.3 DJGPP MPE/iX-gcc OS2-EMX ... NOTE: If in doubt, on Unix-ish systems use './config'.
Dependencies[edit]
If you are prompted to run make depend, then you must do so. For OpenSSL 1.0.2 and below, it’s required to update the standard distribution once configuration options change.
Since you've disabled or enabled at least one algorithm, you need to do the following before building: make depend
OpenSSL 1.1.0 and above performs the dependency step for you, so you should not see the message. However, you should perform a make clean to ensure the list of objects files is accurate after a reconfiguration.
Configure Options[edit]
OpenSSL has been around a long time, and it carries around a lot of cruft. For example, from above, SSLv2 is enabled by default. SSLv2 is completely broken, and you should disable it during configuration. You can disable protocols and provide other options through Configure and config, and the following lists some of them.
Note: if you specify a non-existent option, then the configure scripts will proceed without warning. For example, if you inadvertently specify no-sslv2 rather than no-ssl2 no-ssl3, the script will configure with SSLv2 and without warning for the unknown no-sslv2.
Note: when building a shared object, both the static archive and shared objects are built. You do not need to do anything special to build both when shared is specified.
| Option | Description |
|---|---|
| —prefix=XXX | See PREFIX and OPENSSLDIR in the next section (below). |
| —openssldir=XXX | See PREFIX and OPENSSLDIR in the next section (below). |
| -d | Debug build of the library. Optimizations are disabled (no -O3 or similar) and libefence is used (apt-get install electric-fence or yum install electric-fence). TODO: Any other features? |
| shared | Build a shared object in addition to the static archive. You probably need a RPATH when enabling shared to ensure openssl uses the correct libssl and libcrypto after installation. |
| enable-ec_nistp_64_gcc_128 | Use on little endian platforms when GCC supports __uint128_t. ECDH is about 2 to 4 times faster. Not enabled by default because Configure can’t determine it. Enable it if your compiler defines __SIZEOF_INT128__, the CPU is little endian and it tolerates unaligned data access. |
| enable-capieng | Enables the Microsoft CAPI engine on Windows platforms. Used to access the Windows Certificate Store. Also see Using Windows certificate store through OpenSSL on the OpenSSL developer list. |
| no-ssl2 | Disables SSLv2. OPENSSL_NO_SSL2 will be defined in the OpenSSL headers. |
| no-ssl3 | Disables SSLv3. OPENSSL_NO_SSL3 will be defined in the OpenSSL headers. |
| no-comp | Disables compression independent of zlib. OPENSSL_NO_COMP will be defined in the OpenSSL headers. |
| no-idea | Disables IDEA algorithm. Unlike RC5 and MDC2, IDEA is enabled by default |
| no-asm | Disables assembly language routines (and uses C routines) |
| no-dtls | Disables DTLS in OpenSSL 1.1.0 and above |
| no-dtls1 | Disables DTLS in OpenSSL 1.0.2 and below |
| no-shared | Disables shared objects (only a static library is created) |
| no-hw | Disables hardware support (useful on mobile devices) |
| no-engine | Disables hardware support (useful on mobile devices) |
| no-threads | Disables threading support. |
| no-dso | Disables the OpenSSL DSO API (the library offers a shared object abstraction layer). If you disable DSO, then you must disable Engines also |
| no-err | Removes all error function names and error reason text to reduce footprint |
| no-npn/no-nextprotoneg | Disables Next Protocol Negotiation (NPN). Use no-nextprotoneg for 1.1.0 and above; and no-npn otherwise |
| no-psk | Disables Preshared Key (PSK). PSK provides mutual authentication independent of trusted authorities, but it’s rarely offered or used |
| no-srp | Disables Secure Remote Password (SRP). SRP provides mutual authentication independent of trusted authorities, but it’s rarely offered or used |
| no-ec2m | Used when configuring FIPS Capable Library with a FIPS Object Module that only includes prime curves. That is, use this switch if you use openssl-fips-ecp-2.0.5. |
| no-weak-ssl-ciphers | Disables RC4. Available in OpenSSL 1.1.0 and above. |
| -DXXX | Defines XXX. For example, -DOPENSSL_NO_HEARTBEATS. |
| -DPEDANTIC | Defines PEDANTIC. The library will avoid some undefined behavior, like casting an unaligned byte array to a different pointer type. This define should be used if building OpenSSL with undefined behavior sanitizer (-fsanitize=undefined). |
| -DOPENSSL_USE_IPV6=0 | Disables IPv6. Useful if OpenSSL encounters incorrect or inconsistent platform headers and mistakenly enables IPv6. Must be passed to Configure manually. |
| -DNO_FORK | Defines NO_FORK. Disables calls to fork. Useful for operating systems like AppleTVOS, WatchOS, AppleTVSimulator and WatchSimulator. |
| -Lsomething, -lsomething, -Ksomething, -Wl,something | Linker options, will become part of LDFLAGS. |
| —anythingelse, +anythingelse | Compiler options, will become part of CFLAGS. |
Note: on older OSes, like CentOS 5, BSD 5, and Windows XP or Vista, you will need to configure with no-async when building OpenSSL 1.1.0 and above. The configuration system does not detect lack of the Posix feature on the platforms.
Note: you can verify compiler support for __uint128_t with the following:
# gcc -dM -E - </dev/null | grep __SIZEOF_INT128__ #define __SIZEOF_INT128__ 16
PREFIX and OPENSSLDIR[edit]
—prefix and —openssldir control the configuration of installed components. The behavior and interactions of —prefix and —openssldir are slightly different between OpenSSL 1.0.2 and below, and OpenSSL 1.1.0 and above.
The rule of thumb to use when you want something that «just works» for all recent versions of OpenSSL, including OpenSSL 1.0.2 and 1.1.0, is:
- specify both —prefix and —openssldir
- set —prefix and —openssldir to the same location
One word of caution is avoid —prefix=/usr when OpenSSL versions are not binary compatible. You will replace the distro’s version of OpenSSL with your version of OpenSSL. It will most likely break everything, including the package management system.
OpenSSL 1.0.2 and below
It is usually not necessary to specify —prefix. If —prefix is not specified, then —openssldir is used. However, specifying only —prefix may result in broken builds because the 1.0.2 build system attempts to build in a FIPS configuration.
You can omit If —prefix and use —openssldir. In this case, the paths for —openssldir will be used during configuration. If —openssldir is not specified, the the default /usr/local/ssl is used.
The takeaway is /usr/local/ssl is used by default, and it can be overridden with —openssldir. The rule of thumb applies for path overrides: specify both —prefix and —openssldir.
OpenSSL 1.1.0 and above
OpenSSL 1.1.0 changed the behavior of install rules. You should specify both —prefix and —openssldir to ensure make install works as expected.
The takeaway is /usr/local/ssl is used by default, and it can be overridden with both —prefix and —openssldir. The rule of thumb applies for path overrides: specify both —prefix and —openssldir.
Debug Configuration[edit]
From the list above, it’s possible to quickly configure a «debug» build with ./config -d. However, you can often get into a more amicable state without the Electric Fence dependency by issuing:
$ ./config no-asm -g3 -O0 -fno-omit-frame-pointer -fno-inline-functions
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring OpenSSL version 1.1.0-pre5-dev (0x0x10100005L)
no-asm [option] OPENSSL_NO_ASM
...
Configuring for linux-x86_64
IsMK1MF =no
CC =gcc
CFLAG =-Wall -O3 -pthread -m64 -DL_ENDIAN -g3 -O0 -fno-omit-frame-pointer
...
Don’t be alarmed about both -O3 and -O0. The last setting «sticks», and that’s the -O0.
If you are working in Visual Studio and you can’t step into library calls, then see Step into not working, but can force stepping after some asm steps on Stack Overflow.
Modifying Build Settings[edit]
Sometimes you need to work around OpenSSL’s selections for building the library. For example, you might want to use -Os for a mobile device (rather than -O3), or you might want to use the clang compiler (rather than gcc).
In case like these, its’ often easier to modify Configure and Makefile.org rather than trying to add targets to the configure scripts. Below is a patch that modifies Configure and Makefile.org for use under the iOS 7.0 SDK (which lacks gcc in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/):
- Modifies Configure to use clang
- Modifies Makefile.org to use clang
- Modifies CFLAG to use -Os
- Modifies MAKEDEPPROG to use $(CC) -M
Setting and resetting of LANG is required on Mac OSX to work around a sed bug or limitation.
OLD_LANG=$LANG unset LANG sed -i "" 's|"iphoneos-cross","llvm-gcc:-O3|"iphoneos-cross","clang:-Os|g' Configure sed -i "" 's/CC= cc/CC= clang/g' Makefile.org sed -i "" 's/CFLAG= -O/CFLAG= -Os/g' Makefile.org sed -i "" 's/MAKEDEPPROG=makedepend/MAKEDEPPROG=$(CC) -M/g' Makefile.org export LANG=$OLD_LANG
After modification, be sure to dclean and configure again so the new settings are picked up:
make dclean ./config make depend make all ...
Using RPATHs[edit]
RPATH’s are supported by default on the BSD platforms, but not others. If you are working on Linux and compatibles, then you have to manually add an RPATH. One of the easiest ways to add a RPATH is to configure with it as shown below.
./config -Wl,-rpath=/usr/local/ssl/lib
For modern Linux you should also use -Wl,—enable-new-dtags. The linker option sets a RUNPATH as opposed to a RPATH. A RUNPATH allows library path overrides at runtime, while a RPATH does not.
./config -Wl,-rpath=/usr/local/ssl/lib -Wl,--enable-new-dtags
Note well: you should use a RPATH or RUNPATH when building both OpenSSL and your program. If you don’t add a RPATH or RUNPATH to both, then your program could runtime-link to the wrong version of OpenSSL. Linking against random versions of a security library is not a good idea.
You can also add an RPATH or RUNPATH by hard coding the RPATH into a configure line. For example, on Debian x86_64 open the file Configure in an editor, copy linux-x86_64, name it linux-x86_64-rpath, and make the following change to add the -rpath option. Notice the addition of -Wl,-rpath=… in two places.
"linux-x86_64-rpath", "gcc:-m64 -DL_ENDIAN -O3 -Wall -Wl,-rpath=/usr/local/ssl/lib::
-D_REENTRANT::-Wl,-rpath=/usr/local/ssl/lib -ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:
${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.$(SHLIB_MAJOR).$(SHLIB_MINOR):::64",
Above, fields 2 and 6 were changed. They correspond to $cflag and $ldflag in OpenSSL’s builds system.
Then, Configure with the new configuration:
$ ./Configure linux-x86_64-rpath shared no-ssl2 no-ssl3 no-comp
--openssldir=/usr/local/ssl enable-ec_nistp_64_gcc_128
Finally, after make, verify the settings stuck:
$ readelf -d ./libssl.so | grep -i -E 'rpath|runpath' 0x000000000000000f (RPATH) Library rpath: [/usr/local/ssl/lib] $ readelf -d ./libcrypto.so | grep -i rpath 0x000000000000000f (RPATH) Library rpath: [/usr/local/ssl/lib] $ readelf -d ./apps/openssl | grep -i rpath 0x000000000000000f (RPATH) Library rpath: [/usr/local/ssl/lib]
Once you perform make install, then ldd will produce expected results:
$ ldd /usr/local/ssl/lib/libssl.so
linux-vdso.so.1 => (0x00007ffceff6c000)
ibcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00007ff5eff96000)
...
$ ldd /usr/local/ssl/bin/openssl
linux-vdso.so.1 => (0x00007ffc30d3a000)
libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00007f9e8372e000)
libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00007f9e832c0000)
...
FIPS Capable Library[edit]
If you want to use FIPS validated cryptography, you download, build and install the FIPS Object Module (openssl-fips-2.0.5.tar.gz) according to the FIPS User Guide 2.0 and FIPS 140-2 Security Policy. You then download, build and install the FIPS Capable Library (openssl-1.0.1e.tar.gz).
When configuring the FIPS Capable Library, you must use fips as an option:
./config fips <other options ...>
If you are configuring the FIPS Capable Library with only prime curves (openssl-fips-ecp-2.0.5.tar.gz), then you must configure with no-ec2m:
./config fips no-ec2m <other options ...>
Compile Time Checking[edit]
If you disable an option during configure, you can check if it’s available through OPENSSL_NO_* defines. OpenSSL writes the configure options to <openssl/opensslconf.h>. For example, if you want to know if SSLv3 is available, then you would perform the following in your code:
#include <openssl/opensslconf.h> ... #if !defined(OPENSSL_NO_SSL3) /* SSLv3 is available */ #endif
Compilation[edit]
After configuring the library, you should run make. If prompted, there’s usually no need to make depend since you are building from a clean download.
Quick[edit]
./config <options ...> --openssldir=/usr/local/ssl make make test sudo make install
Various options can be found examining the Configure file (there is a well commented block at its top). OpenSSL ships with SSLv2, SSLv3 and Compression enabled by default (see my $disabled), so you might want to use no-ssl2 no-ssl3, no-ssl3, and no-comp.
Platfom specific[edit]
Linux[edit]
Intel[edit]
ARM[edit]
X32 (ILP32)[edit]
X32 uses the 32-bit data model (ILP32) on x86_64/amd64. To properly configure for X32 under current OpenSSL distributions, you must use Configure and use the x32 triplet:
# ./Configure LIST | grep x32 linux-x32 ...
Then:
# ./Configure linux-x32
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x10100006L)
no-asan [default] OPENSSL_NO_ASAN (skip dir)
...
Configuring for linux-x32
CC =gcc
CFLAG =-Wall -O3 -pthread -mx32 -DL_ENDIAN
SHARED_CFLAG =-fPIC
...
If using an amd64-compatible processor and GCC with that supports __uint128_t, then you usually add enable-ec_nistp_64_gcc_128 in addition to your other flags.
Windows[edit]
3noch wrote a VERY good guide in 2012 here (PLEASE NOTE: the guide was written in 2012 and is no longer available at the original location; the link now points to an archived version at the Internet Archive Wayback Machine).
Like he said in his article, make absolutely sure to create separate directories for 32 and 64 bit versions.
W32 / Windows NT — Windows 9x[edit]
type INSTALL.W32
- you need Perl for Win32. Unless you will build on Cygwin, you will need ActiveState Perl, available from http://www.activestate.com/ActivePerl.
- one of the following C compilers:
- Visual C++
- Borland C
- GNU C (Cygwin or MinGW)
- Netwide Assembler, a.k.a. NASM, available from http://nasm.sourceforge.net/ is required if you intend to utilize assembler modules. Note that NASM is now the only supported assembler.
W64[edit]
Read first the INSTALL.W64 documentation note containing some specific 64bits information.
See also INSTALL.W32 that still provides additonnal build information common to both the 64 and 32 bit versions.
You may be surprised: the 64bit artefacts are indeed output in the out32* sub-directories and bear names ending *32.dll. Fact is the 64 bit compile target is so far an incremental change over the legacy 32bit windows target. Numerous compile flags are still labelled «32» although those do apply to both 32 and 64bit targets.
The important pre-requisites are to have PERL available (for essential file processing so as to prepare sources and scripts for the target OS) and of course a C compiler like Microsoft Visual Studio for C/C++. Also note the procedure changed at OpenSSL 1.1.0 and is more streamlined. Also see Why there is no msdo_ms.bat after perl Configure VC-WIN64A on Stack Overflow.
OpenSSL 1.1.0[edit]
For OpenSSL 1.1.0 and above perform these steps:
- Ensure you have perl installed on your machine (e.g. ActiveState or Strawberry), and available on your %PATH%
- Ensure you have NASM installed on your machine, and available on your %PATH%
- Extract the source files to your folder, here
cd c:myPathopenssl - Launch Visual Studio tool x64 Cross Tools Command prompt
- Goto your defined folder
cd c:myPathopenssl - Configure for the target OS with
perl Configure VC-WIN64Aor other configurations to be found in the INSTALL file (e.g. UNIX targets).- For instance:
perl Configure VC-WIN64A.
- For instance:
- (Optional) In case you compiled before on 32 or 64-bits, make sure you run
nmake cleanto prevent trouble across 32 and 64-bits which share output folder. - Now build with:
nmake - Output can be found in the root of your folder as libcrypto-1_1x64.dll and libssl-1_1-x64.dll (with all the build additionals such as .pdb .lik or static .lib). You may check this is true 64bit code using the Visual Studio tool ‘dumpbin’. For instance
dumpbin /headers libcrypto-1_1x64.dll | more, and look at the FILE HEADER section. - Test the code using the ‘test’ make target, by running
nmake test. - Reminder, clean your code to prevent issues the next time you compile for a different target. See step 7.
Windows CE[edit]
Not specified
OpenSSL 1.0.2[edit]
For OpenSSL 1.0.2 and earlier the procedure is as follows.
- Ensure you have perl installed on your machine (e.g. ActiveState or Strawberry), and available on your %PATH%
- Ensure you have NASM installed on your machine, and available on your %PATH%
- launch a Visual Studio tool x64 Cross Tools Command prompt
- change to the directory where you have copied openssl sources
cd c:myPathopenssl - configure for the target OS with the command
perl Configure VC-WIN64A. You may also be interested to set more configuration options as documented in the general INSTALL note (for UNIX targets). For instance:perl Configure VC-WIN64A. - prepare the target environment with the command:
msdo_win64a - ensure you start afresh and notably without linkable products from a previous 32bit compile (as 32 and 64 bits compiling still share common directories) with the command:
nmake -f msntdll.mak cleanfor the DLL target andnmake -f msnt.mak cleanfor static libraries. - build the code with:
nmake -f msntdll.mak(respectivelynmake -f msnt.mak) - the artefacts will be found in sub directories out32dll and out32dll.dbg (respectively out32 and out32.dbg for static libraries). The libcrypto and ssl libraries are still named libeay32.lib and ssleay32.lib, and associated includes in inc32 ! You may check this is true 64bit code using the Visual Studio tool ‘dumpbin’. For instance
dumpbin /headers out32dll/libeay32.lib | more, and look at the FILE HEADER section. - test the code using the various *test.exe programs in out32dll. Use the ‘test’ make target to run all tests as in
nmake -f msntdll.mak test - we recommend that you move/copy needed includes and libraries from the «32» directories under a new explicit directory tree for 64bit applications from where you will import and link your target applications, similar to that explained in INSTALL.W32.
Windows CE[edit]
OS X[edit]
The earlier discussion presented a lot of information (and some of it had OS X information). Here are the TLDR versions to configure, build and install the library.
If configuring for 64-bit OS X, then use a command similar to:
./Configure darwin64-x86_64-cc shared enable-ec_nistp_64_gcc_128 no-ssl2 no-ssl3 no-comp --openssldir=/usr/local/ssl/macos-x86_64 make depend sudo make install
If configuring for 32-bit OS X, then use a command similar to:
./Configure darwin-i386-cc shared no-ssl2 no-ssl3 no-comp --openssldir=/usr/local/ssl/macosx-i386 make depend sudo make install
If you want to build a multiarch OpenSSL library, then see this answer on Stack Overflow: Build Multiarch OpenSSL on OS X.
iOS[edit]
The following builds OpenSSL for iOS using the iPhoneOS SDK. The configuration avoids the dynamic library the DSO interface and engines.
If you run make install, then the headers will be installed in /usr/local/openssl-ios/include and libraries will be installed in /usr/local/openssl-ios/lib.
32-bit[edit]
For OpenSSL 1.1.0 and above, a 32-bit iOS cross-compiles uses the ios-cross target, and options similar to —prefix=/usr/local/openssl-ios.
$ export CC=clang;
$ export CROSS_TOP=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
$ export CROSS_SDK=iPhoneOS.sdk
$ export PATH="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:$PATH"
$ ./Configure ios-cross no-shared no-dso no-hw no-engine --prefix=/usr/local/openssl-ios
Configuring OpenSSL version 1.1.1-dev (0x10101000L)
no-afalgeng [forced] OPENSSL_NO_AFALGENG
no-asan [default] OPENSSL_NO_ASAN
no-dso [option]
no-dynamic-engine [forced]
...
no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS
no-zlib [default]
no-zlib-dynamic [default]
Configuring for ios-cross
PERL =perl
PERLVERSION =5.16.2 for darwin-thread-multi-2level
HASHBANGPERL =/usr/bin/env perl
CC =clang
CFLAG =-O3 -D_REENTRANT -arch armv7 -mios-version-min=6.0.0 -isysroot $(CROSS_TOP)/SDKs/$(CROSS_SDK) -fno-common
CXX =c++
CXXFLAG =-O3 -D_REENTRANT -arch armv7 -mios-version-min=6.0.0 -isysroot $(CROSS_TOP)/SDKs/$(CROSS_SDK) -fno-common
DEFINES =NDEBUG OPENSSL_THREADS OPENSSL_NO_DYNAMIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM AES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
...
If you are working with OpenSSL 1.0.2 or below, then use the iphoneos-cross target.
$ export CC=clang;
$ export CROSS_TOP=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
$ export CROSS_SDK=iPhoneOS.sdk
$ export PATH="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:$PATH"
$ ./Configure iphoneos-cross no-shared no-dso no-hw no-engine --prefix=/usr/local/openssl-ios
Configuring for iphoneos-cross
no-dso [option]
no-engine [option] OPENSSL_NO_ENGINE (skip dir)
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-hw [option] OPENSSL_NO_HW
...
no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
IsMK1MF=0
CC =clang
CFLAG =-DOPENSSL_THREADS -D_REENTRANT -O3 -isysroot $(CROSS_TOP)/SDKs/$(CROSS_SDK) -fomit-frame-pointer -fno-common
...
64-bit[edit]
For OpenSSL 1.1.0 , a 64-bit iOS cross-compiles uses the ios64-cross target, and —prefix=/usr/local/openssl-ios64. ios64-cross. There is no built-in 64-bit iOS support for OpenSSL 1.0.2 or below.
$ export CC=clang;
$ export CROSS_TOP=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
$ export CROSS_SDK=iPhoneOS.sdk
$ export PATH="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:$PATH"
$ ./Configure ios64-cross no-shared no-dso no-hw no-engine --prefix=/usr/local/openssl-ios64
Configuring OpenSSL version 1.1.1-dev (0x10101000L)
no-afalgeng [forced] OPENSSL_NO_AFALGENG
no-asan [default] OPENSSL_NO_ASAN
no-dso [option]
no-dynamic-engine [forced]
...
no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS
no-zlib [default]
no-zlib-dynamic [default]
Configuring for ios64-cross
PERL =perl
PERLVERSION =5.16.2 for darwin-thread-multi-2level
HASHBANGPERL =/usr/bin/env perl
CC =clang
CFLAG =-O3 -D_REENTRANT -arch arm64 -mios-version-min=7.0.0 -isysroot $(CROSS_TOP)/SDKs/$(CROSS_SDK) -fno-common
CXX =c++
CXXFLAG =-O3 -D_REENTRANT -arch arm64 -mios-version-min=7.0.0 -isysroot $(CROSS_TOP)/SDKs/$(CROSS_SDK) -fno-common
DEFINES =NDEBUG OPENSSL_THREADS OPENSSL_NO_DYNAMIC_ENGINE OPENSSL_PIC OPENSSL_BN_ASM_MONT SHA1_ASM SHA256_ASM SHA512_ASM VPAES_ASM ECP_NISTZ256_ASM POLY1305_ASM
...
Android[edit]
Visit Android and FIPS Library and Android.
More[edit]
VAX/VMS[edit]
I you wonder what are files ending with .com like test/testca.com those are VAX/VMX scripts.
This code is still maintained.
OS/2[edit]
NetWare[edit]
5.x 6.x
HP-UX[edit]
HP-UX Itanium FIPS and OpenSSL build
Autoconf[edit]
OpenSSL uses its own configuration system, and does not use Autoconf. However, a number of popular projects use both OpenSSL and Autoconf, and it would be useful to detect either OPENSSL_init_ssl or SSL_library_init from libssl. To craft a feature test for OpenSSL that recognizes both OPENSSL_init_ssl and SSL_library_init, you can use the following.
if test "$with_openssl" = yes ; then
dnl Order matters!
if test "$PORTNAME" != "win32"; then
AC_CHECK_LIB(crypto, CRYPTO_new_ex_data, [], [AC_MSG_ERROR([library 'crypto' is required for OpenSSL])])
FOUND_SSL_LIB="no"
AC_CHECK_LIB(ssl, OPENSSL_init_ssl, [FOUND_SSL_LIB="yes"])
AC_CHECK_LIB(ssl, SSL_library_init, [FOUND_SSL_LIB="yes"])
AS_IF([test "x$FOUND_SSL_LIB" = xno], [AC_MSG_ERROR([library 'ssl' is required for OpenSSL])])
else
AC_SEARCH_LIBS(CRYPTO_new_ex_data, eay32 crypto, [], [AC_MSG_ERROR([library 'eay32' or 'crypto' is required for OpenSSL])])
FOUND_SSL_LIB="no"
AC_SEARCH_LIBS(OPENSSL_init_ssl, ssleay32 ssl, [FOUND_SSL_LIB="yes"])
AC_SEARCH_LIBS(SSL_library_init, ssleay32 ssl, [FOUND_SSL_LIB="yes"])
AS_IF([test "x$FOUND_SSL_LIB" = xno], [AC_MSG_ERROR([library 'ssleay32' or 'ssl' is required for OpenSSL])])
fi
fi
Many thanks to the Postgres folks for donating part of their configure.in. Also see How to tell Autoconf “require symbol A or B” from LIB? on Stack Overflow.
1. 
When we build and ship Certify One and FireDaemon Fusion we try to ensure it contains the most recent version of OpenSSL. We thought it would be useful to make our OpenSSL Binary Distribution available for you to download and use in a standalone fashion or in your own software projects for free.
Table of Contents
- Download OpenSSL ZIP File
- OpenSSL ZIP File Installation Instructions
- Download OpenSSL 3.0 Windows Installer
- OpenSSL Screenshot
- OpenSSL Documentation
- Checking SSL / TLS Certificate Validity with Certify One
- Compiling OpenSSL From Source
- Source
- Release Policy
- Compilation and Build Script
- Dependencies
- Integrating OpenSSL with Your Visual Studio Project
- Additional Include Directories
- Additional Library Directories
- Privilege Escalation Mitigation
- Compatibility and Support Matrix
- License, Warranty, and Support
- Acknowledgments
- Buy SSL / TLS Certificates
Download OpenSSL ZIP File
|
Download OpenSSL Binary Distribution for Microsoft Windows |
|
|
Pre-compiled executables (EXE) and libraries (DLL) for Microsoft Windows Operating Systems. The distributions can be used standalone or integrated into any Windows application. The EXE and DLL are digitally signed with our Extended Validation (EV) EV code signing certificate. The distributions depend on the Microsoft Visual Studio runtime which is included in the ZIP file. |
|
|
November 2022 |
|
|
For 64-bit / Win64 / x64 and 32-bit / Win32 / x86 Microsoft Windows Operating Systems OpenSSL maintains a list of 3rd-party maintained binary distributions of OpenSSL. Please review our Release Policy before downloading and using this distribution. |
OpenSSL ZIP File Installation Instructions
- Follow the instructions below if you have downloaded one of the ZIP files above and want to deploy OpenSSL manually (e.g. on the local hard disk or on a USB drive for a portable installation)
- Download the appropriate FireDaemon OpenSSL Binary Distribution ZIP file via the links above.
- Unpack the contents of the «openssl-1.1» or «openssl-3» folder in the respective ZIP file to a temporary directory (e.g. C:Temp)
- Copy the contents of (i.e. the files and directories contained within) the x64 folder or x86 folder to your target directory (e.g. C:OpenSSL)
- Copy the ssl folder and contents to the target directory
- Copy the prerequisites folders and contents to the target directory
- Install the appropriate Visual Studio C++ Runtime found in the prerequisites folder. Install VC_redist.x64.exe on 64-bit systems. Install VC_redist.x86.exe on 32-bit systems.
- To use OpenSSL, simply open an elevated Command Prompt then (adjusting the path in OPENSSL_HOME to suit your manual installation):
REM You can set OPENSSL_HOME=%~dp0 in a batch script for portable installs set OPENSSL_HOME=C:OpenSSL set OPENSSL_CONF=%OPENSSL_HOME%sslopenssl.cnf set PATH=%OPENSSL_HOME%bin;%PATH% cd /d %OPENSSL_HOME% openssl version -a
To create a certificate signing request and private key using the same environment variables as above :
openssl genrsa -out server.key 4096 openssl req -new -key server.key -out server.csr -sha256 openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Download OpenSSL 3.0 Windows Installer
Instead of downloading the ZIP file, and for convenience, you can download our Windows installer which will deploy OpenSSL 3.0 x64 (64-bit). OpenSSL is installed into the following file system locations. These locations are specified during the build and follow OpenSSL’s own conventions. Thanks to Advanced Installer for helping us out.
%PROGRAMFILES%FireDaemon OpenSSL 3 %PROGRAMFILES%Common FilesFireDaemon SSL 3
OpenSSL Screenshot
Below is a screenshot showing the executed commands at an elevated command prompt:
OpenSSL Documentation
Please refer to OpenSSL’s documentation.
Checking SSL / TLS Certificate Validity with Certify One
FireDaemon Certify One allows you to audit, check, inspect, and validate SSL / TLS certificates and certificate chains. Fortify also has a browser-based TLS Encryption Check Tool available.
Compiling OpenSSL From Source
Source
We directly pull from OpenSSL’s official GitHub repository.
Release Policy
Whenever we release an updated version of FireDaemon Fusion, Certify One, or OpenSSL gets updated with security fixes, we will provide the latest tagged version of the OpenSSL stable branch. The currently deployed OpenSSL library is version 3.0.7 and 1.1.1s at commit openssl-3.0.7-0-g19cc035b6c and OpenSSL_1_1_1s-0-g129058165d respectively:
git describe --always --tag --long --first-parent --dirty
Compilation and Build Script
The actual command line to build OpenSSL is as follows (where %toolset% is VC-WIN32 and VC-WIN64A respectively):
perl ..Configure %toolset% no-asm no-ssl3 no-zlib no-comp no-ui-console no-autoload-config --api=1.1.0 --prefix="%installdir%" --openssldir="%commoninstalldir%" -DOPENSSL_NO_DEPRECATED
For reference, the build script used to create the binary distributions is attached to this article. The build script has the following dependencies:
- Visual Studio Community Edition
- Git for Windows
- Strawberry Perl.
Dependencies
The OpenSSL binary distribution depends on the Microsoft Visual Studio runtime. The OpenSSL 1.1.1 binaries are built with the Microsoft Visual C++ (MSVC) 14.29 compiler and toolset. The OpenSSL 3 binaries are built with the Microsoft Visual C++ (MSVC) 14.33 compiler and toolset. The external dependency creates much smaller modules and .pdb files and integrates nicely with FireDaemon Fusion and Certify One. We believe that this shouldn’t be problematic since the MSVC 14.3 runtime is binary compatible with applications built using the MSVC 14.0 or 14.1 runtimes, and once installed the Universal C Runtime (CRT) is subject to automatic Windows updates.
Integrating OpenSSL with Your Visual Studio Project
To use the headers and libraries present in OpenSSL in your Visual Studio project, you will need to configure the properties of your project.
Additional Include Directories
Prepend «C:Program FilesFireDaemon Open SSL 3include»; to Property Pages -> C/C++ -> General -> Additional Include Directories in your project per the screenshot below (adjusting the prepended path to suit your installation):
Additional Library Directories
Prepend «C:Program FilesFireDaemon Open SSL 3lib»; to Property Pages -> Linker -> General -> Additional Library Directories in your project per the screenshot below (adjusting the prepended path to suit your installation):
Privilege Escalation Mitigation
When building OpenSSL, the build scripts bake the default location of the library (ie. the installation directory) and the SSL configuration into the final product. By default, OpenSSL automatically loads the SSL configuration file from the default file system location. This leads to an easily exploitable privilege escalation scenario documented in CVE-2019-12572. Our build of OpenSSL mitigates this flaw using the following preventative measures:
- The target directories we have chosen are Windows’ default system program files directories assuming a 64-bit architecture with a shared configuration file directory common to both x64 and x86:
- x64: C:Program FilesFireDaemon OpenSSL, C:Program FilesCommon FilesFireDaemon SSL
- x86: C:Program Files (x86)FireDaemon OpenSSL, C:Program FilesCommon FilesFireDaemon SSL
- To mitigate security holes even on non-default installations, we build the library such that it doesn’t automatically load the SSL configuration. Hence, when using the OpenSSL tools or the DLLs in your products you have to explicitly load the SSL configuration.
- All FireDaemon software products that utilise OpenSSL initialise the OpenSSL library at runtime using a flag that prevents the loading of the default configuration.
Compatibility and Support Matrix
The table below provides a compatibility and support matrix, mapping specific compatible Microsoft Windows operating system versions to specific FireDaemon OpenSSL software versions.
| OpenSSL Versions |
OpenSSL 3.0 and OpenSSL 1.1.1 | |
| Windows Operating System Version | 32-bit (x86) | 64-bit (x64) |
| Windows XP (1) | ||
| Windows Vista (1) | ||
| Windows 7 (1) | ||
| Windows 8 (1) | ||
| Windows 8.1 (1) | ||
| Windows 10 | ||
| Windows 11 | ||
| Server 2008 (2) | ||
| Server 2008 R2 (2) | ||
| Server 2012 | ||
| Server 2012 R2 | ||
| Server 2016 | ||
| Server 2019 | ||
| Server 2022 |
(1) Windows Desktop Operating System is End of Support
(2) Windows Server Operating System is End of Support
| Compatible / Supported | The software product is designed to be installed on the Microsoft Windows operating system version. The operating system version plus software version combination is actively supported by us on the proviso that the 32-bit (x86) version is deployed on a 32-bit (x86) operating system and the 64-bit (x64) version is deployed on a 64-bit (x64) operating system. Please see the License, Warranty, and Support section below. |
| Compatible / Unsupported | The software product should install on the Microsoft Windows operating system version. The operating system version plus software version combination is not supported by us. This is typically due to the operating system version reaching End of Support. |
| Incompatible / Unsupported | The software product should not or does not install on the Microsoft Windows operating system version or does not work. The operating system version plus software version combination is not supported by us. |
License, Warranty, and Support
Our OpenSSL Binary Distribution is free to use and redistribute. Product use, redistribution, and warranty are governed by the OpenSSL License. If you have questions regarding OpenSSL, wish to report bugs, or require implementation guidance please consider joining the OpenSSL Community.
Acknowledgments
This product includes:
- Software developed by the OpenSSL Project for use in the OpenSSL Toolkit
- Cryptographic software written by Eric Young
- Software written by Tim Hudson.
Buy SSL / TLS Certificates
Introduction
Open SSL project is open-source project that maintains the Open SSL software. It is a general-purpose cryptography library that is used to implement SSL and TLS protocols. Some of the uses of the Open SSL software is to
- Generate private keys
- Install self-signed or signed SSL/TLS certificates
- Identify certificate information
In one of my projects, I need to decrypt the private key information from a signed certificate. Using OpenSSL, you can verify the private key information to check the validity and legitimacy. In this article, we will see how to set up Open SSL software on Windows 10 machine. The same steps can be performed for Windows 11 too.
Download the Official Library Repository
Below steps tells how to download the required openssl files from GitHub repo.
Step 1
Validate if you have open SSL already configured. If there is no initial setup from the command prompt when you type in ‘OpenSSL’ you will be getting a message saying that
‘openssl’ is not recognized as an internal or external command, operable program or batch file’.
Step 2 — Create a folder for OpenSSL.
At first create a folder in local directory. In this case, I created it in C:InstallOpenSSLLibrary. The folder can be created anywhere.
Make sure there are no files existing.
Step 3
Clone the OpenSSL folder from the official Git page maintained by the OpenSSL project team. The official open SSL library is located at git.openssl.org.
For this step you need to have git installed on your windows machine. Please check the references section on how to install ‘Git’ on Windows machines. This Git install is a straightforward process as it has binary available, and it configures the required settings during the install.
Now go to the folder from the command prompt where the openssl folder is created. In my case it is c:InstallOpenSSLLibrary.
Now run the following command that copies the openssl library and files into this folder
git clone git://git.openssl.org/openssl.gityou should see message ‘Cloning into ‘openssl’ and should finish in sometime after that.
Now validate a subfolder ‘openssl’ is created and underneath it you have all the required files copied over from the git repository.
The above steps finishes downloading the required libraries to the folder.
Setup OpenSSL
Now we need to install the dependencies to configure the OpenSSL. The below steps need to be performed in following order
- Install PERL
- Install NASM
- Validating the PATH from the Environment variables.
- Configuring Openssl
Now we will perform the steps.
Step 1
Install the PERL. OpenSSL recommends to install Strawberry Perl from the below link
http://strawberryperl.com/. Since my windows OS is 64-bit, I have chosen to download the 64-bit MSI
Now you should have the required setup file downloaded to the local directory. In my case, it is ‘Downloads’ folder.
Double click on the set-up file and follow the steps. In my case, I have defaulted to the values from the install screens.
Accept the License Agreement.
Here I left the default. You can change to required folder if needed.
You should see below message
Once finished click on ‘Finish’. This confirms that PERL is downloaded and set up on your machine.
Install NASM
NASM stands for Net Assembler and is available at https://www.nasm.us/
Step 1
Download the latest version from the home page by clicking on version no.
Step 2
Now it will take to download page, with various builds. Since my OS is 64-bit, I am selecting Win64
Now click on the .exe file which should download to local directory. In my case, it got downloaded to ‘Downloads’ folder.
Step 3
Now go to the file and double click on the install.
If you get below message which prompts for privileged account, right click on setup and chose ‘Run as administrator’.
- It will ask for the user options I chose default.
- Next step is to choose components. I left it default.
- Next, it will ask for install path. Please make a note of this path, as this is required to set up PATH in environment variables.
- Next it will ask for start menu folder. Left it as default.
- The install should take less than 2 minutes and show status as ‘Completed’. Click on close
Setting up Environment Variables
Now the PERL and NASM software is configured, now it’s time to check the environment variables.
Step 1
For this from the windows start menu and search for ‘Environment Variables’ and click on ‘Edit the system environment variables.
Step 2
Click on the ‘Environment Variables’ in the ‘System Properties’ window.
Step 3
Look for Path under ‘System Variables’.
Step 4
If you observe the Environment Variables for Strawberry PERL has been configured, but not for NASM (Net Assembler).
For NASM the path value needs to be set up manually.
Step 5
Click on ‘New’ and enter the install location where NASM has been installed. In my case it is C:Program FilesNASM
Step 6
Click on Ok for 3 times and exit out of the Environment Variables window.
The above steps finish the configuration of Environment Variables.
Configuring Open SSL
Now we have all the pre-requisites set up for Openssl, now it’s time to finish the final steps.
Step 1
Open the cmd prompt as an administrator.
Step 2
Change the directory to the Openssl folder. In my case it is C:InstallOpenSSLLibraryopenssl
Step 3
Type In below command
perl Configure
At the end, you should get message ‘Open SSL has been successfully configured’.
Validation
Now close the admin command prompt and open the normal command prompt and type in ‘Openssl’. You should see Openssl command prompt.
Conclusion
Thus, in this article, we have seen what Openssl is and how this is configured on windows machines.
References
- https://github.com/openssl/openssl
- https://www.openssl.org/
- https://github.com/openssl/openssl/blob/master/NOTES-WINDOWS.md
- https://www.c-sharpcorner.com/blogs/how-to-install-git-for-windows
Keeping your computer secure is a balancing act. On one hand, you need to keep your computer safe from viruses and hackers so that confidential information doesn’t get leaked. On the other hand, it’s also important that programs and apps are able to access information from users as needed so they can complete tasks efficiently. Keeping these two factors in mind is essential when installing software on your Windows OS.
Luckily for you, this article will explore how you can install OpenSSL on Windows. You see, OpenSSL helps developers and programmers create applications or software that have encrypted communication over the internet. In this article, you will learn what OpenSSL is and why it’s essential when creating a new app or program with security in mind. Additionally, we explore how to install OpenSSL on Windows using simple steps that even beginners can understand. Let’s get started!
This tutorial will help you to install OpenSSL on Windows operating systems.
Step 1 – Download OpenSSL Binary
You need to download the latest OpenSSL windows installer file. Click the below link to visit the OpenSSL download page:
http://slproweb.com/products/Win32OpenSSL.html
The above screenshot may be outdated but we recommend downloading the most recent version of OpenSSL.
Step 2 – Run OpenSSL Installer
Now run the OpenSSL installer on your system. The OpenSSL required Microsoft Visual C++ to be installed on your system. If your system doesn’t have Microsoft Visual C++ installed, the installer will show your message like:
Click Yes to download and install required Microsoft Visual C++ package on your system.
Then again run the OpenSSL installer and follow the wizard.
Step 3 – Setup Environment Variables
Now set the environment variables to function OpenSSL properly on your system. You are required to set OPENSSL_CONF and Path environment variables.
Use the following commands to set the environment for the current session only:
set OPENSSL_CONF=C:OpenSSL-Win64binopenssl.cfgset Path=%Path%;C:OpenSSL-Win64bin
Set Variables Permanently – You can also set the OPENSSL_CONF and Path environment variables in the system permanently. To set the environment variable follow:
Press Windows + R keys together to open run window, Then type “sysdm.cpl” in the Run dialog box and hit Enter. Alternatively, you can open Command Prompt and type the same command to open System Properties
Go to “Advanced” tab and click on “Environment variables“.
Set OPENSSL_CONF Variable:
Set Path Variable:
Step 4 – Run OpenSSL Binary
Open a command prompt on your system and type openssl to open OpenSSL prompt. After that type version to get the installed OpenSSL version on your system.
Conclusion
This tutorial helped you for installing OpenSSL on the Windows system. As a best security practice, it is recommended to use the latest OpenSSL version on your system. You can find the latest version details from the www.openssl.org