Need advice about SSL configs

blutoo

New member
Joined
Feb 15, 2022
Messages
4
Last weekend we migrated all our customers from and old DA server to a brand new one. This was my first time making a move like that and in hindsight I should have done certain things differently.

Overall, I think a correct goal for the new server is to have a server-wide, SNI-based SSL/TLS cert for things like port 2222, dovecot, and exim. I would like as many customers as possible to be SSL-secured. (A few of them use us only for mail and their website lives elsewhere. For them, I assume Let's Encrypt won't work properly and they can only be secured via SNI.) Almost all our customers share IPs with other users. I want customers to avoid getting "mismatch" errors where, for example, their mail client expects to see the customer's domain in the cert but the cert instead shows our DA server's main hostname.

I've probably read every page in DA's documentation site that talks about SSL. But I still find a lot of it confusing. I'd appreciate the forum's advice on what changes I should make so SSL is properly set up for the server and for customers. Background info follows...

Old server
Hostname: directadmin.wisperisp.com
Server IP: 67.43.112.14
DA-managed IPs: 67.43.112.15-17
SNI enabled and tied to our company's wildcard cert.
Some customers had Let's Encrypt certs.

New server
OS: Ubuntu 20.04
DA version: 1.63.7
Hostname during pre-migration staging: directadmin2.wisperisp.com
Let's Encrypt server cert was created using hostname directadmin2.wisperisp.com
Hostname after migration: directadmin.wisperisp.com
Server IP: 66.232.160.170
DA-managed IPs: 67.43.112.14-17
A copy of new server's directadmin.conf and custombuild options.conf are attached.


To start staging the new DA server, I assigned it IP 66.232.160.170 and hostname directadmin2.wisperisp.com before beginning to test-copy customer's data from the old server to the new one. Successfully requested a Let's Encrypt cert using these commands:
cd /usr/local/directadmin/scripts
./letsencrypt.sh request_single `directadmin2.wisperisp.com` 4096

The old server was very out of date and multiple people administered it over the years. So to get a fresh start, I mostly did NOT simply copy the old server's configs (for PHP, Apache, Exim, etc.) over to the new server.

Before officially migrating customers' data, I removed IPs 67.43.112.14-17 from the old server and used DA's GUI to add them.
After migrating customers, I noticed a few of them still needed a Let's Encrypt cert. So I requested a cert for them. Cert requests mostly went okay.

After migrating customers, I changed the new server's hostname from directadmin2.wisperisp.com to directadmin.wisperisp.com. This change, as well as DNS, probably messed things up. Same as when the old server was running, DNS showed directadmin.wisperisp.com was at 67.43.112.14. And DNS still shows directadmin2.wisperisp.com is at 66.232.160.170.

One or two customers who are heavy mail users reported their mail client would no longer connect over SSL. When we looked at the errors, the mail clients showed the cert was tied to directadmin2.wisperisp.com and there was a mismatch. For one of those customers, we quickly bought a cert from zerossl and pasted it into their User account on DA.

We're still getting a few email-user questions or problems most they have mostly quieted down.

If anything above is written in a confusing way, I apologize and am happy to provide clarification. Thanks, and I appreciate any suggestions you can offer!
 

Attachments

I changed the new server's hostname from directadmin2.wisperisp.com to directadmin.wisperisp.com.
Did you also use the request_single command again for a new hostname certificate for this server?

Did you also check your DNS manager and look for the hostname entry there? Might be there are some old ip's in there too.

For the ip's also check /usr/local/directadmin/data/admin/ip.list file and the ips directory if ip's are still correct.

Check that 66.232.160.170 ip as at this moment, it's pointing to ns1.mvn.net so if this is correct, then it's good. If not, the rDNS is also not set correctly.
 
Back
Top