So looking into this further, I think that we should make Virtualmin only copy the default domain’s cert to BIND, Dovecot, Postfix, etc. if a valid LE cert is received. Otherwise we can end up in an odd state like this.
1 Like
I would prefer the hostname certificate to be used so the domain accounts are kept separate.
Client accounts should always be separate. If manual certs are used for them, there might be legal implications of using their certificate for something that is not theirs.
Also if the cert on the DoT services needs to be validated in the future, it will come back with a client’s details on it.
It should already be the case because the hostname SSL cert is copied as default across all services like Postfix, Dovecot and others.
1 Like
@Ilia can you send a PR for this fix? I don’t follow the code for creating the default domain well enough to figure it out.
Yes, sure! It was added through a PR last year:
Right, and I think what we want is to not do that if the default domain is going to be deleted.
We only do it if the SSL cert request is successful. If not, we don’t set it up at all in the first place. And, we delete the domain only if the SSL cert request is not successful.
However, when the host SSL certificate with the domain is removed, the service certificates are removed also:
Those are only the certs specific to the domain’s IP or hostname though. The problem here is with certs used globally by BIND.
Well, yes, those would also be removed—otherwise, how can we delete a domain and have those SSL cert files in place? We delete everything under /etc/virtualmin/ssl/<dom-id> too, right? And, in this case, I think we should clear BIND configs, right? Until a new domain is chosen to be used as global default, right?
Actually in most cases, we copy the cert into the BIND or Postfix or Dovecot’s directory, so that even if the domain is removed they keep working. Because there is no support in Virtualmin for removing the global cert for other servers if the domain it was originally created from is deleted.
That’s right! So, what problem are we solving then? What’s not working?
The only problem I see is that we shouldn’t copy the cert for the default domain to BIND / Postfix / etc unless it’s a real cert from Let’s Encrypt.
Agreed! I don’t do it in my code as far as I know—I only copy it after a successful LE request.
Could you also check if we’re doing it somewhere else, maybe?
I would check the status of the bind process. That way you can see the actual error message.
I think it makes sense to keep it enabled. I think it is great that virtualmin now apparently embraces DNS over TLS. This way requests to your dns can be made encrypted, even though between nameservers this is not yet as common I believe.
Hello! I have been a Virtualmin user for more than 10 years and it has always helped me a lot, thank you very much! Now, I wish to add 3 new servers, but yesterday, when I started with the first one, I haven’t managed to get it to work. At first the Apache was not activated; After much searching, I found that there were two attempts to listen for port 443. I removed the extra lines and was able to activate the Apache. However, I couldn’t see virtaulmin’s homepage in an internet browser. That’s how I came to this thread. The version that is downloaded with the automatic installation is 7.40.1. Is there a way to install version 7.30.8 while you finish making adjustments to 7.40.1? The new server is a Debian 12 without any other software intalled on it.
Thanks, so much!
I’m seeing similar issues on 7.40.0. Looks like systemd-resolved on Debian 12 is causing DNS timeouts (127.0.0.53). Try pointing /etc/resolv.conf to a public DNS (like 8.8.8.8) or check if bind9 is starting cleanly. Rolling back to 7.39.x fixed it for me too — so might be a regression.
Yes, you’re not alone — several users have reported DNS-related issues after upgrading to Virtualmin 7.40.0, especially on Debian 12. We’ve seen delays in DNS propagation, timeouts with 172.0.0.53, and unusually long installation times. Rolling back to 7.39.x seems to restore normal behavior.
It’s likely something changed in how DNS or systemd-resolved is being handled in the 7.40.0 installer or post-install config. As a temporary workaround, try manually adjusting /etc/resolv.conf or disabling systemd-resolved, and see if that resolves the lookup issues. Also, keep an eye on Virtualmin forums or GitHub for a patch or official update.
@cartdaniel @hariiee @agusdiaz Does your system have an IPv6 stack configured?
If you upgrade to the latest Virtualmin 7.40.1 and then apply the following patch:
webmin patch https://github.com/virtualmin/virtualmin-gpl/commit/7fdbe16
…does it fix the DNS problem?
No, I have tried two times reinstalling from 0 the server and Virtualmin, apply the patch and no change…
I need to setup at least one of my new servers, would you please tell me how could I install 7.38.x o 7.39.x mean while?
Thanks so much!