| commit | 9cde848bd1109f1a0a77d68b19732ed5535d6953 | [log] [tgz] |
|---|---|---|
| author | Christopher Patton <chrispatton@gmail.com> | Tue Jul 17 11:36:36 2018 -0700 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Fri Jan 04 19:29:33 2019 +0000 |
| tree | d8f55391cd66fa3fc4001d7eb11c9e5572de1060 | |
| parent | 1aaa7aa83c13d52043e1fe342d0df68cc91b7b0e [diff] [blame] |
Use handshake parameters to decide if cert/key are available Whether the host has a valid certificate or private key may depend on the handshake parameters and not just its configuration. For example, negotiating the delegated credential extension (see https://tools.ietf.org/html/draft-ietf-tls-subcerts) requires an alternate private key for the handshake. Change-Id: I11cea1d11e731aa4018d980c010b8d8ebaa64c31 Reviewed-on: https://boringssl-review.googlesource.com/c/33664 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
diff --git a/ssl/tls13_both.cc b/ssl/tls13_both.cc index f6e359c..605942a 100644 --- a/ssl/tls13_both.cc +++ b/ssl/tls13_both.cc
@@ -441,7 +441,7 @@ return false; } - if (!ssl_has_certificate(hs->config)) { + if (!ssl_has_certificate(hs)) { return ssl_add_message_cbb(ssl, cbb.get()); }