Thanks for the report.

Considering this as feature request, marking as Untriaged.

Requesting Dev team to look into this issue and update.

Client certificate error messages are not something a client can control. What we do depends strongly on what alert the server is kind enough to send us and other factors like whether we filter out expired certs ahead of time (I forget).

Please attach a net-internals log per these instructions:
https://dev.chromium.org/for-testers/providing-network-details

David: We do filter out ahead of time. This is the case where the cert enters the cache (unexpired), but then later expires during use.

There's only one place NSS sets SSL_ERROR_EXPIRED_CERT_ALERT: a certificate_expired alert - https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#3756

Seems reasonably low-friction to support, but haven't checked the spec.

We already map that alert to ERR_BAD_SSL_CLIENT_AUTH_CERT, hence the net-internals request. I actually suspect we're simply filtering the certs out, sending none, and hitting  issue #646567 . A net-internals log will confirm.

Following Comment #4, please find attached the requested net-internals report.

Deleted: net-internals-log.json 103 KB

net-internals-log.json 103 KB View Download

Thanks! Comment #4 is indeed what's going on. Merging into the other bug. ClientCertStoreMac filters out expired certificates, so we're not prompting or offering anything. The server then responds with our favorite generic handshake_failure alert (since TLS didn't define an alert for this) which we currently map to a generic error.

 Issue #646567  is being worked on (I have a meeting with some UI folks next week), so hopefully in a future release we'll map this to something more useful.

Ok, thanks for taking this into account.
By the way, I am not sure what you mean by "cache" here, but in my case the certificate had not been requested by the server for several weeks or even months (I mostly use other computers for this task). The browser has had many opportunities to be quit since last time the cert has been requested by the server, and the whole computer has been rebooted several times as well.
I would guess the cache you mention has had many opportunities to be cleared or invalidated.

Yeah, I don't think the cache was involved. I think we were confused about how much time passed between steps 2 and 3. :-) Either way, the issue is the same was #646567.

(The problem is TLS failed to define an alert for "you sent no certificate, but I needed one", so everyone sends the generic handshake_failure alert which is used for bad cipher suites and everything else. We're going to need some extra logic to guess when it was because you didn't send a client cert. I've gotten the IETF to define a new alert for TLS 1.3, so going forward servers will hopefully be saner.)

I have seen the new error with Version 55.0.2875.0 canary (64-bit) on macOS 10.12.
This is a very helpful error message, thanks!

I just wish it were present in the DevTools security audit as well (see attachment).

Deleted: Capture d’écran 2016-09-30 à 01.06.13.png 91.2 KB

	Capture d’écran 2016-09-30 à 01.06.13.png 91.2 KB View Download

That's probably for +lgarron. It looks like that's just what we show on net error pages? In such a situation, we can't really show any of the bits DevTools would show because we haven't made a connection at all, but probably we shouldn't "Valid Certificates" and "Secure Resources" either.

(Probably should be tracked in a separate bug.)

I just tried several times creating a new issue for this, but I got a blank page.

Here is a copy of the report, please feel free to report it yourself with above screenshot:
Please enter a one-line summary:
DevTools' Security panel doesn't always show specific errors when overview marked "not secure"

What part of the browser is affected?
The Security panel in DevTools

Steps to reproduce the problem:
1. Have an expired client certificate
2. Load a webpage that requires this client certificate
3. Open the DevTools' Security panel

What is the expected behavior?
At least one warning or error message in the details to explain the overview label: "This page is not secure".
This panel really shines when user-friendly messages are displayed to help the less technical-oriented users.

What went wrong?
Although the overview displays a message "This page is not secure" (which is correct in this case), the details show no error. This creates confusion for the end user.

Did this work before?
  Not applicable or don't know  Yes - This is a regression  No - I think it never worked  

Any other comments?
Sometimes the actual TLS error is not even displayed in the main browser window, as shown by #646567.
Please see #647910 for more history on this issue.

Odd. Well, anyway, I've pasted your report to  issue #651866 .