When running certbot to regularly renew my domain’s certificates, it appears to run sudo by itself and edit my nginx config to set up its challenge/response and install the certificates. Can I
Make it not run sudo? I’d be happy to run commands as root by myself if it tells me what I need to install/set up. Or, if the script exits with “Certbot must run as root”, that would be okay too, and this is how most root-requiring utilities work. I’ve never seen a utility that runs if (not root) sudo ./myself and it’s a bit surprising.
Make it not touch my nginx config but instead tell me what I have to modify? If the script prints “Edit your Nginx config with the following…”, that would be a much less invasive experience in my opinion.
I’m not sure about the sudo point, but if you don’t use the --nginx flag, it won’t do anything to your configuration. You could instead run certbot certonly -w /path/to/webroot . . ., and in that case it doesn’t need to do anything to your config files.
Certbot automatically trying to run sudo sounds like you're using the certbot-auto script. If you don't want it to use sudo, you'll need to run it as root.
I'm not sure why the developers chose to let the certbot-auto script sudo itself, while the certbot application itself will happily run as normal user for modes not requiring root access (such as certbot --help). Perhaps it's because certbot (and the wrapper script certbot-auto) is meant for a very broad public, also for people who do not necessarily have very much *nix skills.
It won't tell you how to modify your configuration files. Also, it will not modify ANYTHING unless you tell it to do so. If you're not using one of the installer plugins to modify the configuration files automatically, I guess the developers assume you're capable to install the certificate manually all by itself. It's kinda redundant also: why tell the user to do some steps manually exactly the same as the automated part? If you don't want it automated, you probably want something custom, so there's not really a reason to tell the user what he/she should do.
This doesn't seem true. As a test, I ran ./certbot-auto, and it said "Plugins selected: Authenticator nginx, Installer nginx", maybe because I've used --nginx before, or maybe because it scanned my list of processes.
I answered the "Which names would you like to activate HTTPS for?" question, I chose "2: Renew & replace the cert (limit ~5 per 7 days)" for the "What would you like to do?" question, and chose "No redirect". My nginx config was modified with a bunch of entries saying # managed by Certbot.
Quite possibly. To be more explicit--tell it to only issue the cert and not install it (the certonly command), and tell it where your web root is (the -w flag), and it won't have any reason to touch your config files (and indeed it won't do so). Otherwise, if you want it to install the cert, how do you expect it to do so without changing them?
I wasn’t aware that certbot existed. I thought that certbot-auto was self-contained instead of downloading other software. See, that’s why I think this system is much too invasive.
It looks like these are my options, along with my comments on their “level of invasiveness”.
Use certbot-auto: It does mysterious things. I’d have to read through its 7000 lines, and I likely wouldn’t approve of it spreading files throughout my OS’s filesystem without my knowledge.
Use Docker: I don’t have it installed on most of my servers. I also rarely use it so it’s in unfamiliar territory for me. I also feel it’s unusual to download hundred-MB images for what could be a hundred-line Python script that runs the challenge/response process.
Use the distro’s package manager: My distros aren’t recent enough to have certbot in its repo.
Add a third-party repo that provides a build: I don’t think this exists, as I couldn’t find it in the documentation.
Install from source using https://certbot.eff.org/docs/contributing.html#running-a-local-copy-of-the-client: I think this is by far the best option. The documentation tells me exactly what to install, how to set up the Python environment, and how to run the software. I think this should be the “default” method for sysadmins to try instead of hiding it behind a miscategorized “Contributing” page.
I understand the intention to recommend developers to use certbot-auto and let itself do everything for them, but I believe in reality this is a bad philosophy and ends up causing more headaches for even beginner Linux admins. The quote “everything should be as simple as it can be but not simpler” is relevant here. Imagine if all applications attempted to install apt/yum dependencies themselves, Python dependencies, and generate files/folders in /etc/ and possibly other locations.
Depends on your distribution. When you started this thread in the Help section, it should have provided you with a questionnaire. Either the software did not present this to you, or you decided to remove this questionnaire. In either way we don't know your distribution. For example, there is a certbot PPA for Ubuntu distributions.
I suppose I miscategorized this thread. My distro is not relevant because I’m not really interested in solving a “problem” of mine, just suggesting a philosophical change to how Let’s Encrypt is portayed in its documentation. Would this belong in #feature-requests or #docs?
Thanks for the links. https://acme.sh/ looks more relevant to me, but that’s just a personal preference. But I disagree with the statement “We recommend that most people with shell access use the Certbot ACME client.” on https://letsencrypt.org/getting-started/. Perhaps that paragraph can be replaced with just to link to https://letsencrypt.org/docs/client-options/ which offers an unbiased comparison between ACME clients and libraries?
Why should Let’s Encrypt be unbiased? The team of certbot is largely populated by Let’s Encrypt employees. This community forum is mainly experienced with certbot: for other clients giving help would probably end in refering to the developers of the client.
Try this out: https://github.com/bruncsak/ght-acme.sh . It is absolutely non-intrusive. In fact, you cannot even use for modifying web configurations, no code in it for that (unlike other ACME clients). It does not require any privilege, you may run it as non-root. It is small, you can easily scroll through the code to verify what it does. In order to run it needs curl, openssl and some basic standard UNIX utilities. No Linux is required: tested on Solaris and Tru64 UNIX.
certbot in general is a tangled mess of dependencies, which is one of the reasons I avoid using it when I can. But I think part of the problem is that how you want it to behave, and what it's designed for, just aren't quite the same thing. Certbot is designed to be (or at least, be able to be) "SSL for dummies", such that someone who knows nothing about SSL, certificates, web servers, configuration, or anything else can use it to secure their web server (and it shows, in a whole bunch of the topics here). Whether it quite achieves that objective is a separate question, but that's what it's trying to do. If you want it to just get a cert and let you install and configure it yourself, it can do that, but you need to explicitly tell it to do so, and that still doesn't do anything about all the dependencies. But still, it's the "official" client, written by Let's Encrypt itself (and in fact, it was previously called letsencrypt).
As you now know, there are a lot of alternative clients, many (if not most) of which have a much more limited scope. It sounds like one of them would better suit your needs.