diff options
author | Ingela Anderton Andin <[email protected]> | 2016-01-13 22:04:00 +0100 |
---|---|---|
committer | Ingela Anderton Andin <[email protected]> | 2018-09-12 10:51:03 +0200 |
commit | 45b6afd71bbb7c4b9a0678067bbb7f9276be5605 (patch) | |
tree | 04935ddb812c53d931bbe3f21d8ff4beff2b6ff6 /lib/inets/info | |
parent | 53b8f2bc723e7a9db8bb01b5c5a2292d12b30b14 (diff) | |
download | otp-45b6afd71bbb7c4b9a0678067bbb7f9276be5605.tar.gz otp-45b6afd71bbb7c4b9a0678067bbb7f9276be5605.tar.bz2 otp-45b6afd71bbb7c4b9a0678067bbb7f9276be5605.zip |
ssl: Handle incomplete and unorded chains
If the peer sends an incomplete chain that we can reconstruct with
our known CA-certs it will be accepted.
We will assume that the peer honors the protocol and sends an orded
chain, however if validation fails we will try to order the chain in
case it was unorded. Will also handle that extraneous cert where present.
See Note form RFC 8446
Note: Prior to TLS 1.3, "certificate_list" ordering required each
certificate to certify the one immediately preceding it; however,
some implementations allowed some flexibility. Servers sometimes
send both a current and deprecated intermediate for transitional
purposes, and others are simply configured incorrectly, but these
cases can nonetheless be validated properly. For maximum
compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.
Diffstat (limited to 'lib/inets/info')
0 files changed, 0 insertions, 0 deletions