SecKeychainGetStatus returns varying errors after SecKeychainOpen succeeds on macOS 26.6.2

Question

Created 2w

Replies 1

Boosts 0

Participants 2

Hi, so far i've been using the following API Call Sequence in order to check the keychain status prior to using one of the certificates inside the keychain for signing or verifying remote tls connection.

// Step 1: Open keychain
SecKeychainRef keychain = nil;
OSStatus status = SecKeychainOpen(keychainPath, &keychain);
// Result: errSecSuccess (0) — always succeeds, returns valid ref

// Step 2: Get keychain status
SecKeychainStatus keychainStatus = 0;
status = SecKeychainGetStatus(keychain, &keychainStatus);
// Result: FAILS : see table below

I observed SecKeychainGetStatus return errSecInternalError or errSecInvalidHandle

│    Process │  Keychain                                               │        Error                    │  Code  │
│ GUI App │ login.keychain.                                       |  errSecInternalError    │ -26276 │
│ GUI App │ login.keychain                                        |  errSecInvalidHandle  │ -25308 │
│ GUI App │ /Library/Keychains/System.keychain   |  errSecInvalidHandle  │ -25308 │
│ Daemon │ /Library/Keychains/System.keychain │ errSecInvalidHandle  │ -25308 │

SecKeychainOpen always returns errSecSuccess with a non-null SecKeychainRef
SecKeychainGetStatus fails immediately when called on that reference
The error for login.keychain varies between calls (not deterministic)
The error for System.keychain is consistently errSecInvalidHandle
Issue is 100% reproducible. every keychain access attempt fails
Started immediately after macOS 26.6.2 upgrade

Do you know if there were any changes in 26.6.2 that could have caused this behavior? If this is expected, how should I address it?

Thanks

Answer 1

DTS Engineer OP

Apple

2w

There have been significant keychain changes to the file-based keychain starting in macOS 26.4, but I’m not aware of any that would cause this specific problem. You should feel free to file a bug about it. However, be aware that the file-based keychain is effectively deprecated, and SecKeychainGetStatus itself is officially deprecated, which might limit the traction it gets.

If you do file a bug, please post your bug number, just for the record.

Taking a step back, I’m not sure why you’re doing any of this. Your table in your posts lists this combination:

| Process | Keychain                           |
| ------- | --------                           |
| GUI App | login.keychain                     |
| GUI App | login.keychain                     |
| GUI App | /Library/Keychains/System.keychain |
| Daemon  | /Library/Keychains/System.keychain |

All of those combinations are valid, which is great. However, none of those combinations need you to explicitly open the keychain. The relevant keychain should be open, present in the search list, and unlocked, all by default.

So why are you opening the keychain at all?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"