I had an issue recently where vmin was showing a different SSL cert to what our browsers was displaying. I managed to fix this by removing references to some old SSL certs within /etc/webmin/miniserv.conf. I didn’t add them in there so either vmin or certbot did, presumably it was vmin?
Previously, in our old vmin server, I’ve used the certbot command line tool to create and update SSL certs for the webmin/vmin login page / the main domain of our virtualmin server. Is this not how we are supposed to that, is there a feature within vmin for that? I expect so but I don’t know where it is.
How do ssl certs end up in miniserv.conf? What is the correct way to clean up old or incorrect SSL certs created by certbot? We created a wildcard cert for our domain in error and we want to revert to a cert for the main domain only. I tried tidying up the old certs manually and trashed apache.
If I change SSL cert details using certbot, it won’t adjust my miniserv.conf file so I presume you advise against people using certbot?
If you created a certificate in Webmin (not in Virtualmin for domains), under Webmin->Webmin Configuration->SSL Certificate->Let’s Encrypt, you’d potentially be conflicting with Virtualmin-managed certs.
The general case for a Virtualmin system, you should use Virtualmin for managing certificates, and you’d use Virtualmin-managed domain names to connect to Webmin (i.e. once you have Virtualmin domains, you no longer login to https://system-hostname:10000, you log in to https://some-virtualmin-domain:10000 and Webmin will use the Virtualmin-managed certificate). You would never use the Webmin form to generate a certificate, you’d use the Virtualmin form.
If that’s not how you got there, I don’t know. Certificates should be automatically managed by Virtualmin for all services it can manage, and you probably don’t need to think about it.
So, if that’s not it, can you be more specific about what you’re seeing? Certificates managed by Virtualmin will include some information about the related domain in their option name (e.g. ipkey_domain.tld, ipcert_domain.tld), and they’ll point to the Virtualmin-managed certificate files. What were the “references to old SSL certs” exactly?
That has nothing to do with OPs questions. If you have questions about Webmin and managing your own Certificate Authority, you should start a new topic.
OK so it seems to me that you don’t have an SSL specific docs beyond what I linked to in the OP so I’m really hoping this situation will improve. I can’t be the only person who finds this quite complicated but its also fundamental to getting a vmin server configured.
When I said CA I did indeed mean Certificate Authority, some online entity who provides SSL certs.
Straight off, I hope you can see why I’m confused. That feature ( Webmin->Webmin Configuration->SSL Encryption->Let’s Encrypt->Request certificate) is the feature that I would’ve guessed I should be using to manage the SSL cert of https://system-hostname:10000. I don’t think I knew this feature existed the first time I installed vmin so I just used certbot. I managed to get that to work somehow so thats what I’ve been trying to do this time.
My limited understanding of the vmin configuration is than webmin / https://system-hostname:10000` uses miniserv as its web server then vmin uses apache or nginx to manage all the other sites. If that is the case, I’m wondering how I got certbot to work with miniserv and I don’t think it claims to support miniserv?
If I try running Webmin->Webmin Configuration->SSL Encryption->Let’s Encrypt->Request certificate on my vmin server that already has a LE cert created by certbot, I get the error:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate for mydomain
Unable to change the --key-type of this certificate because --reuse-key is set. To stop reusing the private key, specify --no-reuse-key. To change the private key this one time and then reuse it in future, add --new-key.
So that sounds to me like I would somehow need to remove / tidy up or modify my previously generated LE cert if I was wanting webmin to manage the cert for https://system-hostname:10000. I am unsure how I would do this without breaking apache and or miniserv?
When I mentioned “references to old certs” it looked to me as if there were at least two different certs mentioned in my miniserv.conf and my browser was showing an older SSL cert when I visited :10000 than the cert details vmin was showing me.
How do you recommend I create and manage (update) LE certs for https://system-hostname:10000 ? I presume that if I create a LE cert for https://system-hostname:10000 using Webmin->Webmin Configuration->SSL Encryption->Let’s Encrypt->Request certificate it will get auto renewed every few months?
Do you really need an ssl certificate for the hostname ? The only reason that i can think of is to avoid the certificate warning when logging into webmin using the hostname. As virtualmin configures each created domain to use domain.tld:10000 to access webmin and :20000 to access to access usermin. Most services e.g postfix are configured in the same manner given that there is no need to have a certificate for the hostname, unless you have configured a domain to match the hostname which you shouldn’t do
Ok so there is a way around this why not remove the dns entry for the hostname so it no longer resolves or remove the wildcard dns entry for the domain that your hostname is linked to and add each dns record required, but this won’t please the security team as you can still access webmin via the server ip which will not be encrypted
The post I was responding to (which has been deleted) was asking about a completely unrelated feature in Webmin. (Webmin can manage a local CA for cert-based authentication. That is not related to the problem you are trying to solve.)
You should not worry about the system hostname.
Once you have Virtualmin domains, any of them will work for logging into Virtualmin (and Webmin). So do that. Getting a certificate for the system hostname in the Webmin form is trickier, and there’s no way we can make it less so.
miniserv is the web server for the UI in Webmin and Virtualmin. You do not need to manage certificates for it. Any domain in Virtualmin that has a TLS cert can be used to log in to Webmin/Virtualmin, with no configuration or manual futzing around. Everything on port 10000 is miniserv.
Your websites are hosted by the web server you chose during installation (Apache or nginx).
You do not use certbot directly in any circumstance, if Virtualmin is managing your TLS records. If you ever use certbot directly, you are going to break something. Maybe that’s how you got into this situation?
You should not do that. If you’re using certbot directly, use certbot always. I’m not recommending you do that, but you can. But if you do, you have to always do so.
And, you’ll need to configure the Webmin TLS configuration yourself and make sure it’s always pointing to the correct certs (including through renewals). This is also true of Virtualmin domain TLS certs. If Virtualmin is managing your certs, you don’t have to think about it (unless something goes wrong).
I still don’t know exactly what you mean. I gave examples of what Virtualmin-managed certs look like in the miniserv.conf, and there will be multiple instances of those if you have multiple domains with certs managed in Virtualmin. miniserv can have multiple certs, and it may or may not have a cert for the system hostname (but it does not need one, you never need to talk to anything on the system using the system hostname, so it doesn’t need a cert, you’re just making work for yourself that you don’t need to do).
Also, I guess I should mention Virtualmin tries to setup a hidden virtual server for the system hostname so it can manage a Let’s Encrypt cert for the system hostname automatically (at least, I’m pretty sure this is still in there, even though I don’t like the idea or the implementation, I think it works OK now if your system hostname resolves when you install Virtualmin). That would also cause conflicts with trying to manage a separate cert in Webmin or using certbot for the system hostname. The TLS configuration in miniserv.conf would tell us whether that’s where the “extra” certs came from. There are many ways to break Virtualmin managed certificates, if you go out of your way to do so.
But, in all cases: Using certbot directly breaks anything managed by Virtualmin, so don’t do it. And, a cert for the system hostname managed in the Webmin UI is more complicated to validate and manage than certs managed for Virtualmin domains (for a variety of reasons, Webmin doesn’t have “ownership” of the whole stack the way Virtualmin does…if Virtualmin is correctly configured, it knows what your DNS looks like and maybe can manage it, it is responsible for your Apache or nginx configuration and is able to modify it to suit Let’s Encrypt validation…Webmin can do that, and tries, but it has a different mandate than Virtualmin and does a lot less in this context). You don’t need to do it. Just use Virtualmin for your TLS certificates and forget the system hostname even exists, you never need it for anything.
Don’t use this feature with Virtualmin. We’ve updated the Webmin code to stop Certbot from renewing Virtualmin-managed domains automatically, even if certbot.timer is unmasked and re-enabled.
Head back to that page and disable it…
If your hostname can be resolved now, all you need to do is enable the “Setup Let’s Encrypt SSL certificate for hostname” option on the “System Settings ⇾ Virtualmin Configuration: SSL settings” page, and re-run configuration check — it will be automatically prompted after you save mentioned page.
What is the correct way to clean up old or incorrect SSL certs created by certbot?
Certbot tracks the domains it manages in the /etc/letsencrypt/renewal directory. In Webmin, you can manually edit the miniserv.conf file to remove certificates for specific domains that no longer exist by locating entries starting with ipcert_ and ipkey_.
To revert to the default self-signed certificate, locate in miniserv.conf file the certfile= key and delete it. Then, find the keyfile= key and replace it with:
Thanks to Joe and Ilia to explaining in more detail how miniserv, webmin and vmin handle SSL certs.
I would very much like to see the information in this thread brought together in a more easy to read way for confused sysadmins who don’t know or don’t enjoy reading perl who may get confused about how virtualmin and webmin handle, or at least prefer the user to handle SSL certs.
I would like to see a new vmin/webmin SSL docs page for sysadmins that covers all of the details you’ve just explained to me ie everything we need to know regarding SSL certs and how you prefer we handle them and then link to this new page on the “how to add an SSL cert” page. I can’t be the first person to not fully understand how SSL certs are supposed to work across webmin, vmin and miniserv etc yet its important knowledge for those setting up a vmin server.
I’m so sorry we all have to deal with ssl certs. Bane of my life! I hope they go away soon.
I was updating my notes on virtuamin config today and I noticed this, which I’d forgot about. It may be useful to someone else or could be added to any new vmin/webmin SSL docs:
Fixing the Webmin portal SSL cert and key paths
After you initially install LetsEncrypt under Webmin, if you look under Webmin → Webmin Configuration → SSL encryption → SSL Settings tab you will see input boxes for your sites Private (SSL) Key File and the certificate file. The installer creates certs in and configures these paths to /etc/webmin/letsencrypt-key.pem for the key and /etc/webmin/letsencrypt-cert.pem for the cert but these need to be changed to:
From my perspective I don’t need to change this unless you have produced or added the hostname to an ssl certificate I just wonder why this is important to some people as when you are up and running you don’t need it and TBF you can accept the self signed certificate for the first login and then use a newly created domain to then administrate the system