just to inform that certbot-auto cannot locate my self compiled apache in /usr/local/apache
on linux Fedora 30
Have you tried specifying the location?:
That’s to be expected if you run non-standard configurations.
Also, if you mean you’ve cloned the entire certbot git repository just for the
certbot-auto script, you’re not doing it right. The
certbot-auto script doesn’t even use all those other files from the git repository, it downloads everything from
PyPi. The recommended method of getting the
certbot-auto script is:
Also, certbot has been packaged for Fedora, so you also could have done
dnf install certbot certbot-apache, but it probably won’t be the latest version (which you should get with
certbot-auto). Seems Fedora 30 currently sports certbot 1.0.0, which isn’t bad at all!
/usr/local/ is obviously a standard source compile path for any kind of applications.
install certbot apache-certbot from package was not a good solution since it forces me to install apache and module packages, creating mess with my own compiled apache
I ended with the options above --apache-server-root and --apache-ctl.
Another issue, is when let’s say “secure.exmple.tld” point to several ip spread on a geo cluster the script doesn’t catch the local IP tha pointing on the domain, but rather on an external IP which is weird since even the local nameserver is set to answer the local IP first.
Ok I didn’t know I just need to download the script, thanks
Let’s Encrypt’s validation servers connect to your site from the Internet by arbitrarily (or randomly) picking IP addresses available in the public DNS. (IPv6 is preferred over IPv4, though.)
There isn’t a way to make them choose one IP over another.
One option, if it’s possible in your environment, is to use DNS validation instead of HTTP validation.
Otherwise, you have to make sure that each server can respond appropriately, using HTTP redirects, reverse proxying, a shared filesystem, or something like that.
You may want to have one server run Certbot and obtain certificates, then have it copy them to the other servers.
That might be true but compiling stuff yourself isn’t thát standard.
That would be unwise indeed.
How do you mean, “the script doesn’t catch the local IP”? When verifying the hostname?
i.e. the domain secure.exmple.ltd point to 4 different ip addresses (a kind of anycast)
on the name server authority.
If I understand certbot uses its own dns resolver right?
Another issue is if DNS challenge is used for wildcards like
certbot-auto certonly --manual --preferred-challenges=dns --email email@example.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.exemple.ltd
the weird thing is we must randomly wait the propagation time to continue the script, but if it fails we have to restart everything from the start like change the key on all nameservers which is absolutely not easy to manage.
So why not to insert in the certbot-auto a loop that tries until a timeout so it will avoid to restart with a new key if it fails because of propagation or maybe I’m missing something?
When thinking of a single client to a single server maybe you CAN loop as long as you like.
But when thinking in terms of millions of clients to a single server… the server should stop as soon as there is a problem; Or this could create, or allow for, a DoS or at least require increased resources ($$$).
Ah, ok, understood it can be a security threat indeed. That’s why the key is changing everytime the cert creation failed