• Home
Name
Date
Size
#Lines
LOC

..--

Configurations/12-May-2024-10,1498,665

VMS/12-May-2024-452400

apps/12-May-2024-57,40248,514

crypto/12-May-2024-510,084404,740

demos/12-May-2024-8,9475,829

doc/12-May-2024-130,10392,455

engines/12-May-2024-10,8088,381

external/perl/12-May-2024-5,0282,210

fuzz/12-May-2024-3,7673,127

include/12-May-2024-50,02236,140

ms/12-May-2024-598431

ohos_lite/12-May-2024-44,97331,570

open_harmony_openssl_config/12-May-2024-3726

os-dep/12-May-2024-122

providers/12-May-2024-59,55145,268

ssl/12-May-2024-59,68544,076

test/12-May-2024-386,523327,920

tools/12-May-2024-260207

util/12-May-2024-28,20522,825

ACKNOWLEDGEMENTS.mdD12-May-2024157 74

AUTHORS.mdD12-May-2024990 5246

BUILD.gnD12-May-202464.8 KiB1,9111,839

CHANGES.mdD12-May-2024728.9 KiB19,83313,800

CONTRIBUTING.mdD12-May-20244.3 KiB9572

COPYRIGHT.OpenSourceD12-May-202412.2 KiB187186

ConfigureD12-May-2024132.4 KiB3,5952,842

FAQ.mdD12-May-2024197 74

HACKING.mdD12-May-20241.2 KiB3425

INSTALL.mdD12-May-202461.5 KiB1,8181,253

LICENSE.txtD12-May-20249.9 KiB178150

NEWS.mdD12-May-202471.8 KiB1,6041,295

NOTES-ANDROID.mdD12-May-20244.5 KiB9172

NOTES-DJGPP.mdD12-May-20242.1 KiB4736

NOTES-NONSTOP.mdD12-May-202410.6 KiB260197

NOTES-PERL.mdD12-May-20244.9 KiB12895

NOTES-UNIX.mdD12-May-20245.6 KiB11693

NOTES-VALGRIND.mdD12-May-20242.7 KiB7352

NOTES-VMS.mdD12-May-20244.7 KiB13393

NOTES-WINDOWS.mdD12-May-20249 KiB266182

OAT.xmlD12-May-20243.1 KiB4227

README-ENGINES.mdD12-May-202415.3 KiB317264

README-FIPS.mdD12-May-20243.8 KiB8763

README-PROVIDERS.mdD12-May-20245.3 KiB146111

README.OpenSourceD12-May-2024453 1111

README.mdD12-May-20246.5 KiB225161

SUPPORT.mdD12-May-20243.8 KiB9469

VERSION.datD12-May-2024100 87

appveyor.ymlD12-May-20242 KiB8375

build.infoD12-May-20243.7 KiB9384

bundle.jsonD12-May-2024984 3837

configD12-May-2024378 112

config.comD12-May-20242.5 KiB9490

configdata.pm.inD12-May-202416.3 KiB488375

e_os.hD12-May-202412.8 KiB433287

empty.pyD12-May-20240 10

make_openssl_build_all_generated.shD12-May-20242.5 KiB4913

run_command.pyD12-May-20241.1 KiB3414

README-ENGINES.md

