I ran this command: "Request Certificate" via UI in Virtualmin.
It produced this output: Requesting a certificate for awards.botany.org, www.awards.botany.org from Let's Encrypt ..
.. request failed : Web-based validation failed :
cannot change profile for the next exec call: No such file or directory
My web server is (include version): Apache version 2.4.41
The operating system my web server runs on is (include version): Ubuntu 20.04.3
My hosting provider, if applicable, is: AWS
I can login to a root shell on my machine (yes or no, or I don't know): Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Webmin 1.981/Virtualmin 6.17-3
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
/home/ubuntu# certbot --version
cannot change profile for the next exec call: No such file or directory
The above domain currently has a valid letsencrypt cert on it, but these errors started happening when renewal time started.
Thank you for asking about the certbot --version; that yields the same information so I am concluding that the error message in the Virtualmin UI is about certbot as well. Do I need to reinstall the certbot snap? I have little knowledge of snapd at this point, and no knowledge of what snap dependencies letsencrypt has.
This does not answer your problem as to why your renewal request failed now. Just pointing out further info to help resolve. I am not familiar with VirtualMin at all. You could search this forum for other threads on that and maybe you will find something helpful. This is the most recent:
Sorry to be pedantic but let's clear up some terminology. Lets Encrypt (LE) is a Certificate Authority which issues certs by way of ACME protocol. You need an ACME client on your server to get certs from LE.
So, LE itself has no snap dependencies since nothing it does is on your computer. It is just the client on your system.
Certbot is one such client but there are others. You seem to have used VirtualMin. I see someone else is replying too so hopefully they know more about VirtualMin.
LetsEncrypt does not have any snap dependencies, nor will it run on snap. It is a cloud service available by API.
Certbot is one of the MANY LetsEncrypt clients, and runs on Snap. When installed via snap, it will install it's dependencies. A very early version of Certbot was titled "LetsEncrypt", but it then became it's own project.
What @MikeMcQ is trying to determine with you, is exactly what client you previously used. It appears the VirtualMin application/service handled getting the LetsEncrypt certificate for you; you need to figure out how it did that -- through an internal feature or by calling an external client -- and what external client that is.
It's possible that your system previously used a Certbot snap , and that was somehow uninstalled -- however it is also possible that your system has never used Certbot and used some other client. You can search the configuration files and logs on your system to try and find an answer to this.
I'm sorry this may sound frustrating to you, but the only information people can glean from your posts is that you are using VirtualMin and can't get a certificate. There simply isn't any information suggesting Certbot or another client is involved.
There may be an issue with the two other names included in the cert:
X509v3 Subject Alternative Name:
DNS:awards.awstemp.botany.org <<< HTTPS NOT WORKING !!!
DNS:awards.botany.org <<< HTTPS WORKING
DNS:www.awards.awstemp.botany.org <<< HTTPS NOT WORKING !!!
DNS:www.awards.botany.org <<< HTTPS WORKING
They are attempted to be served via this wildcard cert (which lacks coverage):
Given: The HTTP authentication requests won't need to connect via HTTPS, it just seems indicative of the lack of coverage by your (VirtualMin) system for those names.
The missing subdomains are a result of me cleaning up my configuration. They were valid last time I had a successful renewal but were targeted for deletion. When I started getting THIS error, I decided the time had come to simplify and removed them. So the renewal of the cert isn't QUITE exactly like the previous one.
I'm not exactly sure how VM works, so this may not be the best advice:
But I would remove the HTTPS from it and then immediately add it back.
So that VM only tries to issue a cert for the remaining two names.
Note: This runs the risk of not having a cert at all if VM continues to fail.
[but I'm the gambling type - LOL]
Shows that Virtualmin is trying to renew the default domains, and that if I wanted to I could do a custom list of them if the default isn't appropriate. And I can tell you from experience that when the domains aren't "right" you get an error message that tells you so. So unless there's a brand new bug somewhere, I don't think those recently removed subdomains have anything to do with the issue.
In the meantime, I have confirmed that my system SHOULD be using certbot. I've attempted to verify it's proper installation by uninstalling it and installing it again using the instructions here:
When I get to the step to verify that it' working, I get:
$ sudo certbot --apache
cannot change profile for the next exec call: No such file or directory
The "A-" is optional, I always prefer "A+".
And frankly a meager grade IYAM - LOL
"A-" = "B++"
[which is only slightly better than "C++" and hardly no one uses that anymore ROFL]
@robbrandt I googled your exact failure message and the top hits both involved a failed apparmor component. I know nothing about it other than these 2 threads describe a remedy for your exact message. The apparmor problem causes other programs to not run with that error shown.
This one (start at bottom and work up - it's long)
And, this one:
Let us know if this tip helped. Otherwise we can look further and we will want to see the outputs suggested by Rudy and me above. Thanks
$ sudo certbot certificates
cannot change profile for the next exec call: No such file or directory
The last entry from /var/log/letsencrypt/letsencrypt.log was from October 22nd, although the automated renewal fails every few hours and I've tried manually at least a dozen times in the last 4 days.
The list of VHOSTS is quite extensive and I'd rather not publish it. Anything in particular you want to focus on?
$ sudo which -a certbot
/usr/bin/certbot
/snap/bin/certbot
$ sudo lxd --version
cannot change profile for the next exec call: No such file or directory
snap-update-ns failed with code 1
$ microk8s
Command 'microk8s' not found, but can be installed with:
sudo snap install microk8s
$ sudo snap install microk8s
error: This revision of snap "microk8s" was published using classic confinement
and thus may perform arbitrary system changes outside of the security
sandbox that snaps are usually confined to, which may put your system at
risk.
If you understand and want to proceed repeat the command including
--classic.
I'll stop right here because it seems significant.
Do not bother with lxd or microk8s. In those other trouble reports those programs were being prevented from running just as certbot is in yours. We need to find the underlying reason for that. So far apparmor is the only candidate.
But, you are using a Lets Encrypt cert. And, you most recently issued a cert on Oct20. See:
that when the domains aren't "right" you get an error message that tells you so. So unless there's a brand new bug somewhere, I don't think those recently removed subdomains have anything to do with the issue.