808735 - TB fails to accept re-issued self-signed cert with duplicate issuer and serial number

Status: NEW

(Thunderbird :: Security, defect)

Description

[Philip Prindeville]

Attachment: Original self-signed cert

I'm running TB 16.0.1 on MacOS 10.8.2.

I'm using Sendmail 8.14.5 on Fedora 16 as my MTA.

I had originally generated a cert (attached) using the bundled script /etc/pki/tls/certs/make-dummy-cert.

After a year, it had expired, so I "reissued" the same cert using the attached script "repem" (new cert also attached).

Now when I try to send a message, Sendmail gets:

Nov  5 12:29:33 mail mimedefang.pl[32509]: helo: macbook.redfish-solutions.com (192.168.1.17:53705) said "helo macbook.redfish-solutions.com"
Nov  5 12:29:33 mail sendmail[791]: STARTTLS=server, error: accept failed=0, SSL_error=1, errno=0, retry=-1, relay=macbook.redfish-solutions.com [192.168.1.17]
Nov  5 12:29:33 mail sendmail[791]: STARTTLS=server: 791:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1195:SSL alert number 42
Nov  5 12:29:33 mail sendmail[791]: qA5JTXJq000791: macbook.redfish-solutions.com [192.168.1.17] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA

and I get the dialog saying:

Send Message Error

Sending of message failed.
The message could not be sent using SMTP server mail.redfish-solutions.com for an unknown reason. Please verify that your SMTP server settings are correct and try again, or contact your network administrator.

but running:

openssl s_client -connect 66.232.79.143:587 -starttls smtp -crlf

works fine (also attached).

Comment 1

[Philip Prindeville]

Attachment: Renewed self-signed cert

Comment 2

[Philip Prindeville]

Attachment: Cert renewal script

Comment 3

[Philip Prindeville]

Attachment: Output of running openssl s_client ...

Comment 4

[Kai Engert (:KaiE:)]

Philip, I think the problem is on your server side.

Apparently your server is configured to request a client authentication cert from connecting clients. That's the reason your server logfile reports a bad cert error.

I suspect thunderbird complies to the server's request by using one of the client certs stored in thunderbird, but the server doesn't like it and therefore rejects it?

Do you get a prompt to select a cert when you connect to the server?
If not, did you change edit/prefs/advanced/encryption "when a server requests my personal cert" to "auto"?

Comment 5

[Philip Prindeville]

I stopped TB, downloaded certutil (thanks, bz!) and manually deleted all of the certs (which were now expired) from cert8.db.

I restarted TB, and it asked me if I wanted to accept the new certs (for SMTP/STARTTLS and IMAP/S).

I accepted them, and now the cert8.db only includes the currently valid certs.

It looks to me like TB doesn't allow you to replace an expired cert with a new valid one (with an incremented serial #, of course) automatically... nor does the configuration editor allow you to manually delete either expired or self-signed certs (it's not clear which it was choking on).

Comment 6

[Philip Prindeville]

I'm currently running thunderbird-24.0-3.fc18.x86_64, and recently replaced my self-signed certs (bumping the serial number, but using the same key).

I deleted the certs from my profile directory using:

certutil -D -d . -n mail.redfish-solutions.com

for both of them (one for port 993 and one for port 587).

When I try to send a message after restarting TB, however, I get:

========

Sending of message failed.
The message could not be sent using SMTP server mail.redfish-solutions.com for an unknown reason. Please verify that your SMTP server settings are correct and try again, or contact your network administrator.

========

Running "openssl s_client" worked fine.

Not sure why TB is failing. I did an odd combination of manipulations to get it working again last year (the certs are good for 365 days), but it shouldn't be this hard.

Sendmail logs say:

Nov 10 13:03:39 mail mimedefang.pl[15106]: helo: builder.redfish-solutions.com (192.168.1.10:56594) said "helo [192.168.1.10]"
Nov 10 13:03:39 mail sendmail[16613]: STARTTLS=server, error: accept failed=0, reason=sslv3 alert bad certificate, SSL_error=1, errno=0, retry=-1, relay=builder.redfish-solutions.com [192.168.1.10]
Nov 10 13:03:39 mail sendmail[16613]: rAAK3d4m016613: builder.redfish-solutions.com [192.168.1.10] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA

Error console says:

An error occurred during a connection to mail.redfish-solutions.com:587.

You have received an invalid certificate.  Please contact the server administrator or email correspondent and give them the following information:

Your certificate contains the same serial number as another certificate issued by the certificate authority.  Please get a new certificate containing a unique serial number.

(Error code: sec_error_reused_issuer_and_serial)

Imap/s and SMTP/S have separate certificates, but the CN is the same (even though the serial #'s and issue/expiry dates are different). This used to not be an issue, but the last couple of years it is.

Has a regression crept in?

Can we please get some progress on this defect?

Thanks.

Comment 7

[Philip Prindeville]

I should also note that I'm using the script:

/etc/pki/tls/certs/renew-dummy-cert /etc/pki/tls/certs/sendmail.pem

to renew my SMTP certificate.  This script is part of the openssl packaging (distro specific) on Fedora.

Comment 8

[Philip Prindeville]

After some additional digging, it seems the issue is related to the fact that IMAP and SMTP are using the same subject (CN) and serial #, but have different issue/expiry dates and RSA keys.

When the certs are retrieved, they aren't indexed by the tuple of [subject, port#] from what I can tell, or there wouldn't be a collision.

Oddly though, I'm seeing in the Certificate Manager entries that have under the Server column:

scayl.com:465
scayl.com:143
scayl.com:995

so it looks like they're listed by the above tuple... but they're not retrieved that way.

Also worth noting that self-signed certs whose issuing authority isn't mapped to a known CA, don't show the "Expires On" field in the Certificate Manager, and the "View...", "Edit Trust...", and "Export..." buttons remain greyed out.

The certs have expiry values, so I'm not sure why the "Expires On" field is blank.  Or why the certs aren't viewable.

Comment 9

[Ruben]

I have the same problem still in TB 31.8.0 on ubuntu

is there a workaround? Or do we have to create new certificates on our webserver, so TB accepts them?

Comment 10

[Ruben]

I already tried to delete all certificates like this:

https://support.mozilla.org/en-US/kb/Certificate%20contains%20the%20same%20serial%20number%20as%20another%20certificate

But it seems there is no solution to ignore this issue in Thunderbird.

All other clients i tried have an option to ignore the message

> Your certificate contains the same serial number as another certificate issued by the certificate authority.  Please get a new certificate containing a unique serial number.

Comment 11

[Ruben]

I solved this now by creating new certificates with correct serial numbers, but the issue stays open: how to ignore this if you cannot create the cetificates yourself?

And why can other clients ignore this?

Comment 12

[Kai Engert (:KaiE:)]

Comment 6 mentioned sec_error_reused_issuer_and_serial

NSS uses a legacy implementation that cannot deal if such a duplicate is encountered (it's forbidden by RFCs).
The only way is to manually clean up all existing storage of duplicate certificates and restart.

Comment 13

[Kai Engert (:KaiE:)]

See also bug bug 435013