1 Engines
2 =======
3 
4 Deprecation Note
5 ----------------
6 
7 The ENGINE API was introduced in OpenSSL version 0.9.6 as a low level
8 interface for adding alternative implementations of cryptographic
9 primitives, most notably for integrating hardware crypto devices.
10 
11 The ENGINE interface has its limitations and it has been superseeded
12 by the [PROVIDER API](README-PROVIDERS.md), it is deprecated in OpenSSL
13 version 3.0. The following documentation is retained as an aid for
14 users who need to maintain or support existing ENGINE implementations.
15 Support for new hardware devices or new algorithms should be added
16 via providers, and existing engines should be converted to providers
17 as soon as possible.
18 
19 Built-in ENGINE implementations
20 -------------------------------
21 
22 There are currently built-in ENGINE implementations for the following
23 crypto devices:
24 
25   * Microsoft CryptoAPI
26   * VIA Padlock
27   * nCipher CHIL
28 
29 In addition, dynamic binding to external ENGINE implementations is now
30 provided by a special ENGINE called "dynamic". See the "DYNAMIC ENGINE"
31 section below for details.
32 
33 At this stage, a number of things are still needed and are being worked on:
34 
35   1. Integration of EVP support.
36   2. Configuration support.
37   3. Documentation!
38 
39 Integration of EVP support
40 --------------------------
41 
42 With respect to EVP, this relates to support for ciphers and digests in
43 the ENGINE model so that alternative implementations of existing
44 algorithms/modes (or previously unimplemented ones) can be provided by
45 ENGINE implementations.
46 
47 Configuration support
48 ---------------------
49 
50 Configuration support currently exists in the ENGINE API itself, in the
51 form of "control commands". These allow an application to expose to the
52 user/admin the set of commands and parameter types a given ENGINE
53 implementation supports, and for an application to directly feed string
54 based input to those ENGINEs, in the form of name-value pairs. This is an
55 extensible way for ENGINEs to define their own "configuration" mechanisms
56 that are specific to a given ENGINE (eg. for a particular hardware
57 device) but that should be consistent across *all* OpenSSL-based
58 applications when they use that ENGINE. Work is in progress (or at least
59 in planning) for supporting these control commands from the CONF (or
60 NCONF) code so that applications using OpenSSL's existing configuration
61 file format can have ENGINE settings specified in much the same way.
62 Presently however, applications must use the ENGINE API itself to provide
63 such functionality. To see first hand the types of commands available
64 with the various compiled-in ENGINEs (see further down for dynamic
65 ENGINEs), use the "engine" openssl utility with full verbosity, i.e.:
66 
67     openssl engine -vvvv
68 
69 Documentation
70 -------------
71 
72 Documentation? Volunteers welcome! The source code is reasonably well
73 self-documenting, but some summaries and usage instructions are needed -
74 moreover, they are needed in the same POD format the existing OpenSSL
75 documentation is provided in. Any complete or incomplete contributions
76 would help make this happen.
77 
78 STABILITY & BUG-REPORTS
79 =======================
80 
81 What already exists is fairly stable as far as it has been tested, but
82 the test base has been a bit small most of the time. For the most part,
83 the vendors of the devices these ENGINEs support have contributed to the
84 development and/or testing of the implementations, and *usually* (with no
85 guarantees) have experience in using the ENGINE support to drive their
86 devices from common OpenSSL-based applications. Bugs and/or inexplicable
87 behaviour in using a specific ENGINE implementation should be sent to the
88 author of that implementation (if it is mentioned in the corresponding C
89 file), and in the case of implementations for commercial hardware
90 devices, also through whatever vendor support channels are available.  If
91 none of this is possible, or the problem seems to be something about the
92 ENGINE API itself (ie. not necessarily specific to a particular ENGINE
93 implementation) then you should mail complete details to the relevant
94 OpenSSL mailing list. For a definition of "complete details", refer to
95 the OpenSSL "README" file. As for which list to send it to:
96 
97   * openssl-users: if you are *using* the ENGINE abstraction, either in an
98     pre-compiled application or in your own application code.
99 
100   * openssl-dev: if you are discussing problems with OpenSSL source code.
101 
102 USAGE
103 =====
104 
105 The default "openssl" ENGINE is always chosen when performing crypto
106 operations unless you specify otherwise. You must actively tell the
107 openssl utility commands to use anything else through a new command line
108 switch called "-engine". Also, if you want to use the ENGINE support in
109 your own code to do something similar, you must likewise explicitly
110 select the ENGINE implementation you want.
111 
112 Depending on the type of hardware, system, and configuration, "settings"
113 may need to be applied to an ENGINE for it to function as expected/hoped.
114 The recommended way of doing this is for the application to support
115 ENGINE "control commands" so that each ENGINE implementation can provide
116 whatever configuration primitives it might require and the application
117 can allow the user/admin (and thus the hardware vendor's support desk
118 also) to provide any such input directly to the ENGINE implementation.
119 This way, applications do not need to know anything specific to any
120 device, they only need to provide the means to carry such user/admin
121 input through to the ENGINE in question. Ie. this connects *you* (and
122 your helpdesk) to the specific ENGINE implementation (and device), and
123 allows application authors to not get buried in hassle supporting
124 arbitrary devices they know (and care) nothing about.
125 
126 A new "openssl" utility, "openssl engine", has been added in that allows
127 for testing and examination of ENGINE implementations. Basic usage
128 instructions are available by specifying the "-?" command line switch.
129 
130 DYNAMIC ENGINES
131 ===============
132 
133 The new "dynamic" ENGINE provides a low-overhead way to support ENGINE
134 implementations that aren't pre-compiled and linked into OpenSSL-based
135 applications. This could be because existing compiled-in implementations
136 have known problems and you wish to use a newer version with an existing
137 application. It could equally be because the application (or OpenSSL
138 library) you are using simply doesn't have support for the ENGINE you
139 wish to use, and the ENGINE provider (eg. hardware vendor) is providing
140 you with a self-contained implementation in the form of a shared-library.
141 The other use-case for "dynamic" is with applications that wish to
142 maintain the smallest foot-print possible and so do not link in various
143 ENGINE implementations from OpenSSL, but instead leaves you to provide
144 them, if you want them, in the form of "dynamic"-loadable
145 shared-libraries. It should be possible for hardware vendors to provide
146 their own shared-libraries to support arbitrary hardware to work with
147 applications based on OpenSSL 0.9.7 or later. If you're using an
148 application based on 0.9.7 (or later) and the support you desire is only
149 announced for versions later than the one you need, ask the vendor to
150 backport their ENGINE to the version you need.
151 
152 How does "dynamic" work?
153 ------------------------
154 
155 The dynamic ENGINE has a special flag in its implementation such that
156 every time application code asks for the 'dynamic' ENGINE, it in fact
157 gets its own copy of it. As such, multi-threaded code (or code that
158 multiplexes multiple uses of 'dynamic' in a single application in any
159 way at all) does not get confused by 'dynamic' being used to do many
160 independent things. Other ENGINEs typically don't do this so there is
161 only ever 1 ENGINE structure of its type (and reference counts are used
162 to keep order). The dynamic ENGINE itself provides absolutely no
163 cryptographic functionality, and any attempt to "initialise" the ENGINE
164 automatically fails. All it does provide are a few "control commands"
165 that can be used to control how it will load an external ENGINE
166 implementation from a shared-library. To see these control commands,
167 use the command-line;
168 
169     openssl engine -vvvv dynamic
170 
171 The "SO_PATH" control command should be used to identify the
172 shared-library that contains the ENGINE implementation, and "NO_VCHECK"
173 might possibly be useful if there is a minor version conflict and you
174 (or a vendor helpdesk) is convinced you can safely ignore it.
175 "ID" is probably only needed if a shared-library implements
176 multiple ENGINEs, but if you know the engine id you expect to be using,
177 it doesn't hurt to specify it (and this provides a sanity check if
178 nothing else). "LIST_ADD" is only required if you actually wish the
179 loaded ENGINE to be discoverable by application code later on using the
180 ENGINE's "id". For most applications, this isn't necessary - but some
181 application authors may have nifty reasons for using it. The "LOAD"
182 command is the only one that takes no parameters and is the command
183 that uses the settings from any previous commands to actually *load*
184 the shared-library ENGINE implementation. If this command succeeds, the
185 (copy of the) 'dynamic' ENGINE will magically morph into the ENGINE
186 that has been loaded from the shared-library. As such, any control
187 commands supported by the loaded ENGINE could then be executed as per
188 normal. Eg. if ENGINE "foo" is implemented in the shared-library
189 "libfoo.so" and it supports some special control command "CMD_FOO", the
190 following code would load and use it (NB: obviously this code has no
191 error checking);
192 
193     ENGINE *e = ENGINE_by_id("dynamic");
194     ENGINE_ctrl_cmd_string(e, "SO_PATH", "/lib/libfoo.so", 0);
195     ENGINE_ctrl_cmd_string(e, "ID", "foo", 0);
196     ENGINE_ctrl_cmd_string(e, "LOAD", NULL, 0);
197     ENGINE_ctrl_cmd_string(e, "CMD_FOO", "some input data", 0);
198 
199 For testing, the "openssl engine" utility can be useful for this sort
200 of thing. For example the above code excerpt would achieve much the
201 same result as;
202 
203     openssl engine dynamic \
204               -pre SO_PATH:/lib/libfoo.so \
205               -pre ID:foo \
206               -pre LOAD \
207               -pre "CMD_FOO:some input data"
208 
209 Or to simply see the list of commands supported by the "foo" ENGINE;
210 
211     openssl engine -vvvv dynamic \
212               -pre SO_PATH:/lib/libfoo.so \
213               -pre ID:foo \
214               -pre LOAD
215 
216 Applications that support the ENGINE API and more specifically, the
217 "control commands" mechanism, will provide some way for you to pass
218 such commands through to ENGINEs. As such, you would select "dynamic"
219 as the ENGINE to use, and the parameters/commands you pass would
220 control the *actual* ENGINE used. Each command is actually a name-value
221 pair and the value can sometimes be omitted (eg. the "LOAD" command).
222 Whilst the syntax demonstrated in "openssl engine" uses a colon to
223 separate the command name from the value, applications may provide
224 their own syntax for making that separation (eg. a win32 registry
225 key-value pair may be used by some applications). The reason for the
226 "-pre" syntax in the "openssl engine" utility is that some commands
227 might be issued to an ENGINE *after* it has been initialised for use.
228 Eg. if an ENGINE implementation requires a smart-card to be inserted
229 during initialisation (or a PIN to be typed, or whatever), there may be
230 a control command you can issue afterwards to "forget" the smart-card
231 so that additional initialisation is no longer possible. In
232 applications such as web-servers, where potentially volatile code may
233 run on the same host system, this may provide some arguable security
234 value. In such a case, the command would be passed to the ENGINE after
235 it has been initialised for use, and so the "-post" switch would be
236 used instead. Applications may provide a different syntax for
237 supporting this distinction, and some may simply not provide it at all
238 ("-pre" is almost always what you're after, in reality).
239 
240 How do I build a "dynamic" ENGINE?
241 ----------------------------------
242 
243 This question is trickier - currently OpenSSL bundles various ENGINE
244 implementations that are statically built in, and any application that
245 calls the "ENGINE_load_builtin_engines()" function will automatically
246 have all such ENGINEs available (and occupying memory). Applications
247 that don't call that function have no ENGINEs available like that and
248 would have to use "dynamic" to load any such ENGINE - but on the other
249 hand such applications would only have the memory footprint of any
250 ENGINEs explicitly loaded using user/admin provided control commands.
251 The main advantage of not statically linking ENGINEs and only using
252 "dynamic" for hardware support is that any installation using no
253 "external" ENGINE suffers no unnecessary memory footprint from unused
254 ENGINEs. Likewise, installations that do require an ENGINE incur the
255 overheads from only *that* ENGINE once it has been loaded.
256 
257 Sounds good? Maybe, but currently building an ENGINE implementation as
258 a shared-library that can be loaded by "dynamic" isn't automated in
259 OpenSSL's build process. It can be done manually quite easily however.
260 Such a shared-library can either be built with any OpenSSL code it
261 needs statically linked in, or it can link dynamically against OpenSSL
262 if OpenSSL itself is built as a shared library. The instructions are
263 the same in each case, but in the former (statically linked any
264 dependencies on OpenSSL) you must ensure OpenSSL is built with
265 position-independent code ("PIC"). The default OpenSSL compilation may
266 already specify the relevant flags to do this, but you should consult
267 with your compiler documentation if you are in any doubt.
268 
269 This example will show building the "atalla" ENGINE in the
270 crypto/engine/ directory as a shared-library for use via the "dynamic"
271 ENGINE.
272 
273   1. "cd" to the crypto/engine/ directory of a pre-compiled OpenSSL
274      source tree.
275 
276   2. Recompile at least one source file so you can see all the compiler
277      flags (and syntax) being used to build normally. Eg;
278 
279          touch hw_atalla.c ; make
280 
281      will rebuild "hw_atalla.o" using all such flags.
282 
283   3. Manually enter the same compilation line to compile the
284      "hw_atalla.c" file but with the following two changes;
285       * add "-DENGINE_DYNAMIC_SUPPORT" to the command line switches,
286       * change the output file from "hw_atalla.o" to something new,
287         eg. "tmp_atalla.o"
288 
289   4. Link "tmp_atalla.o" into a shared-library using the top-level
290      OpenSSL libraries to resolve any dependencies. The syntax for doing
291      this depends heavily on your system/compiler and is a nightmare
292      known well to anyone who has worked with shared-library portability
293      before. 'gcc' on Linux, for example, would use the following syntax;
294 
295          gcc -shared -o dyn_atalla.so tmp_atalla.o -L../.. -lcrypto
296 
297   5. Test your shared library using "openssl engine" as explained in the
298      previous section. Eg. from the top-level directory, you might try
299 
300          apps/openssl engine -vvvv dynamic \
301                -pre SO_PATH:./crypto/engine/dyn_atalla.so -pre LOAD
302 
303 If the shared-library loads successfully, you will see both "-pre"
304 commands marked as "SUCCESS" and the list of control commands
305 displayed (because of "-vvvv") will be the control commands for the
306 *atalla* ENGINE (ie. *not* the 'dynamic' ENGINE). You can also add
307 the "-t" switch to the utility if you want it to try and initialise
308 the atalla ENGINE for use to test any possible hardware/driver issues.
309 
310 PROBLEMS
311 ========
312 
313 It seems like the ENGINE part doesn't work too well with CryptoSwift on Win32.
314 A quick test done right before the release showed that trying "openssl speed
315 -engine cswift" generated errors. If the DSO gets enabled, an attempt is made
316 to write at memory address 0x00000002.
317 

README-FIPS.md

1 OpenSSL FIPS support
2 ====================
3 
4 This release of OpenSSL includes a cryptographic module that can be
5 FIPS 140-2 validated. The module is implemented as an OpenSSL provider.
6 A provider is essentially a dynamically loadable module which implements
7 cryptographic algorithms, see the [README-PROVIDERS](README-PROVIDERS.md) file
8 for further details.
9 
10 A cryptographic module is only FIPS validated after it has gone through the complex
11 FIPS 140 validation process. As this process takes a very long time, it is not
12 possible to validate every minor release of OpenSSL.
13 If you need a FIPS validated module then you must ONLY generate a FIPS provider
14 using OpenSSL versions that have valid FIPS certificates. A FIPS certificate
15 contains a link to a Security Policy, and you MUST follow the instructions
16 in the Security Policy in order to be FIPS compliant.
17 See <https://www.openssl.org/source/> for information related to OpenSSL
18 FIPS certificates and Security Policies.
19 
20 Newer OpenSSL Releases that include security or bug fixes can be used to build
21 all other components (such as the core API's, TLS and the default, base and
22 legacy providers) without any restrictions, but the FIPS provider must be built
23 as specified in the Security Policy (normally with a different version of the
24 source code).
25 
26 The OpenSSL FIPS provider is a shared library called `fips.so` (on Unix), or
27 resp. `fips.dll` (on Windows). The FIPS provider does not get built and
28 installed automatically. To enable it, you need to configure OpenSSL using
29 the `enable-fips` option.
30 
31 Installing the FIPS module
32 ==========================
33 
34 The following is only a guide.
35 Please read the Security Policy for up to date installation instructions.
36 
37 If the FIPS provider is enabled, it gets installed automatically during the
38 normal installation process. Simply follow the normal procedure (configure,
39 make, make test, make install) as described in the [INSTALL](INSTALL.md) file.
40 
41 For example, on Unix the final command
42 
43     $ make install
44 
45 effectively executes the following install targets
46 
47     $ make install_sw
48     $ make install_ssldirs
49     $ make install_docs
50     $ make install_fips     # for `enable-fips` only
51 
52 The `install_fips` make target can also be invoked explicitly to install
53 the FIPS provider independently, without installing the rest of OpenSSL.
54 
55 The Installation of the FIPS provider consists of two steps. In the first step,
56 the shared library is copied to its installed location, which by default is
57 
58     /usr/local/lib/ossl-modules/fips.so                  on Unix, and
59     C:\Program Files\OpenSSL\lib\ossl-modules\fips.dll   on Windows.
60 
61 In the second step, the `openssl fipsinstall` command is executed, which completes
62 the installation by doing the following two things:
63 
64 - Runs the FIPS module self tests
65 - Generates the so-called FIPS module configuration file containing information
66   about the module such as the self test status, and the module checksum.
67 
68 The FIPS module must have the self tests run, and the FIPS module config file
69 output generated on every machine that it is to be used on. You must not copy
70 the FIPS module config file output data from one machine to another.
71 
72 On Unix the `openssl fipsinstall` command will be invoked as follows by default:
73 
74     $ openssl fipsinstall -out /usr/local/ssl/fipsmodule.cnf -module /usr/local/lib/ossl-modules/fips.so
75 
76 If you configured OpenSSL to be installed to a different location, the paths will
77 vary accordingly. In the rare case that you need to install the fipsmodule.cnf
78 to non-standard location, you can execute the `openssl fipsinstall` command manually.
79 
80 Using the FIPS Module in applications
81 =====================================
82 
83 Documentation about using the FIPS module is available on the [fips_module(7)]
84 manual page.
85 
86  [fips_module(7)]: https://www.openssl.org/docs/man3.0/man7/fips_module.html
87 

README-PROVIDERS.md

1 Providers
2 =========
3 
4  - [Standard Providers](#standard-providers)
5     - [The Default Provider](#the-default-provider)
6     - [The Legacy Provider](#the-legacy-provider)
7     - [The FIPS Provider](#the-fips-provider)
8     - [The Base Provider](#the-base-provider)
9     - [The Null Provider](#the-null-provider)
10  - [Loading Providers](#loading-providers)
11 
12 Standard Providers
13 ==================
14 
15 Providers are containers for algorithm implementations. Whenever a cryptographic
16 algorithm is used via the high level APIs a provider is selected. It is that
17 provider implementation that actually does the required work. There are five
18 providers distributed with OpenSSL. In the future we expect third parties to
19 distribute their own providers which can be added to OpenSSL dynamically.
20 Documentation about writing providers is available on the [provider(7)]
21 manual page.
22 
23  [provider(7)]: https://www.openssl.org/docs/man3.0/man7/provider.html
24 
25 The Default Provider
26 --------------------
27 
28 The default provider collects together all of the standard built-in OpenSSL
29 algorithm implementations. If an application doesn't specify anything else
30 explicitly (e.g. in the application or via config), then this is the provider
31 that will be used. It is loaded automatically the first time that we try to
32 get an algorithm from a provider if no other provider has been loaded yet.
33 If another provider has already been loaded then it won't be loaded
34 automatically. Therefore if you want to use it in conjunction with other
35 providers then you must load it explicitly.
36 
37 This is a "built-in" provider which means that it is compiled and linked
38 into the libcrypto library and does not exist as a separate standalone module.
39 
40 The Legacy Provider
41 -------------------
42 
43 The legacy provider is a collection of legacy algorithms that are either no
44 longer in common use or considered insecure and strongly discouraged from use.
45 However, some applications may need to use these algorithms for backwards
46 compatibility reasons. This provider is **not** loaded by default.
47 This may mean that some applications upgrading from earlier versions of OpenSSL
48 may find that some algorithms are no longer available unless they load the
49 legacy provider explicitly.
50 
51 Algorithms in the legacy provider include MD2, MD4, MDC2, RMD160, CAST5,
52 BF (Blowfish), IDEA, SEED, RC2, RC4, RC5 and DES (but not 3DES).
53 
54 The FIPS Provider
55 -----------------
56 
57 The FIPS provider contains a sub-set of the algorithm implementations available
58 from the default provider, consisting of algorithms conforming to FIPS standards.
59 It is intended that this provider will be FIPS140-2 validated.
60 
61 In some cases there may be minor behavioural differences between algorithm
62 implementations in this provider compared to the equivalent algorithm in the
63 default provider. This is typically in order to conform to FIPS standards.
64 
65 The Base Provider
66 -----------------
67 
68 The base provider contains a small sub-set of non-cryptographic algorithms
69 available in the default provider. For example, it contains algorithms to
70 serialize and deserialize keys to files. If you do not load the default
71 provider then you should always load this one instead (in particular, if
72 you are using the FIPS provider).
73 
74 The Null Provider
75 -----------------
76 
77 The null provider is "built-in" to libcrypto and contains no algorithm
78 implementations. In order to guarantee that the default provider is not
79 automatically loaded, the null provider can be loaded instead.
80 
81 This can be useful if you are using non-default library contexts and want
82 to ensure that the default library context is never used unintentionally.
83 
84 Loading Providers
85 =================
86 
87 Providers to be loaded can be specified in the OpenSSL config file.
88 See the [config(5)] manual page for information about how to configure
89 providers via the config file, and how to automatically activate them.
90 
91  [config(5)]: https://www.openssl.org/docs/man3.0/man5/config.html
92 
93 The following is a minimal config file example to load and activate both
94 the legacy and the default provider in the default library context.
95 
96     openssl_conf = openssl_init
97 
98     [openssl_init]
99     providers = provider_sect
100 
101     [provider_sect]
102     default = default_sect
103     legacy = legacy_sect
104 
105     [default_sect]
106     activate = 1
107 
108     [legacy_sect]
109     activate = 1
110 
111 It is also possible to load providers programmatically. For example you can
112 load the legacy provider into the default library context as shown below.
113 Note that once you have explicitly loaded a provider into the library context
114 the default provider will no longer be automatically loaded. Therefore you will
115 often also want to explicitly load the default provider, as is done here:
116 
117     #include <stdio.h>
118     #include <stdlib.h>
119 
120     #include <openssl/provider.h>
121 
122     int main(void)
123     {
124         OSSL_PROVIDER *legacy;
125         OSSL_PROVIDER *deflt;
126 
127         /* Load Multiple providers into the default (NULL) library context */
128         legacy = OSSL_PROVIDER_load(NULL, "legacy");
129         if (legacy == NULL) {
130             printf("Failed to load Legacy provider\n");
131             exit(EXIT_FAILURE);
132         }
133         deflt = OSSL_PROVIDER_load(NULL, "default");
134         if (deflt == NULL) {
135             printf("Failed to load Default provider\n");
136             OSSL_PROVIDER_unload(legacy);
137             exit(EXIT_FAILURE);
138         }
139 
140         /* Rest of application */
141 
142         OSSL_PROVIDER_unload(legacy);
143         OSSL_PROVIDER_unload(deflt);
144         exit(EXIT_SUCCESS);
145     }
146 

README.OpenSource

1 [
2   {
3     "Name": "OpenSSL",
4     "License": "Apache License 2.0",
5     "License File": "LICENSE.txt",
6     "Version Number": "3.0.9",
7     "Owner": "wanghaixiang@huawei.com",
8     "Upstream URL": "https://www.openssl.org/source/openssl-3.0.9.tar.gz",
9     "Description": "OpenSSL is a robust, commercial-grade, full-featured Open Source Toolkit for the Transport Layer Security (TLS) protocol formerly known as the Secure Sockets Layer (SSL) protocol."
10   }
11 ]

README.md

1 Welcome to the OpenSSL Project
2 ==============================
3 
4 [![openssl logo]][www.openssl.org]
5 
6 [![github actions ci badge]][github actions ci]
7 [![appveyor badge]][appveyor jobs]
8 
9 OpenSSL is a robust, commercial-grade, full-featured Open Source Toolkit
10 for the Transport Layer Security (TLS) protocol formerly known as the
11 Secure Sockets Layer (SSL) protocol. The protocol implementation is based
12 on a full-strength general purpose cryptographic library, which can also
13 be used stand-alone.
14 
15 OpenSSL is descended from the SSLeay library developed by Eric A. Young
16 and Tim J. Hudson.
17 
18 The official Home Page of the OpenSSL Project is [www.openssl.org].
19 
20 Table of Contents
21 =================
22 
23  - [Overview](#overview)
24  - [Download](#download)
25  - [Build and Install](#build-and-install)
26  - [Documentation](#documentation)
27  - [License](#license)
28  - [Support](#support)
29  - [Contributing](#contributing)
30  - [Legalities](#legalities)
31 
32 Overview
33 ========
34 
35 The OpenSSL toolkit includes:
36 
37 - **libssl**
38   an implementation of all TLS protocol versions up to TLSv1.3 ([RFC 8446]).
39 
40 - **libcrypto**
41   a full-strength general purpose cryptographic library. It constitutes the
42   basis of the TLS implementation, but can also be used independently.
43 
44 - **openssl**
45   the OpenSSL command line tool, a swiss army knife for cryptographic tasks,
46   testing and analyzing. It can be used for
47   - creation of key parameters
48   - creation of X.509 certificates, CSRs and CRLs
49   - calculation of message digests
50   - encryption and decryption
51   - SSL/TLS client and server tests
52   - handling of S/MIME signed or encrypted mail
53   - and more...
54 
55 Download
56 ========
57 
58 For Production Use
59 ------------------
60 
61 Source code tarballs of the official releases can be downloaded from
62 [www.openssl.org/source](https://www.openssl.org/source).
63 The OpenSSL project does not distribute the toolkit in binary form.
64 
65 However, for a large variety of operating systems precompiled versions
66 of the OpenSSL toolkit are available. In particular on Linux and other
67 Unix operating systems it is normally recommended to link against the
68 precompiled shared libraries provided by the distributor or vendor.
69 
70 For Testing and Development
71 ---------------------------
72 
73 Although testing and development could in theory also be done using
74 the source tarballs, having a local copy of the git repository with
75 the entire project history gives you much more insight into the
76 code base.
77 
78 The official OpenSSL Git Repository is located at [git.openssl.org].
79 There is a GitHub mirror of the repository at [github.com/openssl/openssl],
80 which is updated automatically from the former on every commit.
81 
82 A local copy of the Git Repository can be obtained by cloning it from
83 the original OpenSSL repository using
84 
85     git clone git://git.openssl.org/openssl.git
86 
87 or from the GitHub mirror using
88 
89     git clone https://github.com/openssl/openssl.git
90 
91 If you intend to contribute to OpenSSL, either to fix bugs or contribute
92 new features, you need to fork the OpenSSL repository openssl/openssl on
93 GitHub and clone your public fork instead.
94 
95     git clone https://github.com/yourname/openssl.git
96 
97 This is necessary, because all development of OpenSSL nowadays is done via
98 GitHub pull requests. For more details, see [Contributing](#contributing).
99 
100 Build and Install
101 =================
102 
103 After obtaining the Source, have a look at the [INSTALL](INSTALL.md) file for
104 detailed instructions about building and installing OpenSSL. For some
105 platforms, the installation instructions are amended by a platform specific
106 document.
107 
108  * [Notes for UNIX-like platforms](NOTES-UNIX.md)
109  * [Notes for Android platforms](NOTES-ANDROID.md)
110  * [Notes for Windows platforms](NOTES-WINDOWS.md)
111  * [Notes for the DOS platform with DJGPP](NOTES-DJGPP.md)
112  * [Notes for the OpenVMS platform](NOTES-VMS.md)
113  * [Notes on Perl](NOTES-PERL.md)
114  * [Notes on Valgrind](NOTES-VALGRIND.md)
115 
116 Specific notes on upgrading to OpenSSL 3.0 from previous versions can be found
117 in the [migration_guide(7ossl)] manual page.
118 
119 Documentation
120 =============
121 
122 Manual Pages
123 ------------
124 
125 The manual pages for the master branch and all current stable releases are
126 available online.
127 
128 - [OpenSSL master](https://www.openssl.org/docs/manmaster)
129 - [OpenSSL 3.0](https://www.openssl.org/docs/man3.0)
130 - [OpenSSL 1.1.1](https://www.openssl.org/docs/man1.1.1)
131 
132 Wiki
133 ----
134 
135 There is a Wiki at [wiki.openssl.org] which is currently not very active.
136 It contains a lot of useful information, not all of which is up to date.
137 
138 License
139 =======
140 
141 OpenSSL is licensed under the Apache License 2.0, which means that
142 you are free to get and use it for commercial and non-commercial
143 purposes as long as you fulfill its conditions.
144 
145 See the [LICENSE.txt](LICENSE.txt) file for more details.
146 
147 Support
148 =======
149 
150 There are various ways to get in touch. The correct channel depends on
151 your requirement. see the [SUPPORT](SUPPORT.md) file for more details.
152 
153 Contributing
154 ============
155 
156 If you are interested and willing to contribute to the OpenSSL project,
157 please take a look at the [CONTRIBUTING](CONTRIBUTING.md) file.
158 
159 Legalities
160 ==========
161 
162 A number of nations restrict the use or export of cryptography. If you are
163 potentially subject to such restrictions you should seek legal advice before
164 attempting to develop or distribute cryptographic code.
165 
166 Copyright
167 =========
168 
169 Copyright (c) 1998-2022 The OpenSSL Project
170 
171 Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson
172 
173 All rights reserved.
174 
175 <!-- Links  -->
176 
177 [www.openssl.org]:
178     <https://www.openssl.org>
179     "OpenSSL Homepage"
180 
181 [git.openssl.org]:
182     <https://git.openssl.org>
183     "OpenSSL Git Repository"
184 
185 [git.openssl.org]:
186     <https://git.openssl.org>
187     "OpenSSL Git Repository"
188 
189 [github.com/openssl/openssl]:
190     <https://github.com/openssl/openssl>
191     "OpenSSL GitHub Mirror"
192 
193 [wiki.openssl.org]:
194     <https://wiki.openssl.org>
195     "OpenSSL Wiki"
196 
197 [migration_guide(7ossl)]:
198     <https://www.openssl.org/docs/man3.0/man7/migration_guide.html>
199     "OpenSSL Migration Guide"
200 
201 [RFC 8446]:
202      <https://tools.ietf.org/html/rfc8446>
203 
204 <!-- Logos and Badges -->
205 
206 [openssl logo]:
207     doc/images/openssl.svg
208     "OpenSSL Logo"
209 
210 [github actions ci badge]:
211     <https://github.com/openssl/openssl/workflows/GitHub%20CI/badge.svg>
212     "GitHub Actions CI Status"
213 
214 [github actions ci]:
215     <https://github.com/openssl/openssl/actions?query=workflow%3A%22GitHub+CI%22>
216     "GitHub Actions CI"
217 
218 [appveyor badge]:
219     <https://ci.appveyor.com/api/projects/status/8e10o7xfrg73v98f/branch/master?svg=true>
220     "AppVeyor Build Status"
221 
222 [appveyor jobs]:
223     <https://ci.appveyor.com/project/openssl/openssl/branch/master>
224     "AppVeyor Jobs"
225