Virtualmin always wants to include the "mail" sub-domain when generating SSL certificates

Yes, I do manually override it (each time), but this wasn't happening on my previous Virtualmin installation. I did suspect that it might be hard-coded, and that perhaps it's in the "default settings" referred to either at System Settings -> Server Templates -> TEMPLATE -> BIND DNS domain or -> Apache website, possibly the latter as I do see "mail.whatever" referred to in the former on the old server, but not the latter. I wasn't using the default settings in those places on the old server, but was trying to do minimal to no configuring of certain things on the new server.

Do you suggest that I do indeed explicitly configure those sections of the server template in order to make the "mail" sub-domain disappear?

Are you domains using the email feature?

On both the "old" and new servers I have every mail-related option disabled under both the Account Plan that I created on the server, and (on the new server) the Account Plan that was created by Virtualmin during the import.

On both the old and the new servers all Server Templates do, of course, have text in the Mail for domain -> Email message to send upon server creation field, but all other options under "Mail for domain" are set to "none" or "default settings". There is no magic button to enable or disable "Mail for domain", per se.

Also, is there a particular issue you're running into when trying to use those aliases in the SSL certificate?

Well, besides the fact that I don't want a mail sub-domain in the certificate and I have to manually exclude it for every certificate I create, the mail sub-domain does exist (and is controlled by a discrete nameserver not connected to Virtualmin at all) and points to a different server. I don't suppose including the mail sub-domain in the certificate will break anything, as it should never be referenced, but it's untidy and unnecessary and just plain wrong (IMHO), and didn't used to be on the "old" server.

Just to be clear, the "old" server is completely up to date, and was also set up within the last two years -- actually, maybe just over, in July or August 2017 if I remember correctly.

Later today I will experiment with the Apache and/or BIND settings in the server templates and see if this results in the "mail" sub-domain not being included by default.

Yes, that is my intention.

I checked a small selection of domains on both the old and new servers -- ones that that had been added as new on the new server and ones that had been migrated -- and none of them even have "Mail for domain" listed under Edit Virtual Server -> Enabled Features, which, again, is my desire and intention by trying to disable every email-related function I can find in Virtualmin.

OK, good to hear about Jamie. Thanks.

Yes, I did consider that I can make tickets public after they're resolved, if they don't contain any information I'd rather keep private. I'll probably follow your advice in the future. I don't want to be rude to someone who might think they're being helpful, but looking for support from a software vendor is a very different situation from looking for help from a "community" of open-source software users. I do occasionally peruse recently updated or created tickets here, but I would never even consider posting in one with idle speculation as that person has done. Even if I knew for sure that I could help someone by saying, "Oh, yeah, click X then Y and it will work," I wouldn't because I don't know Virtualmin anywhere near as well as you, Jamie and Joe and there could be other factors that I might not even know are relevant.

OK, I sort of concluded that in message #2 and at the end of message #4, but I just haven't had the time to do the experiment I said I'd do at the end of message #4. I will do that on the weekend, as I'm unlikely to have the time tomorrow.

This seems like a good time to make another pitch for a feature i'd like to see, and that is I'd like it if the first question during the installation of Virtualmin was, "What do you want to use Virtualmin for?" followed by a checklist of major functions. For most of the people to whom Virtualmin is marketed, this would be web, email and DNS, but I'm sure some might want further options. My point is that references to "email users" and various other email functions on a server that does nothing but host websites is confusing to the point of being detrimental, so in my case I'd like to select just "web" and have all references to email be completely obliterated and all mail-related packages not installed (with the exception of the minimal email packages needed to allow websites to send emails as necessary).

I'll do as you suggest and post back here with the results. Thanks.

Jaime, yes, that would seem to me to make some sense, but it's a far cry from my overarching suggestion.

I've finally taken a closer look at this and tried to experiment. However, I'm more confused than before and do not see a direct correlation between my actions in one area of Virtualmin and the results in other areas.

In particular, I see no references at Virtualmin -> System Settings -> Server Templates -> PLAN -> Apache website referring to mail.$DOM -- or to mail.${DOM} either. The reference to this part of Virtualmin makes no sense at all to me in the context of this support request.

