| commit | dd9f70fcd6798f2241f6977d9d5ae4713ee27679 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@chromium.org> | Sat Feb 24 22:22:08 2018 |
| committer | Commit Bot <commit-bot@chromium.org> | Sat Feb 24 22:22:08 2018 |
| tree | 0827a273d9065bc6a231fc66f225fb0c24351fa0 | |
| parent | c9b2d5fcbbf3ce57dc9b3ffa24c057d2f64b52c1 [diff] |
Request a new client certificate if a cached one is stale. If an SSLPrivateKey is backed by a smartcard or other interesting module, the handle may eventually stop working. In particular, the smartcard may be removed at some point. Ideally, the OS would provide reliable fine-grained signals to clear relevant the cache entries, but the OS tends not to provide these APIs. We do drop the cache entry on failure, but the user is required to retry the operation. Instead, if an SSLPrivateKey was grabbed from the SSLClientAuthCache, assume it is potentially stale. Should the signing operation fail, we can not only drop the cache entry, but retry the request. This CL does not implement this logic for proxy client certificates, only server client certificates. Proxy client certificates a missing the cache clearing logic (https://crbug.com/814911), so we can fill this in once the plumbing is in place. Along the way, fill in some URLRequest-level client certificate unit tests. Bug: 813022 Change-Id: I9f0450e9f4df1383dd8b73d0297ebea5e3368fec Reviewed-on: https://chromium-review.googlesource.com/935723 Reviewed-by: Ryan Sleevi <rsleevi@chromium.org> Commit-Queue: David Benjamin <davidben@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#539022} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 76a40adc6e37be621cdc45c72eaf8b2b24254e75
TODO: Add network stack documentation. :)