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:

example.com www.example.com mail.example.com

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

Thanks.

Craig

Status: 
Closed (works as designed)

Comments

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 mail.domain.com 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.

The field at Virtualmin -> System Settings -> Server Templates -> PLAN -> Apache website that is relevant here is "Directives and settings for new websites", specifically the line ServerAlias www.${DOM} . If that's missing, Apache for new domains won't get configured to accept requests to http://mail.domain.com , which also means that no Let's Encrypt cert will be requested for that hostname.

The way Virtualmin decides which hostnames to include in the Let's Encrypt cert request is to look at the Apache and DNS configs. The hostnames domain.com , mail.domain.com and autoconfig.domain.com are added to the cert iff they are in both configs.

Most of the time this works, but in your case I understand from comment #4 that the mail subdomain is hosted separately, and you don't receive email on your Virtualmin system at all. Hence the change I suggested in comment #15 will resolve this.

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?

Yes, changing the template to remove the ServerAlias mail.${DOM} line will fix this issue for new domains. However, there's no way to mass update the Apache configs for all existing domains ... you'd have to manually edit the Apache config file to remove them.

Regarding comment #15, that's a change we will make in Virtualmin in the next release. But removing the mail. ServerAlias will have the same effect.

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.

Regarding the template, can you not edit the field at Virtualmin -> System Settings -> Server Templates -> Default Settings -> Apache website -> Directives and settings for new websites ? That will also apply to all templates that don't have custom directives.

Regarding applying a changed template, this is tricky because there may have been all kinds of other changes to the Apache config after a domain was created, and merging those with a new template is near impossible..

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.

Yeah, you can edit that template.

Status:
Active
»
Closed (works as designed)

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.