I ran this command: certbot certonly --non-interactive --email firstname.lastname@example.org --preferred-challenges http --standalone --agree-tos --renew-by-default --webroot-path /var/www/html -d sd-155842.dedibox.fr
My web server is (include version): httpd-2.4.37
The operating system my web server runs on is : Rocky Linux 8.7
The version of my client is : certbot 1.22.0
Right, here goes. I've been using Certbot since the first beta back in 2015, and I'm a happy camper with it. I'm currently fiddling with Certbot on Rocky Linux 8, since I want to migrate (and update) all my production servers running CentOS 7 to this other RHEL clone.
Here's a thing that puzzles me. On my sandbox machine running Rocky Linux 8 and Certbot 1.22, I've issued a classic standalone certificate. No webroot here.
On my CentOS 7 servers (running Certbot 1.11) I can't generate/renew certificates in standalone mode without stopping Apache, since it uses TCP port 80 needed to generate/review my certificates.
I just gave it a spin on Rocky Linux 8 with a few static dummy sites, and curiously enough, it looks like I can generate/renew certificates in standalone mode with Apache still running.
Is this a feature in more recent versions of Certbot ? Just asking because I have one of these curious cases of "It works, but it shouldn't".
You probably have a cached authorization on your account so that Let's Encrypt doesn't need to retry the challenge (for that specific account during that specific time period). Would that explain what you've seen?
These options don't really make sense together. The HTTP challenge is the only challenge type that --standalone can perform, while --webroot-path is only used by --webroot, not by --standalone. There is no webroot (in the sense of a location on disk from which a pre-existing web server will be asked to serve static files) used by --standalone at all.
And this option has been renamed to --force-renewal, and might be interesting for your experiments but as @Osiris alludes to is usually not necessary or useful (it causes a replacement for an existing certificate to be issued early).