Run certbot-auto from git

Hi,
just to inform that certbot-auto cannot locate my self compiled apache in /usr/local/apache
on linux Fedora 30
thanks

1 Like

Have you tried specifying the location?:
[https://certbot.eff.org/docs/using.html]

1 Like

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 pip/PyPi. The recommended method of getting the certbot-auto script is: wget https://dl.eff.org/certbot-auto

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!

2 Likes

/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.
@ [Osiris]
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.

1 Like

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?

1 Like

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 admin@example.ltd --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

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.