Dovecot.conf duplicate entries after line 3475 on 220 domain server

Virtualmin
1
SYSTEM INFORMATION
OS type and version Ubuntu 24.04.3 LTS
Webmin version 2.510
Virtualmin version 7.40.1
Webserver version Apache/2.4.58
Related packages Dovecot 2.3.21 (47349e2482)

Recently on a server that only provides email dovecot.conf entries are mangled, out of bounds, and duplicated.

The duplicates are like the example below. example1.com is what we would typically expect, and example2.com shows the duplications:

local_name example1.com {
  ssl_cert = </etc/ssl/virtualmin/17594035742849915/ssl.combined
  ssl_key = </etc/ssl/virtualmin/17594035742849915/ssl.key
}
local_name *.example1.com {
  ssl_cert = </etc/ssl/virtualmin/17594035742849915/ssl.combined
  ssl_key = </etc/ssl/virtualmin/17594035742849915/ssl.key
}
local_name webmail.example1.com {
  ssl_cert = </etc/ssl/virtualmin/17549938561617050/ssl.combined
  ssl_key = </etc/ssl/virtualmin/17549938561617050/ssl.key
}
local_name *.webmail.example1.com {
  ssl_cert = </etc/ssl/virtualmin/17549938561617050/ssl.combined
  ssl_key = </etc/ssl/virtualmin/17549938561617050/ssl.key
}
local_name example2.com {
  ssl_cert = </etc/ssl/virtualmin/17594265633325517/ssl.combined
  ssl_cert = </etc/ssl/virtualmin/17594265633325517/ssl.combined
  ssl_cert = </etc/ssl/virtualmin/17594265633325517/ssl.combined
  ssl_key = </etc/ssl/virtualmin/17594265633325517/ssl.key
  ssl_key = </etc/ssl/virtualmin/17594265633325517/ssl.key
  ssl_cert = </etc/ssl/virtualmin/17594265633325517/ssl.combined
  ssl_key = </etc/ssl/virtualmin/17594265633325517/ssl.key
}
  ssl_key = </etc/ssl/virtualmin/17594265633325517/ssl.key
  ssl_cert = </etc/ssl/virtualmin/17594265633325517/ssl.combined
local_name *.example2.com {
  ssl_key = </etc/ssl/virtualmin/17594265633325517/ssl.key
  ssl_cert = </etc/ssl/virtualmin/17594265633325517/ssl.combined
  ssl_key = </etc/ssl/virtualmin/17594265633325517/ssl.key
}

We seem to have stablized the system somewhat by upping default_vsz_limit = 256M to 512M, so no more memory crashes, but we can reliably reproduce the duplications by simply adding a new domain.

Maybe the duplications are fine, because they are exactly the same, but other times we end up with this issue by removing the duplications.

2025-10-02T19:35:26.185272+02:00 host dovecot: imap-login: Error: Failed to initialize SSL server context: Can't load SSL certificate (ssl_cert setting): The certificate is empty: user=<>, rip=1.2.3.4, lip=5.6.7.8, session=<BgYaaTBACuqcm7Fw>

Our fix then is to just remove and add the domain again, and ignore the duplications.

We need to break the system down and simplify it and gain some insight into volumes. My one gut feeling is the configuration interpreter reads the dovecot.conf file, gets confused due to the sheer volume of line items, and doesn’t complete it’s job.

I’m not sure. Just need anything to try next.

2

I’ve had exactly the same issues when restoring virtual servers from backup. Never had it happening when adding the server first and then restoring the backup.

Anyway I’ve now started to inspect the dovecot.conf -file every time I add or remove virtual server, pretty annoying.

I have 130 domains hosted.

3

I’m about 15 hours into troubleshooting this issue.

My latest theory is this:

We create an ordinary domain, say “example1.com”.

Then, to avoid many instances of RoundCube being installed, we create an alias on a holding domain, say “host.server.com”, and this is called “webmail.example1.com” with the DNS Feature enabled.

At this point, dovecot.conf has four entries per domain, e.g.:

local_name example1.com {
...
}
local_name *.example1.com {
...
}
local_name webmail.example1.com {
...
}
local_name *.webmail.example1.com {
...
}

My theory is that things go haywire from there. Both from a Dovecot point of view and also very much from an SSL binding to Dovecot point of view.

Basically Dovecot then flip flops between confused states of combined SSL keys, and just normal SSL cert.

And still perhaps the Perl interpreter reads the dovecot.conf file expecting a consistent list of domains but the “duplicates” causes it to break things because it doesn’t know where things start and stop properly.

I might be construing two problems into one, but heck, this is so difficult to troubleshoot. Here are again some of the SSL errors that I just can’t find workarounds for:

Error: Failed to initialize SSL server context: Can't load SSL certificate (ssl_cert setting): The certificate is empty: user=<>

and

Disconnected: TLS initialization failed

and

dovecot: imap-login: Error: Failed to initialize SSL server context: Can't load SSL private key (ssl_key setting): Key is for a different cert than ssl_cert: user=<>

