Various doc fixes from GH pull requests
Thanks folks: 348 Benjamin Kaduk 317 Christian Brueffer 254 Erik Tews 253 Erik Tews 219 Carl Mehner 155 (ghost) 95 mancha 51 DominikNeubauer Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
This commit is contained in:
parent
898ea7b855
commit
740ceb5b0c
2
CHANGES
2
CHANGES
@ -162,7 +162,7 @@
|
|||||||
[mancha <mancha1@zoho.com>]
|
[mancha <mancha1@zoho.com>]
|
||||||
|
|
||||||
*) Fix eckey_priv_encode so it immediately returns an error upon a failure
|
*) Fix eckey_priv_encode so it immediately returns an error upon a failure
|
||||||
in i2d_ECPrivateKey.
|
in i2d_ECPrivateKey. Thanks to Ted Unangst for feedback on this issue.
|
||||||
[mancha <mancha1@zoho.com>]
|
[mancha <mancha1@zoho.com>]
|
||||||
|
|
||||||
*) Fix some double frees. These are not thought to be exploitable.
|
*) Fix some double frees. These are not thought to be exploitable.
|
||||||
|
2
README
2
README
@ -1,7 +1,7 @@
|
|||||||
|
|
||||||
OpenSSL 1.1.0-dev
|
OpenSSL 1.1.0-dev
|
||||||
|
|
||||||
Copyright (c) 1998-2011 The OpenSSL Project
|
Copyright (c) 1998-2015 The OpenSSL Project
|
||||||
Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson
|
Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson
|
||||||
All rights reserved.
|
All rights reserved.
|
||||||
|
|
||||||
|
@ -588,7 +588,7 @@ OPTIONS s_client_options[] = {
|
|||||||
"SRP username into second ClientHello message"},
|
"SRP username into second ClientHello message"},
|
||||||
{"srp_moregroups", OPT_SRP_MOREGROUPS, '-',
|
{"srp_moregroups", OPT_SRP_MOREGROUPS, '-',
|
||||||
"Tolerate other than the known g N values."},
|
"Tolerate other than the known g N values."},
|
||||||
{"srp_strength", OPT_SRP_STRENGTH, 'p', "Minimal mength in bits for N"},
|
{"srp_strength", OPT_SRP_STRENGTH, 'p', "Minimal length in bits for N"},
|
||||||
#endif
|
#endif
|
||||||
#ifndef OPENSSL_NO_NEXTPROTONEG
|
#ifndef OPENSSL_NO_NEXTPROTONEG
|
||||||
{"nextprotoneg", OPT_NEXTPROTONEG, 's',
|
{"nextprotoneg", OPT_NEXTPROTONEG, 's',
|
||||||
|
@ -40,9 +40,8 @@ consider insecure or to be insecure pretty soon.
|
|||||||
|
|
||||||
3. To generate a DSA key
|
3. To generate a DSA key
|
||||||
|
|
||||||
A DSA key can be used for signing only. This is important to keep
|
A DSA key can be used for signing only. It is important to
|
||||||
in mind to know what kind of purposes a certificate request with a
|
know what a certificate request with a DSA key can really be used for.
|
||||||
DSA key can really be used for.
|
|
||||||
|
|
||||||
Generating a key for the DSA algorithm is a two-step process. First,
|
Generating a key for the DSA algorithm is a two-step process. First,
|
||||||
you have to generate parameters from which to generate the key:
|
you have to generate parameters from which to generate the key:
|
||||||
|
@ -216,7 +216,7 @@ key is encrypted using triple DES and the certificate using 40 bit RC2.
|
|||||||
|
|
||||||
these options allow the algorithm used to encrypt the private key and
|
these options allow the algorithm used to encrypt the private key and
|
||||||
certificates to be selected. Any PKCS#5 v1.5 or PKCS#12 PBE algorithm name
|
certificates to be selected. Any PKCS#5 v1.5 or PKCS#12 PBE algorithm name
|
||||||
can be used (see B<NOTES> section for more information). If a a cipher name
|
can be used (see B<NOTES> section for more information). If a cipher name
|
||||||
(as output by the B<list-cipher-algorithms> command is specified then it
|
(as output by the B<list-cipher-algorithms> command is specified then it
|
||||||
is used with PKCS#5 v2.0. For interoperability reasons it is advisable to only
|
is used with PKCS#5 v2.0. For interoperability reasons it is advisable to only
|
||||||
use PKCS#12 algorithms.
|
use PKCS#12 algorithms.
|
||||||
|
@ -30,7 +30,6 @@ B<openssl> B<req>
|
|||||||
[B<-keygen_engine id>]
|
[B<-keygen_engine id>]
|
||||||
[B<-[digest]>]
|
[B<-[digest]>]
|
||||||
[B<-config filename>]
|
[B<-config filename>]
|
||||||
[B<-subj arg>]
|
|
||||||
[B<-multivalue-rdn>]
|
[B<-multivalue-rdn>]
|
||||||
[B<-x509>]
|
[B<-x509>]
|
||||||
[B<-days n>]
|
[B<-days n>]
|
||||||
@ -506,16 +505,16 @@ Examine and verify certificate request:
|
|||||||
|
|
||||||
Create a private key and then generate a certificate request from it:
|
Create a private key and then generate a certificate request from it:
|
||||||
|
|
||||||
openssl genrsa -out key.pem 1024
|
openssl genrsa -out key.pem 2048
|
||||||
openssl req -new -key key.pem -out req.pem
|
openssl req -new -key key.pem -out req.pem
|
||||||
|
|
||||||
The same but just using req:
|
The same but just using req:
|
||||||
|
|
||||||
openssl req -newkey rsa:1024 -keyout key.pem -out req.pem
|
openssl req -newkey rsa:2048 -keyout key.pem -out req.pem
|
||||||
|
|
||||||
Generate a self signed root certificate:
|
Generate a self signed root certificate:
|
||||||
|
|
||||||
openssl req -x509 -newkey rsa:1024 -keyout key.pem -out req.pem
|
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out req.pem
|
||||||
|
|
||||||
Example of a file pointed to by the B<oid_file> option:
|
Example of a file pointed to by the B<oid_file> option:
|
||||||
|
|
||||||
@ -531,7 +530,7 @@ expansion:
|
|||||||
Sample configuration file prompting for field values:
|
Sample configuration file prompting for field values:
|
||||||
|
|
||||||
[ req ]
|
[ req ]
|
||||||
default_bits = 1024
|
default_bits = 2048
|
||||||
default_keyfile = privkey.pem
|
default_keyfile = privkey.pem
|
||||||
distinguished_name = req_distinguished_name
|
distinguished_name = req_distinguished_name
|
||||||
attributes = req_attributes
|
attributes = req_attributes
|
||||||
@ -572,7 +571,7 @@ Sample configuration containing all field values:
|
|||||||
RANDFILE = $ENV::HOME/.rnd
|
RANDFILE = $ENV::HOME/.rnd
|
||||||
|
|
||||||
[ req ]
|
[ req ]
|
||||||
default_bits = 1024
|
default_bits = 2048
|
||||||
default_keyfile = keyfile.pem
|
default_keyfile = keyfile.pem
|
||||||
distinguished_name = req_distinguished_name
|
distinguished_name = req_distinguished_name
|
||||||
attributes = req_attributes
|
attributes = req_attributes
|
||||||
|
@ -114,7 +114,7 @@ EVP_CIPHER_CTX_init() initializes cipher contex B<ctx>.
|
|||||||
EVP_EncryptInit_ex() sets up cipher context B<ctx> for encryption
|
EVP_EncryptInit_ex() sets up cipher context B<ctx> for encryption
|
||||||
with cipher B<type> from ENGINE B<impl>. B<ctx> must be initialized
|
with cipher B<type> from ENGINE B<impl>. B<ctx> must be initialized
|
||||||
before calling this function. B<type> is normally supplied
|
before calling this function. B<type> is normally supplied
|
||||||
by a function such as EVP_des_cbc(). If B<impl> is NULL then the
|
by a function such as EVP_aes_256_cbc(). If B<impl> is NULL then the
|
||||||
default implementation is used. B<key> is the symmetric key to use
|
default implementation is used. B<key> is the symmetric key to use
|
||||||
and B<iv> is the IV to use (if necessary), the actual number of bytes
|
and B<iv> is the IV to use (if necessary), the actual number of bytes
|
||||||
used for the key and IV depends on the cipher. It is possible to set
|
used for the key and IV depends on the cipher. It is possible to set
|
||||||
|
@ -25,7 +25,7 @@ encrypted using this key.
|
|||||||
|
|
||||||
EVP_SealInit() initializes a cipher context B<ctx> for encryption
|
EVP_SealInit() initializes a cipher context B<ctx> for encryption
|
||||||
with cipher B<type> using a random secret key and IV. B<type> is normally
|
with cipher B<type> using a random secret key and IV. B<type> is normally
|
||||||
supplied by a function such as EVP_des_cbc(). The secret key is encrypted
|
supplied by a function such as EVP_aes_256_cbc(). The secret key is encrypted
|
||||||
using one or more public keys, this allows the same encrypted data to be
|
using one or more public keys, this allows the same encrypted data to be
|
||||||
decrypted using any of the corresponding private keys. B<ek> is an array of
|
decrypted using any of the corresponding private keys. B<ek> is an array of
|
||||||
buffers where the public key encrypted secret key will be written, each buffer
|
buffers where the public key encrypted secret key will be written, each buffer
|
||||||
|
@ -192,7 +192,7 @@ to use the pointer value at all, as this kind of reference is a guarantee
|
|||||||
that the structure can not be deallocated until the reference is released.
|
that the structure can not be deallocated until the reference is released.
|
||||||
|
|
||||||
However, a structural reference provides no guarantee that the ENGINE is
|
However, a structural reference provides no guarantee that the ENGINE is
|
||||||
initiliased and able to use any of its cryptographic
|
initialised and able to use any of its cryptographic
|
||||||
implementations. Indeed it's quite possible that most ENGINEs will not
|
implementations. Indeed it's quite possible that most ENGINEs will not
|
||||||
initialise at all in typical environments, as ENGINEs are typically used to
|
initialise at all in typical environments, as ENGINEs are typically used to
|
||||||
support specialised hardware. To use an ENGINE's functionality, you need a
|
support specialised hardware. To use an ENGINE's functionality, you need a
|
||||||
@ -201,8 +201,8 @@ specialised form of structural reference, because each functional reference
|
|||||||
implicitly contains a structural reference as well - however to avoid
|
implicitly contains a structural reference as well - however to avoid
|
||||||
difficult-to-find programming bugs, it is recommended to treat the two
|
difficult-to-find programming bugs, it is recommended to treat the two
|
||||||
kinds of reference independently. If you have a functional reference to an
|
kinds of reference independently. If you have a functional reference to an
|
||||||
ENGINE, you have a guarantee that the ENGINE has been initialised ready to
|
ENGINE, you have a guarantee that the ENGINE has been initialised and
|
||||||
perform cryptographic operations and will remain uninitialised
|
is ready to perform cryptographic operations, and will remain initialised
|
||||||
until after you have released your reference.
|
until after you have released your reference.
|
||||||
|
|
||||||
I<Structural references>
|
I<Structural references>
|
||||||
@ -370,7 +370,7 @@ I<Using a specific ENGINE implementation>
|
|||||||
Here we'll assume an application has been configured by its user or admin
|
Here we'll assume an application has been configured by its user or admin
|
||||||
to want to use the "ACME" ENGINE if it is available in the version of
|
to want to use the "ACME" ENGINE if it is available in the version of
|
||||||
OpenSSL the application was compiled with. If it is available, it should be
|
OpenSSL the application was compiled with. If it is available, it should be
|
||||||
used by default for all RSA, DSA, and symmetric cipher operation, otherwise
|
used by default for all RSA, DSA, and symmetric cipher operations, otherwise
|
||||||
OpenSSL should use its builtin software as per usual. The following code
|
OpenSSL should use its builtin software as per usual. The following code
|
||||||
illustrates how to approach this;
|
illustrates how to approach this;
|
||||||
|
|
||||||
@ -401,7 +401,7 @@ I<Automatically using builtin ENGINE implementations>
|
|||||||
|
|
||||||
Here we'll assume we want to load and register all ENGINE implementations
|
Here we'll assume we want to load and register all ENGINE implementations
|
||||||
bundled with OpenSSL, such that for any cryptographic algorithm required by
|
bundled with OpenSSL, such that for any cryptographic algorithm required by
|
||||||
OpenSSL - if there is an ENGINE that implements it and can be initialise,
|
OpenSSL - if there is an ENGINE that implements it and can be initialised,
|
||||||
it should be used. The following code illustrates how this can work;
|
it should be used. The following code illustrates how this can work;
|
||||||
|
|
||||||
/* Load all bundled ENGINEs into memory and make them visible */
|
/* Load all bundled ENGINEs into memory and make them visible */
|
||||||
|
Loading…
x
Reference in New Issue
Block a user