How to install openssl on windows

TLS/SSL and crypto library. Contribute to openssl/openssl development by creating an account on GitHub.

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__

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.


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.

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

How to Install OpenSSL on Windows

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:

How to Install OpenSSL on Windows

Click Yes to download and install required Microsoft Visual C++ package on your system.

How to Install OpenSSL on Windows

Then again run the OpenSSL installer and follow the wizard.

How to Install OpenSSL on Windows

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

How to Install OpenSSL on Windows

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

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.

OpenSSL Library Options

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:

  1. Ensure you have perl installed on your machine (e.g. ActiveState or Strawberry), and available on your %PATH%
  2. Ensure you have NASM installed on your machine, and available on your %PATH%
  3. Extract the source files to your folder, here cd c:myPathopenssl
  4. Launch Visual Studio tool x64 Cross Tools Command prompt
  5. Goto your defined folder cd c:myPathopenssl
  6. Configure for the target OS with perl Configure VC-WIN64A or other configurations to be found in the INSTALL file (e.g. UNIX targets).
    1. For instance: perl Configure VC-WIN64A.
  7. (Optional) In case you compiled before on 32 or 64-bits, make sure you run nmake clean to prevent trouble across 32 and 64-bits which share output folder.
  8. Now build with: nmake
  9. 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.
  10. Test the code using the ‘test’ make target, by running nmake test.
  11. 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.

  1. Ensure you have perl installed on your machine (e.g. ActiveState or Strawberry), and available on your %PATH%
  2. Ensure you have NASM installed on your machine, and available on your %PATH%
  3. launch a Visual Studio tool x64 Cross Tools Command prompt
  4. change to the directory where you have copied openssl sources cd c:myPathopenssl
  5. 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.
  6. prepare the target environment with the command: msdo_win64a
  7. 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 clean for the DLL target and nmake -f msnt.mak clean for static libraries.
  8. build the code with: nmake -f msntdll.mak (respectively nmake -f msnt.mak )
  9. 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.
  10. 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
  11. 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.

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 2048

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

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

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

Generate SHA265 Key from .crt file

openssl x509 -in mydomain.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

Output:

XXXXXXxxXXXXXXXXXXXXXXXxXXXXxXXXX121XX=

Generate PF12 file .crt file

openssl pkcs12 -export -out yourdomain.com.p12 -inkey yourdomain.com.key -in yourdomain.crt -certfile CACert.crt

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

OpenSSL is a small but powerful open source cross-platform utility, which can be used in various digital PKI certificate activities. OpenSSL can be used to convert the digital certificates from one to another format, export private keys from certificates, and build your own Certificate Authority. However, OpenSSL is included in basic packages in most of the popular Linux distributions. It is not required to install the OpenSSL on Linux. Well, the story is not similar in the case of the Windows platform. Don’t be disappointed, since OpenSSL is a cross-platform utility that supports Windows, Linux, and mac. You can install OpenSSL on the Windows platform just with few clicks.

Why Should You Install OpenSSL On Windows?

First of all, OpenSSL is not for normal users. It is not mandatory to install OpenSSL on the Windows platform. As we said earlier, OpenSSL is a cryptographic SSL/TLS tool kit, which provides a wide range of solutions for those who work on Digital Certificates, SSL/TLS testing, application development or implementation, application testing, and security testing. There are a lot of things you can do using OpenSSL. Only a few of them are listed here:

  1. You can create your own Certificate Authority and issue certificates on your network. 
  2. Convert digital certificates from one to another format. 
  3. Export or Import private keys from the certificates.
  4. Validate the HTTPS connections to the destination website.
  5. Verify the certificate of the destination website.
  6. Run benchmark tests of your server and remote website.
  7. Extract information like issuer, subject, issued and expiring dates, and fingerprint from certificates.
  8. Create CSR.
  9. Decode CSR and Certificates to verify contents.

You can enjoy the features of OpenSSL if you have installed it on your Windows machine.
Let’s begin the procedure to install OpenSSL on the Windows platform.

How To Install OpenSSL On The Windows Platform?

The installation procedure is very simple and straight. You should download the OpenSSL installer, run it to install, and configure Environment variables.

Time needed: 10 minutes.

