I have used @9peppe method to install it successfully and have just used your method to "remove the well-know" block with equal success.
I'm now sure it was a problem with the code in the service block, although I'm not sure why. But the problem is solved, thank you very much for your help.
If you didn't successfully run the "dry run" certbot command that I just posted above, you haven't actually solved anything yet. 
You also need to run the second certbot command that I just posted above in order to actually update your renewal configuration to avoid using the webroot authenticator.
4 Likes
You're right, 
Certbot failed to authenticate some domains (authenticator: nginx). The Certific ate Authority reported these problems:
Domain: cachedesk.com
Type: unauthorized
Detail: 2604:a880:400:d0::201e:5001: Invalid response from https://cachedesk.c om/.well-known/acme-challenge/DX0P-GQsL3Qji3beNAU2BxCzLceVv4EStYw5Q1ixzsI: 404
Domain: www.cachedesk.com
Type: unauthorized
Detail: During secondary validation: 2604:a880:400:d0::201e:5001: Invalid resp onse from https://www.cachedesk.com/.well-known/acme-challenge/vIp4OcUVINL9-M2to 2rhcIzVLSzgAIvAtHs0gLg9aEA: 404
Hint: The Certificate Authority failed to verify the temporary nginx configurati on changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
It still doesn't work. i already delete 'well-know' block,Does this mean there are other errors in the service block?
Oh wait! 
That's not a primary failure.
4 Likes
Im trying this again.
You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/cachedesk.com.conf)
What would you like to do?
1: Attempt to reinstall this existing certificate
2: Renew & replace the certificate (may be subject to CA rate limits)
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate for cachedesk.com and www.cachedesk.com
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/cachedesk.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/cachedesk.com/privkey.pem
This certificate expires on 2022-12-21.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Successfully deployed certificate for cachedesk.com to /etc/nginx/sites-enabled/cachedesk.com
Successfully deployed certificate for www.cachedesk.com to /etc/nginx/sites-enabled/cachedesk.com
Your existing certificate has been successfully renewed, and the new certificate has been installed.
If you like Certbot, please consider supporting our work by:
- Donating to ISRG / Let's Encrypt: Donate - Let's Encrypt
- Donating to EFF: Support EFF's Work on Let's Encrypt | Electronic Frontier Foundation
1 Like
That's a great sign! 
Try this now:
certbot renew --cert-name cachedesk.com --dry-run
Adding cert-name makes the renewal check only try for that specific certificate.
4 Likes
I suspect that you have orphaned nginx processes with old configuration loaded. I recommend completely restarting your whole webserver then running the dry-run renew command a few more times.
5 Likes
It goes back to the beginning. So you are correct, the problem is not actually solved. Here is some additional information,
I'm using a directory to have multiple domains pointing to it, which means there are multiple domains in nignx pointing to a directory file. I'm guessing maybe certbot doesn't allow this kind of authentication?
I honestly don't think that's the issue here. It would fail consistently if it were. It appears that nginx is yielding different responses, which is typically caused by either orphaned processes or load-balanced instances with different configurations.
4 Likes
Those files appear to have all the original problems that we already addressed.
5 Likes
Try the server restart. I think it will work. I need to run for now, but I believe you're on the right track.
5 Likes
Im trying restart server.
Have a good day. 
3 Likes
There is reason:
As I copied the default block, the presence of the original 80 blocks in the:
{
location / {
try_files $uri $uri/ /index.php$is_args$args;
}
}
Then when the certificate is generated, it exists in both port 80 and 443, which will generate Too many redirections error. This will not affect the certificate request, but will affect browser access.
My final solution is to
First, Remove the virtual server.
then delete All cert
sudo certbot delete
and make a new server
server {
listen [::]:80;
listen 80;
root /var/www/example.com/;
index index.html index.htm index.nginx-debian.html;
server_name cachedesk.com www.cachedesk.com;
}
DO NOT ADD THIS
location / {
try_files $uri $uri/ =404;
}
and last step
sudo certbot --nginx -d "catchdesk.com,www.catchdesk.com"
Its working now.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.