For now to simplify things I’m removing DNS on all webmail.* domains to see if this simplification of the file works.

4

After another 5 hours I found the culprit thanks to this post, and specifically this sentence (hats of to Christian Kivalo !):

image
image665Ă—351 24.1 KB

To recap, the client has over 220 domains on one server.
We thought is was duplication in dovecot.conf that is causing issues.

In fact, it was ChatGPT that caused issues.

The client tried fixing the repeat of Can't load SSL certificate (ssl_cert setting) that they saw in the log file. When the server was handed to me to fix, I noticed that Dovecot wouldn’t start and further notice it complained about a missing ssl_certificate here:

/etc/dovecot/conf.d/10-ssl.conf

Settings:

# Commented out YYYY/MM/DD because Dovecot didn't want to start up
#ssl_cert = </etc/ssl/virtualmin/17549938561617050/ssl.combined
#ssl_key = </etc/ssl/virtualmin/17579316602518260/ssl.key
# Added the correct certificate files YYYY/MM/DD !
ssl_cert = </etc/dovecot/private/dovecot.pem.
ssl_key = </etc/dovecot/private/dovecot.key

My gut feeling is the 10-ssl.conf file was broken by following bad advice. What made this complicated to solve on a busy server, is for each ssl_cert setting we had 4 x 220, and we kept on looking and working in the wrong place.

If anyone has made it this far in reading this post, especially the developers, I have to break the news that Usermin is fantastic but the typical end-user doesn’t like Usermin and prefers Roundcube.

We got ourselves into this mess because because we had to help with a implementation for “many users” without installing 220 copies of Roundcube.

What triggered the false diagnosis as mentioned is that the aliases domains were also trying to create DNS and adding more clutter to dovecot.conf.

The ideal situation is that Virtualmin gives us a super user friendly way to “just get aliased” webmail to Roundcube working.

For our environment, apart from creating the aliased domains, we have to take a number of other steps too:

  • Disable the default Usermin port 20000 redirection, by server templates, website for domain:

image

  • Create a template that will still create a webmail.* record after each domain creation

image
image684Ă—272 22.5 KB

Then you just create an alias as usual on an anchor domain, WITHOUT DNS to avoid clutter.

I love Virtualmin and my as a tech loves Usermin and it’s power too, but for my typical end-user I can’t give two tools and most prefer Roundcube.

Maybe as a start, on the Edit Server Template → Website for domain, instead of just “Redirect webmail.${DOM} Yes/No”, another option,

“Still create webmail.${DOM} DNS record when creating server.”

One less step to easily configure Roundcube for all :slightly_smiling_face:

5

I’ve been doing some migration from server to server using the built-in backup & restore -functions and this is really getting frustrating :frowning:

I’ve narrowed it down, that if I choose to restore SSL sertificates, it pretty much always corrupts the dovecot.conf file:

Screenshot 2025-10-06 at 8.22.59
Screenshot 2025-10-06 at 8.22.59778Ă—472 86.6 KB

Highlighted row is the one that’s causing the whole dovecot going haywire and SSL-connections to IMAP etc starts to fail. Every time I restore server, I have triple check the whole dovecot.conf and fix it manually & restart the service.

It also usually corrupts if I restore top level server with it’s sub servers at the same run. Usually restoring just single top level servers works 9/10 times.

Here is an example of my dovecot.conf after restoring parent server with some sub servers, as you can see, it’s a total mess :smiley:

Screenshot 2025-10-06 at 10.17.38
Screenshot 2025-10-06 at 10.17.381416Ă—1714 260 KB

Here are my system details:

SYSTEM INFORMATION
OS type and version Ubuntu Linux 24.04.3
Usermin version 2.400
Virtualmin version 7.40.1 Pro
Theme version 25.10
Apache version 2.4.58
Package updates All installed packages are up to date

Ping @Ilia or someone who might know more about the bug :slight_smile:

6

Can you show what the /etc/dovecot/dovecot.conf file looks like on the source (old) system?

9

The initial part of the restoring (re-creating…) process goes ok and dovecot.conf gets updated correctly. It seems to be the stage “Restoring backup for virtual server..” where it goes wild.

How interesting! @Jamie and I fought this bugs years ago, we solved it, and no one has reported this recently.

Can you make a backup of outindesign.fi for us? You should exclude the public_html directory and not back up the database. Then attach it to the private message and mention us with @staff.

1 Like
10

Please try this patch and let us know if it fixes the issue for you:

webmin patch https://github.com/virtualmin/virtualmin-gpl/commit/be76bc6
11

Seems to work! Just restored 3 servers with sub servers for the sake of testing. No corruption to the dovecot.conf file :slight_smile:

1 Like
12

Excellent! We will include that in upcoming Virtualmin 7.50.0.

Thanks for reporting this in the first place, kamu!

1 Like
13

Thanks a lot for quick fix, kamu! :wink:

1 Like