so i re-added agree-dev-preview (just for grins) but gave it an arbitrary value and now received this:
Use of --agree-dev-preview is deprecated.
followed by my errant value: letsencrypt: error: unrecognized arguments: Y
but still doesn’t work.
i user centos 7 in case that matters…
Yeah i test both both CentOS 7.1 via default python 2.7 system and CentOS 6.7 via IUS Community repo’s python 2.7.10 side install
i see the same error even when running a basic command such as
./letsencrypt-auto --help webroot
i use letsencrypt command not letsencrypt-auto
/root/.local/share/letsencrypt/bin/letsencrypt --version
letsencrypt 0.1.0
no problems
/root/.local/share/letsencrypt/bin/letsencrypt --help webroot
usage:
letsencrypt [SUBCOMMAND] [options] [-d domain] [-d domain] ...
The Let's Encrypt agent can obtain and install HTTPS/TLS/SSL certificates. By
default, it will attempt to use a webserver both for obtaining and installing
the cert. Major SUBCOMMANDS are:
(default) run Obtain & install a cert in your current webserver
certonly Obtain cert, but do not install it (aka "auth")
install Install a previously obtained cert in a server
revoke Revoke a previously obtained certificate
rollback Rollback server configuration changes made during install
config_changes Show changes made to server config during installation
plugins Display information about installed plugins
optional arguments:
-h, --help show this help message and exit
-c CONFIG_FILE, --config CONFIG_FILE
config file path (default: None)
webroot:
Webroot Authenticator
-w WEBROOT_PATH, --webroot-path WEBROOT_PATH
public_html / webroot path. This can be specified
multiple times to handle different domains; each
domain will have the webroot path that preceded it.
For instance:-w /var/www/example -d example.com -d www.example.com -w /var/www/thing -d thing.net -d m.thing.net(default: None)
nope; same error. in fact, even the version command produces said error.
maybe reinstall the client
already done; and by that i mean i moved my /letsencrypt folder elsewhere and re-pulled from git. any other steps needed?
I just tried requesting a brand new cert with an original domain with no luck; i received the same error. has no one else really seen this using centos 7 and webroot auth with nginx?
now i can’t request addt’l new certs anymore… 
There is a project out there called Caddy which automatically integrates LE and i tested that; works fine with a new unique cert / domain request.
1 Like
strange having no problems with my Centmin Mod LEMP Nginx stack with CentOS 6.7 or 7.1 uses webroot too Letsencrypt Free SSL Certificates
have you tried without a .ini file passed on cmd line and just doing full webroot commands too ? maybe it's some formatting issue in your .ini file ?
yes i tried with cmd line only; no joy.
Now I’m really confused; I just tried again with a new domain and this time strictly followed the Beta invite’s email instructions (with letsencrypt-auto):
/root/.local/share/letsencrypt/bin/letsencrypt certonly -a webroot --webroot-path /usr/lib/mailman -d lists.garbage-juice.com --server https://acme-v01.api.letsencrypt.org/directory --agree-dev-preview
and while it did warn me of the deprecation of the agree-dev-preview command, it worked, for the new cert.
Now I just tried renewing the same cert i just received, this time adding --renew-by-default, and it also now worked fine, while still warning me of the deprecated command.
So now I went back to one of my original domains (one cert, 2 domains) I had been trying to renew for days now (as a test), and SOB, it appears to possibly have worked except i got rateLimited (probably due to my testing).
So IDK what’s up but it works now seemingly. WTF!? haha…
1 Like
weird you sure previously you used bin/letsencrypt and not bin/letsencrypt-auto when running webroot command ?
i actually have always been using (including now with my success):
/letsencrypt/letsencrypt-auto …
i see i ask as i always use bin/letsencrypt with webroot without issues
I had the idea to run the webroot thing via a crontab. Problem is that everytime I do that manually the script requires me to confirm that I want to replace existing certificates for the given domain(s). Won’t that be an issue with crontab-running?
I actually didn’t, neither did I find it in the docs nor via the --help flag. What exactly does that flag do?
EDIT: I just ran the command with that flag in addition and it didn’t prompt me for confirmation - nice, thanks! Is that the (only) thing the flag does?
You should see all available parameters using letsencrypt-auto --help all. If you can’t see that parameter maybe is because letsencrypt is outdated. To update it, if you used git clone letsencrypt just go to the same dir where you have letsencrypt-auto command and use git pull command to update it.
Regarding --renew-by-default parameter, yes, as far as I know that is all that it does, renew your certificate without asking questions:
--renew-by-default Select renewal by default when domains are a superset
of a a previously attained cert (default: False)
1 Like