I make requests:
request to: https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce Ok
request to: https://acme-staging-v02.api.letsencrypt.org/acme/new-acct Ok
request to: https://acme-staging-v02.api.letsencrypt.org/acme/new-order Ok
request to https://acme-staging-v02.api.letsencrypt.org/acme/finalize/12583153/76890793
and I have 403 error: Order’s status (“pending”) is not acceptable for finalization
What I forgot?
When I must make challenge?
Challenge must be done between new order and finalize.
Is it request from 7.5. Identifier Authorization of RFC 8555
POST /acme/authz/PAniVnsZcis ?
Precisely, the a11ns must be done.
Generally, the process is:
(I might missed some part but i think this is a general enough summary…)
How the complete validation?
What is the request by url ?
section 7.5.1. Responding to Challenges
"url": "https://example.com/acme/chall/prV_B7yEyA4", ????
My Requests:
request to: https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce
request to: https://acme-staging-v02.api.letsencrypt.org/acme/new-acct
create account status: 200
request to: https://acme-staging-v02.api.letsencrypt.org/acme/new-order
request to: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/40842755
Have the token.
set token to DNS TXT ("_acme-challenge.my.domain.net)
request to https://acme-staging-v02.api.letsencrypt.org/acme/finalize/12583153/76890793
and status 403
Order's status ("pending") is not acceptable for finalization"
My requests:
request to: https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce
request to: https://acme-staging-v02.api.letsencrypt.org/acme/new-acct
request to: https://acme-staging-v02.api.letsencrypt.org/acme/new-order
request to: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/40842755
request to: https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/40842755/wX8BZQ
request to https://acme-staging-v02.api.letsencrypt.org/acme/finalize/12583153/76890793
ERROR 403 Order’s status (“pending”) is not acceptable for finalization
What is absent?
This explains types of request: Challenge Types - Let's Encrypt
If you want to know how to complete the request or finish the process, you have a lot of resources to reference to. There might be clients that uses the same programming language available on letsencrypt.org/docs/client-options/, and most of their code are available on GitHub.
Having examples and understand it is better than people explaining in plain words.
As I said, you need to obtain and complete the validation. Then request Let's Encrypt to verify the result.
After all above are completed successfully, you can finalize the order and complete the whole process.
P.S. it seems like English might not be the language you used. Which language do you speak? (We might have someone know that language)
Thank you
I'm russain
I must make the challenge check status while it is pending?
How long time is creating the cert? ( 10 sec or 10 min)
I check the status by request https://.../acme/chall-v3/xxx
Is it True?
Hi @akalend,
If you don't understand we could ask @leader to help out in Russian (especially since he has successfully developed an ACME client).
In RFC 8555 it says
The server is said to "finalize" the authorization when it has
completed one of the validations. This is done by assigning the
authorization a status of "valid" or "invalid", corresponding to
whether it considers the account authorized for the identifier. If
the final state is "valid", then the server MUST include an "expires"
field. When finalizing an authorization, the server MAY remove
challenges other than the one that was completed, and it may modify
the "expires" field. The server SHOULD NOT remove challenges with
status "invalid".
Usually, the validation process will take some time, so the client
will need to poll the authorization resource to see when it is
finalized. For challenges where the client can tell when the server
has validated the challenge (e.g., by seeing an HTTP or DNS request
from the server), the client SHOULD NOT begin polling until it has
seen the validation request from the server.
To check on the status of an authorization, the client sends a POST-
as-GET request to the authorization URL, and the server responds with
the current authorization object. In responding to poll requests
while the validation is still in progress, the server MUST return a
200 (OK) response and MAY include a Retry-After header field to
suggest a polling interval to the client.
So yes, you need to poll (repeatedly ask for the status of the validation) in order to find out when the certificate authority is done. There are two stages of the RFC 8555 procedure where you have to "poll for status":
+-------------------+--------------------------------+--------------+
| Action | Request | Response |
+-------------------+--------------------------------+--------------+
| Get directory | GET directory | 200 |
| | | |
| Get nonce | HEAD newNonce | 200 |
| | | |
| Create account | POST newAccount | 201 -> |
| | | account |
| | | |
| Submit order | POST newOrder | 201 -> order |
| | | |
| Fetch challenges | POST-as-GET order's | 200 |
| | authorization urls | |
| | | |
| Respond to | POST authorization challenge | 200 |
| challenges | urls | |
| | | |
| Poll for status | POST-as-GET order | 200 |
| | | |
| Finalize order | POST order's finalize url | 200 |
| | | |
| Poll for status | POST-as-GET order | 200 |
| | | |
| Download | POST-as-GET order's | 200 |
| certificate | certificate url | |
+-------------------+--------------------------------+--------------+
You have to "poll for status" after responding to the challenges (while waiting for the certificate authority to finish checking them), and then again after finalizing the order (while waiting for the certificate authority to finish issuing the certificate).
I believe the reason for these steps in terms of the software architecture is that a different component of the certificate authority system is responsible for challenge validation (and for certificate issuance), and the amount of time either step can take is somewhat unpredictable.
If you get a retry-after: header from the CA, you can use that as a guide for when to retry the request. In general, the typical delays that you would see with Let's Encrypt validation and issuance are much closer to 10 seconds than to 10 minutes.
Thanks for information, it is very help me
But I have new problem:
I make fetch challenges request and a have status invalid and
error: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.fi469.hmn.me - check that a DNS record exists for this domain
status400 urn:ietf:params:acme:error:dns
HTTP status 200 Ok
the dig tool answer:
_acme-challenge.fi469.hmn.me. 299 IN TXT “EmiWaWoMGrlYHlMHQO0M0fY1gPZ-TJxGdmTqorBstQA”
I make fetch every 10 sec to 3-5 min. The DNS type TXT _acme-challenge.fi469.hmn.me exist end content is token value
I create certificate by cerbot without any problem.
When the challenge status becomes invalid, you cannot do much with it anymore. Normally, it means that you should treat the order invalid as well (except the unlikely case you want to validate the same identifier with a different validation method).
The error you quoted normally means that the record was not (yet) available on all DNS servers at the time of checking, or due to other DNS data propagation delays.
bruncsak Thank very match,
I use Cloudflare DNS provider. As I use certbot:
certbot certonly --dns-cloudflare … ,
as I have generation certs twenty sec.
But, I use API, the cert have invalid status more 5 min. It is abnormally.
I probably have an error.
I study certbot logs, and do not find difference with my requests
If the challenge or order has invalid status, it won’t change its status anymore. It is not matter before or after 5 minutes.
After putting the TXT DNS records in place, and next your API script is asking to verify the challenge, enough time must elapse. You should check that, is that correctly configured.
(By the way I believe the following practice is reliable: my script checks each DNS records with matching value individually on each of the authoritative name servers before continuing, such as asking the ACME server to verify the challenge. Normally it finishes its run in two to three seconds.)
I set delay 10 sec after call challenge API, before authz request and repeat one every 10 sec.
If I don't delete old DNS TXT record, I have authorized error.Therefore, the letsencrypt API reads DNS records, but tokens value do not compare.
I will make DNS check record before call authz request
I create delay by checking dns TXT while value not eq token and have error:
{
'type': 'urn:ietf:params:acme:error:unauthorized',
'status': 403,
'detail': 'Incorrect TXT record "FvDRNcErTIXKlaD2TPHk080YZdOo0EbSoy-1qWPS9jE" found at _acme-challenge.fi469.hmn.me'
}
What is reason?
The error means that the ACME server found a TXT DNS record for validatation, but its value does not much the expected value. Did you properly extract the challenge value from the jws data, create the hash for the DNS?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.