iOS 5 – S/MIME certificate deletion bug

June 30

This article discloses a potential security bug in the X.509 certificate management in iOS 5. The bottom line is the following. An imported X.509 certificate stays forever in the iOS keychain and is used for S/MIME encryption by the Mail client. In other words, even after the manual deletion of the certificate via the system preferences, iOS keeps using it and there is nothing the user can do about it.

Here are the steps which illustrate this behavior. This is actually a normal use case of an e-mail encryption scenario. No need for special manipulation to reproduce the bug.

Step one: Configure Mail to use S/MIME for encryption (not described here) and start composing an e-mail to a recipient whose certificate is not yet imported. The external recipient will be in the rest of this article my personal gmail address At this point, Mail reports correctly that the S/MIME encryption is not possible.

MIME encryption in iPhone

Step two: I import the recipient’s certificate (simply open a link which points to a certificate in the iPhone’s Safari or let it email yourself as attachment).

Certificate profile in iPhone

After clicking on “install”, you have to confirm the “Install Profile” dialog.

Step three: Open the Mail app again and start composing to the same recipient. This time, again as expected, the Mail App finds the certificate that we’ve just imported and uses it for S/MIME encryption.


Email encryption in iPhone

At this point, we have our Mail client set up for a S/MIME encrypted communication with our recipient. So far so good, no bugs until here.

Step four: removing the certificate. There are many reasons why we want to do that such as
– temporarily disable encryption to this recipient
– the recipient revoked his certificate and it should not be used anymore!
– we have initially imported a wrong certificate
– …

To delete the profile, go to Settings >; General >; Profiles, chose the one you want to remove and confirm the deletion.


Delete certificate from iPhone

So now, one would think that the recipient’s certificate is gone from the system. It’s here where the troubles start.

If you open Mail and start composing an e-mail to the same recipient, you’ll notice that Mail still shows the blue lock indicating S/MIME encryption. Didn’t we just deleted it?

I initially thought that the Mail app was somehow intelligent and that it was looking into the received signed messages to eventually grab the certificate from there (a S/MIME signature contains the certificate of the signer).

I ended up deleting all signed messages but the blue lock was still there, even after removing and setting up again the entire e-mail account.

Apple’s lack of user documentation about S/MIME and the forums didn’t help either so I decided to go the low-level way: decrypt and dump the iOS Keychain.

After some quick Googleing, I ended up reading all the articles of this blog. They are all very interesting.

The one relevant for our case is the Keychain Dumper that I used to list the certificates contained in the keychain (option -c). Here follows the listings made during the different steps

Step one (before any certificate import), no trace of the recipient’s certificate (look for the e-mail address)

After the certificate import (Step two)

iPhone:~ root# ./keychain_dumper -c

Entitlement Group:
Serial Number: ;
Subject Key ID: ;
Subject Key Hash:;

Entitlement Group:
Label: 786EE64B-A38F-4042-8C03-XXXXX
Serial Number: ;
Subject Key ID: ;
Subject Key Hash:;


Here you can see that an e-mail certificate is imported to two different Entitlement Groups. Long story short, the “Entitlement Group” is basically an ID of the application which can access the keychain item. More info here or in the Apple’s recent iOS Security document (section Keychain Data Protection)

Step four (after certificate removal)

iPhone:~ root# ./keychain_dumper -c

Entitlement Group:
Serial Number: ;
Subject Key ID: ;
Subject Key Hash:;


Here we can see that even after the removal via the System app, there is still one certificate keychain entry .. with the “” entitlement group …

There is another way to double check it: list the SQLite keychain database with a SQL statement that basically counts all the certificate entries in the keychain.

Before any certificate import (Step one)

iPhone:~ root# sqlite3 /var/Keychains/keychain-2.db "select count(*) from cert;"
<strong>18 </strong>

18 is the total number of all certificates present on my iPhone before the import. Note that this number includes certificates used for other purposes than S/MIME.

After the certificate import (Step two):

iPhone:~ root# sqlite3 /var/Keychains/keychain-2.db "select count(*) from cert;"
<strong>20 </strong>

.. Here we go with two entries added: 20 certificates

Step four (after certificate removal):

iPhone:~ root# sqlite3 /var/Keychains/keychain-2.db "select count(*) from cert;"

19 … which confirms that only one of the two entries was deleted.

So iOS 5 does not delete the certificates as the user thinks. If I missed a hidden option somewhere or if there is a documentation which states that this behavior is wanted, please let me know and ignore this article. I’d be surprised though.

To conclude, the question to ask is how bad this is.

In my opinion, a good management of the PKI is a key to a strong security. Things are secure or they are not. There is no halfway. In this case, the Mail client ends up in a situation where it keeps using a certificate explicitly removed by the iOS user. If the recipient’s private key has been for example compromised you will end up exposing confidential information.

This problem was identified by Tex-Twil and I just helped him in providing the steps to confirm it.

Note: This article is written by Tex-Twil who is working as software engineer in the e-mail security branch. I am just publishing his work 🙂


Posted by on June 30, 2012 in iPhone


Tags: , , ,

3 responses to “iOS 5 – S/MIME certificate deletion bug

  1. Alberto

    July 11, 2012 at 1:05 am

    Great post. I observed this behavior too, when playing with s/mime some weeks ago. I seem to remember that you can get rid of the certificate also removing it via a message signed by the certificate owner (touching the sender’s name and then Remove). The point you made still holds, however, because the procedure is far from intuitive.

  2. Tex-Twil

    July 16, 2012 at 5:46 pm

    @Alberto, your workaround seems to work. It is, as you said, far from being intuitive but it seems the only way to actually remove the certificate without hacking with the keychain.

    Thanks for your feedback. I’ll ask Satish to update the article with your workaround.

  3. Alberto

    July 20, 2012 at 11:57 pm

    Many thanks, Tex-Twil. A little note. You will probably have noticed that in my reply I missed a step in the description of the procedure to remove a certificate through a signed message. The three steps obviously are: (a) touch the sender’s name, (b) touch the View Certificate button, (c) touch the Remove button.