How to prevent *.domain in SSL configs?

OS type and version Rocky Linux 9.1
Webmin version 2.001
Virtualmin version 7.3

I have successfully been using Virtualmin to create per-domain SSL certs via Letsencrypt, on my server running Apache, Postfix and Dovecot.

I have not enabled creation of wildcard domains for the certificates.

However, when Virtualmin creates the certificate entries in the configuration files, it also adds wildcard domain entries, which cause undesired behaviour when I have separate certificates for both and For example:

In dovecot/dovecot.conf:

local_name {
  ssl_cert = </etc/ssl/virtualmin/166734225438488/ssl.combined
  ssl_key = </etc/ssl/virtualmin/166734225438488/ssl.key
local_name * {
  ssl_cert = </etc/ssl/virtualmin/166734225438488/ssl.combined
  ssl_key = </etc/ssl/virtualmin/166734225438488/ssl.key

In postfix/sni_map:     /etc/ssl/virtualmin/166734225438488/ssl.key,/etc/ssl/virtualmin/166734225438488/ssl.cert    /etc/ssl/virtualmin/166734225438488/ssl.key,/etc/ssl/virtualmin/166734225438488/ssl.cert

In webmin/miniserv.conf and usermin/miniserv.conf:,*,*

How can I tell webmin/virtualmin NOT to create the entries for * and, and to create the entries ONLY for

I have tried looking in the SSL configuration areas for a likely setting without success.


OK, I’ve been doing some digging, and found the appropriate parts of virtual-server/, and there doesn’t seem to be a config option for this behaviour:

Line 1431:

# setup_ipkeys(&domain, &miniserv-getter, &miniserv-saver, &post-action)
# Add the per-IP/domain SSL key for some domain
sub setup_ipkeys
my ($d, $getfunc, $putfunc, $postfunc) = @_;
my @doms = ( $d, &get_domain_by("alias", $d->{'id'}) );
my @dnames = map { ($_->{'dom'}, "*.".$_->{'dom'}) } @doms;

I just want the last line to behave as:

my @dnames = map { ($_->{'dom'}) } @doms;

Line 2191:

# sync_dovecot_ssl_cert(&domain, [enable-or-disable])
# If supported, configure Dovecot to use this domain's SSL cert for its IP
sub sync_dovecot_ssl_cert
        my @dnames = map { ($_->{'dom'}, "*.".$_->{'dom'}) }
                         grep { !$_->{'deleting'} } @doms;


        my @dnames = map { ($_->{'dom'}) }
                         grep { !$_->{'deleting'} } @doms;

Line 2492:

# sync_postfix_ssl_cert(&domain, enable)
# Configure Postfix to use a domain's SSL cert for connections on its IP
sub sync_postfix_ssl_cert
        my @dnames = map { ($_->{'dom'}, ".".$_->{'dom'}) }
                         grep { !$_->{'deleting'} } @doms;

Again, need the option for just:

        my @dnames = map { ($_->{'dom'}) }
                         grep { !$_->{'deleting'} } @doms;

I could modify those sections of code as required, but obviously those mods would get lost when virtualmin got updated. Similarly, if I manually edited dovecot/dovecot.conf, postfix/sni_map and *min/miniserv.conf, I suspect those edits would be undone when subsequently saving a configuration.

Could I propose configurability of this behaviour as a feature request?

I can see it is actually a more complicated issue than just the above. For postfix and dovecot, for example, what I really need are two things:

  1. Not to create any entries in dovecot/dovecot.conf and postfix/sni_map for domains that have NOT been configured with “Enable mail for domain”.

  2. To be able to create specific entries for rather than and * (or in the case of postfix).

But in the miniserv.conf files, I think the *. should not be there. I have been finding that with two different certificates for and is causing the wrong certificate to be selected by webmin when a call to matches * in the config file instead.

Would be interested in others’ insights.

Huh. I can’t imagine why it would configure it this way for non-wildcard certificates. And, wildcards are not recommended, in general, so erring on the side of making things work with wildcards isn’t great.

I’ll ask @Jamie why it’s acting this way for non-wildcard certificates.

We do it this way because the cert might be for multiple sub-domains, even if it’s not a wildcard cert. Using * just tells Dovecot or Webmin to use that cert file for any requests under the domain, which is independent of whether it’s a wildcard or not.

But, that causes the problem identified by OP wherein a subdomain that has its own cert can’t get the right one (it gets the parent domain cert instead).

Yes, thank you! Exactly that is what the issue boils down to, or at least what made me go digging.

For now, I have made manual adjustments to the generated config files, and have a record of them courtesy of the excellent etckeeper, in case Virtualmin overwrites them in the future. As my server config doesn’t change that much, that will probably suffice for now.

I do think though that the entries in dovecot/dovecot.conf and postfix/sni_map should only be written for domains that have Mail for Domain enabled in the virtual server configuration, although that is arguably a separate issue from my original one.

Is the subdomain in this case a separate domain managed by Virtualmin?

Thinking about this some more, it seems like the right fix is for Virtualmin to popular dovecot.conf and sni_map in the correct order so that the more specific domain is listed first.

Alternately, we could add an option to not use * at all, and instead expand to the full list of hostnames from the cert. But I prefer the idea of fixing the order in the config, as it will work even if the cert is re-issued.

Yes, to be specific, the server was a clean install of Rocky 9 with the hostname, and Virtualmin created the first vhost with that name.

I then created a new vhost for, which automatically had aliases of www, mail and autoconfig within that domain (also admin and webmail too).

I created LetsEncrypt certs for both vhosts, but found that if I went to it would get the certificate for instead, because the SNI matched * instead of This happened initially when going to webmin itself, but also with Dovecot. I’ll reply more to the next message.

I’m not so convinced about resolving the ambiguity just by the order of entries.

It seems logical to me that SNI matching should only offer a certificate to an SNI for which the certificate is valid. Although it also doesn’t seem very logical to create SNI map and dovecot entries for all possible aliases.

Since the Virtualmin standard appears to be as the mail host, it seems to me that dovecot.conf and sni_map only really need to create entries for and (perhaps only even the latter), rather than and * or as appropriate.

And I feel that miniserv.conf should only match the exact domain names and not a wildcard.

Anyway, thank you for considering this issue, and I will watch with interest for how you decide to address it. For myself, I’m ok for now.

So I’ve started working on this, and was able to resolve the issue for Dovecot by re-ordering the dovecot.conf entries so that sub-domains come first. This seems cleaner to me than listing every hostname the cert is valid for in dovecot.conf, and it avoids the need to update that config if the cert is re-issued for new hostnames.

For Postfix, I’ll also need to make the same change, and possibly for Webmin as well.


Thanks! While you’re working on it, do you agree it would be better only to write entries to dovecot and postfix for domains that have been configured as “Mail for domain enabled”? At present it appears to write entries for all my virtual servers, even those without mail enabled.

1 Like

We actually did skip adding the entries for domains without email enabled initially, but some users reported that they still wanted this because the domain owner can receive email at the system’s hostname. I don’t see how it can cause issues to have extra entries in dovecot.conf though?

OK, fair enough. It doesn’t cause problems, but just seemed untidy, and I didn’t know the history.

Further update - after the next Webmin and Virtualmin releases, Postfix SNI maps will be properly configured to put sub-domains first so that the correct cert is used.


thanx for this quick solution, I had problems with these wildcard/ordering recently, too.

While we are at this: I’ve had some trouble recently when deleting (sub)domains, that the corresponding cert wasn’t deleted from dovecot (and perhaps postfix, don’t remember)
config files. This was bad, as a (much later) reboot let not start dovecot due to
the missing cert files. Is this maybe fixed in the mean time, too?

Thanx in advance!

I haven’t seen that bug recently - does it happen consistently? Are there certain steps which can trigger it?

I had to dig a bit in my git logs, so I’ve found that it was really :wink: 9 months ago
using webmin 1.990 - didn’t find which virtualmin version at that time. The deletion of the domain was on Feb 16 2022, the failed reboot on Mar 10 2022.

So, hopefully it’s fixed. Sorry for the noise.

Yes, please let us know if you can re-produce this with a more recent version…