This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Self-Signed Certificates. Unable to send mail with version 7.8.3.2. (Found a work-around)

  • 5 balasan
  • 1 ada masalah ini
  • 230 paparan
  • Balasan terakhir oleh atErik

more options

I'm using hmailserver on a standalone Server 2019 (not a DC). It's for internal mail only, and that's it. So set up for SSL/TLS on port 465 and STARTTLS on port 143 using a self-signed e-mail cert. There's no problem receiving, but unable to send e-mail with a a warning that the certificate can't be verified. Tried to "solve" the problem and I was unable to after a few hours. Overall, I'm not yet convinced where the problem is - the hmailserver program or the Thunderbird program. So time for a new approach. Instead of trying to figure out why it won't work, what can I do to "make" it work? So with a new approach I decided to see if I could find a work-around. I did.

Navigate to C:\Users\<pofile_name>\AppData\Roaming\Thunderbird\Profiles\<profile_in_use>\ and open the Cert_Override.txt file using notepad. List there you will see the data for your self-signed certificate, but only for the incoming mail port. (Port 143) in my case. It will look something like this: my.mail.server:143 OID.2.16.840.1.101.3.4.2.1 CE:D6:4C: (buch of key gibberish after this)

Copy the above to a new line, and the only thing you need to change is the port number. In my case, I changed it from port 143 to port 465 since that's what I use on the hmailserver program for the SMTP port. Then save the file. Now now the file looks like this: my.mail.server:143 OID.2.16.840.1.101.3.4.2.1 CE:D6:4C: (buch of key gibberish after this) my.mail.server:465 OID.2.16.840.1.101.3.4.2.1 CE:D6:4C: (buch of key gibberish after this) Now you can restart Thunderbird and when you check the certificate exceptions you'll see the cert listed twice - once for the incoming port and again for the outgoing port. I now have no problem receiving "or" sending e-mail through my end-to-end encrypted hmailserver program.

I'm using hmailserver on a standalone Server 2019 (not a DC). It's for internal mail only, and that's it. So set up for SSL/TLS on port 465 and STARTTLS on port 143 using a self-signed e-mail cert. There's no problem receiving, but unable to send e-mail with a a warning that the certificate can't be verified. Tried to "solve" the problem and I was unable to after a few hours. Overall, I'm not yet convinced where the problem is - the hmailserver program or the Thunderbird program. So time for a new approach. Instead of trying to figure out why it won't work, what can I do to "make" it work? So with a new approach I decided to see if I could find a work-around. I did. Navigate to C:\Users\<pofile_name>\AppData\Roaming\Thunderbird\Profiles\<profile_in_use>\ and open the Cert_Override.txt file using notepad. List there you will see the data for your self-signed certificate, but only for the incoming mail port. (Port 143) in my case. It will look something like this: my.mail.server:143 OID.2.16.840.1.101.3.4.2.1 CE:D6:4C: (buch of key gibberish after this) Copy the above to a new line, and the only thing you need to change is the port number. In my case, I changed it from port 143 to port 465 since that's what I use on the hmailserver program for the SMTP port. Then save the file. Now now the file looks like this: my.mail.server:143 OID.2.16.840.1.101.3.4.2.1 CE:D6:4C: (buch of key gibberish after this) my.mail.server:465 OID.2.16.840.1.101.3.4.2.1 CE:D6:4C: (buch of key gibberish after this) Now you can restart Thunderbird and when you check the certificate exceptions you'll see the cert listed twice - once for the incoming port and again for the outgoing port. I now have no problem receiving "or" sending e-mail through my end-to-end encrypted hmailserver program.

Penyelesaian terpilih

That looks like an easier workaround than downgrading to TB 68, so it might be worth mentioning in the bug report.

Baca jawapan ini dalam konteks 👍 2

All Replies (5)

more options

Penyelesaian Terpilih

That looks like an easier workaround than downgrading to TB 68, so it might be worth mentioning in the bug report.

more options

Thanks for the pointer to the bug report. I'm not at all familiar enough with bugzilla to know what I'm doing. But since you pointed me right to it, I've added the above to the bug report.

more options

Thanks for the addition. There have been a few reports of the bug on this forum, so it will help others until it's fixed in the release version. Bugzilla is mainly for developers, but users are certainly welcome to submit bugs, workarounds and requests for new features.

more options

@Calr1959

Thank you so much for posting this!! I was going crazy because TB78 wouldn't confirm the security exception (which I need for one of my clients) and TB68 wouldn't work with outlook multi factor authentication (which I needed for another). I have literally spent all day on this and tried claw mail, evolution, mailspring and countless hours on this.

I tell you all of this to show you the importance of you sharing your solution. You are appreciated!!

more options

few EXTRA info:

to submit outbound emails into your mail-sever , if you choose port 465 ( aka SMTPS = Mail-Submission Over TLS/SSL ) then you should choose TLS/SSL security/encryption, but if you choose port 587 then you should normally choose StartTLS security/encryption. but mail-server can be configured to use TLS/SSL for port 587 too. avoid using StartTLS, as that has bugs+vulnerabilities+backdoors.


even for internal (intranet) purpose mail, you should still use IMAPS port 993 & TLS/SSL security/encryption.

port 143/993 (IMAP/IMAPS) & 110/995 (POP/POPS) are used retrieving received emails from mail-server, into your email client programs, for-example: TB = Thunderbird , SM = SeaMonkey, etc.

port 465/587 are used for submitting outbound/outgoing emails into your mail-server.

those who are inside business/commercial internet connection line , they can also use port 25 to submit outbound emails into their mail-servers, along with port 465, 587, etc.

those who are inside residential/home internet connection line , they cannot use port 25 to submit outbound emails into their mail-servers , unless the user calls the ISP & removes the port 25 related restrictions, etc . users with such internet connection line, must use port 465 or 587, etc to submit outgoing/outbound emails to mail-server.

if v78 series TB gives trouble, then a user can/may also use v68 series Portable Thunderbird Legacy, as a second TB , to connect with their own mail-server.

v68 series TB supports older/unsafe TLS security/encryption by default . can be manually configured to disable that. v78 series TB does not support older/unsafe TLS security/encryption by default . can be manually configured to enable that.

v68 series TB uses GPG based OpenPGP , mork/mab based address book, etc. v78 series TB uses RNP based OpenPGP , sqlite based address book, etc.

there are such various differences.

you/user can create own root certificate by yourself/ownself to use it as a CA (certificate authority) root certificate , then you/user can create other certificates under that root cert, for example, certificate(s) for your mail-server, web-server, etc. if you load that CA root cert in TB & in mail-server's (hmailserver in windows) root cert collection/database , then various certificate handling operations become bit more easier.

if a user's mail-server is using a self-signed cert , then, connection in between sender's mail-server AND destination mail-server, (this happens over port 25), will usually be open (not-encrypted), etc , so that is not secured/safe.

so having a domain-name, & a fixed-IP-address from ISP, & a rDNS record setup with ISP, & a free TLS/SSL cert from Let's-Encrypt or ZeroSSL (or a paid TLS/SSL cert from other CA company), etc for SMTP, are essential & required to send encrypted email from sender mail-server to a destination mail-server.

as IMAPS/POPS (and SMTPS = Mail-Submission over TLS/SSL,etc) are used by specific clients/members of a specific mail-server , a mail-server's owner/operator-user can share/give his/her self-signed pub-cert (of mail-server's IMAPS/POPS & SMTPS ports) to his/her clients/members , so that only those clients/members can view/get received emails from mail-servers via IMAP/POPS, and submit outbound emails to mail-servers via SMTPS.