I followed the installation guide to make my server hostname main.somedomain.com. But I can’t seem to figure out which Let’s Encrypt option to use to make the certificate for the panel. (I don’t think I can use the “DNS validation using BIND” option because my DNS is live through Cloudflare.) Let’s Encrypt certbot is complaining about the port not being open.
I know I shouldn’t make a virtual site for the virtualmin panel, but I don’t know which option would fit in? For some reason my server was struggling to make the initial Let’s Encrypt security certificate. (My guess was the DNS propagation took a minute.)
You don’t need to. You can use any domain name hosted in Virtualmin to log into the panel.
But, if the hostname of your system resolved when you installed, you’ll get a Let’s Encrypt certificate and a dummy domain in Virtualmin (it’s a domain that doesn’t do anything but get a cert for the system hostname). If the hostname of the system doesn’t resolve during installation, that dummy domain doesn’t get created, but it doesn’t matter. You never need the system hostname for anything once you have domains in Virtualmin.
Okay then, silly question with regards to this: after the server is set up and configured, and I have nameservers pointing elsewhere, do I still need to define the server’s hostname with the DNS?
You almost certainly should if you’re sending email, at least, if that name is the PTR response for your IP.
To send email, your server needs a PTR record for the IP, and it needs to point to a name that resolves back to the same IP. It doesn’t really matter if the PTR resolves to the same as the system hostname (but a lot of people like it to be), but if it is, it’ll need to resolve the other direction. A PTR needs a matching A.
If you’re not sending mail from the server (or using a mail relay service like Amazon SES or Mailgun or Sendgrid or whatever), you almost certainly don’t need to care about any of that. Only local users will ever look up the name, so a hosts entry is sufficient.
Got it. Right now I have a PTR record for my IP pointing to each of the four root domains being hosted through Virtualmin. (For this example, I’ll call it domaina.com, domainb.com, domainc.com, and domaind.com) and Virtuamin “resides” at main.domaina.com.
There is an A record for each of the four main domains in the DNS record (the four listed) and my PTR checks back to those four. That should be sufficient at that point, yes?
You should not do that. It violates spec, and the expectations of everyone on the internet.
You have to pick one. A single IP should map to a single name. You can have as many names mapping to the IP as you want, because all services support name-based virtual hosting, but you can’t do the other direction.
Ah okay. I should tell me PTR manager to delete the others then. But what name should the PTR resolve to then?
Nevermind the last part, doing google searches took me down a path to answer this. Unless I’m mistaken, regardless of what domains are on the server, the hostname of the server should be the name assigned to the rDNS. So if my hostname is main.mydomain.com, my PTR for the domain should be main.mydomain.com
“Should” is a stronger word than I would use, but it makes most people happiest to have it match the system hostname. It’s not necessary for sending email (some people believe it is treated as a spammy trait to have the HELO name not match the PTR name, but I’ve never seen a server that actually did that).
That’s not my experience. I just created a new server on ESXi, fully resolvable server name. Install VMin, go to log in and I am prompted to allow an exception.
This was also my experience. Thus my questions about how to get it to work with Let’s Encrypt. Granted I have no problems with the admin.hostname names instead. Just feels like I’m leaving something behind with the main.hostname without SSL.
That’s not a useful feeling. I assure you nothing needs a cert for the system hostname, if you don’t try to use it for anything. Mail users will be connecting to their own domain names, mail senders will be connecting to the name given by the MX record (which will never be the system hostname). Outgoing mail will use the certificate of the server it’s connecting to…your server is the client in that interaction, not the server.
I’m sure there’s some way to trigger that dummy domain creation and cert request after installation, but there’s no reason to do it. You’re going to have a bunch of domains with certificates, and you can use any of them for Virtualmin and Usermin.
I use to use these notes, but the options have changed.
System Settings
Virtualmin Configuration
SSL Settings
Create host default domain with LE certificate
Select Yes, and keep visible. (may not need visible).
Request LE cert at creation? - Yes and skip connectivity check.
Show Let’s Encrypt error at domain creation time - Yes
Re-Check Configuration``
Apologies Joe, I wasn’t satisfied, so investigated further and found that the gateway firewall (which blocks very heavily) is blocking some of the random LE testing servers. To prove a point I dropped all rules relating to port 80 and did a fresh install and this time the LE cert was obtained at the end of the install process.
Everyone seems to want the system hostname to be important. I don’t know how to fix that.
But, the only negative side effect of the dummy domain not being created and a cert successfully requested is that you have to click through a browser warning one time when you first log into Virtualmin. That is the sum total of the harm caused by not having the system hostname fetching a Let’s Encrypt cert. Literally, that’s all. Once you create a domain in Virtualmin and it gets a certificate, you never have to think about the system hostname again or use it to connect to the system for any service, including Virtualmin/Webmin/Usermin (which will allow logging in with any domain hosted on the system).
Odd enough, I don’t get that warning. I always get the “this server has HSTS enabled and …” blah blah blah and Chrome refuses to let me advance. I eventually get in through the IP:10000 (or IP:20000 for usermin) though so there’s that.
Even though it’s off by default, the reject_unknown_client_hostname option in Postfix checks if the connecting IP has a PTR record and if that hostname points back to the same IP (FCrDNS). If either check fails, Postfix rejects the request. Yes, it’s not required by RFCs, but many admins turn it on manually. Spam filters also often use FCrDNS as a trust signal, though it usually only has a small impact on the overall spam score.
And, again, you’re totally right—RFC 5321 just says the HELO/EHLO should be a valid FQDN or IP, not that it must match the PTR. Yet, matching the HELO to the PTR has become a common best practice for better mail delivery.
That’s because we were able to install a Let’s Encrypt SSL certificate for your system’s hostname, so you’d connect to it after Virtualmin was installed. This ties into what Joe mentioned—it’s the only reason the hostname SSL certificate exists and should be set up in the first place.