]>
Commit | Line | Data |
---|---|---|
2186cd8e UM |
1 | =pod |
2 | ||
3 | =head1 NAME | |
4 | ||
5 | crypto - OpenSSL cryptographic library | |
6 | ||
ff3bb913 RS |
7 | =head1 SYNOPSIS |
8 | ||
9 | See the individual manual pages for details. | |
10 | ||
2186cd8e UM |
11 | =head1 DESCRIPTION |
12 | ||
dfabee82 RL |
13 | The OpenSSL crypto library (C<libcrypto>) implements a wide range of |
14 | cryptographic algorithms used in various Internet standards. The services | |
0666d531 MC |
15 | provided by this library are used by the OpenSSL implementations of TLS and |
16 | CMS, and they have also been used to implement many other third party products | |
17 | and protocols. | |
2186cd8e | 18 | |
0666d531 MC |
19 | The functionality includes symmetric encryption, public key cryptography, key |
20 | agreement, certificate handling, cryptographic hash functions, cryptographic | |
21 | pseudo-random number generators, message authentication codes (MACs), key | |
22 | derivation functions (KDFs), and various utilities. | |
2186cd8e | 23 | |
0666d531 | 24 | =head2 Algorithms |
2186cd8e | 25 | |
0666d531 MC |
26 | Cryptographic primitives such as the SHA256 digest, or AES encryption are |
27 | referred to in OpenSSL as "algorithms". Each algorithm may have multiple | |
28 | implementations available for use. For example the RSA algorithm is available as | |
29 | a "default" implementation suitable for general use, and a "fips" implementation | |
30 | which has been validated to FIPS standards for situations where that is | |
31 | important. It is also possible that a third party could add additional | |
32 | implementations such as in a hardware security module (HSM). | |
72e04bd1 | 33 | |
0666d531 | 34 | =head2 Operations |
72e04bd1 | 35 | |
0666d531 MC |
36 | Different algorithms can be grouped together by their purpose. For example there |
37 | are algorithms for encryption, and different algorithms for digesting data. | |
38 | These different groups are known as "operations" in OpenSSL. Each operation | |
39 | has a different set of functions associated with it. For example to perform an | |
40 | encryption operation using AES (or any other encryption algorithm) you would use | |
41 | the encryption functions detailed on the L<EVP_EncryptInit(3)> page. Or to | |
42 | perform a digest operation using SHA256 then you would use the digesting | |
43 | functions on the L<EVP_DigestInit(3)> page. | |
72e04bd1 | 44 | |
0666d531 | 45 | =head2 Providers |
72e04bd1 | 46 | |
0666d531 MC |
47 | A provider in OpenSSL is a component that collects together algorithm |
48 | implementations. In order to use an algorithm you must have at least one | |
49 | provider loaded that contains an implementation of it. OpenSSL comes with a | |
50 | number of providers and they may also be obtained from third parties. If you | |
51 | don't load a provider explicitly (either in program code or via config) then the | |
52 | OpenSSL built-in "default" provider will be automatically loaded. | |
72e04bd1 | 53 | |
0666d531 | 54 | =head2 Library contexts |
ff3bb913 | 55 | |
0666d531 MC |
56 | A library context can be thought of as a "scope" within which configuration |
57 | options take effect. When a provider is loaded, it is only loaded within the | |
58 | scope of a given library context. In this way it is possible for different | |
59 | components of a complex application to each use a different library context and | |
60 | have different providers loaded with different configuration settings. | |
61 | ||
62 | If an application does not explicitly create a library context then the | |
63 | "default" library context will be used. | |
64 | ||
65 | Library contexts are represented by the B<OSSL_LIB_CTX> type. Many OpenSSL API | |
66 | functions take a library context as a parameter. Applications can always pass | |
67 | B<NULL> for this parameter to just use the default library context. | |
68 | ||
69 | The default library context is automatically created the first time it is | |
70 | needed. This will automatically load any available configuration file and will | |
71 | initialise OpenSSL for use. Unlike in earlier versions of OpenSSL (prior to | |
72 | 1.1.0) no explicit initialisation steps need to be taken. | |
73 | ||
74 | Similarly when the application exits the default library context is | |
75 | automatically destroyed. No explicit de-initialisation steps need to be taken. | |
76 | ||
77 | See L<OSSL_LIB_CTX(3)> for more information about library contexts. | |
b7140b06 | 78 | See also L</ALGORITHM FETCHING>. |
0666d531 MC |
79 | |
80 | =head2 Multi-threaded applications | |
81 | ||
82 | As long as OpenSSL has been built with support for threads (the default case | |
83 | on most platforms) then most OpenSSL I<functions> are thread-safe in the sense | |
84 | that it is safe to call the same function from multiple threads at the same | |
85 | time. However most OpenSSL I<data structures> are not thread-safe. For example | |
86 | the L<BIO_write(3)> and L<BIO_read(3)> functions are thread safe. However it | |
87 | would not be thread safe to call BIO_write() from one thread while calling | |
88 | BIO_read() in another where both functions are passed the same B<BIO> object | |
89 | since both of them may attempt to make changes to the same B<BIO> object. | |
90 | ||
91 | There are exceptions to these rules. A small number of functions are not thread | |
92 | safe at all. Where this is the case this restriction should be noted in the | |
93 | documentation for the function. Similarly some data structures may be partially | |
94 | or fully thread safe. For example it is safe to use an B<OSSL_LIB_CTX> in | |
95 | multiple threads. | |
96 | ||
97 | See L<openssl-threads(7)> for a more detailed discussion on OpenSSL threading | |
98 | support. | |
99 | ||
100 | =head1 ALGORITHM FETCHING | |
101 | ||
102 | In order to use an algorithm an implementation for it must first be "fetched". | |
103 | Fetching is the process of looking through the available implementations, | |
104 | applying selection criteria (via a property query string), and finally choosing | |
105 | the implementation that will be used. | |
106 | ||
107 | Two types of fetching are supported by OpenSSL - explicit fetching and implicit | |
108 | fetching. | |
109 | ||
110 | =head2 Property query strings | |
111 | ||
112 | When fetching an algorithm it is possible to specify a property query string to | |
113 | guide the selection process. For example a property query string of | |
114 | "provider=default" could be used to force the selection to only consider | |
115 | algorithm implementations in the default provider. | |
116 | ||
117 | Property query strings can be specified explicitly as an argument to a function. | |
118 | It is also possible to specify a default property query string for the whole | |
119 | library context using the L<EVP_set_default_properties(3)> function. Where both | |
120 | default properties and function specific properties are specified then they are | |
121 | combined. Function specific properties will override default properties where | |
122 | there is a conflict. | |
123 | ||
124 | See L<property(7)> for more information about properties. | |
125 | ||
126 | =head2 Explicit fetching | |
127 | ||
128 | Users of the OpenSSL libraries never query a provider directly for an algorithm | |
129 | implementation. Instead, the diverse OpenSSL APIs often have explicit fetching | |
130 | functions that do the work, and they return an appropriate algorithm object back | |
131 | to the user. These functions usually have the name C<APINAME_fetch>, where | |
132 | C<APINAME> is the name of the operation. For example L<EVP_MD_fetch(3)> can | |
133 | be used to explicitly fetch a digest algorithm implementation. The user is | |
134 | responsible for freeing the object returned from the C<APINAME_fetch> function | |
135 | using C<APINAME_free> when it is no longer needed. | |
136 | ||
137 | These fetching functions follow a fairly common pattern, where three | |
138 | arguments are passed: | |
139 | ||
140 | =over 4 | |
141 | ||
142 | =item The library context | |
143 | ||
144 | See L<OSSL_LIB_CTX(3)> for a more detailed description. | |
145 | This may be NULL to signify the default (global) library context, or a | |
146 | context created by the user. Only providers loaded in this library context (see | |
147 | L<OSSL_PROVIDER_load(3)>) will be considered by the fetching function. In case | |
148 | no provider has been loaded in this library context then the default provider | |
149 | will be loaded as a fallback (see L<OSSL_PROVIDER-default(7)>). | |
150 | ||
151 | =item An identifier | |
152 | ||
153 | For all currently implemented fetching functions this is the algorithm name. | |
154 | ||
155 | =item A property query string | |
156 | ||
157 | The property query string used to guide selection of the algorithm | |
158 | implementation. | |
159 | ||
160 | =back | |
161 | ||
162 | The algorithm implementation that is fetched can then be used with other diverse | |
163 | functions that use them. For example the L<EVP_DigestInit_ex(3)> function takes | |
164 | as a parameter an B<EVP_MD> object which may have been returned from an earlier | |
165 | call to L<EVP_MD_fetch(3)>. | |
166 | ||
167 | =head2 Implicit fetch | |
168 | ||
169 | OpenSSL has a number of functions that return an algorithm object with no | |
971dbab4 MC |
170 | associated implementation, such as L<EVP_sha256(3)>, L<EVP_aes_128_cbc(3)>, |
171 | L<EVP_get_cipherbyname(3)> or L<EVP_get_digestbyname(3)>. These are present for | |
0666d531 MC |
172 | compatibility with OpenSSL before version 3.0 where explicit fetching was not |
173 | available. | |
174 | ||
175 | When they are used with functions like L<EVP_DigestInit_ex(3)> or | |
176 | L<EVP_CipherInit_ex(3)>, the actual implementation to be used is | |
177 | fetched implicitly using default search criteria. | |
178 | ||
179 | In some cases implicit fetching can also occur when a NULL algorithm parameter | |
180 | is supplied. In this case an algorithm implementation is implicitly fetched | |
181 | using default search criteria and an algorithm name that is consistent with | |
182 | the context in which it is being used. | |
183 | ||
839ffdd1 RL |
184 | Functions that revolve around B<EVP_PKEY_CTX> and L<EVP_PKEY(3)>, such as |
185 | L<EVP_DigestSignInit(3)> and friends, all fetch the implementations | |
186 | implicitly. Because these functions involve both an operation type (such as | |
187 | L<EVP_SIGNATURE(3)>) and an L<EVP_KEYMGMT(3)> for the L<EVP_PKEY(3)>, they try | |
188 | the following: | |
189 | ||
190 | =over 4 | |
191 | ||
192 | =item 1. | |
193 | ||
194 | Fetch the operation type implementation from any provider given a library | |
195 | context and property string stored in the B<EVP_PKEY_CTX>. | |
196 | ||
197 | If the provider of the operation type implementation is different from the | |
198 | provider of the L<EVP_PKEY(3)>'s L<EVP_KEYMGMT(3)> implementation, try to | |
199 | fetch a L<EVP_KEYMGMT(3)> implementation in the same provider as the operation | |
200 | type implementation and export the L<EVP_PKEY(3)> to it (effectively making a | |
201 | temporary copy of the original key). | |
202 | ||
203 | If anything in this step fails, the next step is used as a fallback. | |
204 | ||
205 | =item 2. | |
206 | ||
207 | As a fallback, try to fetch the operation type implementation from the same | |
208 | provider as the original L<EVP_PKEY(3)>'s L<EVP_KEYMGMT(3)>, still using the | |
e304aa87 | 209 | property string from the B<EVP_PKEY_CTX>. |
839ffdd1 RL |
210 | |
211 | =back | |
212 | ||
0666d531 MC |
213 | =head1 FETCHING EXAMPLES |
214 | ||
215 | The following section provides a series of examples of fetching algorithm | |
216 | implementations. | |
217 | ||
218 | Fetch any available implementation of SHA2-256 in the default context. Note | |
219 | that some algorithms have aliases. So "SHA256" and "SHA2-256" are synonymous: | |
220 | ||
221 | EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL); | |
222 | ... | |
223 | EVP_MD_free(md); | |
224 | ||
225 | Fetch any available implementation of AES-128-CBC in the default context: | |
226 | ||
227 | EVP_CIPHER *cipher = EVP_CIPHER_fetch(NULL, "AES-128-CBC", NULL); | |
228 | ... | |
229 | EVP_CIPHER_free(cipher); | |
230 | ||
231 | Fetch an implementation of SHA2-256 from the default provider in the default | |
232 | context: | |
233 | ||
234 | EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", "provider=default"); | |
235 | ... | |
236 | EVP_MD_free(md); | |
237 | ||
238 | Fetch an implementation of SHA2-256 that is not from the default provider in the | |
239 | default context: | |
240 | ||
241 | EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", "provider!=default"); | |
242 | ... | |
243 | EVP_MD_free(md); | |
244 | ||
245 | Fetch an implementation of SHA2-256 from the default provider in the specified | |
246 | context: | |
247 | ||
248 | EVP_MD *md = EVP_MD_fetch(ctx, "SHA2-256", "provider=default"); | |
249 | ... | |
250 | EVP_MD_free(md); | |
251 | ||
252 | Load the legacy provider into the default context and then fetch an | |
253 | implementation of WHIRLPOOL from it: | |
254 | ||
255 | /* This only needs to be done once - usually at application start up */ | |
256 | OSSL_PROVIDER *legacy = OSSL_PROVIDER_load(NULL, "legacy"); | |
257 | ||
258 | EVP_MD *md = EVP_MD_fetch(NULL, "WHIRLPOOL", "provider=legacy"); | |
259 | ... | |
260 | EVP_MD_free(md); | |
261 | ||
262 | Note that in the above example the property string "provider=legacy" is optional | |
263 | since, assuming no other providers have been loaded, the only implementation of | |
264 | the "whirlpool" algorithm is in the "legacy" provider. Also note that the | |
265 | default provider should be explicitly loaded if it is required in addition to | |
266 | other providers: | |
267 | ||
268 | /* This only needs to be done once - usually at application start up */ | |
269 | OSSL_PROVIDER *legacy = OSSL_PROVIDER_load(NULL, "legacy"); | |
270 | OSSL_PROVIDER *default = OSSL_PROVIDER_load(NULL, "default"); | |
271 | ||
272 | EVP_MD *md_whirlpool = EVP_MD_fetch(NULL, "whirlpool", NULL); | |
273 | EVP_MD *md_sha256 = EVP_MD_fetch(NULL, "SHA2-256", NULL); | |
274 | ... | |
275 | EVP_MD_free(md_whirlpool); | |
276 | EVP_MD_free(md_sha256); | |
277 | ||
278 | =head1 OPENSSL PROVIDERS | |
279 | ||
280 | OpenSSL comes with a set of providers. | |
281 | ||
282 | The algorithms available in each of these providers may vary due to build time | |
283 | configuration options. The L<openssl-list(1)> command can be used to list the | |
284 | currently available algorithms. | |
285 | ||
286 | The names of the algorithms shown from L<openssl-list(1)> can be used as an | |
287 | algorithm identifier to the appropriate fetching function. Also see the provider | |
288 | specific manual pages linked below for further details about using the | |
289 | algorithms available in each of the providers. | |
290 | ||
ce289294 | 291 | As well as the OpenSSL providers third parties can also implement providers. |
0666d531 MC |
292 | For information on writing a provider see L<provider(7)>. |
293 | ||
294 | =head2 Default provider | |
295 | ||
296 | The default provider is built in as part of the F<libcrypto> library and | |
297 | contains all of the most commonly used algorithm implementations. Should it be | |
298 | needed (if other providers are loaded and offer implementations of the same | |
299 | algorithms), the property query string "provider=default" can be used as a | |
300 | search criterion for these implementations. The default provider includes all | |
301 | of the functionality in the base provider below. | |
302 | ||
303 | If you don't load any providers at all then the "default" provider will be | |
304 | automatically loaded. If you explicitly load any provider then the "default" | |
305 | provider would also need to be explicitly loaded if it is required. | |
306 | ||
307 | See L<OSSL_PROVIDER-default(7)>. | |
308 | ||
309 | =head2 Base provider | |
310 | ||
311 | The base provider is built in as part of the F<libcrypto> library and contains | |
312 | algorithm implementations for encoding and decoding for OpenSSL keys. | |
313 | Should it be needed (if other providers are loaded and offer | |
314 | implementations of the same algorithms), the property query string | |
315 | "provider=base" can be used as a search criterion for these implementations. | |
316 | Some encoding and decoding algorithm implementations are not FIPS algorithm | |
317 | implementations in themselves but support algorithms from the FIPS provider and | |
318 | are allowed for use in "FIPS mode". The property query string "fips=yes" can be | |
319 | used to select such algorithms. | |
320 | ||
321 | See L<OSSL_PROVIDER-base(7)>. | |
322 | ||
323 | =head2 FIPS provider | |
324 | ||
325 | The FIPS provider is a dynamically loadable module, and must therefore | |
326 | be loaded explicitly, either in code or through OpenSSL configuration | |
327 | (see L<config(5)>). It contains algorithm implementations that have been | |
328 | validated according to the FIPS 140-2 standard. Should it be needed (if other | |
329 | providers are loaded and offer implementations of the same algorithms), the | |
330 | property query string "provider=fips" can be used as a search criterion for | |
331 | these implementations. All approved algorithm implementations in the FIPS | |
332 | provider can also be selected with the property "fips=yes". The FIPS provider | |
333 | may also contain non-approved algorithm implementations and these can be | |
334 | selected with the property "fips=no". | |
335 | ||
b7140b06 | 336 | See L<OSSL_PROVIDER-FIPS(7)> and L<fips_module(7)>. |
0666d531 MC |
337 | |
338 | =head2 Legacy provider | |
339 | ||
340 | The legacy provider is a dynamically loadable module, and must therefore | |
341 | be loaded explicitly, either in code or through OpenSSL configuration | |
342 | (see L<config(5)>). It contains algorithm implementations that are considered | |
343 | insecure, or are no longer in common use such as MD2 or RC4. Should it be needed | |
344 | (if other providers are loaded and offer implementations of the same algorithms), | |
345 | the property "provider=legacy" can be used as a search criterion for these | |
346 | implementations. | |
347 | ||
348 | See L<OSSL_PROVIDER-legacy(7)>. | |
349 | ||
350 | =head2 Null provider | |
351 | ||
352 | The null provider is built in as part of the F<libcrypto> library. It contains | |
353 | no algorithms in it at all. When fetching algorithms the default provider will | |
354 | be automatically loaded if no other provider has been explicitly loaded. To | |
355 | prevent that from happening you can explicitly load the null provider. | |
356 | ||
357 | See L<OSSL_PROVIDER-null(7)>. | |
358 | ||
359 | =head1 USING ALGORITHMS IN APPLICATIONS | |
360 | ||
361 | Cryptographic algorithms are made available to applications through use of the | |
362 | "EVP" APIs. Each of the various operations such as encryption, digesting, | |
363 | message authentication codes, etc., have a set of EVP function calls that can | |
364 | be invoked to use them. See the L<evp(7)> page for further details. | |
365 | ||
366 | Most of these follow a common pattern. A "context" object is first created. For | |
367 | example for a digest operation you would use an B<EVP_MD_CTX>, and for an | |
368 | encryption/decryption operation you would use an B<EVP_CIPHER_CTX>. The | |
369 | operation is then initialised ready for use via an "init" function - optionally | |
370 | passing in a set of parameters (using the B<OSSL_PARAM> type) to configure how | |
371 | the operation should behave. Next data is fed into the operation in a series of | |
372 | "update" calls. The operation is finalised using a "final" call which will | |
373 | typically provide some kind of output. Finally the context is cleaned up and | |
374 | freed. | |
375 | ||
376 | The following shows a complete example for doing this process for digesting | |
377 | data using SHA256. The process is similar for other operations such as | |
378 | encryption/decryption, signatures, message authentication codes, etc. | |
379 | ||
380 | #include <stdio.h> | |
381 | #include <openssl/evp.h> | |
382 | #include <openssl/bio.h> | |
4a4f4460 | 383 | #include <openssl/err.h> |
0666d531 MC |
384 | |
385 | int main(void) | |
386 | { | |
387 | EVP_MD_CTX *ctx = NULL; | |
388 | EVP_MD *sha256 = NULL; | |
389 | const unsigned char msg[] = { | |
390 | 0x00, 0x01, 0x02, 0x03 | |
391 | }; | |
392 | unsigned int len = 0; | |
393 | unsigned char *outdigest = NULL; | |
4a4f4460 | 394 | int ret = 1; |
0666d531 MC |
395 | |
396 | /* Create a context for the digest operation */ | |
397 | ctx = EVP_MD_CTX_new(); | |
398 | if (ctx == NULL) | |
399 | goto err; | |
400 | ||
401 | /* | |
402 | * Fetch the SHA256 algorithm implementation for doing the digest. We're | |
403 | * using the "default" library context here (first NULL parameter), and | |
404 | * we're not supplying any particular search criteria for our SHA256 | |
405 | * implementation (second NULL parameter). Any SHA256 implementation will | |
406 | * do. | |
407 | */ | |
408 | sha256 = EVP_MD_fetch(NULL, "SHA256", NULL); | |
409 | if (sha256 == NULL) | |
410 | goto err; | |
411 | ||
412 | /* Initialise the digest operation */ | |
413 | if (!EVP_DigestInit_ex(ctx, sha256, NULL)) | |
414 | goto err; | |
415 | ||
416 | /* | |
417 | * Pass the message to be digested. This can be passed in over multiple | |
418 | * EVP_DigestUpdate calls if necessary | |
419 | */ | |
420 | if (!EVP_DigestUpdate(ctx, msg, sizeof(msg))) | |
421 | goto err; | |
422 | ||
423 | /* Allocate the output buffer */ | |
ed576acd | 424 | outdigest = OPENSSL_malloc(EVP_MD_get_size(sha256)); |
0666d531 MC |
425 | if (outdigest == NULL) |
426 | goto err; | |
427 | ||
428 | /* Now calculate the digest itself */ | |
429 | if (!EVP_DigestFinal_ex(ctx, outdigest, &len)) | |
430 | goto err; | |
431 | ||
432 | /* Print out the digest result */ | |
433 | BIO_dump_fp(stdout, outdigest, len); | |
434 | ||
4a4f4460 | 435 | ret = 0; |
436 | ||
0666d531 MC |
437 | err: |
438 | /* Clean up all the resources we allocated */ | |
439 | OPENSSL_free(outdigest); | |
440 | EVP_MD_free(sha256); | |
441 | EVP_MD_CTX_free(ctx); | |
4a4f4460 | 442 | if (ret != 0) |
443 | ERR_print_errors_fp(stderr); | |
444 | return ret; | |
0666d531 MC |
445 | } |
446 | ||
447 | =head1 CONFIGURATION | |
448 | ||
449 | By default OpenSSL will load a configuration file when it is first used. This | |
450 | will set up various configuration settings within the default library context. | |
451 | Applications that create their own library contexts may optionally configure | |
452 | them with a config file using the L<OSSL_LIB_CTX_load_config(3)> function. | |
453 | ||
454 | The configuration file can be used to automatically load providers and set up | |
455 | default property query strings. | |
456 | ||
457 | For information on the OpenSSL configuration file format see L<config(5)>. | |
458 | ||
459 | =head1 ENCODING AND DECODING KEYS | |
460 | ||
461 | Many algorithms require the use of a key. Keys can be generated dynamically | |
f9253152 | 462 | using the EVP APIs (for example see L<EVP_PKEY_Q_keygen(3)>). However it is often |
0666d531 MC |
463 | necessary to save or load keys (or their associated parameters) to or from some |
464 | external format such as PEM or DER (see L<openssl-glossary(7)>). OpenSSL uses | |
465 | encoders and decoders to perform this task. | |
466 | ||
467 | Encoders and decoders are just algorithm implementations in the same way as | |
468 | any other algorithm implementation in OpenSSL. They are implemented by | |
469 | providers. The OpenSSL encoders and decoders are available in the default | |
470 | provider. They are also duplicated in the base provider. | |
471 | ||
472 | For information about encoders see L<OSSL_ENCODER_CTX_new_for_pkey(3)>. For | |
473 | information about decoders see L<OSSL_DECODER_CTX_new_for_pkey(3)>. | |
474 | ||
475 | =head1 LIBRARY CONVENTIONS | |
476 | ||
477 | Many OpenSSL functions that "get" or "set" a value follow a naming convention | |
478 | using the numbers B<0> and B<1>, i.e. "get0", "get1", "set0" and "set1". This | |
479 | can also apply to some functions that "add" a value to an existing set, i.e. | |
480 | "add0" and "add1". | |
481 | ||
482 | For example the functions: | |
483 | ||
484 | int X509_CRL_add0_revoked(X509_CRL *crl, X509_REVOKED *rev); | |
485 | int X509_add1_trust_object(X509 *x, const ASN1_OBJECT *obj); | |
486 | ||
487 | In the B<0> version the ownership of the object is passed to (for an add or set) | |
488 | or retained by (for a get) the parent object. For example after calling the | |
489 | X509_CRL_add0_revoked() function above, ownership of the I<rev> object is passed | |
490 | to the I<crl> object. Therefore, after calling this function I<rev> should not | |
491 | be freed directly. It will be freed implicitly when I<crl> is freed. | |
492 | ||
493 | In the B<1> version the ownership of the object is not passed to or retained by | |
494 | the parent object. Instead a copy or "up ref" of the object is performed. So | |
495 | after calling the X509_add1_trust_object() function above the application will | |
496 | still be responsible for freeing the I<obj> value where appropriate. | |
ff3bb913 | 497 | |
2186cd8e UM |
498 | =head1 SEE ALSO |
499 | ||
0666d531 MC |
500 | L<openssl(1)>, L<ssl(7)>, L<evp(7)>, L<OSSL_LIB_CTX(3)>, L<openssl-threads(7)>, |
501 | L<property(7)>, L<OSSL_PROVIDER-default(7)>, L<OSSL_PROVIDER-base(7)>, | |
502 | L<OSSL_PROVIDER-FIPS(7)>, L<OSSL_PROVIDER-legacy(7)>, L<OSSL_PROVIDER-null(7)>, | |
503 | L<openssl-glossary(7)>, L<provider(7)> | |
2186cd8e | 504 | |
e2f92610 RS |
505 | =head1 COPYRIGHT |
506 | ||
fecb3aae | 507 | Copyright 2000-2022 The OpenSSL Project Authors. All Rights Reserved. |
e2f92610 | 508 | |
3187791e | 509 | Licensed under the Apache License 2.0 (the "License"). You may not use |
e2f92610 RS |
510 | this file except in compliance with the License. You can obtain a copy |
511 | in the file LICENSE in the source distribution or at | |
512 | L<https://www.openssl.org/source/license.html>. | |
513 | ||
514 | =cut |