Could not get nonce

Help
1

I've read dozens of "could not get nonce" posts here and just can't figure it out. I don't think it's an issue with the individual domain, as it's occurred for more than a month with different domains. Perhaps my IP (209.216.85.156) is the issue?

My domain is: wellingtontransportation.com

I ran this command:
./acme.sh --dnssleep 300 --force --log --issue --webroot /var/www/www.wellingtontransportation.com-443/html/ -d wellingtontransportation.com -d www.wellingtontransportation.com -d wellingtontransportation.net -d www.wellingtontransportation.net --fullchain-file /etc/letsencrypt/wellingtontrans-fullchain.pem --key-file /etc/letsencrypt/wellingtontrans-privkey.pem

It produced this output:

[Mon Oct  7 09:19:28 PM EDT 2024] Using CA: https://acme.zerossl.com/v2/DV90
[Mon Oct  7 09:19:28 PM EDT 2024] Multi domain='DNS:wellingtontransportation.com,DNS:www.wellingtontransportation.com,DNS:wellingtontransportation.net,DNS:www.wellingtontransportation.net'
[Mon Oct  7 09:19:30 PM EDT 2024] Could not get nonce, let's try again.

My web server is (include version):
httpd-2.4.62-2.fc40.x86_64 (fedora40)

The operating system my web server runs on is (include version):
Fedora 40

My hosting provider, if applicable, is:
Our own server

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 --version
certbot 2.11.0

I'm using acme.sh that I just --upgrade(d)

# ./acme.sh --version
https://github.com/acmesh-official/acme.sh
v3.1.0

[Mon Oct  7 09:13:48 PM EDT 2024] Get nonce with GET. ACME_NEW_NONCE='https://acme.zerossl.com/v2/DV90/newNonce'
[Mon Oct  7 09:13:48 PM EDT 2024] GET
[Mon Oct  7 09:13:48 PM EDT 2024] url='https://acme.zerossl.com/v2/DV90/newNonce'
[Mon Oct  7 09:13:48 PM EDT 2024] timeout=
[Mon Oct  7 09:13:48 PM EDT 2024] Http already initialized.
[Mon Oct  7 09:13:48 PM EDT 2024] _WGET='wget -q --content-on-error '
[Mon Oct  7 09:13:48 PM EDT 2024] ret='0'
[Mon Oct  7 09:13:48 PM EDT 2024] _headers
[Mon Oct  7 09:13:48 PM EDT 2024] _CACHED_NONCE
[Mon Oct  7 09:13:48 PM EDT 2024] nonce
[Mon Oct  7 09:13:48 PM EDT 2024] Could not get nonce, let's try again.

I've also tried using wget manually and it downloads a zero-length file (no content):

