Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
lallybroch.com.au
I ran this command:
sudo certbot renew --rsa-key-size 4096 --pre-hook “service nginx stop” --post-hook “service nginx start”
It produced this output:
Error on starting nginx
My web server is (include version):
The operating system my web server runs on is (include version):
Raspberry Pi
My hosting provider, if applicable, is:
Cloudflare
I can login to a root shell on my machine (yes or no, or I don’t know):
yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
not sure
And one indicator what's going wrong: Your /.well-known/acme-challenge has a loop:
• http://www.lallybroch.com.au/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2606:4700:30::6812:2df0
301
https://www.lallybroch.com.au/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
0.020
A
Visible Content:
• https://www.lallybroch.com.au/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
301
http://www.lallybroch.com.au/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
0.103
F
http redirects to https, https to http.
Ah, the 418 is the I'm a teapot - error:
The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is a teapot. This error is a reference of Hyper Text Coffee Pot Control Protocol which was an April Fools' joke in 1998.
So you have a funny webserver that doesn't want to make coffee.
That's really a bad webserver. You should talk with your server.
If you are using Cloudflare, why don’t you just use the SSL solution they offer, such as “Origin CA” mode of enabling a secure connection between your server and the Cloudflare or even using a self-signed certificate? See:
Basically, if you do not have (or don’t want to install) a proper certificate on your server, you can have a Cloudflare-generated or self-signed one to establish a secure connection between your server and Cloudflare itself if you opt-in for “Full SSL” (with “Flexible SSL” the connection between your server and Cloudflare is not encrypted). As for the connection between the client and Cloudflare, that will be encrypted regardless of whether you choose a Full or Flexible SSL option.
Well, if you need it to have a trusted and not-related to Cloudflare SSL certificate, then see what exactly you will be getting if you issue sudo service nginx start command manually for example. That might help with understanding why it couldn’t have been started (provided Nginx is indeed installed on your Pi, you might need to use some other command to start/stop - for example sudo /etc/init.d/nginx start).
Actually, that is not strictly necessary (with Flexible SSL option for example). Interestingly enough, there was also an article published recently stating that both certbot's HTTP and DNS validation should work just fine for the site behind Cloudflare (however, I haven't checked that personally).
You're stopping nginx during the renewal process - which I suppose means you're using the --standalone plugin for validation.
With that method, certbot runs a temporary webserver on port 80 to respond to the validation challenge.
But if Cloudflare is configured to redirect HTTP to HTTPS, then it will redirect the request before it reaches certbot. Let's Encrypt will make a second request over HTTPS, and if Cloudflare is configured in "Full" or "Full (strict)" SSL mode, it will forward that request to your web server over HTTPS - but certbot won't be listening for that when you run it in standalone mode, so the challenge will fail.
So, you could temporarily disable Cloudflare, or configure it not to redirect HTTP to HTTPS, or switch it to "Flexible" SSL (which forwards the incoming HTTPS request over HTTP to your web server). But a better solution might be to try using a different certbot plugin such as --nginx or --webroot instead of --standalone - as those are capable of responding correctly when the second request comes in over HTTPS, and don't require you to temporarily stop nginx during the renewal.
It’s interesting that the error quoted in the original post says “Error on starting nginx”, which corresponds to post-hook. So presumably stopping worked or nginx was not running in the first place? In any case, I believe some log with more details might help.