New on LowEndTalk? Please Register and read our Community Rules.
Let's Encrypt Certbot Alternatives
JustAMacUser
Member
in General
I'm switching the sites I run to Let's Encrypt. I really don't like how certbot wants to run as root because I don't like things running as root, especially if it's technically not needed. I played around with running it as a separate user and while I got it to work, it feels a little messy.
I am looking for alternatives and acme-tiny seems nice. I like Python and plan to use a CSR for all the requests so it seems like a good fit.
At the end of the day I'm looking for something I can run as an unprivileged user.
Anyone else used acme-tiny or anything else? How was your experience?
Comments
I've used this one for something once (don't remember what it was) and it worked nicely: https://github.com/lukas2511/dehydrated
But if you are going to interact with it programatically then acme-tiny is probably a better choice.
https://github.com/lukas2511/letsencrypt.sh can do that.Oh nevermind, turns out he renamed it "dehydrated" so it was just mentioned above.Currently we are using acme.sh (has been officially integrated into VPSSIM too).
This tiny script can be run as regular user.
I am a fan of VPSSIm btw.
Bash FTW
Well, "technically not needed" is not completely right. As far as I know, there are two things that currently require root:
If you for example want to use the standalone pluging, which binds to ports 80 and 443, you have to be either root or simply use
setcapto let a non-root user bind to a port below 1023.Furthermore the
certbot-autorequires root, because it also updates system dependencies and wants to be able to use alle plugin. Apache and nginx for example would need root too, to allow for a graceful restart.So you have three options to run it without root: Use the standalone plugin with
setcap, or use the webroot and manual plugin.However, this doesn't change the fact, that the client is somehow "messy" compared to those alternatives, that only have a single executable...
dehydrated does that on its own. Why do you need additional script?
Correct me if I am wrong but Dehydrated only does that as part of actually renewing the certs ... isn't that what Issue/enhancement #108 is all about?
Smart Renew just integrated better for my purposes and setup.
Understood, but I've got to do other actions for some custom (read: PITA) DNS setups in support of renewals. Your point is well taken though, for most users you would not have to use Smart Renew.
Thanks. Looked at it over the weekend and it seems to be a pretty complete package. Quite nice that it's all done in Bash.
Between acme-tiny and dehydrated I think I'll be able to do what I want, but does anyone have any other thoughts?
Not a direct answer to your question, but Caddy has Let's Encrypt support built in, so that you don't need to use a separate tool at all.
I'm pretty comfortable with Nginx and Apache at the moment, but I'll take a look at it because it's new to me and I like to tinker.
That is so stupid and harmonizes well with my overall opinion of the intelligence behind Let's Encrypt.
That's a bit disingenuous. You think requiring root privileges is stupid?
Anyway, you can use the DNS challenge which doesn't require opening a listener.
I use letsencrypt.sh (which is now renamed to dehydrated) and I've not had any issues with it AND I don't run as root.
What I've done is roughly:
a) Slightly modified letsencrypt.sh script (essentially uses an openssl config file instead of passing the SAN via cmdline options - not much of a change as such).
b) Uses sshfs to mount a remote directory locally (via ssh-agent/keys so no interaction required). This allows the letsencrypt.sh script to just work as if everything was local.
c) Apache/Nginx (httpd) is setup on the remote server so that the acme-challenge folder is actually what (b) above uses - so letsencrypt.sh writes to the sshfs mounted folder and those random files are accessible via the domain/web-server to issue certs (note that this is a one time setup of aliases/whatever to allow httpd to serve files from the normal-user-owned acme-challenge folder which can live anywhere on the file system).
d) My private keys never leave my system.
e) Once the process completes and the cert is issued, I rsync the cert to whatever remote ssl httpd directory is setup so that httpd can pick it up on a restart.
f) NO Root required at all (except for the one time setup of the acme-challenge folder via httpd configuration settings). The acme-challenge folder is owned by the user running the script (normal user) who has full write permissions etc. and the only need is to ensure that the files created are world readable so that httpd can serve them when referenced (these are the ephemeral files created by the letsencrypt.sh script to validate domain ownership etc.)
g) All this is completely scripted via the wrapper which is what I really run (which calls the letsencrypt.sh script as required for whatever domain).
h) Of course I manually run the wrapper once every 2-3 months but I don't see why that can't be automated as well (letsencrypt.sh handles renewal if required - so no harm in running more often as it won't do anything).
Any holes to poke?
@nullnothere I'm not sure why so complicated? Why not just run dehydrated on the actual HTTPS serving hosts?
Gj, now enjoy porting your changes every time as you upgrade it to a new version. Why not write a small wrapper around the script instead. In your case such wrapper could read your openssl config file, read SANs and pass those to letsencrypt.sh via command line.
What is even the point. Also requires a *nix machine locally, which many people don't have.
Keys to what? To the cert? They need to be present on the HTTPS web server machine anyway.
Sure enough, letsencrypt.sh doesn't require root, in fact mine even gets launched via "sudo -u nobody". On the other hand the wrapper script that I wrote (and therefore trust) runs as root, checks if letsencrypt.sh has renewed or updated anything and then reloads the web server.
That's a monumental hassle and easy to forget, would be a non-starter for me if this was actually required.
I use Dehydrated using dns-01 challenge using a hook script to add the record via cloudflare api, like @rm_ i use a wrapper script too running as root to be able to reload Dovecot/Nginx/Postfix etc.
Dehydrated is run via a unprivileged user as it dose not need any write access to website files, as it using a hook script to do a few curl to cloudflare api to add the dns-01 challenge.
This is what I decided to do as well. After code reviewing dehydrated I decided to go with it. A wrapper script handles the specifics and uses dehydrated to renew the cert from a CSR. Seems like the simplest approach and keeps privileges where they belong.
@rm_,
In my particular case, I have other stuff around openssl config files and so find it easier to just have a one line patch for letsencrypt.sh. Also, I find it much easier to centrally manage my SSLs/configurations instead of having them on multiple servers (as masters instead of just replicated setups).
Other points are of course all personal preferences.
As for the private key, I meant my account key which need not be present on the public webserver(s). The certs' private key is of course on the https server as you point out.
In my case I have cron scripts to remind me about upcoming SSL expiry dates and so the manual run option hasn't been a pain at all (and of course, as I said, it's quite straight forward to automate should I need it).
The key point though was that it is possible to use letsencrypt.sh without root privileges and it works well enough as you and others have attested.