Sending and Receiving S/MIME Encrypted Email on iOS 5 (Beta)
My last post on the topic of S/MIME on iOS 5 got a lot of helpful comments from readers filled in the gaps left by Apple’s current lack of documentation on this topic. The previous article is still the best place for information on how to set up your device to use S/MIME. This post has more information on actually using S/MIME for encrypting email messages.
Enabling S/MIME
There’s a setting I missed in the previous post was pointed out by a commenter. After getting iOS 5 on the device and putting your certificates on there, you need to edit your email settings. Click Settings->Mail, Contacts, Calendars->Your email account->Account->Advanced. Scroll down to the S/MIME section and turn on S/MIME. (Note that this wasn’t required in order to read S/MIME encrypted email.) Enabling S/MIME causes two new options to appear, Sign and Encrypt. Selecting these will cause your iOS device to try and sign and/or encrypt each outgoing message. Make sure you enable the Encrypt option at this point to make your iOS device attempt to encrypt outgoing messages when possible.
Immediately below the S/MIME section is a section called Certificates, which contains the certificates for which your device has private keys. You can select one of these certificates (clicking it puts a checkmark next to it) and this is the certificate that will be used to sign all outgoing messages (if you’ve turned on signing). Note: you can select certificates that are not valid for the digitalSignature key usage value. I submitted a bug report (ID 9601006) to Apple about this today.
Sending Encrypted Email With Exchange
If you are connecting to a Microsoft Exchange Outlook Web Access server, and you have an enterprise public key infrastructure that publishes encryption certificates to users’ global address list (GAL) entries, you are in luck. Sending encrypted email could not be easier.
Simply enable the account and ensure Contact syncing is being performed for the account for email and enable S/MIME (thanks, Allan). When you choose a contact, the iOS device will automatically attempt to download the recipient’s certificate from the GAL. If it considers it valid, you will see a lock icon displayed next to the “To” address like this:
If it can’t find a valid certificate for your recipient, you’ll see something more like this:
Sending Encrypted Email Without Exchange
If you are not connecting to Exchange, there will need to be a bit more manual process to get certificates on to your device. If you’ve used S/MIME at all, you’re likely familiar with the “send me a signed email so I can send you an encrypted email” dance. iOS 5 is no exception. In order to send encrypted emails to recipients you will need their certificates, and as far as I can tell the only way to make that happen (aside from using Exchange) is through an exchange of signed emails.
Once your desired recipient has sent you a signed email, if the iOS device trusts the certificate used to sign it, you will see their name in the From field appear like this:
If your device doesn’t trust them, it will look more like this:
Click the sender’s name. If they are untrusted, you will see a reason why, and have a “Trust” button available to you to choose to trust this certificate from now on. In either case, you will see a “View Certificate” button. Click it.
Click the “Install” button to install this certificate to your iOS device. Now when you reply to the sender’s email (or send them emails in the future), you will see a lock by their name indicating you will be encrypting the email to that individual.
Hopeful Future Improvements
I’d like to see some improvements. I’m filing bug reports with Apple on each of these items, and I hope others will too.
First thing would be an improvement to the signing certificate selection, enabling you to (a) not choose encryption certificates for signing, and (b) make it clear what that selection is for anyway. The certificate selection option is enabled even when you choose Encrypt, which makes the setting user interface very confusing. (On a related note, on my device I could not see a Key Usage value for any certificate by looking at its details. I have also filed this as a bug.)
The second thing would be a capability to import certificates into the device which does not require Exchange or the signed email dance. I created a configuration profile containing public certificates for every user at my company. Unfortunately, iOS Mail did not have the capability to use these certificates for sending encrypted email. In fact, iOS could not even send me an encrypted email until I first sent the device a signed email and imported it, even though my encryption certificate was on the device being used to read encrypted emails. Hopefully Apple will improve this in a future release.
Lastly, there should be a way to look in the contacts of the device to determine whether or not you have a (valid) encryption certificate for a user. If I am going to leave on a trip but I know I want to interact with a few people using encryption, I won’t know until I try to send them an email. The Address Book feature on my Mac already has this, it displays a little checkmark next to email addresses I can encrypt to.
Again, please let me know if you have any additional suggestions or feedback by entering a comment below!
6 thoughts on “Sending and Receiving S/MIME Encrypted Email on iOS 5 (Beta)”
Regarding GAL – you don’t need to enable contact syncing on your account in order to make use of it. You can leave contact sync off and still find recipients on GAL when composing an email, and still get the encryption certificates for recipients if available.
When sending encrypted mail, the mail program needs an identity to use to encrypt the message so that you can read your own outgoing encrypted mail. Mac OS X chooses the identity to use automatically by searching the keychain for one with an email address matching the address you are sending mail from. That’s nice but if you have two identities for the same email address, you don’t get to choose which one is used. On iOS, the identity you’re using for signing/encryption is marked explicitly in the “Certificates” list. This is why the certificate selection UI is still available even if you are only encrypting and not signing. It dictates which identity you need to use to decrypt your own outgoing encrypted mail.
@Allan thanks for the info about the GAL. I’ll make a note.
Regarding the choice of certificates, I have a bit of a difference of opinion. Only if there are multiple certificates for which the keyEncipherment key usage is enabled should there be a choice of certificate for encryption. It shouldn’t let you choose anything else, and in most cases I doubt there would be multiple choices. Likewise for signing certificate, it should only let you choose certificates with the digitalSignature key usage. It should somehow indicate (in both cases) which of the certificates you have that have an email address corresponding to the one in the email account you’re doing the settings for.
All that said, the UI doesn’t show two choices of certificate, so if I select Sign _and_ Encrypt, what is the chosen certificate used for? Both purposes? I think it still needs some work… but I can’t tell you how happy I am to be nitpicking about getting this feature exactly right instead of complaining about how it will never be possible!
As of iOS 5 Beta 4, the signing/encryption UI are grayed by default for Exchange accounts (even Google Sync), the settings before the update are enabled but grayed, iCloud @me account does not have this issue.
i have 3 configured emails each with a certificate issued by COMODO, signing was not working before beta 4 (an smime.p7s file was parsed as an attachment), now with beta4 signature is working.
about certificate publishing to GAL, you can even manually publish your own 3rd party certificate to exchange GAL using outlook ‘publish to GAL’ button in Trust Center(http://support.sherweb.com/Images/Image/1178).
I’m not a developer but I have iOS 5 beta 4 on an iPhone 4. Two things I noticed. Contrary to what Saad OUACHE experienced above signing only using a COMODO cert with a gmail account does not work properly. Maybe, I’m doing something wrong but I don’t think so. It attaches an smile.p7s. Signing and encrypting emails does work properly though. However, I think Apple needs to enhance the ui to select, per email, whether to sign and or encrypt jet like in mail. I can’t open a bug report or I would give feedback to apple.
Comments are closed.