openssl/doc/man3/X509_STORE_CTX_new.pod

184 lines
7.2 KiB
Plaintext
Raw Normal View History

=pod
=head1 NAME
X509_STORE_CTX_new_ex, X509_STORE_CTX_new, X509_STORE_CTX_cleanup,
X509_STORE_CTX_free, X509_STORE_CTX_init, X509_STORE_CTX_set0_trusted_stack,
X509_STORE_CTX_set_cert, X509_STORE_CTX_set0_crls,
X509_STORE_CTX_get0_chain, X509_STORE_CTX_set0_verified_chain,
X509_STORE_CTX_get0_param, X509_STORE_CTX_set0_param,
X509_STORE_CTX_get0_untrusted, X509_STORE_CTX_set0_untrusted,
X509_STORE_CTX_get_num_untrusted,
X509_STORE_CTX_set_default,
X509_STORE_CTX_set_verify,
X509_STORE_CTX_verify_fn
- X509_STORE_CTX initialisation
=head1 SYNOPSIS
#include <openssl/x509_vfy.h>
X509_STORE_CTX *X509_STORE_CTX_new_ex(OSSL_LIB_CTX *libctx, const char *propq);
X509_STORE_CTX *X509_STORE_CTX_new(void);
void X509_STORE_CTX_cleanup(X509_STORE_CTX *ctx);
void X509_STORE_CTX_free(X509_STORE_CTX *ctx);
int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *store,
X509 *x509, STACK_OF(X509) *chain);
void X509_STORE_CTX_set0_trusted_stack(X509_STORE_CTX *ctx, STACK_OF(X509) *sk);
void X509_STORE_CTX_set_cert(X509_STORE_CTX *ctx, X509 *x);
STACK_OF(X509) *X509_STORE_CTX_get0_chain(const X509_STORE_CTX *ctx);
void X509_STORE_CTX_set0_verified_chain(X509_STORE_CTX *ctx, STACK_OF(X509) *chain);
void X509_STORE_CTX_set0_crls(X509_STORE_CTX *ctx, STACK_OF(X509_CRL) *sk);
X509_VERIFY_PARAM *X509_STORE_CTX_get0_param(const X509_STORE_CTX *ctx);
void X509_STORE_CTX_set0_param(X509_STORE_CTX *ctx, X509_VERIFY_PARAM *param);
int X509_STORE_CTX_set_default(X509_STORE_CTX *ctx, const char *name);
STACK_OF(X509)* X509_STORE_CTX_get0_untrusted(const X509_STORE_CTX *ctx);
void X509_STORE_CTX_set0_untrusted(X509_STORE_CTX *ctx, STACK_OF(X509) *sk);
int X509_STORE_CTX_get_num_untrusted(const X509_STORE_CTX *ctx);
typedef int (*X509_STORE_CTX_verify_fn)(X509_STORE_CTX *);
void X509_STORE_CTX_set_verify(X509_STORE_CTX *ctx, X509_STORE_CTX_verify_fn verify);
=head1 DESCRIPTION
These functions initialise an B<X509_STORE_CTX> structure for subsequent use
by X509_verify_cert().
X509_STORE_CTX_new_ex() returns a newly initialised B<X509_STORE_CTX>
structure associated with the specified library context I<libctx> and property
query string I<propq>. Any cryptographic algorithms fetched while performing
processing with the X509_STORE_CTX will use that library context and property
query string.
X509_STORE_CTX_new() is the same as X509_STORE_CTX_new_ex() except that
the default library context and a NULL property query string are used.
X509_STORE_CTX_cleanup() internally cleans up an B<X509_STORE_CTX> structure.
The context can then be reused with a new call to X509_STORE_CTX_init().
X509_STORE_CTX_free() completely frees up I<ctx>. After this call I<ctx>
is no longer valid.
If I<ctx> is NULL nothing is done.
X509_STORE_CTX_init() sets up I<ctx> for a subsequent verification operation.
It must be called before each call to X509_verify_cert(), i.e. a I<ctx> is only
Reject calls to X509_verify_cert that have not been reinitialised The function X509_verify_cert checks the value of |ctx->chain| at the beginning, and if it is NULL then it initialises it, along with the value of ctx->untrusted. The normal way to use X509_verify_cert() is to first call X509_STORE_CTX_init(); then set up various parameters etc; then call X509_verify_cert(); then check the results; and finally call X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets |ctx->chain| to NULL. The only place in the OpenSSL codebase where |ctx->chain| is set to anything other than a non NULL value is in X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be non NULL on entry to X509_verify_cert is if one of the following occurs: 1) An application calls X509_verify_cert() twice without re-initialising in between. 2) An application reaches inside the X509_STORE_CTX structure and changes the value of |ctx->chain| directly. With regards to the second of these, we should discount this - it should not be supported to allow this. With regards to the first of these, the documentation is not exactly crystal clear, but the implication is that you must call X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail to do this then, at best, the results would be undefined. Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is likely to have unexpected results, and could be dangerous. This commit changes the behaviour of X509_verify_cert() so that it causes an error if |ctx->chain| is anything other than NULL (because this indicates that we have not been initialised properly). It also clarifies the associated documentation. This is a follow up commit to CVE-2015-1793. Reviewed-by: Stephen Henson <steve@openssl.org>
2015-06-25 16:47:15 +08:00
good for one call to X509_verify_cert(); if you want to verify a second
certificate with the same I<ctx> then you must call X509_STORE_CTX_cleanup()
Reject calls to X509_verify_cert that have not been reinitialised The function X509_verify_cert checks the value of |ctx->chain| at the beginning, and if it is NULL then it initialises it, along with the value of ctx->untrusted. The normal way to use X509_verify_cert() is to first call X509_STORE_CTX_init(); then set up various parameters etc; then call X509_verify_cert(); then check the results; and finally call X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets |ctx->chain| to NULL. The only place in the OpenSSL codebase where |ctx->chain| is set to anything other than a non NULL value is in X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be non NULL on entry to X509_verify_cert is if one of the following occurs: 1) An application calls X509_verify_cert() twice without re-initialising in between. 2) An application reaches inside the X509_STORE_CTX structure and changes the value of |ctx->chain| directly. With regards to the second of these, we should discount this - it should not be supported to allow this. With regards to the first of these, the documentation is not exactly crystal clear, but the implication is that you must call X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail to do this then, at best, the results would be undefined. Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is likely to have unexpected results, and could be dangerous. This commit changes the behaviour of X509_verify_cert() so that it causes an error if |ctx->chain| is anything other than NULL (because this indicates that we have not been initialised properly). It also clarifies the associated documentation. This is a follow up commit to CVE-2015-1793. Reviewed-by: Stephen Henson <steve@openssl.org>
2015-06-25 16:47:15 +08:00
and then X509_STORE_CTX_init() again before the second call to
X509_verify_cert(). The trusted certificate store is set to I<store>, the end
entity certificate to be verified is set to I<x509> and a set of additional
Reject calls to X509_verify_cert that have not been reinitialised The function X509_verify_cert checks the value of |ctx->chain| at the beginning, and if it is NULL then it initialises it, along with the value of ctx->untrusted. The normal way to use X509_verify_cert() is to first call X509_STORE_CTX_init(); then set up various parameters etc; then call X509_verify_cert(); then check the results; and finally call X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets |ctx->chain| to NULL. The only place in the OpenSSL codebase where |ctx->chain| is set to anything other than a non NULL value is in X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be non NULL on entry to X509_verify_cert is if one of the following occurs: 1) An application calls X509_verify_cert() twice without re-initialising in between. 2) An application reaches inside the X509_STORE_CTX structure and changes the value of |ctx->chain| directly. With regards to the second of these, we should discount this - it should not be supported to allow this. With regards to the first of these, the documentation is not exactly crystal clear, but the implication is that you must call X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail to do this then, at best, the results would be undefined. Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is likely to have unexpected results, and could be dangerous. This commit changes the behaviour of X509_verify_cert() so that it causes an error if |ctx->chain| is anything other than NULL (because this indicates that we have not been initialised properly). It also clarifies the associated documentation. This is a follow up commit to CVE-2015-1793. Reviewed-by: Stephen Henson <steve@openssl.org>
2015-06-25 16:47:15 +08:00
certificates (which will be untrusted but may be used to build the chain) in
I<chain>. Any or all of the I<store>, I<x509> and I<chain> parameters can be
Reject calls to X509_verify_cert that have not been reinitialised The function X509_verify_cert checks the value of |ctx->chain| at the beginning, and if it is NULL then it initialises it, along with the value of ctx->untrusted. The normal way to use X509_verify_cert() is to first call X509_STORE_CTX_init(); then set up various parameters etc; then call X509_verify_cert(); then check the results; and finally call X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets |ctx->chain| to NULL. The only place in the OpenSSL codebase where |ctx->chain| is set to anything other than a non NULL value is in X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be non NULL on entry to X509_verify_cert is if one of the following occurs: 1) An application calls X509_verify_cert() twice without re-initialising in between. 2) An application reaches inside the X509_STORE_CTX structure and changes the value of |ctx->chain| directly. With regards to the second of these, we should discount this - it should not be supported to allow this. With regards to the first of these, the documentation is not exactly crystal clear, but the implication is that you must call X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail to do this then, at best, the results would be undefined. Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is likely to have unexpected results, and could be dangerous. This commit changes the behaviour of X509_verify_cert() so that it causes an error if |ctx->chain| is anything other than NULL (because this indicates that we have not been initialised properly). It also clarifies the associated documentation. This is a follow up commit to CVE-2015-1793. Reviewed-by: Stephen Henson <steve@openssl.org>
2015-06-25 16:47:15 +08:00
B<NULL>.
X509_STORE_CTX_set0_trusted_stack() sets the set of trusted certificates of
I<ctx> to I<sk>. This is an alternative way of specifying trusted certificates
instead of using an B<X509_STORE>.
X509_STORE_CTX_set_cert() sets the certificate to be verified in I<ctx> to
I<x>.
X509_STORE_CTX_set0_verified_chain() sets the validated chain used
by I<ctx> to be I<chain>.
Ownership of the chain is transferred to I<ctx> and should not be
free'd by the caller.
X509_STORE_CTX_get0_chain() returns the internal pointer used by the
I<ctx> that contains the validated chain.
X509_STORE_CTX_set0_crls() sets a set of CRLs to use to aid certificate
verification to I<sk>. These CRLs will only be used if CRL verification is
enabled in the associated B<X509_VERIFY_PARAM> structure. This might be
used where additional "useful" CRLs are supplied as part of a protocol,
for example in a PKCS#7 structure.
X509_STORE_CTX_get0_param() retrieves an internal pointer
to the verification parameters associated with I<ctx>.
X509_STORE_CTX_get0_untrusted() retrieves an internal pointer to the
stack of untrusted certificates associated with I<ctx>.
X509_STORE_CTX_set0_untrusted() sets the internal point to the stack
of untrusted certificates associated with I<ctx> to I<sk>.
X509_STORE_CTX_set0_param() sets the internal verification parameter pointer
to I<param>. After this call B<param> should not be used.
X509_STORE_CTX_set_default() looks up and sets the default verification
method to I<name>. This uses the function X509_VERIFY_PARAM_lookup() to
find an appropriate set of parameters from I<name>.
X509_STORE_CTX_get_num_untrusted() returns the number of untrusted certificates
that were used in building the chain following a call to X509_verify_cert().
X509_STORE_CTX_set_verify() provides the capability for overriding the default
verify function. This function is responsible for verifying chain signatures and
expiration times.
A verify function is defined as an X509_STORE_CTX_verify type which has the
following signature:
int (*verify)(X509_STORE_CTX *);
This function should receive the current X509_STORE_CTX as a parameter and
return 1 on success or 0 on failure.
=head1 NOTES
The certificates and CRLs in a store are used internally and should B<not>
be freed up until after the associated B<X509_STORE_CTX> is freed.
=head1 BUGS
The certificates and CRLs in a context are used internally and should B<not>
be freed up until after the associated B<X509_STORE_CTX> is freed. Copies
should be made or reference counts increased instead.
=head1 RETURN VALUES
X509_STORE_CTX_new() returns a newly allocates context or B<NULL> is an
error occurred.
X509_STORE_CTX_init() returns 1 for success or 0 if an error occurred.
X509_STORE_CTX_get0_param() returns a pointer to an B<X509_VERIFY_PARAM>
structure or B<NULL> if an error occurred.
X509_STORE_CTX_cleanup(), X509_STORE_CTX_free(),
X509_STORE_CTX_set0_trusted_stack(),
X509_STORE_CTX_set_cert(),
X509_STORE_CTX_set0_crls() and X509_STORE_CTX_set0_param() do not return
values.
X509_STORE_CTX_set_default() returns 1 for success or 0 if an error occurred.
X509_STORE_CTX_get_num_untrusted() returns the number of untrusted certificates
used.
=head1 SEE ALSO
L<X509_verify_cert(3)>
L<X509_VERIFY_PARAM_set_flags(3)>
=head1 HISTORY
The X509_STORE_CTX_set0_crls() function was added in OpenSSL 1.0.0.
The X509_STORE_CTX_get_num_untrusted() function was added in OpenSSL 1.1.0.
The X509_STORE_CTX_new_ex() function was added in OpenSSL 3.0.
=head1 COPYRIGHT
Copyright 2009-2020 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the Apache License 2.0 (the "License"). You may not use
this file except in compliance with the License. You can obtain a copy
in the file LICENSE in the source distribution or at
L<https://www.openssl.org/source/license.html>.
=cut