a glob of nerdishness

October 20, 2011

Creating a self-signed S/MIME certificate for Mac and iOS 5 email

written by natevw @ 12:43 pm

Today I needed to send some passwords to someone over the internet again. The recipient recommended using PGP/GPG to send an encrypted email, but unfortunately that protocol appears to be quite a hacky hassle if you use the built-in email clients on Apple’s (and apparently Microsoft’s) platforms.

Fortunately, iOS 5 just added support for a more standard protocol called S/MIME, and so I had recently come across a nice article on setting up secure email on both Mac OS X and iOS 5. Since I mostly want S/MIME for email encryption rather than signing (there’s a good overview of the distinction on its Wikipedia article) I decided to just create a self-signed pair rather than procuring a certificate from some annoying, overpaid and insecure centralized certificate “authority” as that article recommends.

Creating a self-signed S/MIME certificate is actually very quick and relatively easy using the Keychain app that comes with Mac OS X, but I wanted to document the process as getting a certificate that Mail recognizes did require overriding at least one of the assistant’s defaults:

Update: Turns out Mozilla Thunderbird will not accept the certificates generated through this process. I’ve had success by creating a standalone personal certificate authority and then using that to sign a user-only certificate. I need to test it a bit more before writing it up here, but it might be a bit simpler process in the end.

  1. In the Keychain utility application’s menu, choose “Create a Certificate…”:
    Self-signed S/MIME certificate creation, figure 1
  2. I had to override the defaults primarily so I could include my email address necessary for Mail.app to use it:
    Self-signed S/MIME certificate creation, figure 2
  3. Confirm that self-signed is okay
  4. I just accepted the default serial number (1) and validity period (365 days)
  5. Then the part where you enter (at least) the email address you want to use this certificate with:
    Self-signed S/MIME certificate creation, figure 3
  6. For the actual keypair, I went with DSA mostly just because:
    Self-signed S/MIME certificate creation, figure 4
  7. I unchecked all the certificate metadata stuff in the next 4 steps, you can try playing with it but didn’t seem worth the complication:
    Self-signed S/MIME certificate creation, figure 5
  8. Then just have the assistant create it in your login keychain unless you have some different setup. It will take a bit to generate the keypair.
  9. Once it’s created you’ll need to find the certificate and double click it…
    Self-signed S/MIME certificate creation, figure 6
  10. …so that you can manually trust it for at least S/MIME:
    Self-signed S/MIME certificate creation, figure 7

Once you’ve done that, you’ve taken care of the “The Certificate” step and can just follow the rest of the instructions in Ars Technica’s “How to secure your e-mail under Mac OS X and iOS 5 with S/MIME” article using the certificate you created instead of one from some corporation.

There is one major drawback to a self-signed (decentralized) certificate. As you’ve seen yourself after creating your certificate, it will not be trusted by default — only several dozen corporations and governments and rogue nations are trusted to forge certificates; you are not on any platform’s pre-approved issuer list. So: after you give your public key to your email contacts (as will be necessary for them to decrypt your messages) they will have to repeat steps 9 and 10 above to manually trust your self-signed certificate on their own machine.

October 15, 2011


written by natevw @ 8:46 pm

I didn’t get a chance to meet Steve Jobs, and I’m not sure I ever will.

I hadn’t thought to be an audience for Dennis Ritchie until now, and — that chance is gone too.

But I have been privileged in recent years to meet many others: through Seattle Xcoders, at DjangoCon, NodeConf, at CouchConf, in the Tri-Cities and during this week’s visit to Portland.

It would feel like name-dropping to compile the “have met” list here, and honestly, these people have been unanimously surprised to hear that I’d been wanting to meet them in the first place.

It’s an honor to meet so many human heroes and be honored as a human back. To learn to listen better and learn better from them. To hope that I might have something someday to share back, technically or socially or spiritually?

I’m becoming less and less of an independent developer and finding more and more that “indie” should never mean “lonely”. No matter how fast or far the trail, there are many to share it with.

That’s a part of our vision at &yet, and a part of the reason we’re hosting a conference next month. A good conference isn’t to parade heroes or meet new contacts, but to be community.

I have to admit I’m excited to meet more amazing people and to talk again personally with online contacts next month. But I’m also glad that the theme of the conference, Keeping It Realtime, is not about one technology that’s pulling ahead. It’s about a tactic that many technologies in the lead share.

Seems like a heroic strategy to me, as far as those go.