Hakase/openssl-custom
1
0 Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update OpenSSL-1.1.1-pre8-dev

Browse Source
This commit is contained in:
Hakase
2018-06-14 23:58:15 +09:00
parent 7b0e27998c
commit 9a4ebe1ae3
51 changed files with 1109 additions and 288 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/man1/s_client.pod
+50 -1
View File
@@ -23,9 +23,19 @@ B<openssl> B<s_client>
[B<-certform DER|PEM>]
[B<-key filename>]
[B<-keyform DER|PEM>]
[B<-cert_chain filename>]
[B<-build_chain>]
[B<-xkey>]
[B<-xcert>]
[B<-xchain>]
[B<-xchain_build>]
[B<-xcertform PEM|DER>]
[B<-xkeyform PEM|DER>]
[B<-pass arg>]
[B<-CApath directory>]
[B<-CAfile filename>]
[B<-chainCApath directory>]
[B<-chainCAfile filename>]
[B<-no-CAfile>]
[B<-no-CApath>]
[B<-requestCAfile filename>]
@@ -60,6 +70,7 @@ B<openssl> B<s_client>
[B<-verify_hostname hostname>]
[B<-verify_ip ip>]
[B<-verify_name name>]
[B<-build_chain>]
[B<-x509_strict>]
[B<-reconnect>]
[B<-showcerts>]
@@ -212,6 +223,34 @@ be used.
The private format to use: DER or PEM. PEM is the default.
=item B<-cert_chain>
A file containing trusted certificates to use when attempting to build the
client/server certificate chain related to the certificate specified via the
B<-cert> option.
=item B<-build_chain>
Specify whether the application should build the certificate chain to be
provided to the server.
=item B<-xkey infile>, B<-xcert infile>, B<-xchain>
Specify an extra certificate, private key and certificate chain. These behave
in the same manner as the B<-cert>, B<-key> and B<-cert_chain> options. When
specified, the callback returning the first valid chain will be in use by the
client.
=item B<-xchain_build>
Specify whether the application should build the certificate chain to be
provided to the server for the extra certificates provided via B<-xkey infile>,
B<-xcert infile>, B<-xchain> options.
=item B<-xcertform PEM|DER>, B<-xkeyform PEM|DER>
Extra certificate and private key format respectively.
=item B<-pass arg>
the private key password source. For more information about the format of B<arg>
@@ -240,7 +279,7 @@ set multiple options. See the L<x509(1)> manual page for details.
=item B<-CApath directory>
The directory to use for server certificate verification. This directory
must be in "hash format", see B<verify> for more information. These are
must be in "hash format", see L<verify(1)> for more information. These are
also used when building the client certificate chain.
=item B<-CAfile file>
@@ -248,6 +287,16 @@ also used when building the client certificate chain.
A file containing trusted certificates to use during server authentication
and to use when attempting to build the client certificate chain.
=item B<-chainCApath directory>
The directory to use for building the chain provided to the server. This
directory must be in "hash format", see L<verify(1)> for more information.
=item B<-chainCAfile file>
A file containing trusted certificates to use when attempting to build the
client certificate chain.
=item B<-no-CAfile>
Do not load the trusted CA certificates from the default file location
doc/man1/s_server.pod
+45 -1
View File
@@ -246,6 +246,17 @@ certificate and some require a certificate with a certain public key type:
for example the DSS cipher suites require a certificate containing a DSS
(DSA) key. If not specified then the filename "server.pem" will be used.
=item B<-cert_chain>
A file containing trusted certificates to use when attempting to build the
client/server certificate chain related to the certificate specified via the
B<-cert> option.
=item B<-build_chain>
Specify whether the application should build the certificate chain to be
provided to the client.
=item B<-nameopt val>
Option which determines how the subject or issuer names are displayed. The
@@ -295,10 +306,33 @@ and some a DSS (DSA) key. By using RSA and DSS certificates and keys
a server can support clients which only support RSA or DSS cipher suites
by using an appropriate certificate.
=item B<-dcert_chain>
A file containing trusted certificates to use when attempting to build the
server certificate chain when a certificate specified via the B<-dcert> option
is in use.
=item B<-dcertform PEM|DER>, B<-dkeyform PEM|DER>, B<-dpass val>
Additional certificate and private key format and passphrase respectively.
=item B<-xkey infile>, B<-xcert infile>, B<-xchain>
Specify an extra certificate, private key and certificate chain. These behave
in the same manner as the B<-cert>, B<-key> and B<-cert_chain> options. When
specified, the callback returning the first valid chain will be in use by
the server.
=item B<-xchain_build>
Specify whether the application should build the certificate chain to be
provided to the client for the extra certificates provided via B<-xkey infile>,
B<-xcert infile>, B<-xchain> options.
=item B<-xcertform PEM|DER>, B<-xkeyform PEM|DER>
Extra certificate and private key format respectively.
=item B<-nbio_test>
Tests non blocking I/O.
@@ -333,9 +367,19 @@ a certificate is requested.
=item B<-CApath dir>
The directory to use for client certificate verification. This directory
must be in "hash format", see B<verify> for more information. These are
must be in "hash format", see L<verify(1)> for more information. These are
also used when building the server certificate chain.
=item B<-chainCApath dir>
The directory to use for building the chain provided to the client. This
directory must be in "hash format", see L<verify(1)> for more information.
=item B<-chainCAfile file>
A file containing trusted certificates to use when attempting to build the
server certificate chain.
=item B<-no-CAfile>
Do not load the trusted CA certificates from the default file location.
doc/man3/BUF_MEM_new.pod
-2
View File
@@ -6,8 +6,6 @@ BUF_MEM_new, BUF_MEM_new_ex, BUF_MEM_free, BUF_MEM_grow,
BUF_MEM_grow_clean, BUF_reverse
- simple character array structure
standard C library equivalents
=head1 SYNOPSIS
#include <openssl/buffer.h>
doc/man3/DSA_sign.pod
+6 -7
View File
@@ -23,13 +23,12 @@ digest B<dgst> using the private key B<dsa> and places its ASN.1 DER
encoding at B<sigret>. The length of the signature is places in
*B<siglen>. B<sigret> must point to DSA_size(B<dsa>) bytes of memory.
DSA_sign_setup() may be used to precompute part of the signing
operation in case signature generation is time-critical. It expects
B<dsa> to contain DSA parameters. It places the precomputed values
in newly allocated B<BIGNUM>s at *B<kinvp> and *B<rp>, after freeing
the old ones unless *B<kinvp> and *B<rp> are NULL. These values may
be passed to DSA_sign() in B<dsa-E<gt>kinv> and B<dsa-E<gt>r>.
B<ctx> is a pre-allocated B<BN_CTX> or NULL.
DSA_sign_setup() is defined only for backward binary compatibility and
should not be used.
Since OpenSSL 1.1.0 the DSA type is opaque and the output of
DSA_sign_setup() cannot be used anyway: calling this function will only
cause overhead, and does not affect the actual signature
(pre-)computation.
DSA_verify() verifies that the signature B<sigbuf> of size B<siglen>
matches a given message digest B<dgst> of size B<len>.
doc/man3/EVP_PKEY_ASN1_METHOD.pod
+15 -2
View File
@@ -21,6 +21,8 @@ EVP_PKEY_asn1_set_param_check,
EVP_PKEY_asn1_set_security_bits,
EVP_PKEY_asn1_set_set_priv_key,
EVP_PKEY_asn1_set_set_pub_key,
EVP_PKEY_asn1_set_get_priv_key,
EVP_PKEY_asn1_set_get_pub_key,
EVP_PKEY_get0_asn1
- manipulating and registering EVP_PKEY_ASN1_METHOD structure
@@ -125,6 +127,16 @@ EVP_PKEY_get0_asn1
const unsigned char *pub,
size_t len));
void EVP_PKEY_asn1_set_get_priv_key(EVP_PKEY_ASN1_METHOD *ameth,
int (*get_priv_key) (const EVP_PKEY *pk,
unsigned char *priv,
size_t *len));
void EVP_PKEY_asn1_set_get_pub_key(EVP_PKEY_ASN1_METHOD *ameth,
int (*get_pub_key) (const EVP_PKEY *pk,
unsigned char *pub,
size_t *len));
const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey);
=head1 DESCRIPTION
@@ -390,8 +402,9 @@ EVP_PKEY_asn1_set_param(), EVP_PKEY_asn1_set_free(),
EVP_PKEY_asn1_set_ctrl(), EVP_PKEY_asn1_set_item(),
EVP_PKEY_asn1_set_siginf(), EVP_PKEY_asn1_set_check(),
EVP_PKEY_asn1_set_public_check(), EVP_PKEY_asn1_set_param_check(),
EVP_PKEY_asn1_set_security_bits(), EVP_PKEY_asn1_set_set_priv_key() and
EVP_PKEY_asn1_set_set_pub_key() set the diverse methods of the given
EVP_PKEY_asn1_set_security_bits(), EVP_PKEY_asn1_set_set_priv_key(),
EVP_PKEY_asn1_set_set_pub_key(), EVP_PKEY_asn1_set_get_priv_key() and
EVP_PKEY_asn1_set_get_pub_key() set the diverse methods of the given
B<EVP_PKEY_ASN1_METHOD> object.
EVP_PKEY_get0_asn1() finds the B<EVP_PKEY_ASN1_METHOD> associated
doc/man3/EVP_PKEY_new.pod
+39 -10
View File
@@ -8,8 +8,10 @@ EVP_PKEY_free,
EVP_PKEY_new_raw_private_key,
EVP_PKEY_new_raw_public_key,
EVP_PKEY_new_CMAC_key,
EVP_PKEY_new_mac_key
- public/private key allocation functions
EVP_PKEY_new_mac_key,
EVP_PKEY_get_raw_private_key,
EVP_PKEY_get_raw_public_key
- public/private key allocation and raw key handling functions
=head1 SYNOPSIS
@@ -28,10 +30,16 @@ EVP_PKEY_new_mac_key
EVP_PKEY *EVP_PKEY_new_mac_key(int type, ENGINE *e, const unsigned char *key,
int keylen);
int EVP_PKEY_get_raw_private_key(const EVP_PKEY *pkey, unsigned char *priv,
size_t *len);
int EVP_PKEY_get_raw_public_key(const EVP_PKEY *pkey, unsigned char *pub,
size_t *len);
=head1 DESCRIPTION
The EVP_PKEY_new() function allocates an empty B<EVP_PKEY> structure which is
used by OpenSSL to store private keys. The reference count is set to B<1>.
used by OpenSSL to store public and private keys. The reference count is set to
B<1>.
EVP_PKEY_up_ref() increments the reference count of B<key>.
@@ -63,14 +71,32 @@ creation of a CMAC in the B<cipher> argument.
EVP_PKEY_new_mac_key() works in the same way as EVP_PKEY_new_raw_private_key().
New applications should use EVP_PKEY_new_raw_private_key() instead.
EVP_PKEY_get_raw_private_key() fills the buffer provided by B<priv> with raw
private key data. The number of bytes written is populated in B<*len>. If the
buffer B<priv> is NULL then B<*len> is populated with the number of bytes
required to hold the key. The calling application is responsible for ensuring
that the buffer is large enough to receive the private key data. This function
only works for algorithms that support raw private keys. Currently this is:
B<EVP_PKEY_HMAC>, B<EVP_PKEY_POLY1305>, B<EVP_PKEY_SIPHASH>, B<EVP_PKEY_X25519>,
B<EVP_PKEY_ED25519>, B<EVP_PKEY_X448> or B<EVP_PKEY_ED448>.
EVP_PKEY_get_raw_public_key() fills the buffer provided by B<pub> with raw
public key data. The number of bytes written is populated in B<*len>. If the
buffer B<pub> is NULL then B<*len> is populated with the number of bytes
required to hold the key. The calling application is responsible for ensuring
that the buffer is large enough to receive the public key data. This function
only works for algorithms that support raw public keys. Currently this is:
B<EVP_PKEY_X25519>, B<EVP_PKEY_ED25519>, B<EVP_PKEY_X448> or B<EVP_PKEY_ED448>.
=head1 NOTES
The B<EVP_PKEY> structure is used by various OpenSSL functions which require a
general private key without reference to any particular algorithm.
The structure returned by EVP_PKEY_new() is empty. To add a private key to this
empty structure the functions described in L<EVP_PKEY_set1_RSA(3)> should be
used.
The structure returned by EVP_PKEY_new() is empty. To add a private or public
key to this empty structure use the appropriate functions described in
L<EVP_PKEY_set1_RSA(3)>, L<EVP_PKEY_set1_DSA>, L<EVP_PKEY_set1_DH> or
L<EVP_PKEY_set1_EC_KEY>.
=head1 RETURN VALUES
@@ -78,19 +104,22 @@ EVP_PKEY_new(), EVP_PKEY_new_raw_private_key(), EVP_PKEY_new_raw_public_key(),
EVP_PKEY_new_CMAC_key() and EVP_PKEY_new_mac_key() return either the newly
allocated B<EVP_PKEY> structure or B<NULL> if an error occurred.
EVP_PKEY_up_ref() returns 1 for success and 0 for failure.
EVP_PKEY_up_ref(), EVP_PKEY_get_raw_private_key() and
EVP_PKEY_get_raw_public_key() return 1 for success and 0 for failure.
=head1 SEE ALSO
L<EVP_PKEY_set1_RSA(3)>
L<EVP_PKEY_set1_RSA(3)>, L<EVP_PKEY_set1_DSA>, L<EVP_PKEY_set1_DH> or
L<EVP_PKEY_set1_EC_KEY>
=head1 HISTORY
EVP_PKEY_new() and EVP_PKEY_free() exist in all versions of OpenSSL.
EVP_PKEY_up_ref() was first added to OpenSSL 1.1.0.
EVP_PKEY_new_raw_private_key(), EVP_PKEY_new_raw_public_key() and
EVP_PKEY_new_CMAC_key() were first added to OpenSSL 1.1.1.
EVP_PKEY_new_raw_private_key(), EVP_PKEY_new_raw_public_key(),
EVP_PKEY_new_CMAC_key(), EVP_PKEY_new_raw_private_key() and
EVP_PKEY_get_raw_public_key() were first added to OpenSSL 1.1.1.
=head1 COPYRIGHT
doc/man3/SSL_get_current_cipher.pod
+1 -1
View File
@@ -15,7 +15,7 @@ SSL_get_pending_cipher - get SSL_CIPHER of a connection
const char *SSL_get_cipher_name(const SSL *s);
const char *SSL_get_cipher(const SSL *s);
int SSL_get_cipher_bits(const SSL *s, int *np) \
int SSL_get_cipher_bits(const SSL *s, int *np);
const char *SSL_get_cipher_version(const SSL *s);
=head1 DESCRIPTION
doc/man3/X509v3_get_ext_by_NID.pod
+4 -2
View File
@@ -115,8 +115,8 @@ initial extension will not be checked.
X509v3_get_ext_count() returns the extension count.
X509v3_get_ext() and X509v3_delete_ext() return an B<X509_EXTENSION> pointer
or B<NULL> if an error occurs.
X509v3_get_ext(), X509v3_delete_ext() and X509_delete_ext() return an
B<X509_EXTENSION> pointer or B<NULL> if an error occurs.
X509v3_get_ext_by_NID() X509v3_get_ext_by_OBJ() and
X509v3_get_ext_by_critical() return the an extension index or B<-1> if an
@@ -124,6 +124,8 @@ error occurs.
X509v3_add_ext() returns a stack of extensions or B<NULL> on error.
X509_add_ext() returns 1 on success and 0 on error.
=head1 SEE ALSO
L<X509V3_get_d2i(3)>
doc/man7/ossl_store-file.pod
+6 -9
View File
@@ -47,17 +47,14 @@ only).
When needed, the 'file' scheme loader will require a pass phrase by
using the C<UI_METHOD> that was passed via OSSL_STORE_open().
This pass phrase is used as it is, which may present some challenge
when the file that's loaded contains a PKCS#12 object.
This pass phrase is expected to be UTF-8 encoded, anything else will
give an undefined result.
The files made accessible through this loader are expected to be
standard compliant with regards to pass phrase encoding.
Files that aren't should be re-generated with a correctly encoded pass
phrase.
See L<passphrase-encoding(7)> for more information.
=begin comment
The treatment of pass phrases is currently being worked on and may
change.
=end comment
=head1 SEE ALSO
L<ossl_store(7)>, L<passphrase-encoding(7)>
doc/man7/ossl_store.pod
+7
View File
@@ -33,6 +33,13 @@ dynamically from the calling application or from a loadable engine.
Support for the 'file' scheme is built into C<libcrypto>.
See L<ossl_store-file(7)> for more information.
=head2 UI_METHOD and pass phrases
The B<OSS_STORE> API does nothing to enforce any specific format or
encoding on the pass phrase that the B<UI_METHOD> provides. However,
the pass phrase is expected to be UTF-8 encoded. The result of any
other encoding is undefined.
=head1 EXAMPLES
=head2 A generic call
doc/man7/passphrase-encoding.pod
+9 -11
View File
@@ -4,7 +4,7 @@
=head1 NAME
password encoding
passphrase-encoding
- How diverse parts of OpenSSL treat pass phrases character encoding
=head1 DESCRIPTION
@@ -61,11 +61,11 @@ OpenSSL still does this, to be able to read files produced with older versions.
It should be noted that this approach isn't entirely fault free.
A passphrase encoded in ISO-8859-2 could very well have a sequence such as
A pass phrase encoded in ISO-8859-2 could very well have a sequence such as
0xC3 0xAF (which is the two characters "LATIN CAPITAL LETTER A WITH BREVE"
and "LATIN CAPITAL LETTER Z WITH DOT ABOVE" in ISO-8859-2 encoding), but would
be misinterpreted as the perfectly valid UTF-8 encoded code point U+00EF (LATIN
SMALL LETTER I WITH DIARESIS) I<if the passphrase doesn't contain anything that
SMALL LETTER I WITH DIARESIS) I<if the pass phrase doesn't contain anything that
would be invalid UTF-8>.
A pass phrase that contains this kind of byte sequence will give a different
outcome in OpenSSL 1.1.0 and newer than in OpenSSL older than 1.1.0.
@@ -80,13 +80,11 @@ than 1.1.0 was misinterpreted as ISO-8859-1 sequences.
L<ossl_store(7)> acts as a general interface to access all kinds of objects,
potentially protected with a pass phrase, a PIN or something else.
This API currently doesn't stipulate any specific encoding of pass phrases, but
uses the underlying routines with their behaviours.
This means that when using the built-in C<file:> scheme loader, the pass phrase
to unlock a PKCS#12 file will be treated as described for PKCS#12 above, and
the pass phrase for a PEM files will be treated as the general case described
above, since that loader uses the same underlying routines.
I<Note that other loaders will have their own behaviours>.
This API stipulates that pass phrases should be UTF-8 encoded, and that any
other pass phrase encoding may give undefined results.
This API relies on the application to ensure UTF-8 encoding, and doesn't check
that this is the case, so what it gets, it will also pass to the underlying
loader.
=head1 RECOMMENDATIONS
@@ -135,7 +133,7 @@ following:
=item 1.
Try the password that you have as it is in the character encoding of your
Try the pass phrase that you have as it is in the character encoding of your
environment.
It's possible that its byte sequence is exactly right.