diff options
author | jkim <jkim@FreeBSD.org> | 2015-12-03 21:13:35 +0000 |
---|---|---|
committer | jkim <jkim@FreeBSD.org> | 2015-12-03 21:13:35 +0000 |
commit | 8d77ecefb78a0e7ec702cf614a78dd85de9395ee (patch) | |
tree | ade84397c16fe1b20cb2a441f603826e49c36cf2 /crypto/openssl/doc/ssl | |
parent | 5374819b03f4e6dcb332bf2729f9270e5d10b83a (diff) | |
parent | afd52a5fc90e70242dbb0e7d29987c976eb993e0 (diff) | |
download | FreeBSD-src-8d77ecefb78a0e7ec702cf614a78dd85de9395ee.zip FreeBSD-src-8d77ecefb78a0e7ec702cf614a78dd85de9395ee.tar.gz |
Merge OpenSSL 1.0.2e.
Diffstat (limited to 'crypto/openssl/doc/ssl')
-rw-r--r-- | crypto/openssl/doc/ssl/SSL_CTX_add_extra_chain_cert.pod | 35 | ||||
-rw-r--r-- | crypto/openssl/doc/ssl/SSL_CTX_get0_param.pod | 2 | ||||
-rw-r--r-- | crypto/openssl/doc/ssl/SSL_check_chain.pod | 85 |
3 files changed, 109 insertions, 13 deletions
diff --git a/crypto/openssl/doc/ssl/SSL_CTX_add_extra_chain_cert.pod b/crypto/openssl/doc/ssl/SSL_CTX_add_extra_chain_cert.pod index 8e832a5..04300fb 100644 --- a/crypto/openssl/doc/ssl/SSL_CTX_add_extra_chain_cert.pod +++ b/crypto/openssl/doc/ssl/SSL_CTX_add_extra_chain_cert.pod @@ -2,29 +2,39 @@ =head1 NAME -SSL_CTX_add_extra_chain_cert - add certificate to chain +SSL_CTX_add_extra_chain_cert, SSL_CTX_clear_extra_chain_certs - add or clear +extra chain certificates =head1 SYNOPSIS #include <openssl/ssl.h> - long SSL_CTX_add_extra_chain_cert(SSL_CTX ctx, X509 *x509) + long SSL_CTX_add_extra_chain_cert(SSL_CTX *ctx, X509 *x509); + long SSL_CTX_clear_extra_chain_certs(SSL_CTX *ctx); =head1 DESCRIPTION -SSL_CTX_add_extra_chain_cert() adds the certificate B<x509> to the certificate -chain presented together with the certificate. Several certificates -can be added one after the other. +SSL_CTX_add_extra_chain_cert() adds the certificate B<x509> to the extra chain +certificates associated with B<ctx>. Several certificates can be added one +after another. + +SSL_CTX_clear_extra_chain_certs() clears all extra chain certificates +associated with B<ctx>. + +These functions are implemented as macros. =head1 NOTES -When constructing the certificate chain, the chain will be formed from -these certificates explicitly specified. If no chain is specified, -the library will try to complete the chain from the available CA -certificates in the trusted CA storage, see +When sending a certificate chain, extra chain certificates are sent in order +following the end entity certificate. + +If no chain is specified, the library will try to complete the chain from the +available CA certificates in the trusted CA storage, see L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>. -The B<x509> certificate provided to SSL_CTX_add_extra_chain_cert() will be freed by the library when the B<SSL_CTX> is destroyed. An application B<should not> free the B<x509> object. +The B<x509> certificate provided to SSL_CTX_add_extra_chain_cert() will be +freed by the library when the B<SSL_CTX> is destroyed. An application +B<should not> free the B<x509> object. =head1 RESTRICTIONS @@ -37,8 +47,9 @@ be used instead. =head1 RETURN VALUES -SSL_CTX_add_extra_chain_cert() returns 1 on success. Check out the -error stack to find out the reason for failure otherwise. +SSL_CTX_add_extra_chain_cert() and SSL_CTX_clear_extra_chain_certs() return +1 on success and 0 for failure. Check out the error stack to find out the +reason for failure. =head1 SEE ALSO diff --git a/crypto/openssl/doc/ssl/SSL_CTX_get0_param.pod b/crypto/openssl/doc/ssl/SSL_CTX_get0_param.pod index 332f181..ba16b50 100644 --- a/crypto/openssl/doc/ssl/SSL_CTX_get0_param.pod +++ b/crypto/openssl/doc/ssl/SSL_CTX_get0_param.pod @@ -34,7 +34,7 @@ them to suit its needs: for example to add a hostname check. Check hostname matches "www.foo.com" in peer certificate: X509_VERIFY_PARAM *vpm = SSL_get0_param(ssl); - X509_VERIFY_PARAM_set1_host(vpm, "www.foo.com"); + X509_VERIFY_PARAM_set1_host(vpm, "www.foo.com", 0); =head1 RETURN VALUES diff --git a/crypto/openssl/doc/ssl/SSL_check_chain.pod b/crypto/openssl/doc/ssl/SSL_check_chain.pod new file mode 100644 index 0000000..d3b7601 --- /dev/null +++ b/crypto/openssl/doc/ssl/SSL_check_chain.pod @@ -0,0 +1,85 @@ +=pod + +=head1 NAME + +SSL_check_chain - check certificate chain suitability + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + int SSL_check_chain(SSL *s, X509 *x, EVP_PKEY *pk, STACK_OF(X509) *chain); + +=head1 DESCRIPTION + +SSL_check_chain() checks whether certificate B<x>, private key B<pk> and +certificate chain B<chain> is suitable for use with the current session +B<s>. + +=head1 RETURN VALUES + +SSL_check_chain() returns a bitmap of flags indicating the validity of the +chain. + +B<CERT_PKEY_VALID>: the chain can be used with the current session. +If this flag is B<not> set then the certificate will never be used even +if the application tries to set it because it is inconsistent with the +peer preferences. + +B<CERT_PKEY_SIGN>: the EE key can be used for signing. + +B<CERT_PKEY_EE_SIGNATURE>: the signature algorithm of the EE certificate is +acceptable. + +B<CERT_PKEY_CA_SIGNATURE>: the signature algorithms of all CA certificates +are acceptable. + +B<CERT_PKEY_EE_PARAM>: the parameters of the end entity certificate are +acceptable (e.g. it is a supported curve). + +B<CERT_PKEY_CA_PARAM>: the parameters of all CA certificates are acceptable. + +B<CERT_PKEY_EXPLICIT_SIGN>: the end entity certificate algorithm +can be used explicitly for signing (i.e. it is mentioned in the signature +algorithms extension). + +B<CERT_PKEY_ISSUER_NAME>: the issuer name is acceptable. This is only +meaningful for client authentication. + +B<CERT_PKEY_CERT_TYPE>: the certificate type is acceptable. Only meaningful +for client authentication. + +B<CERT_PKEY_SUITEB>: chain is suitable for Suite B use. + +=head1 NOTES + +SSL_check_chain() must be called in servers after a client hello message or in +clients after a certificate request message. It will typically be called +in the certificate callback. + +An application wishing to support multiple certificate chains may call this +function on each chain in turn: starting with the one it considers the +most secure. It could then use the chain of the first set which returns +suitable flags. + +As a minimum the flag B<CERT_PKEY_VALID> must be set for a chain to be +usable. An application supporting multiple chains with different CA signature +algorithms may also wish to check B<CERT_PKEY_CA_SIGNATURE> too. If no +chain is suitable a server should fall back to the most secure chain which +sets B<CERT_PKEY_VALID>. + +The validity of a chain is determined by checking if it matches a supported +signature algorithm, supported curves and in the case of client authentication +certificate types and issuer names. + +Since the supported signature algorithms extension is only used in TLS 1.2 +and DTLS 1.2 the results for earlier versions of TLS and DTLS may not be +very useful. Applications may wish to specify a different "legacy" chain +for earlier versions of TLS or DTLS. + +=head1 SEE ALSO + +L<SSL_CTX_set_cert_cb(3)|SSL_CTX_set_cert_cb(3)>, +L<ssl(3)|ssl(3)> + +=cut |