How to Install OpenSSL on The Windows Platform?

  1. Download the OpenSSL installer

    Download the OpenSSL installer from the official OpenSSL download link: https://slproweb.com/products/Win32OpenSSL.html

    Download the OpenSSL installer for Windows

  2. Run the OpenSSL installer to install

    Execute the downloaded installer file and install the OpenSSL on the Windows machine.

    The installation procedure is quite simple and straight.
    1. Accept license agreement.
    2. Specify the Installation location.

    Specify the Installation location

  3. Initiate installing OpenSSL

    Set Start Menu location and the additional task then click on the Install button to initiate the OpenSSL installation.

    Initiate installing OpenSSL

  4. Installation in progress…….

    Installation of OpenSSL in progress

  5. Complete the installation of OpenSSL.

    The installation will take 5 to 10 seconds. Click Finish to complete the installation process.

    Finish installing OpenSSL

  6. Set Environment variable

    If you just want to set the environment varibles only for a login session, then run these commands.

    >set OPENSSL_CONF=C:Program FilesOpenSSL-Win64binopenssl.cfg
    >set Path=
    C:Program FilesOpenSSL-Win64bin

    If you want to set the env variable for permanently, then add OPENSSL_CONF and Path env variable on System Properties.

    Open Run using ‘Windows’ + ‘r’ then type ‘sysdm.cpl‘. Go to Advanced > Environment Variable.

    Set OPENSSL_CONF and Path variables.

    Environment Variables to run OpenSSL on Windows

  7. Run OpenSSL

    Open the command prompt using ‘Windows’ + ‘r’ then type ‘cmd‘ to open command prompt.

    Type openssl version command on CLI to ensure OpenSSL is installed and configured on your Windows machine. You should see the version information if OpenSSL is configured correctly.

    Run OpenSSL on Windows

Thats’s it. This is how you can install OpenSSL on the Windows platform. Simple itn’t it?

Thanks for reading the small tutorial. Please follow us on this blog to see more such tutorials and security updates.

Author Image

Arun KL

Hi All, I am Arun KL, an IT Security Professional. Founder of “thesecmaster.com”. Enthusiast, Security Blogger, Technical Writer, Editor, Author at TheSecMaster. To know more about me. Follow me on LinkedIn

Generating SSL certificates can be a daunting task, one filled with frustration and sorrow. But it doesn’t have to be that way! If you have Windows 10 and OpenSSL along with a little help from this tutorial, you will be well on your way.

Not a reader? Watch this related video tutorial!

Not seeing the video? Make sure your ad blocker is disabled.

In this article, you’re going to learn how to install OpenSSL on Windows 10. Once installed, you’ll then generate SSL certificates, troubleshoot and debug certificates, and convert between formats.

Let’s begin mastering OpenSSL on Windows 10 with PowerShell!

Related: Managing Certs with Windows Certificate Manager and PowerShell

Prerequisites

In this article, you are going to learn using a hands-on approach. While OpenSSL historically is a Linux OS utility, you can use it with Windows OS as well.

  • A Windows system with Local Administrator rights – The tutorial will be using Windows 10
  • Windows PowerShell 5.1 (comes with Windows) or PowerShell 7
  • Chocolatey – A package manager for Windows installed.
  • PowerShell ISE, Visual Studio Code or any text editor of your choice

All screenshots in this guide were taken from Windows 10 build 1909 and PowerShell 7.

Installing OpenSSL on Windows 10 with PowerShell and Chocolatey

Assuming you have installed Chocolatey using the installation instructions, your first task is to install OpenSSL on Windows 10. To do this, open up your PowerShell console and run choco install OpenSSL.Lightas shown below.

Installing OpenSSL.Light using <a class=
Installing OpenSSL.Light using Chocolatey package manager in PowerShell

That’s it! You’ve now installed OpenSSL with PowerShell.

Set up a Working Directory

This tutorial will be creating a few certificates to learn from. To ensure all of the work you do here is confined to a single folder you can clean up later, go ahead and create one.

This tutorial will store all certificates and related files in the C:certs folder. You can create a folder with PowerShell by running the below command.

New-Item -ItemType Directory -Path C:certs

Now it’s time to configure OpenSSL.

Configuring OpenSSL

By default, OpenSSL on Windows 10 does not come with a configuration file. This is intentional because there are a lot of configuration options that you can customize. For the purposes of this guide, you are going to use a sample configuration that you can customize later to best suit your security requirements.

Open up PowerShell and run the below command. This command downloads a sample configuration file from MIT and saves it as openssl.cnf in the current working directory.

