How to force domain verification on acme.sh?

[BrettD]

Is there a way to force domain verification in acme.sh?

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 acme.sh 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 acme.sh like this:
acme.sh \
--force \
--test \
--issue -d domain.ca -d *.domain.ca \
--dns dns_nsupdate-local --dnssleep 15 \
--ocsp \
...cert install options abridged

and it reports
…
[Tue May 21 12:08:01 EDT 2019] domain.ca is already verified, skip dns-01.
[Tue May 21 12:08:02 EDT 2019] *.domain.ca is already verified, skip dns-01.

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

Thank you!

Brett

[cpu]

Hi @BrettD,

@BrettD

So I need to repeatedly run acme.sh 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 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=https://acme-staging.api.letsencrypt.org/directory acme.sh to set the server to the staging API explicitly.

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

@BrettD

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

This forum is definitely appropriate

[BrettD]

@cpu

I think your best bet is to use the [staging environment]

Agreed! As shown in my acme.sh 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

and a fresh ACME account each time you attempt issuance.
...
I’m not sure how you can make acme.sh use a new account each attempt. If I remember correctly it stores some local state in a hidden folder

I was thinking that something in <domain>/<domain>.conf should control this. Mine:
Le_Domain='domain.ca'
Le_Alt='*.domain.ca'
Le_Webroot='dns_nsupdate-local'
Le_PreHook=''
Le_PostHook=''
Le_RenewHook=''
Le_API='https://acme-staging-v02.api.letsencrypt.org/directory'
Le_Keylength=''
Le_OCSP_Staple='1'
Le_OrderFinalize='https://acme-staging-v02.api.letsencrypt.org/acme/finalize/x/y'
Le_DNSSleep='15'
Le_LinkOrder='https://acme-staging-v02.api.letsencrypt.org/acme/order/x/y'
Le_LinkCert='https://acme-staging-v02.api.letsencrypt.org/acme/cert/x
Le_CertCreateTime='1558319272'
Le_CertCreateTimeStr='Mon May 20 02:27:52 UTC 2019'
Le_NextRenewTimeStr='Fri Jul 19 02:27:52 UTC 2019'
Le_NextRenewTime='1563416872'
Le_RealCertPath=...

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 acme.sh error message that there was no read permission for acme.sh 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 acme.sh as an ordinary, unprivileged user - which is why some people want to use acme.sh. It is easily enough worked around, but likely to be encountered.

[cpu]

@BrettD

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.

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

@BrettD

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

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

[BrettD]

@cpu

I think your best bet is to use the staging environment and a fresh ACME account each time you attempt issuance.

Is creating different ACME accounts considered acceptable?

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

[cpu]

@BrettD

Is creating different ACME accounts considered acceptable?

Yup! Absolutely acceptable, especially in the staging environment.

@BrettD

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

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!

[BrettD]

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 acme.sh, bind dynamic updates…

In the end… it all works pretty darn well!