@pfg, do I need to include my other commands when running letsencrypt renew, like so:
./letsencrypt-renew certonly --email youruser@yourdomain.tld --text
–renew-by-default --agree-tos --webroot -w /home/site/public_html/ -d
mysite.com -d www.mysite.com -w /home/site2/public_html/ -d
sub1.mysite.com -w /home/site3/public_html/ -d sub2.site.com -w
/home/site4/public_html/ -d sub3.mysite.com --dry-run
No, Let’s Encrypt will try to renew using the settings you last used for your certificates. This should do:
./letsencrypt-auto renew
Take a look at the documentation for more details.
How do you do it with certbot-auto?
If I’ve already installed it with certbot-auto by simply dissabling cloudflare to install it and then re-enable it…
Thanks.
Has letsencrypt-auto been renamed certbot-auto? If not where are the installation instructions for letsencrypt-auto?
Yes, the client was renamed a while back. Both commands are essentially compatible.
@jgrahamc I hope you don’t mind - I’ve updated the instructions to account for the client rename and the new install instructions in order to avoid confusion.
Thank you for doing that. That’s great.
Hmm, something’s odd here. I seem to have a problem only when I do a dry-run?
Bluebox# sudo certbot certonly --text --webroot -w /usr/local/www/apache24/data --email=philip@klippenstein.org -d minecraft.klippenstein.org -d philip.klippenstein.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Cert not yet due for renewal
You have an existing certificate that contains exactly the same domains you requested and isn't close to expiry.
(ref: /usr/local/etc/letsencrypt/renewal/minecraft.klippenstein.org.conf)
What would you like to do?
-------------------------------------------------------------------------------
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for minecraft.klippenstein.org
http-01 challenge for philip.klippenstein.org
Using the webroot path /usr/local/www/apache24/data for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Ge nerating key (2048 bits): /usr/local/etc/letsencrypt/keys/0003_key-certbot.pem
Creating CSR: /usr/local/etc/letsencrypt/csr/0003_csr-certbot.pem
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/usr/local/etc/letsencrypt/live/minecraft.klippenstein.org/fullchain.pem.
Your cert will expire on 2017-05-31. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
Bluebox# sudo certbot certonly --dry-run --text --webroot -w /usr/local/www/apache24/data --email=philip@klippenstein.org -d minecraft.klippenstein.org -d philip.klippenstein.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Cert not due for renewal, but simulating renewal for dry run
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for minecraft.klippenstein.org
http-01 challenge for philip.klippenstein.org
Using the webroot path /usr/local/www/apache24/data for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. philip.klippenstein.org (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to minecraft.klippenstein.org.well-known, minecraft.klippenstein.org (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to minecraft.klippenstein.org.well-known
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: philip.klippenstein.org
Type: connection
Detail: Could not connect to minecraft.klippenstein.org.well-known
Domain: minecraft.klippenstein.org
Type: connection
Detail: Could not connect to minecraft.klippenstein.org.well-known
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
This worries me somewhat, because of course it means I haven’t been able to test certbot renew with certbot renew --dry-run as the latter gives me the same error as shown above.
I found that if you just disable the domain name to run thru cloudflare the certs will install without a problem. After finished installing then re-enable cloudflare pass thru
Since you've issued certificate(s) for those names recently, Let's Encrypt probably remembers that it's valid, and doesn't actually try to validate it again. (It currently remembers authorizations for 60 days, a number which will probably change in the future.)
... but when you use --dry-run, if you haven't recently issued any other staging certificates for those names, it won't remember and will validate them. (The staging server has a totally separate database of authorizations.)
And, obviously, validation fails.
http://minecraft.klippenstein.org/.well-known/acme-challenge/ and http://philip.klippenstein.org/.well-known/acme-challenge/ both redirect to https://minecraft.klippenstein.org.well-known/acme-challenge/, an URL with an obviously invalid domain name. You can see for yourself with a web browser or something like curl.
it sounds like there's a missing "/" in your web server configuration. For example, maybe it has "Redirect / https://minecraft.klippenstein.org" where it should be "Redirect / https://minecraft.klippenstein.org/".
(You could also exclude /.well-known/acme-challenge/ from the redirect, if you want. But i don't know how to do that in Apache off hand.)
Speaking of --dry-run, you've issued 3 identical certificates in the last couple days. If you keep doing that you'll start running into the rate limits. If you're testing things, you should make more use of --dry-run in the future.
Thanks for this detail. I was having failures with sub-domains in subdirectories. However, I had to correct one glitch:
./letsencrypt-auto certonly --email youruser@yourdomain.tld --text --renew-by-default --agree-tos --webroot -w /home/site/public_html/ -d mysite.com -d www.mysite.com -w /home/site2/public_html/ -d sub1.mysite.com -w /home/site3/public_html/ -d sub2.site.com -w /home/site4/public_html/ -d sub3.mysite.com --dry-run\
This did not work unless I put in the explicit -w for www.mysite.com:
./letsencrypt-auto certonly --email youruser@yourdomain.tld --text --renew-by-default --agree-tos --webroot -w /home/site/public_html/ -d mysite.com -w /home/site/public_html/ -d www.mysite.com -w /home/site2/public_html/ -d sub1.mysite.com -w /home/site3/public_html/ -d sub2.site.com -w /home/site4/public_html/ -d sub3.mysite.com --dry-run
Hi
I'm running the following command:
certbot --nginx certonly --webroot --webroot-path /home/domainname/public/public_html/ --renew-by-default --email my@email.com --text --agree-tos -d mydomain.com -d www.mydomain.com
but I get the following error:
Could not choose appropriate plugin: Too many flags setting configurators/installers/authenticators 'nginx' -> 'webroot'
I'm running nginx server under Ubuntu 16.10 with Cloudflare Pro Cache everything rule.
Any help?
This really should be a new topic, as it’s almost entirely unrelated to the (very old) one you commented on.
However, the issue is you’re sending both the --nginx and --webroot flags. These are two different plugins. I’m also confused why you’re issuing --nginx at all, when you’re also sending certonly. Certonly tells Certbot to explicitly not do anything that nginx would do, except for use nginx as an authenticator. However, you’re using Cloudflare so you’re (correctly) attempting to use the webroot authenticator.
Unless you have a compelling reason to need certonly, try this:
certbot -i nginx -a webroot --webroot-path /home/domainname/public/public_html/ --email my@email.com --text --agree-tos -d ...
Note that I left renew-by-default out. There are rather few reasons you actually want to use that flag, and it can lead to rate limit issues in many cases.
@minamoto, can you tell us where you found a suggestion to use --renew-by-default? Maybe we can write to whoever is mentioning it in documentation and get it changed. (--renew-by-default was confusingly named, I think originally by me, and has since been renamed to --force-renewal. It doesn't mean "enable autorenewal in the future", it means "force renewal of this certificate right now". The "by default" here means "without asking, even if it appears to be unnecessary".)
I have read all this discussion and I have all time the some error. Domains are accessible and working but still have the error:
Failed authorization procedure. www.digestum.eu (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.digestum.eu/.well-known/acme-challenge/iUnQo6Fg8Mw3dktyNYKr_9N_nKeXt9FcdNpjo4AmEFo: Timeout
Domains was under cludfare I have paused and after deleted under cloudfare, flushed the DNS on google, installed all certbot and cerbot-auto and try the --standalone with apache2 stopped, but all time the some error, maybe I have to put down the firewall, even is oper for the port 80 and 443 that works under apache2.
If don’t work I have to delete/purge it ?
You are advertising the IPv6 address 2001:b07:2ea:23a5:222:68ff:fe65:fab5 via an AAAA record in DNS, but your server is currently only reachable over IPv4, not IPv6. The certificate authority is trying to reach your server on IPv6 because of the AAAA record, and isn't able to.
Hi,
I have put the file on
http://digestum.eu/.well-known/acme-challenge/ddYg5HJOsoLetr5EuxQOLpwwoLHIV-uTH0WC66_FOjQ
And is readable … I have to understand what you means, the domain is set on IP4 and IP6 in DNS but the IP is shared then the certificate authority can read the file only over domain… as all others.
Do you means that is better to delete the IP6 AAAA record from DNS?
ha ok… now work:
IMPORTANT NOTES:
Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/digestum.eu/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/digestum.eu/privkey.pem
Your cert will expire on 2018-05-23. To obtain a new or tweaked
version of this certificate in the future, simply run certbot-auto
again. To non-interactively renew all of your certificates, run
"certbot-auto renew"
If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
The very best thing would be to make your site reachable over IPv6. 
I think that for that is not in me, because it’s the provider, fastweb, that can allow that, mi web server I think work with IP6 too.
I have try and over IP6 is not redirect to me and mi webserver even I have a IP6 connected to me, I can see that in some web sites that show your ip6.
But I’ll ask about that… tank you.
For now work and configured… https://digestum.eu/
After a problem now all is very simple…
I have a question related to this one that is: is it possible to verify a new sub-domain under CloudFlare with 1. “Always use HTTPS” is on. 2. SSL full(strict) mode?
I tried to get an SSL by choosing “Place files in webroot directory”, under the two options configured I mentioned above, Lets Encrypt’s verification request will be redirect to something like https://example.domain/.well-known/something, and CloudFare will try to connect my server using https but the SSL isn’t issued yet…
I’ve tried a page rule: “http://example.domain/.well-known/” – diable security, but it doesn’t work…
I can temporarily disable “Always use HTTPS” while tring to get a certificate, that would work, just curious that if it’s possible to do that with “Always use HTTPS” is on.