New Platform 12.0.5. Better, stronger, faster. Download or Buy on Drive
Instant access to over 300 free and legal portable apps including the new Firefox Developer (Nov 10, 2014) needs your help: Please donate today

Digital signing in Thunderbird Portable using an account with copied mail produces messages unverifiable by OpenSSL

NickApplenet - January 5, 2012 - 8:54am
Share on Facebook

Environment: Thunderbird Portable 9.0.1 on Windows XP Pro (32 bit).

Thunderbird Portable is run from the local hard drive (not from a USB one).
Thunderbird Portable has been upgraded from earlier versions gradually.


Installed automatically (from TERENA Personal CA) a personal certificate in Firefox Portable 9.0.1. I created certificate backup and imported into Thunderbird Portable (9.0.1), then I enabled in an account signing and encryption using this certificate. The account includes copied mail. Signed messages sent using this account cannot be verified.

THIS PROBLEM DOES NOT OCCUR WITH A FRESH INSTALLATION OF THUNDERBIRD (NOT PORTABLE). It also does not occur with other mail clients (e.g. MS Outlook).

However, using other certificates, like the ones generated here:, we can create verifiable messages. (Edit: This, after subsequent investigation, seems irrelevant. The problem is with the account, not with the certificate.)

Why Thunderbird Portable cannot send a signed mail message which can be verified successfully, when mail folders have been copied (migrated) from elsewhere (another TB installation)? And why this does not happen in Thunderbird (standalone)?

Any advice?


( categories: )

New test showed that this

New test showed that this problem does not occur with a fresh installation of Thunderbird Portable (9.0.1).

Could something in the installation have missed upgrade or got broken during such procedures?

How can I "refresh" (the security library ?) of my gradually upgraded installation of Thunderbird Portable to help avoid this situation?


The problem is with migrated mail!

I have tried multiple times to do a clean TB Portable installation. As soon as I create a new account and import my certificate, I can sign messages and they are successfully verified (by the recipient).

