What certificate authorities are trusted by default to issue individual email certificates for s/mime?
e.g. CN = COMODO SHA-256 Client Authentication and Secure Email CA
Wšykne wótegrona (7)
Comodo is one of them.
This sort of thing is often related to anti virus scanning of email.... avira I think tries to make itself a certifying authoraty and leads to strange events.
On the toolbar 
> Options> Advanced > Certificate and click manage Certificates.
Check out the list of certifying authorities listed. If they are missing Houston we have a problem. I see such diverse Ca as Hong kong post, Japanese Government,Startcom and Thawte
Excuse me, the problem is somewhat different from the question.
The "Digital Signature Is Not Valid" error message is due to a missing intermediary certificate. The root certificate authority is in the default trust store, but the intermediary signing certificate is not. When using the internal software keystore, this intermediary certificate is saved upon receiving the issued end-user certificate. From there, exporting from Firefox to Thunderbird will author valid s/mime signatures. However, when using a certain hardware-backed pkcs11 interface, the intermediary is not saved, and export will lead to an s/mime signature that does not include the intermediary. If the intermediary is then imported from another source, it will be included, henceforth allowing validation. Two such providers were compared with these identical results, both using <keygen> implementations.
Was the intermediary provided? And if so, where did it get lost?
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e0:23:cb:15:12:83:53:89:ad:61:6e:7a:54:67:6b:21
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
Validity
Not Before: Dec 22 00:00:00 2014 GMT
Not After : May 30 10:48:38 2020 GMT
Subject: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO SHA-256 Client Authentication and Secure Email CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:89:b1:0d:da:7a:53:19:4e:70:52:1d:bc:56:a6:
06:26:b7:b8:49:e0:96:e7:51:ab:f1:f0:5a:13:49:
15:a3:b4:8c:1b:60:bc:7a:51:42:a7:79:8c:a4:22:
df:17:61:4e:91:d5:76:23:0a:14:d3:4a:02:7f:b6:
1d:09:80:6e:a5:04:3d:d9:ba:bb:16:fe:a1:87:a9:
2e:43:52:43:16:7c:af:32:50:c8:a6:4f:5a:e9:08:
d8:cf:93:25:9c:7b:88:e8:30:64:e6:a4:f8:56:80:
fd:2a:24:14:33:17:99:ac:44:e5:69:8b:a3:46:06:
4b:c2:33:d4:e9:40:9f:06:b0:b1:ac:93:40:b9:b5:
08:93:3a:9c:2a:53:a3:10:db:3d:20:61:3c:55:03:
8e:d9:4e:76:25:02:21:29:fa:a3:7c:71:76:4f:ee:
e1:5f:81:e9:fb:54:80:db:c3:7b:35:52:b7:84:de:
22:3d:2c:30:2d:31:7f:59:bd:52:37:b0:33:69:2d:
43:eb:fa:d6:a5:f1:97:77:67:51:8c:d9:ee:27:eb:
bc:a5:07:38:76:8c:a4:a9:38:ff:df:8c:f5:03:ac:
49:be:ca:f7:73:99:3a:0f:32:ab:9c:95:3a:13:3d:
0e:46:3a:57:74:61:50:be:c6:40:3f:cb:e4:e2:9f:
a2:21
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
X509v3 Subject Key Identifier:
92:61:6B:82:E1:A2:A0:AA:4F:EC:67:F1:C2:A3:F7:B4:80:00:C1:EC
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Extended Key Usage:
TLS Web Client Authentication, E-mail Protection
X509v3 Certificate Policies:
Policy: X509v3 Any Policy
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.usertrust.com/AddTrustExternalCARoot.crl
Authority Information Access:
OCSP - URI:http://ocsp.usertrust.com
Signature Algorithm: sha256WithRSAEncryption
1b:2a:6e:ac:55:c1:3a:ab:88:c5:d8:ed:cd:55:f3:aa:6b:61:
2b:c0:09:10:23:99:0f:c5:66:6a:6f:b1:f5:b4:b5:77:5e:0f:
02:61:00:df:7d:05:fe:12:b3:a4:80:80:00:fc:fb:1d:5b:6a:
72:02:0a:41:bc:05:ba:c1:58:d5:26:c2:ea:d5:4d:84:fb:fe:
82:98:cf:58:1b:e3:22:63:9c:52:f8:bb:05:36:ab:7d:58:a5:
de:ab:3b:63:e5:da:d5:73:ef:ec:e0:fb:7b:e2:a3:ff:f0:42:
23:9c:ca:b6:8d:4d:3e:e4:4b:18:03:b2:a8:2d:d4:d8:bb:42:
4b:90:69:85:10:db:a6:37:34:e8:7b:e0:01:10:a5:9c:ca:3a:
c7:9f:4f:88:34:6e:8a:65:d0:1a:8a:bb:a9:dc:ca:ca:36:d1:
f4:fc:c2:64:29:35:af:d6:b1:a7:71:11:d2:03:43:b1:8f:3e:
9a:ec:9e:32:53:f4:76:92:ca:86:34:07:b9:2c:ca:e6:1c:4a:
d8:99:0d:c1:86:e2:90:92:fb:5a:42:6a:23:21:10:e9:65:c7:
f5:d5:bb:7e:ea:8c:85:20:02:62:ea:d1:3a:07:2c:59:c5:99:
33:f2:38:89:e5:b6:e9:16:7a:1f:79:14:f6:4a:10:1a:26:fa:
7c:8a:fb:9b
BEGIN CERTIFICATE-----
MIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAw bzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1B ZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3Qg RXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBaFw0yMDA1MzAxMDQ4Mzha MIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8G A1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJ sQ3aelMZTnBSHbxWpgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R 1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4jo MGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiTOpwqU6MQ2z0g YTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm 9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYD VR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmg N6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENB Um9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3N VfOqa2ErwAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6 wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIj nMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWcyjrHn0+ING6KZdAairup 3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErYmQ3BhuKQ kvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8 ivub
END CERTIFICATE-----
However, when using a certain hardware-backed pkcs11 interface, the intermediary is not saved, and export will lead to an s/mime signature that does not include the intermediary.
What hardware backed pkcs11 interface?
Export from what? Firefox? Is there a bug in Firefox or some other software.
Smartcard-HSM, http://www.smartcard-hsm.com/ versus NSS Internal PKCS #11 Module Software Security Device
FF > Preferences > Advanced > View Certificates > Your Certificates > Backup (as PKCS12).
Yes, a bug if it should be considered unnecessary to manually install the intermediary certificate when using an HSM, but not necessarily a bug in Mozilla software. Thunderbird is already providing the intermediary in the signature attachment from the soft-store when it is missing from the hard-store. It is also possible that this is a vendor specific issue.
a bug if it should be considered unnecessary to manually install the intermediary certificate when using an HSM
I don't follow what you're talking about. A certificate basically is a public key. There is nothing secret about a certificate. Hence there is no point storing a cert in a HSM. Private keys are stored in a HSM.
Thunderbird is already providing the intermediary in the signature attachment from the soft-store when it is missing from the hard-store.
Again, what are you talking about? Is it possible you confuse the terms 'signature' and 'certificate'?
When using the internal software keystore, this intermediary certificate is saved upon receiving the issued end-user certificate.
If you're talking about a web browser, then indeed, a web server would also send the intermediate cert to the browser in addition to it's own cert. I fail to see what this has got to do with email certs.
This sort of thing is often related to anti virus scanning of email
I doubt the OP's problem has got anything to do with anti-virus software intercepting the TLS connection to the server. This appears to be about S/MIME certs. I do not understand what the OP is doing though.
The end-user certificate is validated by verifying the signature on it from its issuer. If the issuer also has different issuer, then the issuer's issuer's signature is validated on the issuer's, and so on, until the root, self-signed certificate authority is reached. Using Comodo as an example, the "CN = AddTrust External CA Root" is the self-signed CA in the default trust store, but it is not the issuer given on the end-user's certificate. Rather it is an intermediary certificate authority, "CN = COMODO SHA-256 Client Authentication and Secure Email CA", which is posted above (albeit poorly formatted), who is the issuer given on the end user's certificate. This intermediary is signed by "CN = AddTrust External CA Root". Comodo does not publish this intermediary certificate. Both the root and the intermediary are necessary to validate the end certificate.
Using a <keygen> implementation, like Comodo's, wherein a secret key is generated, a certificate request is sent to the server, and the server responds with a signed certificate, should store all intermediary certificates necessary for validation, which it does for the software store. However, using this particular hardware store, the intermediary was neither stored in the soft-store nor hard-store, thereby causing validation to fail on signatures created with the locally generated key. Inspection of HSM shows both a private key object, and a public certificate. The public certificate did not include the intermediary. Manual import of the intermediary into the soft-store allowed allowed validation to proceed, with needed to change any of the prior signatures. In signatures created after the intermediary was available in the soft-store, it was included along with the end-user certificate in the signature attachment.
I can agree to most of the above. However, what you describe is the process to obtain an email cert from an (intermediate) CA using a web browser. It is understood that you'd need to export the private key and the cert from Firefox and import it into Thunderbird, to be able to use it as an email or S/MIME cert in Thunderbird. However, I do fail to understand how all this is related to Thunderbird, as you describe issues related to the process of obtaining the cert (and the intermediate cert) using a browser, but not actually using the cert in Thunderbird.
Then your question would be primarily related to the browser (Firefox?). If this is correct, we could move your query to the Firefox queue.
... with needed to change any of the prior signatures.
I do not understand what that means. What signatures are you talking about?
In signatures created after the intermediary was available in the soft-store
I neither understand that. What signatures do you create, signatures for what, and why? Or do you confuse the terms (again)?