It produced this output:
sudo certbot renew --pre-hook “service nginx stop” --post-hook "service nginx start"
Saving debug log to /var/log/letsencrypt/letsencrypt.log
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/saurabhorange.duckdns.org/fullchain.pem (failure)
Running post-hook command: service nginx start
1 renew failure(s), 0 parse failure(s)
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.
My web server is (include version):
nginx and apache
The operating system my web server runs on is (include version):
debian jessie ( raspbian )
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
is generally only appropriate for --standalone, yet the fact that the validation is using HTTP-01 makes me think that in fact --webroot was not used. (We really need to make the plugins log which plugin is being used for renewal so that we don't have to guess! )
@saurabhvyas, why did you choose to use this particular form of the renew command, including those hook options? Did you find it in a particular tutorial or something? Do you have a reason to believe that your web server needs to be stopped before performing a renewal? What Certbot command did you use at the time you originally obtained your certificate?
When I try to connect to the site right now with HTTP, I see "400 Bad Request The plain HTTP request was sent to HTTPS port", which is a sign of a different kind of misconfiguration (although this specific error would not be directly seen by the Let's Encrypt CA if you use --pre-hook "service nginx stop" while renewing).
I tried all renew commands listed on certbot section for nginx configuation , none of them worked , then i tried different combinations like stopping apache and nginx etc , Is there any way , I can systematically debug the error ?, there is a lot going on , and Its hard to debug …
Sure, could you start by posting the contents of /etc/letsencrypt/renewal/saurabhorange.duckdns.org.conf? I predict that it will say authenticator = webroot somewhere inside.
# renew_before_expiry = 30 days
version = 0.9.3
cert = /etc/letsencrypt/live/saurabhorange.duckdns.org/cert.pem
privkey = /etc/letsencrypt/live/saurabhorange.duckdns.org/privkey.pem
chain = /etc/letsencrypt/live/saurabhorange.duckdns.org/chain.pem
fullchain = /etc/letsencrypt/live/saurabhorange.duckdns.org/fullchain.pem
# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = 745848bb260e310de25ffa4e199ee2bb
webroot_path = /var/www/html,
[[webroot_map]]
www.saurabhorange.duckdns.org = /var/www/html
saurabhorange.duckdns.org = /var/www/html
" @saurabhvyas, where are you copying and pasting from?
this , Alias /.well-known/acme-challenge /path-to-challenge
ProxyPass /.well-known/acme-challenge !
What command did you use when you originally got your certificate for the first time? "
as mentioned in certbot official website under debian jessie and nginx
So the normal command to renew for most people is just certbot renew. However, I predict that that will fail in your current environment for a different reason.
This reason has to do with what happens if we go to your site in a browser: we get the error “400 Bad Request The plain HTTP request was sent to HTTPS port”. This means that your nginx configuration is mistakenly speaking HTTPS on port 80 as well as port 443. (It should speak HTTP on port 80 and HTTPS on port 443, since that’s what browsers expect, as well as what the Let’s Encrypt certificate authority expects to see when testing that you really control this domain name.)
Do you know what you might have done in your nginx configuration that could have produced this behavior in nginx? If not, could you please also post your nginx configuration files?
Thanks for giving a direction for research , Last time ( no 400 bad request ) , it was working perfectly , and I do have backup of that time , so I will investigate and get back to you .
when you go to https://www.saurabhorange.duckdns.org , It works , but when I type http , It doesnt work , I think even earlier , I was using https only , anyway here is the github gist containing current nginx config file and apache2 config file .
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):1
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for saurabhorange.duckdns.org
Cleaning up challenges
Could not open file: /etc/nginx/sites-enabled/rpicam
nginx restart failed:
nginx: [emerg] could not build the server_names_hash, you should increase server_names_hash_bucket_size: 64
Honestly, I would upgrade your nginx. The 400 page is reporting that it’s running 1.6.2, which was released in 2014. That config file looks valid to me on the redirect, although I don’t see any webroot setup under the .well-known location.
I tried upgrading , but according to my current operating system , raspbian jessie , It is the latest version , I couldn’t find any tutorial on how to add backports in sources file , in order to install latest nginx on raspberry pi , If I cannot resolve this in a straightforward way , I will try to backup everything and start with fresh installanation and new certification using certbot
)