Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status remains at 'processing' #3406

Closed
ghost opened this issue Jan 28, 2018 · 7 comments
Closed

Status remains at 'processing' #3406

ghost opened this issue Jan 28, 2018 · 7 comments

Comments

@ghost
Copy link

ghost commented Jan 28, 2018

As requested in this topic, I created some logs to solve this issue.

In the logfiles, you see an URL, followed by a payload array, followed by an array containing the response from the server.

@cpu
Copy link
Contributor

cpu commented Jan 29, 2018

Hi @hsleisink,

Thanks for sharing your logs. Having read those I can confirm this is a duplicate of #3403

In the first log you POST the finalization URL of the order when both authorizations (and the order) are status pending. This produces a 403 urn:ietf:params:acme:error:unauthorized error and the order is stuck in processing.

In the second log I don't see the challenge response being registered but you can see both authorizations listed in the order are status valid:

$> curl https://acme-staging-v02.api.letsencrypt.org/acme/challenge/ew26AHotD3yd8L94Ybbzl0FDCefjA5n5b5cHJUskcbM/96337240 2> /dev/null | jq .status
"valid"

and

$> curl https://acme-staging-v02.api.letsencrypt.org/acme/challenge/V_EM5Goi3asS2FnmMKnf80JOzmhoiO28xJOx-XDLofg/96337237 2> /dev/null | jq .status
"valid"

In that second case since both authorizations are valid at the time you finalize the order, the finalization succeeds.

finalizing order before polling status, according to RFC.

Can you quote which part of the RFC makes you think you should finalize the order before checking the authorizations associated with it are valid? That's not true and I believe the spec makes multiple references to the fact that you should not finalize the order until you have authorized each of the identifiers by completing the order's pending authorizations.

I'm going to close this issue for now since I've confirmed it as a dupe of #3403. Thanks!

@cpu cpu closed this as completed Jan 29, 2018
@ghost
Copy link
Author

ghost commented Jan 29, 2018

Can you quote which part of the RFC makes you think you should finalize the order before checking the authorizations associated with it are valid?

The table at the top of page 18 at https://tools.ietf.org/html/draft-ietf-acme-acme-09 says 'finalize order' before 'polling for status'.

@cpu
Copy link
Contributor

cpu commented Jan 29, 2018

@hsleisink Yes, but "finalize order" is after "Respond to challenge". The polling it mentions would be better phrased as "Poll for Order Status and Certificate URL" - the intention is that you're polling for the transition from "processing" to "valid" and the appearance of the certificate URL. You absolutely must respond to the order's authorization challenges successfully before finalization.

@ghost
Copy link
Author

ghost commented Jan 29, 2018

Ok, so we have two polling fases. One for the authorizations and one for the creation of the certificate?

@cpu
Copy link
Contributor

cpu commented Jan 29, 2018

Yes. You need to make sure the order is fully authorized before POSTing finalize.

Doing otherwise shouldn't leave the order stuck in processing (that will be fixed) but it will always return an unauthorized error if any of the authorizations are not valid.

@ghost
Copy link
Author

ghost commented Jan 29, 2018

Ok, got it. Thanks. The documentation was not really clear on that to me. I found the RFC very hard to read and understand. But that's a different story. I know enough to solve my issue. Thanks!

@cpu
Copy link
Contributor

cpu commented Jan 29, 2018

@hsleisink Great! Glad to hear it. I'm hoping to ship #3404 to fix the processing bug shortly.

I found the RFC very hard to read and understand

If you're interested I think feedback on which aspects you found hardest to understand would be welcome as a new issue on the ACME draft repository or as a new mailing list thread. There's still time for editorial work to make things clearer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant