Originally Web posted 15 April 2013.
Content last modified Sunday, 27 August 2017 .
External links last verified Sunday, 27 August 2017.
The downside to setting up secure email in Tiger versus later versions of OS X is that setup in Tiger is peculiar, quirky, and at some points, illogical. The upside is that, if one is willing to do the crazy dance and once one is all done, secure email works reliably and with minimal fuss in Tiger… something to which later OS X versions often still aspire.
This entire section is based upon, and most of the following steps are taken from, the article Fun with Certificates by James W Walker, without whom we might all still be unable to get secure email in Mail going. Heaps of appreciation to JWW for his pioneering work! My reason for repeating most of his article here is to add points of clarification where i found his original confusing, and to integrate the information into the rest of my site, with coverage of later OS versions.
Fill out thepage. The Certificate Information page is where the associated e-mail address and the certificate name are specified. If you have multiple e-mail addresses, you may find it useful to indicate the e-mail account in the certificate name. For example, if Bob Smith is creating a certificate to sign or encrypt messages from his account email@example.com, he might name the certificate Bob Smith (tester). If you routinely use only one email address/account for secure email, this may not be necessary.
It is probably a good idea to increase the validity period to more than one year. One good choice is 10 years: 3652 days, approximately. The tradeoff: longer is less work for you, yet a longer-term risk of someone getting into your Mac(s) and/or your security credential backup(s) and stealing your master credentials. Shorter minimizes the length of time that a stolen certificate may be valid, but is more work for you to remember to renew (make a new one, basically) before it expires and a lot more work for all your correspondents, who need to renew trust in your new certificate(s).Here’s a screenshot with the absolute minimum number of fields filled out and the default 365 day (one year) validity time span:
You should accept the default settings in the remaining assistant pages. This is important: just accept what is offered unless you know what you’re doing and know that you need to override the defaults. Don’t go looking for trouble.
If you use the Subject Alternate Name extension, you must fill in the same exact, correct email address you entered earlier in the Certificate Information window. On later OS versions, Apple includes this extension by default, and it is Not marked Critical. I suggest following Apple’s lead and leaving the “Make Extension Critical” box unchecked (unless you know beyond any doubt that it is needed for interoperation with a non-Apple system). Again, i find it easier to simply omit this extension, as seen above (Tiger default).
Your public and private keys need no further attention—they’re ready to run. All they need to do is sit there on your system and work.Here’s a view of the new certificate, public key, and private key which were created by Certificate Assistant in the last step:
By the way, since you created the certificate, you might suppose that you could find it more easily in thecategory rather than the category. If you do that, you’ll find that you are unable to export the certificate in the right format.
Note that it appears that it ought to be possible to change the Trust settings of the certificate as it sits in the login keychain, from(or ) to . This is basically how it works in later versions of OS X—but not in Tiger. The implementation appears to be broken… so don’t bother trying.
Also, Mail itself will sometimes offer to trust an unknown certificate… that’s broken too. It works until you quit Mail, but no longer works once Mail is restarted.
For these reasons, even though it appears that other ways of trusting certificates ought to work, in reality they don’t. Don’t bother wasting your time (i already did it for you)… just do this happy dance as described above, and all should work fine.
Now is the time to back up your new certificate, public key, and private key, archive them, or both!
Be sure to back up all three of these new items, ideally together. The private key in particular needs to be preserved—without it, if something goes wrong with the original on your system, you won’t be able to read encrypted email messages sent to you—ever again! If someone else gets ahold of your private key, they’ll be able to read private, encrypted messages sent to you—probably not what you want. If someone else gets ahold of your certificate (or public key, for other systems), it’s no big deal. Still it’s a good idea to have a backup in case you need to put your credentials on multiple machines, or you move to a new Mac.
One might think (or hope) that selecting the three items and dragging and dropping from inside Keychain Access to somewhere out in Finder would work… nope. Works for the certificate only, but not the keys. Even selecting all three items in Keychain Access then choosingfails, in a similar way: a promising-named item is created, but again it is only the certificate.
The best option to preserve these three credential items and keep them together is to create a new keychain and drag copies of them into this new keychain:
Another alternative which i used to use but found out doesn’t work as well is to save each item as a separate entity. If you use this approach, each item needs to be individually selected in Keychain Access, and exported using. For reasons not wholly clear to me, Keychain Access does not allow bundling all three items into one container, and it seems to be strict regarding what options may actually be used. I’ve only had success saving each item individually and in the following formats:
For this last format only, you will be asked for a password, without which you will not be able to open the .p12 file and retrieve your private key. Be sure to choose a suitably strong password to protect your private key, and be certain that you will not lose nor forget this password! Not having the password is effectively the same as no longer having the private key at all.
As discussed in the Sharing One Set of Credentials with Other Machines part of the Points common to all OS versions section of the main article page, one set of email security credentials should be used on all devices you own.
The easiest and possibly best way to do this is to place a copy of the keychain you made with your 3 security credentials on each device and import the items from there. Here’s how it works moving these credentials to a different Mac:
If instead of saving the 3 credential items in a separate keychain you exported each item individually, you will need to usein Keychain Access on each of your backed up/archived .cer, .pem, and .p12 files for the certificate, public key, and private key, respectively.
Due to bugs in Keychain Assistant (and/or the security infrastructure) for OS X all the way from Tiger through Lion, during my testing the certificate went in to the new system just fine, but there was an error message for both the public and private keys:
The private key went in despite this error message; the public key did not. This problem occurs whether i double-click the file in Finder or usewithin Keychain Access. Guess we’d better hope that the public key truly is redundant when importing to Tiger systems!
Open Mail and select New Message. You should see a new pair of icons in the lower right part of the header area, just above the white message body area:
Don’t be concerned right now whether they’re grayed out or black, or whether they’re selected or not (this is all explained in How Secure Email in Mail Works (once everything is set up)). As long as they appear, the setup at your end is complete—Congratulations! You are now ready to exchange certificates with your correspondents.
Secure Email in OS X, Apple Mail The Sonically Pure Pages
This Siber-Sonically Pure Page is and Transitional compliant.