How are you installing your client cert?

We presently only listen for events such as the list of keychains is changed (kSecKeychainListChangedEvent) or the list of trust settings has changed (kSecTrustSettingsChangedEvent). These are done as best effort - for various reasons, the only 'supported' way of changing client certificates - particularly involving resetting previous decisions - is to do a process restart.

This is sufficient to handle the smart-card case, and was done because other events (namely, kSecAddEvent / kSecDeleteEvent / kSecUpdateEvent) are far too noisy to be used in their default state. We've evaluated in the past determining if the effective available set of client certificates for a given connection changes, to revisit that, but we've intentionally decided previously not to do that, as we've seen as much negative consequence as positive benefits.

You can work around this behaviour by handling removing and inserting the keychain. Does that work as an acceptable solution?

We use the security command to add client certs to the keychain.

We're investigating whether removing/adding a keychain is a viable workaround. Thanks for that suggestion!

For posterity, the issues with kSecAddEvent per Ryan (mistakes in transcription are mine) are:

- If pid != self, item and keychain don't get set, so we can't filter out non-certificate keychain events

- The change events fire really often, on per item, so we'd have to debounce it a bit.

Thanks David for encouraging me to be less hand-wavy :)

Correct that the issues in the past were involving it being too noisy. David rightfully pointed out that you can filter events (so as to exclude password change events, for example), but sequences such as locking/unlocking your machine, or accessing passwords in a browser (when the browsers still sync'd directly into the device keychain) could create spurious events. Because of the pid filtering issue (and mind you, this was ~macOS 10.5), we couldn't filter out the reason why.

It's fully possible that this has changed in the macOS 10.9+ world that Chrome supports. It's also a known-issue/intentional-(ish) behaviour that we don't even look for change events on Windows or Linux. On Windows, we'd have to setup hEvent monitoring, and on Linux, we'd need to spawn a dedicated thread-per-slot (and manage reaping threads) in order to do the wait for slot events. I threw the macOS change monitoring in because it was low-cost and (unlike the other platforms) didn't require the dedicated thread blocking.

There's possibilities that this will improve in the future, but I wanted to see about offering workarounds in the event such work is triaged as low priority :)

Hi,

We have got the same problem on macOS High Sierra.

New inserted Keychain SSL certifiates become available to Chrome ONLY WHEN Chrome is RESTARTED.

re Comment #6: Can you please describe how you are 'inserting Keychain SSL certificates' to see whether or not this is the known issue?

Hi,

We don't actually insert the smartcard certificates.

Instead, certificates are read by a TokenD-based service we have developed.

It is the system that finally propagates these data to KeyChain database.

Also, I must mention that the problem does not occur in macOS Sierra (10.12) platform, only the Hign Sierra is affected.