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: mail.rubinsoftware.com
I ran this command: certbot renew -v --break-my-certs --force-renew --server “https://acme-v02.api.letsencrypt.org/directory”
It produced this output:
Attempting to renew cert (mail.rubinsoftware.com) from /etc/certbot/renewal/mail.rubinsoftware.com.conf produced an unexpected error: Failed authorization procedure. mail.rubinsoftware.com (tls-sni-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout during connect (likely firewall problem). Skipping.
My web server is (include version): There is an apache on this machine, but the certificate is for the mail server.
The operating system my web server runs on is (include version):
Linux mail 4.16.0-1-default #1 SMP PREEMPT Wed Apr 4 13:35:56 UTC 2018 (e16f96d) x86_64 x86_64 x86_64 GNU/Linux
My hosting provider, if applicable, is:
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):
Basically this command works flawlessly, it just give me bad certs:
certbot renew -v --break-my-certs --force-renew --server “https://acme-staging-v02.api.letsencrypt.org/directory”
This started when the auto renewal process failed. I have been trying to debug the process since. That it works on staging and fail on production is very confusing. I tried specifying the server because when I ran the debug I noticed that the url was ver 1 instead of 2 and since 2 was staging I decided to try ver 2 production