1

I want to use certbot to create a wildcard certification, and after I run certbot ... it gives me a hash, tells me to wait until I put it on the TXT Record of my domain.

But I don't have direct access to the DNS service I use. I have some office procedure to update the DNS settings, it takes time, so I can't keep the SSH window opened here. If I rerun certbot, the hash changes and the same problem occurs.

What is the correct way to wait for DNS refresh, and keep the hash unchanged? Thanks!

Romulus Urakagi Ts'ai
  • 187
  • 1
  • 9
  • Why can't you keep your session open? This is the only way. DNS propagation is quite fast nowadays, depending on your provider, of course. – Lenniey Oct 22 '19 at 09:03
  • Well at least 6 hours was not enough and I need to shut down my computer and go back home. – Romulus Urakagi Ts'ai Oct 22 '19 at 09:38
  • 6h for DNS propagation on your providers nameserver? That's...long. If the time is a problem, use `screen` (or equivalent) for your SSH session. – Lenniey Oct 22 '19 at 09:39
  • I'd say if you have to wait 6 hrs, then something is not right. Usually it takes seconds using for instance CloudFlare name servers. So the options are either use HTTP authorization or to tune somehow DNS (probably switching to other DNS providers or tune TTL). The simplest way is the HTTP auth for certbot. – user3120146 Oct 22 '19 at 14:24
  • It's a pity that the domain is not managed by me, I need to contact someone each time to change the settings, and also the DNS service is a local provider. Too many reasons to delay :/ Anyway this morning when I rerun `certbot` I found if I do not challenge the hash will not change, so the problem is solved. – Romulus Urakagi Ts'ai Oct 23 '19 at 02:01

4 Answers4

6

I found that if I Ctrl-C before challenging (e.g. press Enter) the hash won't change.

So I can wait for the DNS update then re-run certbot, it shows the same hash, and now I can press Enter immediately.

Romulus Urakagi Ts'ai
  • 187
  • 1
  • 9
2

AFAIK, the TTL is irrelevant for the DNS-01 challenge. It appears that Let's Encrypt checks which servers are authoritative and queries one of the authoritative servers directly, so the necessary delay is about allowing for the zone data to sync to all the authoritative servers, not about waiting for any caches to expire (this would be where TTL is relevant).


That said, the intended way of doing Let's Encrypt is to actually automate, whether you use the HTTP-01 challenge or the DNS-01 challenge.
The major advantage of this is that with a small bit of work upfront the certificates will actually automatically renew as necessary (by having certbot renew invoked regularly), which is pretty important for making these short-lived certificates viable.

certbot comes with a set of plugins for doing DNS updates (and there is always the option implementing your own as well).

At the time of this posting, the list of plugins was:

  • certbot-dns-cloudflare
  • certbot-dns-cloudxns
  • certbot-dns-digitalocean
  • certbot-dns-dnsimple
  • certbot-dns-dnsmadeeasy
  • certbot-dns-google
  • certbot-dns-linode
  • certbot-dns-luadns
  • certbot-dns-nsone
  • certbot-dns-ovh
  • certbot-dns-rfc2136
  • certbot-dns-route53

(See the docs for an up to date list + links to relevant instructions)

Ie, essentially there's a plugin with RFC2136 support (regular DNS dynamic updates, compatible with most standard DNS servers that you might run yourself) + a set of plugins for proprietary APIs of some major DNS service providers.

Example usage:

certbot certonly \
  --dns-rfc2136 \
  --dns-rfc2136-credentials ~/.secrets/certbot/rfc2136.ini \
  -d example.com

These also have an argument (name varies by plugin) like --dns-rfc2136-propagation-seconds that allows for tweaking how long to wait before completing the challenge (to allow zone data to sync to authoritatives).

Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
  • Thanks for the answer, I reached this but I don't know how to do for our local DNS service provider, and I even do not have the direct access to it so it costs time. I think my question is not good so I get answers to accelerate DNS propagation. I will edit it. – Romulus Urakagi Ts'ai Oct 23 '19 at 09:24
1

There isn't any good way to accomplish this atm I guess.

I kept the certbot prompt open for waiting while in my second terminal window I just ran for example dig -t txt _acme-challenge.mydomain.com (replace the txt address with yours). When it didn't show any TTL seconds running in ;; ANSWER SECTION: anymore for that record then the certbot finished successfully after enter-press.

If you should still need to keep your SSH connection alive long time (on the background) then maybe Linux screen tool comes handy? I use it to run long-running commands which might get in danger of SSH-timeout. Just open screen-session with screen -S give_it_a_good_name and run the certbot operation in there. You can then deattach the screen with Ctrl+a d and later come back into it with screen -r your_screen_numerical_id and see your prompt still alive.

Be sure to later access the screen session under same user you initiated it! For ex. if you initiated screen session as root then you don't find it under ubuntu or whatever other user for example.

Andres
  • 111
  • 4
0

Each DNS record has a TTL value. You can change it to anything. You can set it to 60 seconds or normally keep at higher value and prior the change set it to lower value. That way the changes will propagate almost immediately.

Also, the certbot asks you to create a new record. The new records are also propagated very fast (within minutes), so you don't actually have to wait a long time for verification.

esoroka
  • 307
  • 2
  • 5
  • None of this helps, though, if one's DNS process is "file a ticket with IT, who will do it at some point in the next two weeks". As is common with many large organizations. – ceejayoz Aug 09 '21 at 20:16