How to force domain verification on

Is there a way to force domain verification in

I’ve looked at all the options and if there’s one to do this, I don’t see it or haven’t yet tried it. I’ve tried a lot of options already. I also don’t see anything obvious in the .conf files.

While I have successfully installed certs and renewals, I am having some intermittent or unobvious problem with dns_nsupdate-local on one domain, possibly related to file or bind permissions. So I need to repeatedly run and have it make and delete the DNS entries to debug this. But right now it won’t do the domain verification - which I understand is cached somewhere? by LE?

I'm invoking like this: \
--force \
--test \
--issue -d -d * \
--dns dns_nsupdate-local --dnssleep 15 \
--ocsp \
...cert install options abridged

and it reports

[Tue May 21 12:08:01 EDT 2019] is already verified, skip dns-01.
[Tue May 21 12:08:02 EDT 2019] * is already verified, skip dns-01.

All tips appreciated. Also, is there a better place to ask about or is this forum appropriate?

Thank you!


:wave: Hi @BrettD,

I think your best bet is to use the staging environment and a fresh ACME account each time you attempt issuance. Using the staging env is important to avoid using up your production rate limit debugging. Using a new ACME account each time will prevent any valid authorizations from being reused.

I think you can use ACME_DIRECTORY= to set the server to the staging API explicitly.

I'm not sure how you can make use a new account each attempt. If I remember correctly it stores some local state in a hidden folder (Maybe ~/

This forum is definitely appropriate :slight_smile:

1 Like

Agreed! As shown in my options above I am using --test (same as --staging)
I already rate-limited myself for a week when I accidentally invoked
the real server too many times :slightly_frowning_face:

I was thinking that something in <domain>/<domain>.conf should control this. Mine:
Le_CertCreateTimeStr=‘Mon May 20 02:27:52 UTC 2019’
Le_NextRenewTimeStr=‘Fri Jul 19 02:27:52 UTC 2019’

BUT even deleting this file completely seemed to not reenable domain (re)verification for the same domain, which suggests LE caching of the domain name.

Anyway: I requested an additional cert for a previously unused subdomain e.g. x.domain. That then showed me a clear error message that there was no read permission for user on the bind session.key needed for the dns_nsupdate-local authenticator which I am using.

So it seems this issue will arise by default for anyone running as an ordinary, unprivileged user - which is why some people want to use It is easily enough worked around, but likely to be encountered.

1 Like

I think the ACME account keypair is maintained separately from this file and it sounds like it isn't being re-created between attempts. :thinking:

That was a clever workaround too :+1: Glad to hear you arrived at a clear error.

Is creating different ACME accounts considered acceptable?

I didn’t want my IP to be banned or receive another lockout for creating multiple accounts.

1 Like

Yup! Absolutely acceptable, especially in the staging environment.

The staging environment has a very large Accounts per IP rate limit:

  • The Accounts per IP Address limit is 50 accounts per 3 hour period per IP.

If you use the production environment the rate limit is smaller:

You can create a maximum of 10 Accounts per IP Address per 3 hours.

In both cases if you hit the rate limit you'll only have to wait for 3 hours. It won't be a total ban.

Hope that helps!

1 Like

Thank you for making all of these very clear. I did read about them before but there are many LE aspects to try to remember, as well as, bind dynamic updates… :upside_down_face:

In the end… it all works pretty darn well!

1 Like

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