jonny.balotas@ - Thanks for filing the issue...!!

Could you please provide a sample test file/url to test the issue from Te-end.
This will help us in triaging the issue further.

Thanks...!!

Please disregard Comment #2, as it will require the specific physical devices to test.

Can you please include a NetLog, as described at https://dev.chromium.org/for-testers/providing-network-details

Hi,
this is the standard NetLog as described at https://dev.chromium.org/for-testers/providing-network-details; I made a standard NetLog (with "Strip private information" options);
let me know if it's ok or if you need a detailed netlog.

Since this log contains the visited urls, can you restrict the visibility of this bug report?

Thanks

Deleted: chrome-net-export-log.zip 311 KB

chrome-net-export-log.zip 311 KB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Given the error says SEC_ERROR_NO_TOKEN and there's a smartcard change involved, I imagine this is the age-old problem where we have no way of knowing the private key handle has been invalidated.

If you try again at that point, I think it should work. Here's a crazy thought... what if, when we get an SSLPrivateKey from SSLClientAuthCache and the handshake fails with ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED, we just retried and did the client certificate selection again?

Just to make sure I indeed have the scenario right, when this happens for you, if you refresh the page or otherwise try again, does it work again?

I.e. is the problem that Chrome needs some help retrying after it finds the first smartcard is gone, or has it managed to get completely stuck?

Yes, you're correct: if I refresh/retry, the smartcard authentication works as expected (pin & choose certificate dialog).

Thanks! I'll take a look at trying to do that try more automatically.

https://chromium-review.googlesource.com/c/chromium/src/+/935723

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/76a40adc6e37be621cdc45c72eaf8b2b24254e75

commit 76a40adc6e37be621cdc45c72eaf8b2b24254e75
Author: David Benjamin <davidben@chromium.org>
Date: Sat Feb 24 22:22:08 2018

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-Commit-Position: refs/heads/master@{#539022}
[modify] https://crrev.com/76a40adc6e37be621cdc45c72eaf8b2b24254e75/net/http/http_network_transaction.cc
[modify] https://crrev.com/76a40adc6e37be621cdc45c72eaf8b2b24254e75/net/http/http_network_transaction.h
[modify] https://crrev.com/76a40adc6e37be621cdc45c72eaf8b2b24254e75/net/url_request/url_request_unittest.cc

That should smooth things over. Setting a reminder to ask in a week to confirm whether it worked on the next Dev channel (google-chrome-unstable) release.

The NextAction date has arrived: 2018-03-02

Looks like the next Linux Dev channel cut hasn't happened yet. Snoozing for a bit longer.

The NextAction date has arrived: 2018-03-07

Sigh. Why is Dev channel being so slow right now. Resnoozing...

The NextAction date has arrived: 2018-03-14

Okay, after much delay, the fix should be in the Dev channel. If you install google-chrome-unstable, does this case work better? (It uses a separate profile directory and installs in parallel, so it won't clobber your existing state.)

A bit later :) but I tested the issue on chromium release 66.0.3359.181 and it works as expected.

Thanks

Thanks for confirming! Glad to hear that worked. (Client certificate issues often need to be fixed blind, so we're often unsure whether we actually solved the problem or not. :-D)