Where are digital certificates physically stored on a Mac OS X machine?

Question

Can someone tell me and maybe link to literature which describes it, where are the digital certificates storage location on Mac OS X? I know I could access the certificates with the “Keychain” application. But where are the certificates stored on the disk? Under Linux they are for example under /etc/ssl/certs but under Mac OS X they are no certificates in this folder.

I read something about that the certificates are stored in a “Keychain File?” Is this right? If yes, could someone explain me the technical details on it.

If someone has detailed literature of this stuff, would be helpfull to link them here. thanks!

Solution

Where are the digital certificates storage location on Mac OS X

Apple's Mac OS X includes a built-in key and password manager, Keychain, which stores user passwords, user and server certificates, and keys.

Source Certificate and Key Management in Mac OS X ^{(Link no longer available)}

---

Where is the Keychain data stored?

The keychain data is stored in ~/Library/Keychains/, /Library/Keychains/, and /Network/Library/Keychains/.

The first location is where my personal keychain is stored. To access their data, I need the Keychain Utility located in the Utilities folder in the Applications folder.

I like using spotlight to access the Keychain Utility as it only takes a few keys to get there – click on the spotlight icon in the top right corner and type “keychain”. Spotlight is quick and will predict what you are looking for and get it on top of the search quickly, so you don’t even need to type the whole word. Once you open it, you have access to your Keychain.

Understanding Local Keychain Files

I will briefly explain the purpose of the most important files in these directories.

/Users//Library/Keychains/login.keychain – This keychain is created when your user account in Mac OS X is created and normally has its password synchronised with your login password. It is unlocked at login and locked a logout. This is where most of your passwords will end up in. Its password is changed when you change your login password or using the Keychain Access utility.

/Users//Library/Keychains/ – UUID stands for Unique User ID – This identifier does not match your OS UUID. It is created when the account is created. This is where your iCloud keychain is stored but if the service is not enabled, it will appear as “Local Items” and be renamed to “iCloud” when the service is enabled. The iCloud keychain service allows passwords and other types of data from it to be synchronised with your other Apple devices like you iPad, iPhone or another Mac. The only requirements are that all these devices are using the same Apple ID account, and the OS supports the iCloud keychain service (Mac OS X 10.9 and above, iOS 7.0.3 and above).

/Library/Keychains/System.keychain – The System keychain stores items that are accessed by the OS and shared between user to allow, for example, everyone on the Mac to be able to connect to a WiFi network. Only administrators can change its content.

/Library/Keychains/FileVaultMaster.keychain – This file is created by the system when FileVault encryption service is enabled on your Mac. The OS manages its content.

/System/Library/Keychains/ – This is another location that can store loads of keychain files. Its content is managed by the system and other application. Most of them will not appear in the Keychain Access utility however, all users benefit from it.

Source Understanding the Mac OS X Keychain ^{(Link updated)} by Ivaylo Mihaylov

---

Further Reading

• Mac OS X - Working with the System Keychain

Comments

[Opa114]

Is there a difference to OS X Server in the certificate store locations or management? On Windows Server there are much more stores etc.

[DavidPostill]

@Opa114 Sorry, I've no idea. Might be a good question for serverfault.com

[Opa114]

thanks for the hint. I aks there if i need more information. Do you have knowledge how the certificate Management on Unix / Linux are?

[DavidPostill]

@Opa114 Not really.