We have our own Java ACME v2 client.
From today, suddenly we are facing the below error and couldn't issue any certificates,
Error creating new order :: too many currently pending authorizations
But, as per our domain records, there is not pending authorizations for our account.
Help us in fixing this.
Kindly inform if any information is needed from us to check in your (LE) side.
If you are experiencing an urgent issue, you can register a new ACME account and it won’t have any pending authorizations associated with it.
Any changes are done in Authorizations that may cause this error...? @_az @cpu @roland @jsha @Phil @JuergenAuer
Also having another doubt,
Currently, Authorization will be valid for 30 days
but many of our Authz URIs are valid for more than 30 days; today (23/11/2019)
https://acme-v02.api.letsencrypt.org/acme/authz-v3/1353009804
"status": "valid",
"expires": "2019-12-29T10:00:01Z"
A post was split to a new topic: Too many certificates already issued for exact set of domains: wiesert.eu,www.wiesert.eu
We have scanned all our Authorization URLs (22845) in Let's Debug Clear Authz Toolkit
All the domains are not pending in Let's Encrypt side also.
Not sure why getting this below error still.
Error creating new order :: too many currently pending authorizations
The problem with the new account in our side is that we have restricted like one account per LE endpoint in our implementation.
We made this constraint based on the recommendation from LE Integration Guide documentation,
However, for most larger hosting providers we recommend using a single account and guarding the corresponding account key well.
Kindly provide suitable solution... @cpu @jsha @JuergenAuer @roland @Phil @rmbolger
we are working on to support another account for certificate purchase of new domains...
Hi @Devarajan,
Please refrain from the gratuitous use of mentions in each comment. We will dig in as soon as we can.
Hi @Devarajan
I have already answered that question.
pending authorizations are an indicator that your client is buggy.
There are a lot of opportunities why you see that error message and why you don't find pending authorizations.
Simple sample: Your client creates parallel orders at 15:00 - a lot of domains per server, more then one server. 10 server, every with 30 new orders -> the next order has that error message. 30 seconds later, all certificates are created -> no pending order is visible.
So: How many servers use that buggy client? How many domains per server?
Is the same account used with such wrong parallel orders?
A correct client has always only one open order, not 2, not 5, not 200. Then the order is finished, valid + certificate or invalid -> next order.
Then you have never that problem of pending authorizations.
Sorry for the inconvenience 
it would be helpful if we have an option to view our pending Authz associated with an account so that debugging such issues will be easy/transparent for LE users 
Thanks for pointing this out. It's actually the case that a successful validation adds 30 days to the lifetime of the pending authorization, which is 7 days. However, this is definitely confusing. I'll talk to the team about changing it so valid authorizations always last exactly 30 days from the time of validation.
I looked in our logs for the authorization object you mentioned, and it appears that your client doesn't send a specific User-Agent header identifying itself, but instead sends a generic Java User-Agent. Could you fix that so it sends a User-Agent header indicating the client name and version?
In terms of the pending authorization problem: As @JuergenAuer said, this issue is usually caused by a buggy client. Since your client is not publicly available, it's hard for us to help you debug it.
Since the Let's Debug Clear Authz Toolkit couldn't find any pending authorizations in your logs, it sounds like you might not be logging every authorization you create. Can you double-check how many authorizations your code has attempted to create? If there's a mismatch, that is where you should concentrate your debugging energy.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
