# 400 Responses from /acme/new-order endpoint in staging

**URL:** <https://community.letsencrypt.org/t/400-responses-from-acme-new-order-endpoint-in-staging/116110>\
**Category:** Help\
**Created:** [March 11, 2020, 4:19pm UTC](https://community.letsencrypt.org/t/400-responses-from-acme-new-order-endpoint-in-staging/116110 "2020-03-11T16:19:15Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![iamjem](https://avatars.discourse-cdn.com/v4/letter/i/8dc957/32.png) [@iamjem](https://community.letsencrypt.org/u/iamjem)\
**Post date:** [March 11, 2020, 4:19pm UTC](https://community.letsencrypt.org/t/400-responses-from-acme-new-order-endpoint-in-staging/116110/1 "2020-03-11T16:19:15Z")

</div>

We’ve been seeing a ton of 400 responses from the ACM v2 API in staging whenever we attempt to create a new order via this endpoint:

[https://acme-staging-v02.api.letsencrypt.org/acme/new-order](https://acme-staging-v02.api.letsencrypt.org/acme/new-order)

From my understanding this isn’t an endpoint thats being deprecated, but this behavior seems indicative of some kind of brown out? The API responses we see are:

```auto
<html>\r\n<head><title>400 Bad Request</title></head>\r\n<body>\r\n<center><h1>400 Bad Request</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n

```

We create lots of certs programmatically, so this isn’t specific to a particular domain (I can often retry the same request later and it works just fine). We do not see this behavior at all in production.

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [March 11, 2020, 8:00pm UTC](https://community.letsencrypt.org/t/400-responses-from-acme-new-order-endpoint-in-staging/116110/2 "2020-03-11T20:00:49Z")

</div>

HTTP 400 is unlikely to be an outage, but something wrong with the request.

If you can capture the request line + request headers + request body from such an instance, that could help.

Did this happen only in one contiguous window of time or across multiple windows in time?

If the former, perhaps LE were experimenting with the web server configuration.

---

<div class="post-metadata">

**Author:** ![Phil](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/phil/32/76801_2.png) [@Phil](https://community.letsencrypt.org/u/Phil)\
**Post date:** [March 11, 2020, 11:17pm UTC](https://community.letsencrypt.org/t/400-responses-from-acme-new-order-endpoint-in-staging/116110/3 "2020-03-11T23:17:17Z")

</div>

From the LE side we’ve not made any noticeable changes to the staging load balancers or boulder WFE services in ~2 weeks.

I agree with @_az, can we see the request lines, headers, and body please?

---

<div class="post-metadata">

**Author:** ![iamjem](https://avatars.discourse-cdn.com/v4/letter/i/8dc957/32.png) [@iamjem](https://community.letsencrypt.org/u/iamjem)\
**Post date:** [March 12, 2020, 1:47am UTC](https://community.letsencrypt.org/t/400-responses-from-acme-new-order-endpoint-in-staging/116110/4 "2020-03-12T01:47:17Z")

</div>

Yep! I’ll push some code changes out tomorrow so I can capture the outgoing requests that are failing!

---

<div class="post-metadata">

**Author:** ![leader](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/leader/32/7569_2.png) [@leader](https://community.letsencrypt.org/u/leader)\
**Post date:** [March 12, 2020, 8:26am UTC](https://community.letsencrypt.org/t/400-responses-from-acme-new-order-endpoint-in-staging/116110/5 "2020-03-12T08:26:27Z")

</div>

This could be an indication that the code/client you are using has not been updated to [correctly] support Post-As-Get change deployed to stage (but not prod).

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [March 12, 2020, 9:02am UTC](https://community.letsencrypt.org/t/400-responses-from-acme-new-order-endpoint-in-staging/116110/6 "2020-03-12T09:02:24Z")

</div>

In that case OP would be seeing an ACME error response [like this one](https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/18383545).

That we see the default nginx error page strongly suggests that there is an HTTP protocol violation going on. But no idea why it would be intermittent.

---

<div class="post-metadata">

**Author:** ![iamjem](https://avatars.discourse-cdn.com/v4/letter/i/8dc957/32.png) [@iamjem](https://community.letsencrypt.org/u/iamjem)\
**Post date:** [March 12, 2020, 3:51pm UTC](https://community.letsencrypt.org/t/400-responses-from-acme-new-order-endpoint-in-staging/116110/7 "2020-03-12T15:51:51Z")

</div>

We are using an old version of the golang crypto/acme client.

This is the HTTP request (obtained using `httputil.DumpRequestOut`):

```auto
POST /acme/new-order HTTP/1.1
Host: acme-staging-v02.api.letsencrypt.org
User-Agent: go-acme/2
Content-Length: 571
Content-Type: application/jose+json
Accept-Encoding: gzip

{"protected":"<redacted>","payload":"<redacted>","signature":"<redacted>"}

```

This is the payload:

```auto
{"identifiers":[{"type":"dns","value":"direwolf-26360e51fb.staging.herokuappdev.com"}]}

```

This is the response (again):

```auto
<html>\r\n<head><title>400 Bad Request</title></head>\r\n<body>\r\n<center><h1>400 Bad Request</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n

```

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [April 11, 2020, 3:51pm UTC](https://community.letsencrypt.org/t/400-responses-from-acme-new-order-endpoint-in-staging/116110/8 "2020-04-11T15:51:53Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.