From 6d5f8265ce6c4a8ed528462f519d9e8f2b7cfafd Mon Sep 17 00:00:00 2001 From: "Dr. Stephen Henson" Date: Thu, 23 Jul 2015 16:38:58 +0100 Subject: [PATCH] Documentation for SSL_check_chain() Reviewed-by: Matt Caswell --- doc/ssl/SSL_check_chain.pod | 85 +++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 doc/ssl/SSL_check_chain.pod diff --git a/doc/ssl/SSL_check_chain.pod b/doc/ssl/SSL_check_chain.pod new file mode 100644 index 0000000000..d3b7601909 --- /dev/null +++ b/doc/ssl/SSL_check_chain.pod @@ -0,0 +1,85 @@ +=pod + +=head1 NAME + +SSL_check_chain - check certificate chain suitability + +=head1 SYNOPSIS + + #include + + int SSL_check_chain(SSL *s, X509 *x, EVP_PKEY *pk, STACK_OF(X509) *chain); + +=head1 DESCRIPTION + +SSL_check_chain() checks whether certificate B, private key B and +certificate chain B is suitable for use with the current session +B. + +=head1 RETURN VALUES + +SSL_check_chain() returns a bitmap of flags indicating the validity of the +chain. + +B: the chain can be used with the current session. +If this flag is B 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: the EE key can be used for signing. + +B: the signature algorithm of the EE certificate is +acceptable. + +B: the signature algorithms of all CA certificates +are acceptable. + +B: the parameters of the end entity certificate are +acceptable (e.g. it is a supported curve). + +B: the parameters of all CA certificates are acceptable. + +B: the end entity certificate algorithm +can be used explicitly for signing (i.e. it is mentioned in the signature +algorithms extension). + +B: the issuer name is acceptable. This is only +meaningful for client authentication. + +B: the certificate type is acceptable. Only meaningful +for client authentication. + +B: 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 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 too. If no +chain is suitable a server should fall back to the most secure chain which +sets B. + +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, +L + +=cut -- 2.40.0