When I upgraded my production Mac, one of my standard procedures was to copy across its login keychain to the replacement, so I could open it to check any passwords that didn’t carry over correctly, or copy certificates the new Mac required. This was easy to do by adding the old keychain to the list in Keychain Access, and providing its password when I needed to access it.
Since then, keychains have become more complex, with the newer and more secure iCloud Keychain taking over much of the work that had previously been done by the login keychain. Add in passkeys, which can’t be stored in the login keychain, and its main purpose now is to keep my Apple developer signing certificates.
Keychain mobility
Rich Trouton, in his Der Flounder blog, has recently reported that trick with old login keychains no longer works in Tahoe with Macs with Secure Enclaves, because unlocking a keychain on those now involves a secret kept within their Secure Enclave. When you’re prompted to enter your password to gain access to protected contents in that keychain, you enter the correct password but it’s refused, and there’s no way of obtaining access. This makes copying keychains between Macs worthless.
I have confirmed that a login.keychain-db copied from my Mac mini M4 Pro to a virtual machine (VM) running macOS Tahoe 26.6.2 cannot reveal any of its secrets to the Keychain Access app on the VM, as it refuses to accept the valid password. Not only that, but Keychain Access running in a VM cannot access the login.keychain-db keychain copied from another Tahoe VM, although neither has been anywhere near a Secure Enclave.
If you intend migrating manually between Macs, don’t waste time trying to copy across the login keychain, as it’s not likely to work, and its secrets will remain.
Migration
That raises the question of whether this also affects migration performed by Migration Assistant, so I performed test migrations between VMs, and demonstrated that Migration Assistant does copy the contents of the login keychain successfully to the destination Mac.
I seeded the login keychain in a source VM running Tahoe 26.6.2 with passwords and an ad hoc signing certificate, then used that as the ‘server’ for migration to a first-run destination VM also running 26.6.2. Once the migration was completed, the login keychain on the destination contained the seeds, which were fully accessible there. I also repeated this for a migration from the same Tahoe source and a first-run destination VM running Golden Gate 27.0 RC, which was equally successful.
The most reliable way to migrate login keychain contents is using Migration Assistant.
Upgrading VMs using migration
Normally I update macOS in my library of VMs used with Viable, ViableS and Vimy by duplicating them in the Finder to produce a clone, updating that clone, then discarding the original. When it comes to upgrades like Golden Gate, that procedure can work, but may not support new virtualisation features brought by the new macOS. However, setting up a new VM can be tedious, so a better solution is to migrate to it from an older VM.
This is surprisingly straightforward if the virtualiser you’re using supports running two macOS VMs simultaneously, and can set their network MAC addresses manually, as my apps can. Your host Mac also needs sufficient CPU cores and memory to give each a healthy minimum of 3 cores and 12 GB of memory.
The key step in this is to configure and run the two VMs using different MAC addresses, otherwise the migration is doomed to fail. For the tests above I set my ‘server’ VM up with the default MAC address of d6:a7:58:8e:78:d4, and the ‘client’ with d6:a7:58:8e:79:d4. The best time to perform the migration is during the first run of the new VM. I gave a full account of the procedure last year. You can also use this to create multiple VMs preconfigured with apps and custom settings.
The best way to build a new Golden Gate VM matching a Tahoe VM is to migrate between them.
Summary
- If you intend migrating manually between Macs in Tahoe and later, don’t try copying across the login keychain, as it’s unlikely to work.
- The most reliable way to migrate login keychain contents is using Migration Assistant.
- The best way to build a new Golden Gate VM matching a Tahoe VM is to migrate between them.
The Eclectic Light Company 