Hi Eskimo, So regarding the installation process of the certificate + privatekey in the login keychain, Sadly I don't have any control on this flow and I have to deal with non exportable private key in login keychain, and my goal is to be able to use it as part of client-side authentication in TLS.
After reading the links you showed me I think I have some workaround to the problem... Once I reach didReceiveChallenge call in the Daemon side, I will first execute the service's mach-o file but in user-mode process, in such a way that it will send dummy https request to the server.
This will trigger the didReceiveChallenge once again but from the user-mode process, and now I can extract the identity easily and pass it to completion handler. This will likely present popup window that I should confirm using the private key for signing (see attached image)
Once the user press "always allow" then the request will be sent and we go back to the original Daemon now that this key is accessible for signing in this machine.
Now I don't need access to the window server to display any popups, since I already accepted the use of this private key. and If i'll do seteuid to the current active user. I can get the identityRef in the same way I did in the user-mode instance of this Daemon, and when I send it on the completionHandler, It's already have access to this key, so the whole process will go without any user interaction.
This flow is basically meant to bypass the Daemon failed attempt to allow keychain signing with the private key. since this isn't possible as the key reside in login keychain, and the Daemon cannot interact with the Windows server to triggers some popup windows.
it's relatively complicated solution, but I don't have other choice giving how the certificate was installed in the keychain.