At Virtualmin -> System Settings -> Server Templates -> PLAN -> BIND DNS domain there are references to mail.$DOM -- or, more precisely, to mail.${DOM}. (Not trying to be picky; just trying to be precise to avoid misunderstandings.) Under "Hostname for MX record" the default setting (if I remember correctly) was "Default (mail.${DOM})". Changing this to "From default settings" does not seem to change the fact that Virtualmin wants to (by default) create SSL certificates for the root domain, www.domain and mail.domain. I've tried this on both a Pro installation (where some domains were imported from another Pro server) and a GPL installation with only newly added domains.

I'm pretty damn frustrated with Virtualmin these days. I was hoping that a fresh installation (without the pressure I was under for the first installation about two years ago) along with two years of using it under my belt would result in greater peace of mind, but in fact the opposite has happened.

Sorry for dropping the ball on this ticket, especially after I complained that you had dropped the ball. I've had other issues going on.

I'm assuming that you meant to refer to mail.${DOM}, not www.${DOM}. Correct? Assuming that's the case, there is no mention of mail.${DOM} in either of the server templates in use on my server, those being the one I created and the one that the Virtualmin import process created when it imported domains I had exported from my old server.

The template that I created on the new server uses "From default settings" at Virtualmin -> System Settings -> Server Templates -> TEMPLATE -> Apache website. This results in most (but not all) settings on that page being greyed out, including the "Directives and settings for new websites" textarea.

The template that was imported from the old server -- which, as I said earlier (I thought here, but it may have been in another ticket), I created before I was really familiar with Virtualmin -- does have an Apache template in the "Directives and settings for new websites" textarea (that I probably created), and the "Apache directives below .." setting activated. However, it does not mention mail.${DOM}.

Looking through a selection of virtual servers, it seems to be the server template that I created on the new server that uses "From default settings" at Virtualmin -> System Settings -> Server Templates -> TEMPLATE -> Apache website that is the problem; only those domains want to create a "mail" sub-domain for the virtual server when I generate a Let's Encrypt certificate.

So, I guess the "mail" sub-domain must be hard-coded (as Eric actually said in his first reply [comment #1] and I surmised in comment #2) in the default settings for Apache that I am using for that template. The obvious solution would seem to me to change that template and use my own directives in the "Directives and settings for new websites" textarea that do not include mail.${DOM}. Correct?

If that's the case, I wanted to switch all virtual servers that have been imported to the template I created on the new server anyway. How can I do that en masse?

With reference to your comment #15, you refer to "a domain [that] has email enabled." If there a single place to do such enabling and disabling?

Well, as ServerAlias mail.${DOM} seems to be hard-coded in the default settings at Virtualmin -> System Settings -> Server Templates -> TEMPLATE -> Apache website that's not something I can do except by creating non-default settings that don't include ServerAlias mail.${DOM}. I will go back and manually edit the Apache configs of the domains that have been added to the server since the migration.

... there's no way to mass update the Apache configs for all existing domains ...

This is part of what I was referring to in my latest comment (#6) in the ticket about creating scheduled back-ups on the command line by referring to "the set of operations that can be done by mass updates [being] expanded." The "Save and Apply" button that is displayed under a list of virtual servers using a particular Account Plan would certainly be handy under a list of domains using a particular Server Template.

As for your comment about comment #15, my comment at the end of my last message was about my comment in comment #14 above about having one master switch where I can switch off all mail functions and references to email and email users on a server that only hosts websites. However, let's not go down that rabbit hole again!

Unless I have problems related to changing the Apache configs referred to in my first paragraph, I'll consider this matter closed. Thanks.

Oooooohhhhh!!! Those are the infamous "default settings" that I (and Eric) thought were hard-coded? I had no idea. I thought that was just another possible example template. OK, if that's what I should do I will do it in the morning.

OK, understood on the making wholesale changes to previously implemented templates. I haven't thought it all through, but I'm sure you have and I can see your point.

I had this ticket marked for me to look at again, but your comment (#21) drawing my attention to the Default Settings template solved my issue. I'll close this now. Thanks.