Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.
Failed to renew certificate easygotransport.com with error: Some challenges have failed.
All simulated renewals failed. The following certificates could not be renewed:
/etc/letsencrypt/live/easygotransport.com/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)
My web server is (include version): nginx
The operating system my web server runs on is (include version): Ubuntu
My hosting provider, if applicable, is: vultr.com
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):
The version of my client is (e.g. output of `certbot --version` or `certbot-auto --version` if you're using Certbot):
you get to the point... it confused me. I am still on old ip address... I don't know when it is going to swap actually... I changed already ip addresses in DNS record. Do I need to come back and try to certificate after all done (IP swapped)?
I checked now if the IP address actually changed or not. but it has not been changed yet. old ip address was point to. I think I will have to wait until it has changed. Am I right?
The IP address of the server you're running certbot on needs to be the same IP address as in DNS. If that's not the case, you need to wait until the new IP address has propogated through all DNS servers indeed.
Thanks a lot! I thought so... in the meantime, Can I scp the certificate from the each server? I was actually trying to do now but I could not get in live directory (permission denied). Only option is that I have to wait... (sad)
Sure, there's nothing preventing you from using the certificate and its corresponding private key on the other server. Using scp ensures a safe method to transfer the private key.
Root permission is required to access the private key. You could use tar as root to put the required files in a tar archive, which has the added benefit of keeping the permissions (--preserve-permissions is enabled by default when run as root) the same and stores symbolic links as symbolic links by default. Then, you change ownership of the tar archive to your user account, scp it over to the other server as user and at the other server, untar it again as root.