You can now open up the openssl.cnf file and you should see something that looks like below.

Sample OpenSSL configuration file in Visual Studio Code
Sample OpenSSL configuration file

The downloaded configuration will work as-is for now. Do not use the defaults in a production environment!

Update PowerShell Profile Environment Variables

To make things go smoothly, you should modify your PowerShell profile on Windows 10. Setting up some environment variables allows you to easily switch between different versions of OpenSSL that you may have installed.

I suggest adding two environment variables to your PowerShell profile called path and OPENSSL_CONF. You will update the PATH environment variable to ensure you can run the openssl binary in any location while on the command line.

Below you’ll see a way to create a PowerShell profile if you don’t already have one. This command appends the OpenSSL binary path to your PATH and assign the configuration file path to OPENSSL_CONF.

# Add environment variables to PowerShell profile
# Test for a profile, if not found create one!
if (-not (Test-Path $profile) ) {
    New-Item -Path $profile -ItemType File -Force
}

# Edit profile to add these lines
'$env:path = "$env:path;C:Program FilesOpenSSLbin"' | Out-File $profile -Append
'$env:OPENSSL_CONF = "C:certsopenssl.cnf"' | Out-File $profile -Append

To use the environment variables, reload your profile typing . $profile or just close and reopen PowerShell.

Now you can easily invoke the openssl binary wherever you are in PowerShell as shown below.

Verifying OpenSSL version in PowerShell
Verifying OpenSSL version in PowerShell

Using OpenSSL on Windows 10 to Generate a CSR & Private Key

Before you can create an SSL certificate, you must generate a certifiate-signing request (CSR). A CSR is an encoded file that provides you with a way to share your public key with a certificate authority (CA). This file contains identifying information, a signature algorithm, and a digital signature. Let’s create your first CSR and private key.

Related: Your Guide to X509 Certificates for Mortals

To create a CSR, run the below command. OpenSSL will then prompt you to enter some identifying information as you can see in the following demonstration.

openssl req -new -out MyFirst.csr
Generating a CSR and Private Key using OpenSSL in PowerShell
Generating a CSR and Private Key using OpenSSL in PowerShell

Once complete, you will have a valid CSR and private key which can be used to issue an SSL certificate to you.

The configuration file defaults can be edited further to streamline this process should you not want to enter data every time you generate a CSR.

You can read more about the available CSR options and view sample configurations in the man pages. OpenSSL also has an active GitHub repository with examples too.

Generating RSA Key Pairs

You can also create RSA key pairs (public/private) with OpenSSL. To do so, first, create a private key using the genrsa sub-command as shown below.

When you run the command below, OpenSSL on Windows 10 will generate a RSA private key with a key length of 2048 bits. This key is generated almost immediately on modern hardware. The resulting key is output in the working directory

# generate a private key using maximum key size of 2048
# key sizes can be 512, 758, 1024, 1536 or 2048. 
openssl genrsa -out rsa.private 2048

Next, generate a public key using the private key that you just created using the rsa sub-command. The syntax below will create a public key called rsa.public in the working directory from the rsa.private private key.

# generate a public key using the private key
openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

Generating a Self-Signed Certificate

On occasion you may need to generate a self-signed certificate. Self-signed certificates are fine to use for lab use but not a secure practice to use in a production environment.

Let’s create a self-signed certificate before moving onto the next task. To do so, enter the command below to create an X509 SSL certificate. This certificate will use SHA256 cryptography that will be valid for 365 days using an RSA key length of 2048 bits. The certificate will be saved to the working directory.

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt

You are now ready to import the certificate into a browser or server.

Validating CSRs, Certificates, and Keys with OpenSSL

Checking the information in a CSR, private key, certificate, or PKCS#12 can save you time troubleshooting SSL errors. Sometimes a wrong key may have been used to create a certificate, for example. You may have the wrong identifying information in the certificate.

Let’s start by checking a CSR using the req command and some parameters:

openssl req -text -noout -verify -in .MyFirst.csr
Checking a CSR with OpenSSL in PowerShell
Checking a CSR with OpenSSL in PowerShell

Details such as country name, organizational name, and the email address you entered when creating the CSR at the beginning of this guide, should match precisely.

You can also check a certificate using the x509 sub-command with a couple of parameters:

openssl x509 -in .certificate.crt -text -noout | more
Checking a certificate with OpenSSL with the x509 command in PowerShell
Checking a certificate with OpenSSL with the x509 command in PowerShell

