DNS renewal timeout

My domain is: arien.physics.uoguelph.ca

I ran this command: certbot -d hostname --manual --preferred-challenges dns certonly

It produced this output: Renewing an existing certificate for arien.physics.uoguelph.ca

Please deploy a DNS TXT record under the name:


with the following value:


Before continuing, verify the TXT record has been deployed. Depending on the DNS

provider, this may take some time, from a few seconds to multiple minutes. You can

check if it has finished deploying with aid of online tools, such as the Google

Admin Toolbox: Dig (DNS lookup).

Look for one or more bolded line(s) below the line ';ANSWER'. It should show the

value(s) you've just added.

Press Enter to ContinueTimed out waiting for answer to prompt 'Press Enter to Continue'

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.

My web server is (include version): N/A

The operating system my web server runs on is (include version): CentOS 8.4.2105

My hosting provider, if applicable, is: uoguelph.ca

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): certbot 1.17.0

We recently switched our server to private IPs, do I now need to use the DNS-based renewal. When I try and run the certbot command to get the token, by the time our IT department fills the request (1-2 days) and adds the DNS TXT record, the command fails with the message

Timed out waiting for answer to prompt 'Press Enter to Continue'

and when I try and run the command again, I get a different token.

How do you do a DNS-based renewal in such a situation? Is there a flag for certbot to disable the timeout? Why is there a timeout to begin with?

1 Like

Yes, HTTP authentication will fail; as there is no way for the Internet to reach any private IP.


I would try using another system that you can update much faster (preferably in an automated fashion).
How? (you might ask)
Have your IT folks add a CNAME for
{some other DNS service provider FQDN}
[like: Cloudflare DNS, Google DNS, ACME DNS, there are plenty that support API updates]

1 Like

Well, that time out is hardcoded into the code unfortunately.

You could try to use Ctrl-C to quit certbot after it shows the token: this should leave the authorization in the "pending" state, which should be able to be re-used. Try running certbot again and see if you get the same token as before to verify authz re-use.

That said, the method @rg305 described above which can be automated is probably a way better method.


@Osiris, clever hack!
But it still doesn't automate the process, so I'm leaning towards CNAMEing it elsewhere.



I agree! Could be that the IT department refuses such a thing tho. I certainly hope not.


Dam, I didn't even think of that!
[job security via sole sourced control]
Do they charge for DNS adds/deletes/modifications? [ROFLMAO]


Using Ctrl-C is a good tip, that definitely gives me the same challenge on the second call. I will use that method.

I agree that some way to automate this would be better, but unfortunately our IT department allow that.


Have you already asked for adding the CNAME mentioned above? It probably wouldnc't have crossed their own minds, so maybe they'll agree to that.


Make it clear to them that the CNAME would be only for the FQDN:

If they can agree to that, you can start building the automated process.


Sorry, I got distracted by other things. It is not just an issue of getting the CNAME approved, but also to get approved to buy an external domain just to use for this.
In the end I will probably just have to rely on doing this manually every 80 days or so. Not a great solution, but probably the easiest for the <10 machines I have to do this for.
Thanks for your help!


There are plenty of free services that can be used for this purpose.
If IT will allow DNS (TCP&UDP port 53) to reach your system via a dedicated Internet IP, you can handle the delegated requests in the same system.
And, since there will be no DNS service running 24/7 on that device (only when needed), it should pass any security/compliance checks.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.