aboutsummaryrefslogtreecommitdiffstats
path: root/.mailmap
diff options
context:
space:
mode:
authorIngela Anderton Andin <[email protected]>2016-01-13 22:04:00 +0100
committerIngela Anderton Andin <[email protected]>2018-09-12 10:51:03 +0200
commit45b6afd71bbb7c4b9a0678067bbb7f9276be5605 (patch)
tree04935ddb812c53d931bbe3f21d8ff4beff2b6ff6 /.mailmap
parent53b8f2bc723e7a9db8bb01b5c5a2292d12b30b14 (diff)
downloadotp-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 '.mailmap')
0 files changed, 0 insertions, 0 deletions