SSL_check_chain.pod 3.1 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394
  1. =pod
  2. =head1 NAME
  3. SSL_check_chain - check certificate chain suitability
  4. =head1 SYNOPSIS
  5. #include <openssl/ssl.h>
  6. int SSL_check_chain(SSL *s, X509 *x, EVP_PKEY *pk, STACK_OF(X509) *chain);
  7. =head1 DESCRIPTION
  8. SSL_check_chain() checks whether certificate B<x>, private key B<pk> and
  9. certificate chain B<chain> is suitable for use with the current session
  10. B<s>.
  11. =head1 RETURN VALUES
  12. SSL_check_chain() returns a bitmap of flags indicating the validity of the
  13. chain.
  14. B<CERT_PKEY_VALID>: the chain can be used with the current session.
  15. If this flag is B<not> set then the certificate will never be used even
  16. if the application tries to set it because it is inconsistent with the
  17. peer preferences.
  18. B<CERT_PKEY_SIGN>: the EE key can be used for signing.
  19. B<CERT_PKEY_EE_SIGNATURE>: the signature algorithm of the EE certificate is
  20. acceptable.
  21. B<CERT_PKEY_CA_SIGNATURE>: the signature algorithms of all CA certificates
  22. are acceptable.
  23. B<CERT_PKEY_EE_PARAM>: the parameters of the end entity certificate are
  24. acceptable (e.g. it is a supported curve).
  25. B<CERT_PKEY_CA_PARAM>: the parameters of all CA certificates are acceptable.
  26. B<CERT_PKEY_EXPLICIT_SIGN>: the end entity certificate algorithm
  27. can be used explicitly for signing (i.e. it is mentioned in the signature
  28. algorithms extension).
  29. B<CERT_PKEY_ISSUER_NAME>: the issuer name is acceptable. This is only
  30. meaningful for client authentication.
  31. B<CERT_PKEY_CERT_TYPE>: the certificate type is acceptable. Only meaningful
  32. for client authentication.
  33. B<CERT_PKEY_SUITEB>: chain is suitable for Suite B use.
  34. =head1 NOTES
  35. SSL_check_chain() must be called in servers after a client hello message or in
  36. clients after a certificate request message. It will typically be called
  37. in the certificate callback.
  38. An application wishing to support multiple certificate chains may call this
  39. function on each chain in turn: starting with the one it considers the
  40. most secure. It could then use the chain of the first set which returns
  41. suitable flags.
  42. As a minimum the flag B<CERT_PKEY_VALID> must be set for a chain to be
  43. usable. An application supporting multiple chains with different CA signature
  44. algorithms may also wish to check B<CERT_PKEY_CA_SIGNATURE> too. If no
  45. chain is suitable a server should fall back to the most secure chain which
  46. sets B<CERT_PKEY_VALID>.
  47. The validity of a chain is determined by checking if it matches a supported
  48. signature algorithm, supported curves and in the case of client authentication
  49. certificate types and issuer names.
  50. Since the supported signature algorithms extension is only used in TLS 1.2
  51. and DTLS 1.2 the results for earlier versions of TLS and DTLS may not be
  52. very useful. Applications may wish to specify a different "legacy" chain
  53. for earlier versions of TLS or DTLS.
  54. =head1 SEE ALSO
  55. L<SSL_CTX_set_cert_cb(3)>,
  56. L<ssl(7)>
  57. =head1 COPYRIGHT
  58. Copyright 2015-2016 The OpenSSL Project Authors. All Rights Reserved.
  59. Licensed under the OpenSSL license (the "License"). You may not use
  60. this file except in compliance with the License. You can obtain a copy
  61. in the file LICENSE in the source distribution or at
  62. L<https://www.openssl.org/source/license.html>.
  63. =cut