Yes you are right, unfortunately I also couldn't find a way to convert the different objects vice versa to make everything to work together, especially with the swift-certificates.

The SecureEnclave.P256.Signing.PrivateKey(..) unfortunately doesn't add the key automatically to the keychain. You have to add it manually. The SecKeyCreateRandomKey(...) adds the key to the keychain, protect it through the secure enclave if you pass the right attributes: kSecAttrIsPermanent: to save it to the keychain automatically kSecAttrTokenIDSecureEnclave: to protect it through the secure enclave But then as I mentioned you will face problems to convert the keys to the expected types.

I think the problem is, that to can query a valid SecIdentity you must have in the keychain a private key added as kSecClassKey and the corresponding certificate added as kSecClassCertificate. While your example shows that your certificate is added in the right way, unfortunately you private key is added as kSecClassGenericPassword (if you followed the example from the mentioned link). The system doesn't know, that the saved kSecClassGenericPassword is actually a private key.

Thank you very much Quinn for your replay! Regarding your question, I don't have too much insight to the server's code, but until now we always sent self-signed certificates and I guess without making some modifications it works only like this. But I'm curios what is in your mind, when you ask about the "certificate that looks like it was issued by a CA"? Do you mean to create a certificate which is shared between the client and the server and to use it to sign our newly generated one?