# wget --content-on-error https://acme.zerossl.com/v2/DV90/newNonce 2>&1|grep -E 'Location|HTTP'
HTTP response 204  [https://acme.zerossl.com/v2/DV90/newNonce]
2

The acme.sh client by default uses ZeroSSL. It may be that they're limiting you or otherwise having problems, but we probably wouldn't know about it here on the Let's Encrypt forum.

But you might want to try --server letsencrypt to see if it works any better with Let's Encrypt.

5 Likes
3

It won't hurt to lose the --force option, too. It typically causes more problems than it solves, such as running into rate limits. It is only useful in an extremely narrow set of circumstances. Don't use it in your standard certificate issuance and renewal commands.

5 Likes
4

Same error after removing --force and adding --server letsencrypt.

I believe I made a mistake some months ago that resulted in a response that said I had made too many requests, but it also fails with --staging now, and this mistake was months ago.

5

If I gave the impression that removing the --force option would have any immediately noticeable effect, that was not my intention. It was just advice for best practices to build healthy habits for your future workflows.

Testing with --staging, like you just mentioned, is a good habit. The Let's Encrypt staging environment has separate (and higher) rate limits than those in the production environment.

Would you share the command and output when running against the Let's Encrypt staging environment?

4 Likes
6

@gossamer the anti-replay nonce is an http header returned by the ACME API you are using, try curl https://acme.zerossl.com/v2/DV90/newNonce -I

You should get something like:

HTTP/2 200
server: nginx
date: Tue, 08 Oct 2024 02:32:04 GMT
content-type: application/octet-stream
replay-nonce: i4vAnsoOdXXN4caccYVZxkfJOZcJ7HF400PjDC2nrI8
cache-control: max-age=0, no-cache, no-store
access-control-allow-origin: *
link: <https://acme.zerossl.com/v2/DV90>;rel="index"
strict-transport-security: max-age=15724800; includeSubDomains

If the problem persists you'd need to contact ZeroSSL support or switch to Let's Encypt. [ZeroSSL doesn't have a staging/test API so --staging will likely make no difference]

3 Likes
7

That looks to be exactly what I got:

# curl https://acme.zerossl.com/v2/DV90/newNonce -I
HTTP/2 200 
server: nginx
date: Tue, 08 Oct 2024 13:08:28 GMT
content-type: application/octet-stream
replay-nonce: XR-x765l-w7gREyCdxxjzdLUIQvHwEeDOZ45Bo3p0K4
cache-control: max-age=0, no-cache, no-store
access-control-allow-origin: *
link: <https://acme.zerossl.com/v2/DV90>;rel="index"
strict-transport-security: max-age=15724800; includeSubDomains
8
3 Likes
9

It still occurs when using --server letsencrypt.

I'm pretty sure it has something to do with my IP, as the same command works on a different host, although I can't use the docroot option.

Much of this issue originated because GoDaddy no longer allows access to their DNS API, so I have to use the docroot option. It was a round of attempts I ran before I realized why it wasn't working.

10

The nonce endpoint is used for all requests. So, is not directly related to your GoDaddy API change. Perhaps something you changed during that is the culprit.

Would you please show output of these two from same machine you run acme.sh

curl -I https://acme-v02.api.letsencrypt.org/acme/new-nonce
curl -I https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce
3 Likes
11

Thanks so much for your continued help.

[root@darwin .acme.sh]# curl -I https://acme-v02.api.letsencrypt.org/acme/new-nonce
HTTP/2 200 
server: nginx
date: Tue, 08 Oct 2024 19:34:11 GMT
cache-control: public, max-age=0, no-cache
link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
replay-nonce: XSSKzYfC2_4B1nNsuRl68Rt0MQ42rmocJeqZtXPZRBqMX7KQnvM
x-frame-options: DENY
strict-transport-security: max-age=604800

[root@darwin .acme.sh]# curl -I https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce
HTTP/2 200 
server: nginx
date: Tue, 08 Oct 2024 19:34:18 GMT
cache-control: public, max-age=0, no-cache
link: <https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"
replay-nonce: uG3HAO2iMndRRy0ixok5ZzIkh-kq-GhLCyNaIxVfRd-CfLWs7Og
x-frame-options: DENY
strict-transport-security: max-age=604800
2 Likes
12

It sounds like the way that your acme.sh is making requests is doing something different than your curl commands, or is somehow confused by something. I don't know what that difference might be, though. I assume you don't have any sort of proxy server you need to use to access external sites or the like? If I'm understanding the log right, it's using wget instead of curl, can you try running wget --server-response to see if it does anything different for some reason?

Something else you might want to try is another ACME client, even if just for testing. I don't know if there's some specific reason why you picked acme.sh. If you really like shell scripts, there's another shell-script-based one named dehydrated that you might try. I personally like and would recommend lego as one can similarly just copy the binary for your platform and run it without worrying about dependencies.

4 Likes
13

I started to think it had something to do with wget after your comments. So I deleted the acme.sh.* and all other directories and files that acme.sh created, except for the existing certs it already created, and now it works.

I could re-test with --use-wget to confirm, but I'm pretty sure that's the problem.

Thanks so much for your help.

5 Likes
14

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