I don't recall what implementation uses e.g. the system keychain for cert storage but it's not unheard of for a custom keychain to be configured on macs and have agents access it for handshake

I mean, will the client try to find values for --tls_client_cert and --tls_client_key if the server requires client authentication?

The --tls_client_* flags probably refer to paths on-disk. I was under the impression that e.g. osquery does not have mTLS support, so it wouldn’t surprise me if keychain lookup code is similarly not implemented at present

That’s correct, we only support certificate bundles on the filesystem

Not safe) Thank you very much, you helped a lot to save time for experiments.

Do your queries tip off attackers? Mine aren't prescriptive…

I am considering a scenario where most of the employees work remotely and do not want to have open interfaces on the perimeter, as there is always a vulnerability in any software. mTLS solves this problem perfectly. At the same time, the hosts already have device certificates issued by MDM, they could be used, but they are stored in the keychain.

And SCEP is the best protocol to secure MDM behind… 😛

Now we need to think about issuing alternative device certificates, but this in good terms requires the deployment of SCEP.

I mean I totally agree/want mTLS. Let's fund two canoes or trail of bits or zentral and they'll build it in

I haven't seen solutions other than Zentral, I'll take a look at them. I am currently reviewing Fleet and suggest using Nginx (or another proxy) for mTLS

It's about not needing an extra agent/log shipper and having osquery open the connection/send the data

Yes, store on disk is a valid scenario. It just creates a lot of unnecessary complexity, and what's funny, osquery is used, among other things, to keep track of certificates in the store, but it turns out it can't keep track of its own, because it's on disk) 😀