Created attachment 678430 [details] 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: helo: macbook.redfish-solutions.com (192.168.1.17:53705) said "helo macbook.redfish-solutions.com" Nov 5 12:29:33 mail sendmail: 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: 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: 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 188.8.131.52:587 -starttls smtp -crlf works fine (also attached).
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"?
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).
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: helo: builder.redfish-solutions.com (192.168.1.10:56594) said "helo [192.168.1.10]" Nov 10 13:03:39 mail sendmail: 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: 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.
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.
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.
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?
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.
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?
You need to log in before you can comment on or make changes to this bug.