Feature request: Add Option on Create Virtual Server page to stage Let's Encrypt

I think it would be a good idea to add an option on the “Create Virtual Server” page to set Let’s Encrypt SSLs to staging (test mode) so users can test if it is working. And so if they delete and recreate their websites in Virtualmin they don’t run out of SSL certificates from Let’s Encrypt.

OS type and version Debian 12
Webmin version 2.111
Virtualmin version 7.10
Related packages SUGGESTED

There are some settings there in the Server Configuration.

Doesn’t show much difference

I mean how it’s done on the webmin configuration SSL page. There is an option to set it to “Staging (test only” . But instead make it an option before creating the virtual servers.

I did see an option in the virtualmin configuration to turn it off. But having all three options of On, Off, or Staging (test) would be nice to have during virtual server creation.

Alot of new users might not realize that they will run out of SSL certificate request from Let’s Encrypt. Might want to give a warning on that page also. Maybe give a count of how many times they requested SSLs also.

Can you link me to the let’s encrypt documentation on this, when virtualmin requests for me, it requests 50 certs in one go, I would to know what the upper limit is. Or do mean the amount of failed requests due to either misconfigured web server or dns ?

Looks like it is this page:

I think the limit I hit easily was the duplicate certificate limit of 5 per week. If you delete your virtual server and create it 5 times with an SSL request. Then you will have to wait up to a week to request an SSL again for a domain.

It’s this section on the page.

" Renewals are treated specially: they don’t count against your Certificates per Registered Domain limit, but they are subject to a Duplicate Certificate limit of 5 per week. Exceeding the Duplicate Certificate limit is reported with the error message too many certificates already issued for exact set of domains.

A certificate is considered a renewal (or a duplicate) of an earlier certificate if it contains the exact same set of hostnames, ignoring capitalization and ordering of hostnames. For instance, if you requested a certificate for the names [www.example.com, example.com], you could request four more certificates for [www.example.com, example.com] during the week. If you changed the set of hostnames by adding [blog.example.com], you would be able to request additional certificates.

Renewal handling ignores the public key and extensions requested. A certificate issuance can be considered a renewal even if you are using a new key."

But if you backup the SSL cert and key you can still use it. But if you delete the virtual server like I did then you don’t have a backup. At least I think that’s how Virtualmin works. I could be wrong. But maybe Virtualmin shouldn’t delete the SSL certificates. And instead detect if they exist for that domain already and just use them. That would be a nice feature also. I know they store them outside of the home directory now. This is the path on the Default Server Template (/etc/ssl/virtualmin/${ID}/).
I haven’t seen a setting to tell it not delete the SSL though. Maybe offer that also?

Why would you do that ? Perhaps if you are a developer trying to understand the process used. But I would guess if everything is left standard this will never happen. So I guess you are doing something odd or just using the mantra just delete the vs and start again ? Tbf a better point would be to only allow the user x times to ensure that your issue is never hit. It would be better to work out why said virtual server is falling rather than an amount of deletes and creates perhaps

This is a Virtualmin Pro feature.

Switching operating systems a few times on my VPS using their automated reinstall script played a factor also. I needed to backup the SSL certs and keys in that case. These are the types of issues I’m trying to avoid by documenting the install process and creating shell scripts to automate it. So I should just add backing up and downloading the SSL certs as part of the process.

Switched from Debian 12 to Ubuntu 22.04 thinking Ubuntu had more features. But then I read that Debian 12 is actually more up to date. To use the latest version of NGINX you need either Debian 12 or Ubuntu 24.04.

Not that easy to backup backup and restore the SSLs from command line though.

The path to the SSL certs looks like this:

with contents:
ssl.cert, ssl.combined, ssl.everything, ssl.key

So no indication of which domain it is. The number I think is just a timestamp.

You have to run this command to figure it out what domain it is for.
openssl x509 -in /etc/ssl/virtualmin/171846700015697/ssl.cert -text -noout

So looks like the easier way is to use:
Virtualmin, Manager Virtual Server, Setup SSL Certificate, “Current Certificate” tab
and then Download certificate (PEM format), Download private key (PEM format).

Then to restore:
Virtualmin, Manager Virtual Server, Setup SSL Certificate, “Update Certificate and Key” tab
and upload or copy and paste them into the form.

I thought maybe I could use Virtualmin Backup and Restore . But I don’t see an option to backup the SSL certs. I tried backing up the entire website with it. And it doesn’t look like the SSL certs are included.

I think I may have found an issue in Webmin now. I was trying to backup the SSL cert and key for the host domain in Webmin.

Went to: Webmin, Webmin Configuration, SSL Encryption, “Current Certificate” tab. And it only shows the “Download certificate” option. And doesn’t show the “Download key” option. Even though the key is on the server. I can see the .key file is there if I go to the “Per-IP-Certicate” tab. So to download the .key file in Webmin I’d have to use the file manager instead.

Assuming everything is standard you can find the key location here

but as you are using scripts to automate, why not get the value from miniserv.conf with something like

grep 'keyfile=' /etc/webmin/miniserv.conf | sed 's/^.*=//'

and get your script to use path from there and do whatever you want with the keyfile from there ?

My Let’s Encrypt ssl cert and key for the default host domain are in these directories:


In the box you pointed out mine says:

I check it and it is the self-signed key and certificate directory. Strange it still says that though. Even though on the per-ip-certificate tab it shows the correct directory for the Let’s Encrypt SSL certificate.

Looking in the web browser though it does show it as using the Let’s Encrypt SSL. So webmin configuration must be correct for it.

what does this give you ?


In /etc/webmin/miniserv.conf I have these. Where ipcert_host, ipkey_host, ipextracas_host have the host domain SSL paths set.



I guess I should set keyfile=/etc/ssl/virtualmin/171846400638622/ssl.key
Just in case I ever save something on the webmin configuration page and overwrite the Let’s Encrypt SSL key. That could be a problem. This is on the LEMP version of Virtualmin btw. Not sure if the same issue exists on the LAMP version.

Hmm the per ip addresses are certs set for the domains you have created the webmin cert is the set as a default for the host name, so for example if you had a match all sub domains record in your dns and you choose to navigate to sub.domain.tld:<webmin port> and you have not created that sub domain, webmin will use the webmin cert but if you have it created webmin will use the cert that eludes to the domain. I would not worry to much about it just login to webmin using a created domain instead of the hostname or ip or if you wish use whatever cert you like that will be used for domain names that resolve to your ip but are not managed by virtualmin or if they are don’t have a non self signed cert in place.