Converting Certificates with OpenSSL

There are occasions where an application does not use a particular certificate format. You can run into this issue with an application called HAproxy, for example that requires a PEM certificate when you may have a DER-formatted certificate (.crt .cer .der).

To demonstrate converting a certificate, let’s convert the self-signed certificate created earlier in a DER format (certificate.crt) to PEM. Use the code in the following code snippet to do so.

This command below uses the x509 sub-command with the parameter of -inform which should match the format of the -in file followed by the -out format.

openssl x509 -inform der -in .certificate.crt -out .certificate.pem

You can also reverse the order if you’d like to the DER format from PEM too as shown below.

openssl x509 -outform der -in .certificate.pem -out .certificate.der

And last but not least, you can convert PKCS#12 to PEM and PEM to PKCS#12. This is a file type that contain private keys and certificates. To convert to PEM format, use the pkcs12 sub-command.

openssl pkcs12 -in .SomeKeyStore.pfx -out .SomeKeyStore.pem -nodes

You can convert a PEM certificate and private key to PKCS#12 format as well using -export with a few additional options. Below you are exporting a PKCS#12 formatted certificate using your private key by using SomeCertificate.crt as the input source. Using the -certfile option value MyCACert.crt allows you to validate SomeCertificate.crt.

openssl pkcs12 -export -out SomeCertificate.pfx -inkey SomePrivateKey.key -in SomeCertificate.crt -certfile MyCACert.crt

Troubleshooting & Debugging

Now that you can create & convert CSR’s, certificates, and key pairs, it’s time to learn how to troubleshoot and debug them. OpenSSL comes with commands that make it a breeze to troubleshoot problems.

OpenSSL also allows you to check certificates for file integrity and test for possible data corruption. Using an MD5 checksum, you can use the following code examples to test certificates, keys and CSR’s:

# Certificates
openssl x509 -noout -modulus -in .certificate.crt | openssl md5

# Public / Private Keys
openssl rsa -noout -modulus -in .privateKey.key | openssl md5

# Certificate Server Request
openssl req -noout -modulus -in .MyFirst.csr | openssl md5

# Check an external SSL connection
openssl s_client -connect www.google.com:443

Once you have the original hash, you can then compare that original hash with a current hash to verify the certificate hasn’t been modified or corrupted.

Here’s a sample of what that code looks like when run in PowerShell:

Sample troubleshooting command output with OpenSSL in PowerShell
Sample troubleshooting command output with OpenSSL in PowerShell

Summary

In this article, you have learned how to install and configure OpenSSL on Windows 10, create a CSR, key pair, and SSL certificate. You have also learned how to convert between different certificate formats and do some basic troubleshooting using built-in sub-commands.

Additional Resources

  • OpenSSL config man page
  • OpenSSL commands
  • Online SSL Checker
  • Automating IIS SSL Certificate Installation with PowerShell
  • How to Create Self-Signed Certificates with PowerShell

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

Download OpenSSL for Windows 10
Download OpenSSL for Windows 10

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:

OpenSSL requires Microsoft Visual C++ 2017
OpenSSL requires Microsoft Visual C++ 2017

Click Yes to download and install required Microsoft Visual C++ package on your system.

OpenSSL requires Microsoft Visual C++ 2017
OpenSSL requires Microsoft Visual C++ 2017

Then again run the OpenSSL installer and follow the wizard.

OpenSSL setup
OpenSSL setup

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.

Windows 10 Settings page

Secondly, select the option “Edit the system environment variables“.

System Properties on Windows 10
System Properties on Windows 10

Thirdly, at the bottom of this window, click on Environment Variables…

Environment properties on Windows 10
Environment properties on Windows 10

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

Edit System Variable on Windows 10
Edit System Variable on Windows 10

Now, double click on the variable called “Path“.

Edit environment variable on Windows 10
Edit environment variable on Windows 10

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.

OpenSSL is running on PowerShell on Windows 10
OpenSSL is running on PowerShell on Windows 10

Conclusion

In conclusion, this is how to install OpenSSL on Windows 10. If you have any question, please use our Forum.

Понравилась статья? Поделить с друзьями:
  • How to install fonts on windows 10
  • How to install font to windows
  • How to install ffmpeg on windows
  • How to install fedora along windows
  • How to install openssh on windows 7