Letsencrypt wrong domain

OS type and version: CentOS Linux 7.9.2009
Webmin version: 1.981
Virtualmin version: 6.17 Pro

Hi everyone,

My ongoing saga of Letsencrypt continues.

I have been experiencing a number of issues with Letsencrypt as regular visitors might (:slight_smile: ) have read but I think I am beginning to get, at least, somewhere.

The current issue/symptom I amtrying to resolve is that whenever I try to set up an email account in Thunderbird (I have also tried other mail clients and other internet connections) I get a certificate error when trying to send email using domain.com. The error when I use Thunderbird “view certificate” is that the cert is for the wrong site. For clarity I will call that “BADdomain.com”. When I use any certificate testing services the domain.com tests out without error. I have also used a wildcard certificate on domain.com after trying the usual specified servers.

During my attempts to sort the server out I have tried many times to create/host/transfer various test domains including “BADdomain.com”.

If I run “openssl s_client -showcerts -connect 85.234.151.55:465” the report shows “BADdomain.com” being delivered as below :

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let’s Encrypt, CN = R3
verify return:1
depth=0 CN = BADdomain.com
verify return:1
CONNECTED(00000003)

Certificate chain
0 s:/CN=BADdomain.com

Server certificate
subject=/CN=BADdomain.com
issuer=/C=US/O=Let’s Encrypt/CN=R3

I have deleted the VS for BADdomain.com and set up DNS so that the domain no longer resolves to this server (self signed certificate) and allowed for and tested propagation.

Running “openssl s_client -showcerts -connect 85.234.151.55:465” the report stays the same.

In an attempt to remove ALL entries for that domain I found and deleted the entries under /etc/letsencrypt/archive & live & renewal.

Still the problem exists.

Running “openssl s_client -showcerts -connect 85.234.151.55:465” the report stays the same.

In despairation I deleted ALL entries in those three directories.

Still a problem and by now getting really peeved.

It is possible during my fight that I could have clicked the use as default link in the cert module for a domain but thought that would only affect the one domain. Might be wrong.

So I have a couple of questions

1, Can I somehow delete ALL Letsencrypt entries somehow ands start again?

OR

  1. How can I resolve this heinous issue.

All contributions welcome.

Thanks for reading.

A solution, of sorts.

After much searching for others with the same issue I noted someone asked the question if the problem still existed if the outgoing server was using the servers domain name. Unfortunately the question was unanswered. But it did give me an idea of somewhere to look.

I went into Virtualmin>Server Configuration>SSL Certificate for the server host domain and clicked “Set as Default Services Certificate”.

Now when I run “openssl s_client -showcerts -connect 85.234.151.55:465” BADdomain.com has been replaced by the server-domain.com.

Setting up Thunderbird now only works when I specify server-domain.com as the outgoing server. But at least it works!

So the next question has to be, is that normal?

I have always got the users (Centos 5) to use mail.their-domain.com for outgoing server and using the servers domain seems to be somewhat alien to me so I would rather revert to that if possible.

Any suggestions welcome.

Thanks for reading.

For many years I have had all my clients use the hostname of the Virtualmin server as incoming server and outgoing server of their email client, regardless of what their domain name is. For example, in Outlook set incoming server and outgoing server to vps02.indiax.com and this is normal for us. It is a simple arrangement and works quite flawlessly.

YUP agree!

In common, or as domain / company have your own realmailserver on your name / domain (mail whatever) or if not using the name for real mailserver/host in mx.

Al other are possible but kind of no real world, kind of faking thing is my opinion.
While real programm / server /sender is the hostname/mailserver anyway.

OFFTOPIC:
If you use that and no external mailservice …

Yes you can for external as google outlook mail services and and… puth your mail/domain/company as sender receiver is… hmm but that BIG services has a kind of MONOPOL and blocking… also

You can test how good or bad they are here https://en.internet.nl/

For example google using old tls versions still theirselves.:

Technical details:

Mail server (MX) Affected TLS versions Status
gmail-smtp-in.l.google.com. TLS 1.1 phase out
TLS 1.0 phase out
alt4.gmail-smtp-in.l.google.com. TLS 1.1 phase out
TLS 1.0 phase out
alt3.gmail-smtp-in.l.google.com. TLS 1.1 phase out
TLS 1.0 phase out
alt2.gmail-smtp-in.l.google.com. TLS 1.1 phase out
TLS 1.0 phase out
alt1.gmail-smtp-in.l.google.com. TLS 1.1 phase out
TLS 1.0 phase out

Hi Jotst and Calport,
Many thanks for taking the time to reply, it is greatly appreciated.

As I see it, the great benefit of having users using their domain name (mail.their-domain.com) for outgoing email is that should I have to move them to another server this move is transparent to them. Using the hosting server domain for outgoing email is fine until some/all clients need moving and then either the move would have to include ALL clients that use that server all at once or each moving client would have to update their outgoing server setup.

The process sounds like it could get messy.

Or am I missing something?

Well, if you plan to migrate your clients frequently from one server to another and want this migration to be transparent to them (sort of, but it never really is as transparent to clients as we would like it to be, is it?) then each client using his own domain name for incoming and outgoing server would be useful. No doubt about that.

However if this kind of migration happens once in a while, there are best practices which can be followed (and large hosting companies have followed - for example when Rackspace sold off part of its biz to LiquidWeb) to make the migration easy for the client.

For us smaller operators, there are ways to use cnames and aliases (along with the creation of appropriate certs from Let’s Encrypt) so that the new server is made to look like the old server for the purpose of serving email clients across a migration: then even such a migration can be as transparent to the client as a migration where the client uses his own domain name.

Oh, we appear to have gone off-topic…

that is from pro user he should ask @staff

Thanks Unborn, I will do that.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.