The SSL code should be sending intermediates if we got any to send (and indeed if it works in Windows Chrome, that code is platform-independent). Tossing over to certificate folks. I'm guessing something about how we're finding the intermediates in ClientCertStoreMac and how Safari's doing it isn't matching and we're not finding them in this deployment.

I suspect this is related to https://codereview.chromium.org/2910893002/ , which is waiting on a CLA. I'll poke Alex again.

Oh wait, this is finding the leaf cert, but not the intermediates (and macOS 10.11 not 10.12). However, 10.11 did change how the SecTrust APIs work. Unfortunately, this is in the edge-case scenario that's a pain to support.

Given that we've dropped <10.7 support, I may be able to try to work around with SecTrustGetCertificateCount/SecTrustGetCertificateAtIndex, assuming the SecTrust is properly building the chain. However, I suspect it isn't.

Can you attach a chrome://net-internals log?

working on that.  Have never done that before.  Confirmed, I don't know what i'm doing here :) went to chrome://net-internals and didn't get any options to export.  could see what I wanted to export, but feeling stupid :) 

here's a netlog output

Deleted: chrome-net-export-log.json 193 KB

chrome-net-export-log.json 193 KB View Download

I think that's our fault. :-) Things moved around a bit, but we're all still used to saying net-internals. These are the up-to-date instructions. Sorry about the confusion!

https://dev.chromium.org/for-testers/providing-network-details

Thank you for providing more feedback. Adding requester "rsleevi@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

ok, i sent one json without byte-level.  let me know if that's good :)

it says comment 6 deleted, but that's where I think i uploaded.  SOrry -- noob.

Undeleted per comment #10.

(Actually, apparently it got marked as spam. Weird.)

thanks -- strange.  Just let me know if that's not helpful or what you need.

@davidben -- A friendly ping. Could you please look into this issue.

Thanks in advance.

You want one of the certs folks, not me.

Requesting any dev from Internals>Network>Certificate team to please have a look into the issue.

Thanks...!!

A friendly ping...

Request someone from Internals>Network>Certificate team to please look into this issue.

Thanks..

Cc'ing 	mattm@ from Issue 671889 for more inputs on this.

One thing to note is we only try to build the client cert chain if the tls Certificate Request has specified certificate_authorities. From the netlog in #6 it appears the Certificate Request does not specify any certificate_authorities, so this would be expected.
(t= 427 [st=  75]        SSL_HANDSHAKE_MESSAGE_RECEIVED
                        --> hex_encoded_bytes =
                          0D 00 00 26 03 01 02 40  00 1E 06 01 06 02 06 03   .  &...@ .......
                          05 01 05 02 05 03 04 01  04 02 04 03 03 01 03 02   ................
                          03 03 02 01 02 02 02 03  00 00                     ........  
                        --> type = 13)

I did a simple test (no smartcards) and Chrome did send the intermediate when the authority was requested by the server. 

I guess Safari will just build and send whatever random chain it can find even if a specific authority was not requested?

It looks like it.

With respect to client cert authentication, attempting to build a chain on the client is fraught with peril and rife with error. For example, we know of some enterprises that improperly construct their chains, but their servers will (and intentionally) accept such certificates.

Most importantly, there's no reason to believe or assume that the client set of CAs matches the server set of CAs, and as such, no reasonable way to assume a 'correct' chain can be built - because it's ultimately determined by the server as to what constitutes the trust anchor and what is a valid chain.

A proper deployment of client certificates should have the server implement whatever path building and discovery is appropriate for its use case. This is done on some servers (e.g. Microsoft IIS deployments), as that allows the server full support for all of its policies regarding authentication, such as checking for LDAP-based stores of intermediates and CRLs, applying revocation checks as appropriate, and handling policy-based path building.

In the case of CAC, this is already required as part of the DoD PKI for accepting/recognizing CAC cards, and the interoperability testing performed by DISA/JITC. It appears some organizations may be more relaxed with respect to PIV, but I would be surprised if there aren't similar acceptance criteria requirements.

The behaviour of macOS is consistent with our Linux and Android implementations, and we should align our Windows implementation to match this, particularly as we migrate more of our Windows path-building code.

I'm closing this as WontFix/WorkingAsIntended, as the proper way for supporting client certificates - regardless of whether or not the UA presents intermediates - is to handle path building and discovery on the server, as appropriate to its policies.