Yet, when I manually copy in the Mail directory of the new account (e.g. in Mail\ all my (many!) mail folders from the respective Mail directory of my current TB installation (note: named differently, e.g. Mail\ in order to do a full migration, everything works, but signed messages fail verification at the recipient end.

It happens like that every time with TB Portable. It does not happen with TB Standard (Normal version). There is no issue there.

Why TB account with all my (older, copied) mail behaves differently than a clean one (in TB portable)?


but as I also use certs with TB, I can try to think what may cause such behaviour.
I have to say first, that for long time the only reliable TB which worked with certs was version 2.x

OK now, certs are tightly coupled with the e-mail identity, that means the name and the e-mail address has to be exactly as stated in the cert. If this goes wrong then results will be bad.

As you say the issue arises first when all parts of the mail folder is imported and not before (!) I would say that one of the mail accounts is picked when signing and in fact it should not.

How many mail accounts do you have in the full mail folder?
Do you have with some accounts more then one identity?

What I would try as next:
have solid backup of all profile etc somewhere
import whole mail folder into the freshly set up TB portable.
Problem will come up

Then delete from that install mail accounts and their respective local folders and identities one by one and see if you can clear the problem.

Also close search in the signed received mail may give some traces as what is going wrong.
First what does the cryptomodule say? Why is it not verified? Is it signed with the right key?
Or is it signed with a key which does not belong to the apparent sender?
Or is it just that the mail was mutilated under way? (Sender and signer are correct, but hash does not correspond)

When you look at the source of the mail, is the sender there exactly corresponding to the data in the certificate used?

Next test:
try mails as plain text only, no fancy formating, here you might see more then when all is obscured by some invisible html formating!

You could also try to disable the certificate signing in some accounts, as you say you have more then one apparently.

>(e.g. in Mail\ all my (many!) mail folders from the respective Mail directory of my current TB installation (note: named differently, e.g. Mail\ in order to do a full migration,<

this will result in two different accounts in the TB.
Now it come to the question which one do you pick when sending and signing a mail?
Apparently it can not be done with both and probably one of the accounts has also different e-mail address.
Note any difference even some kind of hidden space sign in the name of the sneder will make signature invalid.

Otto Sykora
Basel, Switzerland


Thanks for the reply.

Let's see the steps one by one:

1. I do a clean TB Portable install.

2. I create an account (POP) and I import a personal certificate. So TB now has one account only with one identity only.

3. I send signed messages from that account without problems, and they are verifiable from the recipient. (Expected behavior)

4. The above account TB Mail folder is:
The folder contains:

11/01/2012  07:54 μμ              .
11/01/2012  07:54 μμ              ..
11/01/2012  02:53 μμ                 0 Inbox
11/01/2012  07:53 μμ             2.179 Inbox.msf
11/01/2012  07:52 μμ            22.476 Sent
11/01/2012  07:54 μμ             3.732 Sent.msf
11/01/2012  02:53 μμ                 0 Trash
11/01/2012  03:28 μμ             1.337 Trash.msf
               6 File(s)         29.724 bytes

5. Now I delete the above files and I copy my mail folders from my current installation. Here is the new content:

11/01/2012  08:08 μμ              .
11/01/2012  08:08 μμ              ..
31/03/2011  08:05 πμ                 0 Archives
11/01/2012  10:34 πμ             2.970 Archives.msf
11/01/2012  10:21 πμ              Archives.sbd
15/11/2011  11:16 πμ           191.555 Bind-DLZ
11/01/2012  10:08 μμ            16.275 Bind-DLZ.msf
10/12/2010  09:31 μμ       181.394.656 Clips 1
23/10/2011  12:26 μμ            42.029 Clips 1.msf
12/01/2012  08:51 πμ        90.493.348 Cron Jobs
12/01/2012  08:51 πμ         1.084.926 Cron Jobs.msf
11/01/2012  07:49 μμ             4.109 dir.txt
11/01/2012  08:13 μμ             1.498 dir.txt.msf
10/12/2010  09:29 μμ        13.487.286 Documents
23/10/2011  12:20 μμ             4.135 Documents.msf
12/01/2012  08:51 πμ        27.013.956 Dovecot
12/01/2012  08:51 πμ         4.871.311 Dovecot.msf
12/01/2012  10:13 πμ        26.263.673 Drafts
12/01/2012  10:16 πμ           517.063 Drafts.msf
10/12/2010  09:29 μμ        51.682.632 DS
19/12/2011  10:12 μμ             8.509 DS.msf
19/11/2008  02:02 μμ                 0 Faxes
22/12/2011  04:11 μμ             3.368 Faxes.msf
12/11/2008  09:43 πμ                80 filterlog.html
11/01/2012  11:32 μμ         6.647.920 horde
11/01/2012  11:34 μμ           892.597 horde.msf
12/01/2012  10:28 πμ     2.337.282.112 Inbox
12/01/2012  10:29 πμ        11.486.118 Inbox.msf
11/01/2012  10:21 πμ              Inbox.sbd
20/07/2010  02:43 μμ            31.375 Infected Items
22/12/2011  01:00 μμ             3.781 Infected Items.msf
12/01/2012  08:51 πμ       107.370.152 IronPort Reporting
12/01/2012  08:51 πμ           227.638 IronPort Reporting.msf
12/01/2012  09:09 πμ         7.315.633 Junk
12/01/2012  10:35 πμ            21.926 Junk.msf
12/01/2012  08:51 πμ        18.125.618 Logwatch
12/01/2012  10:10 πμ         3.171.763 Logwatch.msf
12/01/2012  10:11 πμ           412.290 Maia
12/01/2012  10:11 πμ            35.762 Maia.msf
12/01/2012  08:51 πμ        43.295.579 Mondo
12/01/2012  08:52 πμ           982.186 Mondo.msf
02/01/2012  10:31 πμ             3.182 msgFilterRules.dat
02/09/2003  05:48 μμ                 0 n@eo
09/10/2011  01:33 μμ             3.275 n@eo.msf
11/01/2012  10:21 πμ              n@eo.sbd
10/01/2012  11:00 πμ         3.314.850 NetDisco
11/01/2012  10:34 πμ           277.215 NetDisco.msf
10/06/2011  10:55 μμ        17.405.395 Network
21/12/2011  04:47 μμ             8.415 Network.msf
11/01/2012  07:23 μμ           656.226 nfsen
11/01/2012  08:08 μμ            30.868 nfsen.msf
11/01/2012  12:23 πμ           647.322 OpenDKIM
11/01/2012  12:26 πμ            86.013 OpenDKIM.msf
09/04/2011  10:47 πμ            70.673 OpUtils
11/01/2012  12:22 πμ            13.020 OpUtils.msf
12/01/2012  09:09 πμ         8.883.398 Pdns
12/01/2012  09:09 πμ         1.318.409 Pdns.msf
30/12/2011  04:09 μμ       188.003.418 Photos
30/12/2011  04:09 μμ            35.016 Photos.msf
12/01/2012  08:51 πμ            20.639 popstate.dat
12/01/2012  08:51 πμ        58.104.474 Postfix
12/01/2012  10:10 πμ         6.298.864 Postfix.msf
11/01/2012  08:31 μμ         4.222.127 ProFTPd
11/01/2012  09:37 μμ           313.430 ProFTPd.msf
10/12/2010  09:30 μμ        20.389.369 Promo
07/10/2011  11:15 μμ             5.549 Promo.msf
11/01/2012  08:23 μμ       717.661.083 Sent
11/01/2012  09:42 μμ         4.208.575 Sent.msf
24/10/2011  10:10 πμ         1.965.419 Squid
11/01/2012  10:34 πμ           318.936 Squid.msf
12/01/2012  10:12 πμ           766.607 Squirrelmail
12/01/2012  10:12 πμ            30.185 Squirrelmail.msf
01/08/2003  10:17 πμ                 0 Templates
11/01/2012  10:34 πμ             2.503 Templates.msf
12/01/2012  10:11 πμ         6.807.691 Trash
11/01/2012  06:03 μμ            74.571 Trash.msf
29/11/2011  12:22 μμ                 0 work folder
05/12/2011  08:44 μμ             2.641 work folder.msf
              73 File(s)  3.976.335.187 bytes

6. Now we have the initial clean installation, with the initial one account, its certificate and the same (one) identity; the only difference is that we have replaced mail folders/files. The certificate is always the same, the account sender address still matches one of the email addresses included in the Certificate's Subject Alt Name Extension.

7. Now, I send signed messages from this account and they cannot be verified at the recipient end. (Verification fails.)

8. If I follow the same steps in Thunderbird standalone, this issue does not occur. I can still send signed messages after having copied the above mail folders/files, and they are verified successfully by the recipient.

9. In all tests I send ISO-8859-1 messages to avoid charset issues.

10. When I receive one of such signed messages (bcc'd) to my own TB Portable (the one that send the message), TB does not give any indication that there is a verification problem. The cert is the right one, the mail sender address matches one of the addresses in the Certificate Subject Alt Name extension. (Note: There is no E attribute in the Certificate Subject.) TB's "Message Security" box displays as the email address the first of those included in the Certificate Subject Alt Name and shows the message: "This message includes a valid digital signature. The message has not been altered since it was sent." Yet, ALL RECIPIENTS (except me) cannot verify the message successfully.

I repeat that this issue does not occur, if the above steps are followed in a TB standalone installation. It only occurs with TB Portable.

11. For example, here is a verification effort on a linux mail server (upon a signed message I sent, lying in an IMAP mailbox of a recipient):

# openssl smime -verify -in,S=9156,W=9298:2,S -CAfile /etc/pki/CA/certs/ca-bundle.crt
Verification failure
31565:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:245:Verify error:unsupported certificate purpose

I repeat that my TB Portable seems to be verifying the message correctly!

12. By contrast, here is a successfully verified message:

# openssl smime -verify -in,S=7699,W=7820:2,S -CAfile /etc/pki/CA/certs/ca-bundle.crt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

test on TB standalone after copying mail folders

Verification successful

I hope the above can help in resolving this issue.


still confusing

but, you state that you can verify well your copy.

Now it would be nice to know what does the recipients client refuse or what it claims is wrong?

Can you receive with some other computer, other address etc?

Is the message mutilated or does the account not match? This has to be found out now as next.

Then as I said, I would delete the accounts one by one and see if the things improve. It still can be that one of the added accounts is interfering somehow.

Also check the ability to send all in plain text in contrary to html etc.

Check the formating of each account, particularly where same name etc is used.

what operating system and what mail client is on the other side?

you can also try to contact me via myusername(at)usa(dot)net
then we can exchange public keys and I will try to verify with more then one client.

Otto Sykora
Basel, Switzerland

cert purpose

>Verify error:unsupported certificate purpose<

in the error msg, well this would mean that you have either kind of twin certificate, which exists often now and the wrong one is picked by the sign mechanism as only one within a twin cert has mail signing enabled, the other is in general only for authentication purposes.

But wyh it is picked here and not with the standard install is still not clear.

Otto Sykora
Basel, Switzerland

The problem is (partly) with OpenSSL

I have confirmed that the problem occurs only when I send mail from a TB Portable account with migrated/copied folders/mails (as I described above) AND ONLY when the recipient is checking the mail using OpenSSL.

So, if the recipient is verifying with Thunderbird (any version) on Windows or Outlook, verification works fine.

However, if the recipient is verifying using OpenSSL directly (command line) or indirectly (e.g. in Thunderbird/Linux or in Squirrelmail with SMIME plugin or in Horde with S/MIME enabled), then verification fails.

I can't explain this behavior, but that is what's happening!

(I'll send a direct mail as well for testing).


Solved without tracing the problem

Following ottosykora's advice, I deleted ALL cert selections from the security settings of ALL accounts, then deleted ALL my personal certificates themselves.

Finally, I deleted the file cert8.db.

Then I re-imported my key pair and configured the security settings (cert selections) in the involved account.

Thus, signing works well at last.

After MANY hours of testing, I still can't tell exactly what causes things to break.