Email certificate warning

Today I was presented with a certificate warning by Thunderbird, titled: “Domain Name Mismatch”. The warning happened as I was sending SMTP mail through

In the warning text: “You have attempted to establish a connection with “”. However, the security certificate presented belongs to “”. It is possible, though unlikely, that someone may be trying to intercept your communication with this web site.”

The certificate looked okay though, it had all the dreamhost info expiring sometime in 2007, but I hadn’t received this message before and later emails also didn’t present the warning.

Does this happen occasionally? Or maybe it was a Thunderbird hiccup? I have TB’s outgoing SMTP set to use “TLS, if available” (default setting).

As a curious experiment, I changed the setting to use SSL and got the exact same warning, although I don’t think there is any SSL connection available for mail, at least not mine. Perhaps more evidence of a TB issue.


I have gotten the same message today. Something must be up… I’ll keep checking back for updates.

FYI, I’m using Thunderbird also.

Just as an update. I had been sending and receiving messages fine without any further warnings since my posting until just now. The same dialog warning just popped up.

Seems that if I’m not alone in this, it may not be TB’s issue alone. Could be related to some dreamhost system actions in combatting the DoS attacks.

Any system admins out there have any idea?

I get that every time I start up Thunderbird, but only once per session. This is related to using SSL with POP or IMAP.

I suspected some correlation to SSL initially, and reproduced the warning when I set TB to use SSL. However, my usual setting is “TLS, if available” and the warning happened twice so far using that setting. The mystery continues. :frowning:

Interestingly, shutting down and restarting TB didn’t cause the warning to reappear. Maybe it isn’t session related in this case. Unless the session is a time related entity, e.g. 24hrs or such. I’ll see if I get another one tomorrow.

Yeah, it’s not just a Thunderbird thing. It is indeed an SSL issue and not related specifically to the DDOS, since it started several weeks ago.

In particular, someone changed the certificate on the server and it doesn’t match the actual server common name.

This also affects other clients such as Fetchmail, which on some systems try to connect to the server using SSL by default. In order to circumvent this, you need to add an option to the end of each line in fetchmailrc that relates to the Dreamhost connection. The option to add is sslproto “”.

Of course, this is less secure but I don’t think there’s any other way around it unless they sort out the certificate situation…

Same issue with webmail. DreamHost would have to create a certificate for each subdomain that is configured to access the mail servers. That’s going to be a lot of certificates, and the server software probably can’t handle that. One could conveivably expect DreamHost to create a certificate with the local machine name (ie instead of and ask customers who want SSL /w no warnings to use that subdomain instead of their own. But then again one might get a Ceritificate Authority warning as well, since DreamHost is not a known CA. And what happens if DreamHost needs to change the machine for accessing your mail? That’s why they ask customers to use mail instead of the local machine name.

Seems like one should expect mail clients to better be able to handle issues where you just want the encryption and don’t care about the trust. Obviously if you care about the trust you would not be using a shared mail server in the first place.

:cool: Perl / MySQL / HTML+CSS

You can save the cert with Thunderbird / Mozilla, and after that you shouldn’t get warnings (for both webmail and SSL POP3 / IMAP). Only Apple Mail is a real pain (it will let you save the cert, but won’t ignore the fact that the cert hostname doesn’t match the hostname you’re connecting to).

I don’t remember exactly how to do it, but it’s not that hard. Look in the archives here or google for more information.

The big problem here is that people need to be connecting to “”… I believe there was some discussion of having people use “” where blahblah represents a cluster of machines (and getting real SSL certs with that hostname) - but this would end up creating a lot of hassle and is a lot more confusing for people. So even if there were an official “signed” SSL cert, you’d still usually get a warning about the hostname / certificate name mismatch.

Hmm, this is all still a bit confusing to me. Sorry for my denseness.

I believe my mail client (Thunderbird) doesn’t try to connect with SSL, unless my normal default setting “Use TLS, if available” is some form of SSL.

While I was able to reproduce the warning by temporarily setting “Use SSL” as an experiment, the warning also appeared before and after the experiment every 24hrs with my normal default.

No reboots, or TB restarts inbetween, so not apparent session relation. Of course, with my ignorance of such matters, a session may be time-based, for all I know.

Bottom line questions:

  1. What would cause an SSL related certificate warning to appear if my client is not set to use SSL?

  2. Is it safe to simply accept the certificate permanently, or might it have other effects I should know about?

Thanks for the rigorous discussion, folks. I appreciate the community.

TLS = Transport Layer Security

Same stuff applies.

[quote]TLS = Transport Layer Security
Same stuff applies.[/quote]
This Wikipedia article on TLS might be a bit more accessible. Of particular note it explains that Transport Layer Security is the successor to Secure Sockets Layer and:

There are slight differences between SSL 3.0 and TLS 1.0, but the protocol remains substantially the same. -Tom

I can’t explain why this happened only recently, but I’d speculate it had something to do with your use of the “TLS, if available” setting. Probably prior to the point when you saw the warning your access to the TLS port was blocked on either your end or on the Dreamhost side, so Thunderbird was using a non encrypted connection.

As for the warning, it’s harmless, but annoying. It’s a known problem both with Thunderbird and Dreamhost (though not specific to either). There’s an extensive thread on this issue in Thunderbird’s bug database:

In comment #12 I explained one way to work around the problem.


Thanks for all your information Tom and Will. I feel a little better about the situation now.

Sorry to resurrect an older post, but there is a solution (or workaround) to the domain mismatch problem for Thunderbird and Firefox users. If this has been mentioned elsewhere, I apologize.

Andrew Lucking has written a plugin aptly called Remember Mismatched Domains available at Short of allowing us to use as our server, this will solve the problem.