Seeing this problem with Xcode Version 15.2 (15C500b).

There’s no API to get the user-visible name for a keychain. For a file-based keychain one typically shows the file name. I usually do this by getting the localizedNameKey property. I don’t think that’ll hide the extension by default, so you’ll want to drop the extension first. Will try this. It doesn’t. Keychain Access is built in to macOS and, as such, it can do things that a third-party app can’t do. Is it true to say that the iCloud keychain (the one visible in Keychain Access, not private groups defined by SecAccessControl) is hidden from all 3rd party apps? The end goal is to add keychain support to Redwax Tool at https://redwax.eu/rt/, which reads certificates and keys from all the places, matches them all up in ways you define, and then writes them back to all the places. It seems that supporting anything other than file based keychains is not possible.

So SecKeychainCopyDomainSearchList takes a SecPreferencesDomain, which is an enumeration of user, system, common and dynamic. If I start with user, I get one entry back: <SecKeychain 0x101604b70 [0x7ff84e723800]> I only appear to be able to get the path of this SecKeychain with SecKeychainGetPath, which gives me what looks like a path on the filesystem like this: /Users/minfrin/Library/Keychains/login.keychain-db How do I get the name "login" from the above, do I have to parse the filename? That doesn't make sense for keychains not backed by a file, I feel like I a missing an API call or an attribute I should be requesting for the name, the docs say nothing on this. The system enumeration gives me one keychain, with a path as follows: /Library/Keychains/System.keychain The common enumeration gives me the same as the system enumeration, but I can't see any explanation as to why: /Library/Keychains/System.keychain The dynamic enumeration gives me nothing (not tried it with any smartcards plugged in). How does this map onto the Keychain Access application? Neither "iCloud" nor "System Roots" appear anywhere as keychains, are these handled as special cases? Where do their names "iCloud" and "System Roots" come from, are they returned by an API or are they hardcoded? What is the correct way to query iCloud as a keychain using SecItemCopyMatching?

Through experimentation I have worked out that exporting the public key as follows will generate a SubjectPublicKeyInfo: err = SecItemExport(keyref, kSecFormatOpenSSL, 0, NULL, &der);

There is a search parameter to SecItemCopyMatching() - pass value of kSecAttrKeyClassPublic into the key kSecAttrKeyClass and you get public keys. CFStringRef dictkeys[] = { kSecClass, kSecMatchLimit, kSecAttrKeyClass, kSecReturnRef, }; CFTypeRef dictvalues[] = { kSecClassKey, kSecMatchLimitAll, kSecAttrKeyClassPublic, kCFBooleanTrue, }; CFDictionaryRef query = CFDictionaryCreate( NULL, (const void **) dictkeys, dictvalues, sizeof(dictkeys) / sizeof(dictkeys[0]), &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks ); OSStatus err = SecItemCopyMatching(query, &keys);

SecIdentityCreateWithCertificate() is the secret for MacOS thank you. In this case, the certificate created with SecCertificateCreateWithData() is passed into SecIdentityCreateWithCertificate(), and you get a SecIdentityRef that you can extract the key from. Getting the key exported is the next problem, SecKeyCopyExternalRepresentation's output format isn't well defined. Subject for a different post.

The code that needs to do this is the Redwax Tool at https://redwax.eu/rt/, which does universal certificate and key handling between different systems. SecKeyCopyAttributes() doesn't work in this case, because when the key you are trying to find the class of is a private key, you have to unlock the keychain for this key before keychain will tell you this is a private key, and the whole point is to not unlock private keys that are unrelated to the task - a chicken and egg problem. This gives a terrible user experience as the user is asked to unlock every key one by one. One possible way around this is if there was a search parameter to SecItemCopyMatching() that allows you to restrict the class to kSecAttrKeyClassPublic, but this too appears not possible / undocumented. What I'm looking for are the public keys that keychain has, so I can match them up with certs on the outside, which will then trigger an attempt to unlock the private keys that are relevant and no others.

Lots of digging, stumbled on something that said that kSecAttrPublicKeyHash in the certificate is supposed to match kSecAttrApplicationLabel on the key. It does not however appear possible to retrieve kSecAttrPublicKeyHash from a certificate. The function this is set in is defined below, but appears to be a private API. https://github.com/apple-opensource/Security/blob/5e9101b3bd1fb096bae4f40e79d50426ba1db8e9/OSX/sec/Security/SecCertificate.c#L5627 In theory I could emulate this code with SecCertificateCopyKey() and SecSHA1DigestCreate(), but this would then break as soon as Apple used a digest other than SHA1. Am I missing something, or is this a bug?

I think I am having the same issue with a Safari Web Extension. The window appears, but nothing interactive works - it cannot be sized, a splitview cannot be moved, etc. Did you ever get to the bottom of this?

Five months later, anyone making Safari Web Extensions?

I am seeing the same problem in Safari 14.1.2 for Big Sur.