Hi Eskimo,
Unfortunately, when i follow your guidance to export the certificate I get the following message :
Does it means that the key is completely non-exportable ?
Post
Replies
Boosts
Views
Activity
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.
Hi Eskimo, So if I understand you correctly, since my identity (which represent the private key) cannot be exported from the login keychain, therefore I cannot set it in system keychain.
In this case, what options do I left ? my main objective is to establish the https connection from the Daemon, and unfortunately, the certificate is installed only to the login keychain... maybe it's worth considering seteuid to the active user ?
thanks !
Hi Eskimo, thanks for the thorough explanation.
To your question, my user signing certificate (leaf certificate with private key installed in login keychain) is installed so that you cannot export the private key (once trying to import the object to p12 file - I get the following error
An error has occcurred. Unable to export an item... The contents of this item cannot be retrieved")
Basically, there's another software that deploy this certificate in the keychain, and I've no control over it (it's JAMF Self Service).
So in this case, what are my options to pass the digital identity to the Daemon process ?
Hi Eskimo, Perhaps you can advise about the right approach in this matter ?
I'm thinking about converting the SecCertificateRef objects in the certificate chain, into NSData type using method like SecCertificateCopyData. and convert them back to certificate type on the other side (the daemon side) before import each such certificate into the keychain.
Do you recommend this approach ?
thanks !
Luckily I control the user process code as well. This is how I create the NSURLCredentials in my user process
NSURLCredential *certificateBasedCredential = [NSURLCredential credentialWithIdentity:identityRef
certificates:certificateArray
persistence:NSURLCredentialPersistenceForSession];
where certificateArray contains of the certificates from the chain (until the agreed self signed CA).
So your proposal is to simply pass this array of certificates to the Daemon so it can save them on the system keychain and use them when needed, right ?
But is it possible to pass reference objects from type SecCertificateRef on the XPC ? or should I use different type ?
Thanks !
That's for your point... for some reason the ForEach loop goes through the items twice.
for example, if the list contain [a b c]
so the foreach goes through: a b c a b c
any idea why ?
Hi, did you manage to solve it. I also struggling with the same issue.
Hi, Just trying to bump this issue as it's really crucial for me.
Currently in order to workaround this problem I run the CMake twice, once to generate Xcode project and another time to build from regular Makefile.
the Makefile build is meant only for running the clang-tidy, while the Xcode project used for debugging ... however, it's very cumbersome to make the extra builds, and I'm sure there maybe an easier workaround like Xcode plugin or such ...
Ok, So i've implemented my receive function to call new receiveMessageWithCompletionHandler upon successful completion and it's working great.
But now I've got another issue in the same area...
If I'm sendPingWithPongReceiveHandler method as a webSocket heartbeat, how can I ensure that the Pong responses wouldn't get caught by the receiveMessage completion handler, but by the pongReceiveHandler ?
Are the Pong responses differ from other responses in terms of routing so that each trigger a different callback by design ?
If you mentioned the proxy provider. I also had an idea to use NETransparentProxyNetworkSettings to create some local proxy and use Include/ExcludeMethodRules in order to decide what will enter my tunnel and what traffic goes to the default interface (like en0). Can this class also replace the NEPacketTunnelProvider in creating and starting the tunnel (along with the tunnel protocol), or it can just be used for splitting the relevant traffic to the tunnel, which will be implemented by the provider itself ?
thanks!