my case is a bit special. I work with Let’s Encrypt certificates on windows (Server and Client) since several years. First I tested the letsencrypt-win-simple client - it worked but had its limits.
Because I use the certificates for a few mail-servers and for the development of RPC-Servers and wanted to have compatibilty with my management program XCA I looked for another solution and found (some years ago) zerossl.com.
I used own csr’s, different Let’s Encrypt accounts for each domain and pem in- and output. It was perfect no problems at all (though some hours work every three months). Some days ago I wanted to do the renewal of the certs and surprisingly zerossl.com is not what it was before (You know what I mean) - I lost my client.
So I spent hours and hours to find an alternative and tested win-acme. There was no option to import a pem account-key I did it without and used the staging environment of Let’s Encrypt - it worked. I used the production environment and got an “invalid anti-replay nonce” error after DNS validation. I repeated the next day, same result.
2020-06-24 02:45:37.351 +02:00 [INF] Preliminary validation succeeded
2020-06-24 02:45:38.085 +02:00 [ERR] Error authorizing PKISharp.WACS.DomainObjects.TargetPart
2020-06-24 02:45:38.101 +02:00 [ERR] (AcmeProtocolException): JWS has an invalid anti-replay nonce: “0102J1jqqLlF71rziLpgtm0is9GK9w8aH8w-N7_1GYqibxo”
2020-06-24 02:50:43.710 +02:00 [ERR] Create certificate failed: JWS has an invalid anti-replay nonce: “0102J1jqqLlF71rziLpgtm0is9GK9w8aH8w-N7_1GYqibxo”
I thought it might be the new created account (I could not use the original account) causing that error and I searched for a client I can use with the original account-key and found gethttpsforfree.com. It’s a bit more complicated than zerossl.com (earlier) but I think I did it correctly - with the result (before domain validation)::
Error: Account registration failed. Please start back at Step 1. { “type”: “urn:ietf:params:acme:error:badNonce”, “detail”: "JWS has an invalid anti-replay nonce: “0101dqJaUsoayxATS9NeZeFny21pZ2znGBPOthlZPH7AvC8"”, “status”: 400 }
What can I do? I need Help.
Johanna
PS: I use a Windows Pro VM for the cert management incl. renewal and the services run on windows server.
With win-acme I used the cert for mail.chrmnet.com - with gethttpsforfree.com I used the cert for mail.fb-com-svcs.net.
I will look at your link tomorrow and yes I have thought to use Linux because I know the most ACME-clients are based on this OS but I hesitated - I am not very familiar with Linux. Since several years I try to get in a closer touch but at the end I see, my roots are on windows.
Another problem is the availibility of XCA. XCA is written in Qt, so perhaps there is a linux version but I have to check that. I use XCA to setup internal CA’s (the corresponding sites for ca-enrollment and revocation run on IIS) and issue certificates for RPC-Server development For public tests I use the Let’s Encrypt certificates on the server and sometimes on the client but the administration (Key creation, CSR creation, import and export in several formats and the general overview) I do as well in XCA. So I need this program (many thanks to the author!!!).
On the other hand: two similar error messages, one from a windows client, one from a linux based web site - I think a lower layer (f.e. a library) may be raising the exceptions.
So I thought a bit deeper and there are some general questions:
What happens when it try to renew a certificate issued under one of my old accounts (with zerossl) now with a new account (same contact mail), as it happened during my tests with the win-acme client?
Is the the host name from the old certificate bound to the old account?
May be the result of the renewal try under a new account a lock of the old account or a lock of the new account or a lock of the hostname?
I think you are overthinking the problem.
FQDNs are not tied to, or locked by, accounts as you might think: Multiple accounts can request certs for the exact same name.
If you are using the latest client, you should be able to get a cert despite whatever may have happened via any other account previously.
That logic makes sense if you understand that everyday domains are sold or transferred to new owners… How would the new owner then be able to obtain certs for it?
first of all, thank You for the link to Posh-ACME, yesterday I’ve read the feature list (sounds good) and thought I should test it.
But at that point I had only half an hour (not enough to start with it) and so I scrolled again through the client list on the Let’s Encrypt site just to kill the time.
And at a link named “ZeroSSL project” I stopped. I had skipped this entry the days before because I thought it would lead to the new site that has nothing to do with LE anymore.
Nevertheless, yesterday I checked the link target and noticed I was wrong. The link leads to a github project “Crypt-LE” and reading the details I was electrified. This seems to be the interface to LE the old ZeroSSL site worked with. And they have a portable Windows client that needs no additional software.
In the evening I downloaded the client and tested it with a certificate currently not in use - it worked. Then I tested it with the two certs I had problems with (see above) and it worked as well.
So, meanwhile I have almost all of my certificates updated. The Crypt-LE client is the ideal tool for all users that worked with the old ZeroSSL site in the past.
By the way, I will as well test Posh-ACME later but for the moment my problems are solved.
Thank You very much for the help and the patience to read my posts.
Thank you for mentioning that. That reminded me that the way that link is worded might indeed be confusing considering that ZeroSSL project has changed ownership. And since Crypt-LE supports more than just Let's Encrypt (issuance of the certificates by other CAs and ACME-compatible servers is also supported), it should be listed as Crypt-LE there. I will submit the corrections to that list.