Closed Bug 1462915 Opened 2 years ago Closed Last year

digital signing S/MIME (X509) not working


(Thunderbird :: Message Compose Window, defect, major)

Windows 10
Not set


(Not tracked)



(Reporter: vtol, Unassigned)



TB 62.0a1 (2018-05-19) (64-bit)
enigmail 2.0.1
W10 1709 b16299.431

Saving/sending a S/MIME (X509) signed message always producing this error.

"You specified that this message should be digitally signed, but the application either failed to find the signing certificate specified in your Mail & Newsgroup Account Settings, or the certificate has expired."

The certificates are listed in options and are not expired.
disabling enigmail has no impact.
nothing related in the error console

If not mistaken this been introduced with the update from 61 to 62
Is this part of the Efail matter and thus been disabled? Will it be reinstated any time soon again or is S/MIME dead?
Works for me. TB62.0a1 2018-05-25

I could sign with and without Enigmail (alpha version).
(In reply to Alfred Peters from comment #2)
> Works for me. TB62.0a1 2018-05-25
> I could sign with and without Enigmail (alpha version).

that is also on W10 1709 b16299.x?

My box advanced since the initial reported occurance to W10 1709 b16299.461 and TB 62.0a1 (2018-05-27) (64-bit) and having enigmail removed, but the issue is still persistent. It was working fine with TB 61.x

After clicking OK in the displayed error popup the following output is observed on the console

GenericSendMessage FAILED: [Exception... "Component returned failure  MsgComposeCommands.js:3465
code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgCompose.SendMsg]" nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://messenger/content/messengercompose/MsgComposeCommands.js ::
GenericSendMessage :: line 3461"  data: no]

GenericSendMessage chrome://messenger/content/messengercompose/MsgComposeCommands.js:3465:5
SaveAsDraft chrome://messenger/content/messengercompose/MsgComposeCommands.js:3649:3
Save chrome://messenger/content/messengercompose/MsgComposeCommands.js:3628:23
doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:736:9
doCommand chrome://messenger/content/messengercompose/MsgComposeCommands.js:947:5
goDoCommand chrome://global/content/globalOverlay.js:84:7
oncommand chrome://messenger/content/messengercompose/messengercompose.xul:1:1
Further debugging with 62.0a1 (2018-05-28) (64-bit) and enigmail-nightly-all.xpi (build date: 2018-05-28, version: 2.1a1pre) on W10 1709 b16299.461

Protocol: S/MIME = same error as described previously, not working
Protocol: PGP/MIME(auto) = no error, working
Protocol: Inline PGP = no error, working
Having discovered the TB made it finally as x64 for Win it has been switched from daily 62.0a1 (2018-06-24) to 60.0b8 (64-bit) but the issue is still present.

Will saving/sending a S/MIME (X509) signed message (soon) return natively to TB or has the user to rely solely on 3rd party tool, e.g. enigmail?
We had a few reports like this one lately, see bug 1481969 and bug 1470077. On was resolved by removing the cert8.db file from the profile, the other one got going by reselecting the certificate.

Personally I had problems when jumping between versions of TB on the same profile, but reimporting and reselecting the certificate worked for me.
See Also: → 1481969, 1470077
Closed: Last year
Resolution: --- → INVALID
What happened?
Flags: needinfo?(vtol)
Well, it does not seem a bug then but rather an inconvenience caused by switching TB versions on the same profile, which I did similiar to what you mentioned (that was prior the release of a 64-bit version for Win)

Got it working now after having

1. disabled Enigmail (which is not the cause but for due dilligence purpose)
2. removed the certs 
3. cleaned identities security (if not cleaned the certs will be still present after TB restart which was unexpected)
4. restarted TB
5. imported the certs again
6. reinstated identities security
Flags: needinfo?(vtol)
You need to log in before you can comment on or make changes to this bug.