1325901 - Email signatures from Start.Com result in Certificate not found error

Status: RESOLVED INVALID

(Thunderbird :: Security, defect)

Description

[Matt]

I have used start.com SSl certificates for digital signing of email and S/Mime encryption for a number of years in Thunderbird.  Recent daily builds result in an error when these certificates are included to sign the mail, the first below on Sending and the second on any attempt to save the message.

Sending of the message failed.
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.

And

Unable to save your message as a draft.
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.

I regenerated the certificate that was due to expire 9th January with a new one that expires March 20 2020.

Again I received the above error message

Created a certificate from Comodo for another account and added that.  No error.  So my experience is the error only relates to StartCom certificates.

Following the error the error console displays
GenericSendMessage FAILED: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgCompose.SendMsg]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js :: GenericSendMessage :: line 3154"  data: no]  MsgComposeCommands.js:3158

The certificate store appear to have the STARTCOM entries, so the key chain "looks"  like it is all there.

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Can you try with a recent nightly version of Thunderbird? ( https://archive.mozilla.org/pub/thunderbird/nightly/2017/01/2017-01-13-03-02-23-comm-central/ ) This may have been fixed by bug 1312827.

Comment 2

[Matt]

Tried with 
Application Build ID 	20170113030223

Built from https://hg.mozilla.org/comm-central/rev/d4fb23de45465e419feb385b79d1e201dcc82759

Still see the error

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Oh, right - this wouldn't be due to OneCRL. Basically, Mozilla does not trust new certificates issued by StartCom (see bug 1309707 comment 0) and treats them as revoked. I think what's going on is Thunderbird is attempting to verify your signing certificate before using it. In some ways this is a good idea because Thunderbird is basically asking "is this a good certificate to use to sign emails?". Then again, it doesn't entirely make sense to do this because what it actually asks is "does Mozilla trust this certificate when verifying a signed email?", which is not what the sender cares about (the sender only cares if the recipient trusts that certificate to verify a signature on an email). Long story short, I think this is a decision Thunderbird should make: is it best to keep verifying email signing certificates (given that the platform may not trust them) or should it just skip that step (given that it really doesn't matter what the platform thinks, as long as the recipient trusts it)?

Comment 4

[Wayne Mery (:wsmwk)]

"Long story short, I think this is a decision Thunderbird should make: is it best to keep verifying email signing certificates (given that the platform may not trust them) or should it just skip that step (given that it really doesn't matter what the platform thinks, as long as the recipient trusts it)?" (from comment 3)

Comment 5

[Magnus Melin [:mkmelin]]

Sounds to me the current behavior is preferable. You can't really know what app the recipient will use, and if it will show as an error or not. 

Signing/encryption is complicated enough as it is, so users should never be taught that it's sometimes ok for there to be an error. If they do that the whole system fails.