I’ve been using gethttpsforfree.com for about a year with only intermittent glitches. In the last 24 hours I have been getting variations of a nonce error at various stages of the https://gethttpsforfree.com/ web page and I have been unable to get or install a certificate.
I have cleared my Firefox caches before every attempt to use https://gethttpsforfree.com/. I have now attempted 8 times over 12 hours … all met with failure.
I see Intermittent badNonce errors but I don’t know if this is related to my problem. I don’t know if the “Boulder” referred to in the post is Boulder, Colorado but I’m in Longmont … an adjacent city. I doubt if that’s related to my problem but, hey, I threw that in.
Last September my team and I debuted a system that allows our customers to get LE certs and have them installed automatically on their sites. Since then we have experienced 11,872 invalid anti-replay nonce errors. Our system is designed to retry the request when this error occurs. Simply retrying seems to “solve” the problem. And by solve I mean the order process continues without issues.
Boulder in that post refers to Let’s Encrypt’s API. It’s just the name of the API and most likely has nothing to do with your physical location.
The response in the thread you linked to that is likely related to what your experiencing is this one. Essentially, Boulder only allows X amount of nonces to be active at any time. Once X is reached then Boulder begins invalidating nonces starting with the oldest ones. This means that if you make a request a request to Boulder and then wait a bit it is possible the nonce you received previously will be invalid when you make the next request. I am unfamiliar with the service you’re using so I’m not sure how they handle this.
This means that if you make a request a request to Boulder and then wait a bit it is possible the nonce you received previously will be invalid when you make the next request.
Please define "a bit". Is that seconds, minutes, hours, or days? When does the nonce (whatever that is) start? When does it end?
Is there background information a newbie like me might read to better understand the failure?
Is the problem that I'm being to fast or too slow when making my requests. I suspect from your answer that I'm too slow but I'm not sure.
I truly appreciate your help but I still have no clue how to solve my problem. Perhaps saying what you (the human) and your code's relationship to Lets Encrypt is might help others and me.
I’m going to mention @diafygi who created gethttpsforfree.
But, @jsha@cpu, this sounds like it might be a backend problem if the problem is intermittent, exists across multiple clients, and is often resolved simply by retrying.
For gethttpsforfree.com, I request all the needed nonces (GET /directory) after Step 2, and they get used through the remaining steps. So if things start to roll over before you get done, that might be the issue.
Based on current usage volume I'd estimate we start rolling nonces out of validity inside of ~1-2 hours for production. Since your requests were ~4 hours apart the nonces had expired. I think the ultimate take-away should be to view the bad nonce errors as non-fatal and have your systems recover by refreshing the nonce used.
-[Intermittent badNonce errors - #12 by cpu]
@cpu That was 9 months ago, so is the rolling time limit now?
To answer Ralph’s question, a nonce is a value chosen differently each time. Because it’s different each time, a bad guy can’t just watch what you do and then do the same, the nonce they get will be different. But Let’s Encrypt needs to remember the ones it gave out. Rather than remember an unlimited number of nonces, it chooses to forget the older ones. So, it’s possible if you can do the steps more quickly they’ll succeed. Still, maybe Let’s Encrypt should invest in storing a few more or some other arrangement that would help people avoid this.
Please do let us know if doing the steps quicker helps, or if it doesn’t.
@tialaramex: In terms of speed, gethttpsforfree.com requires a fair amount of manual cutting and pasting. For me, from the time I fill in the first section of the website (where it asks for an email address and a public key) to the point where it has verified I own the website associated with the URIs stresslesshomestaging.com and www.stresslesshomestaging.com, it takes me about 10 minutes if I do it quickly which, of course, is prone to error.
So a question for @diafygi: With gethttpsforfree.com, when does the nonce start and when does it end? That is, when is the first time the nonce is generated and when is the last time it is used?
@RalphShnelvar The nonce requests happen when you click “Validate CSR” on Step 2. The last nonce is used when you click the verification of the last domain you have on Step 4. So the rolling time is between Step 2 and Step 4.
So on Sunday morning (about 4 a.m. Mountain time) I cut and paste as fast as I could and … I got my certificate!
For another website using an Apache2 server, I used certbot-auto ( i.e. sudo wget https://dl.eff.org/certbot-auto ) and, remarkably, had almost no problems. The entire process - once I fixed all my problems (I had multiple virtual hosts in my mydomain.com.conf file) - probably took less than 3 minutes.