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

For some reason, Virtualmin wants to generate Let's Encrypt certificates for three domains:

From where is it deciding that it needs to include the "mail" sub-domain?





Howdy -- thanks for contacting us!

It would normally attempt to include every alias, and "mail" is one of the aliases it would attempt to use in the SSL creation process. I believe that's hard coded into Virtualmin.

You should be able to override that by manually setting which domains to include in the SSL cert. Let us know if you're seeing an issue with that though.

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?

While not super recent, the "mail." alias is newish (as in the last year or two if I recall).

I believe it automatically attempts to include that if the "Mail for Domain" feature is enabled.

Are you domains using the email feature?

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

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.

It sounds like in the Server Templates and Account Plans that mail has been more or less disabled -- but what about in the Virtual Server features?

That is, in Edit Virtual Server -> Enabled Features, is the Mail for Domain feature enabled?

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.

I'm unfortunately not quite sure, I think we're going to need Jamie's input on this one.

Also, note that if you don't want community members to respond to your posts, we'd really just recommend making them private :-) You can always set them to public when they're completed.

Joe is working on new ticketing software, and we may end up just making all tickets private in that one (we'll also be getting new Forum and Billing software, yay!).

I touched base with Jamie about the 3 issues you had open, we should be hearing from him soon!

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.

The reason mail is included in the SSL cert is to support SMTP clients that use an SSL connection to for sending email. The only way to prevent this currently is to update the Apache template for new domains to not include mail.$DOM in the ServerAlias directive. That said, it's quite harmless to include.

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.

One small change we could make would be to not setup the mail. DNS record unless a domain has email enabled.

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.