Generating "subproblems" to test against

Client dev
1

Saw this in another thread. Was there a thread in API Announcements I missed about it?

Regardless, it's awesome and I'd love to make sure my client handles and displays these appropriately. Is there an easy way to generate some subproblem errors with Pebble or Staging?

4 Likes
2

There wasn’t a post in API Announcements. I think it didn’t occur to us to make one since it’s a backwards-compatible change, but it probably does make sense to let everyone know it’s available!

The easiest way to generate subproblems on staging is to submit an order that has some valid identifiers and some invalid ones (basically anything that’s not a domain name). Pebble doesn’t yet support subproblems; we should add that.

4 Likes
3

Are we sure this is actually live? I just sent an order request to staging with the following payload:

{
   "identifiers":[
      {
         "value":"_example.org",
         "type":"dns"
      },
      {
         "value":"example.net",
         "type":"dns"
      },
      {
         "value":"asdf",
         "type":"dns"
      }
   ]
}

And this is the raw response I’m getting at the moment.

HTTP/1.1 400 Bad Request
Server: nginx
Content-Type: application/problem+json
Content-Length: 231
Boulder-Requester: 8473560
Link: <https://acme-staging-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: <removed>
Expires: Thu, 20 Jun 2019 18:44:56 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Thu, 20 Jun 2019 18:44:56 GMT
Connection: close

{
  "type": "urn:ietf:params:acme:error:rejectedIdentifier",
  "detail": "Error creating new order :: Policy forbids issuing for \"example.net\" and 1 more identifiers. Refer to sub-problems for more information",
  "status": 400
}

So it looks like it thinks its sending subproblems, but didn’t actually attach them?

1 Like
4

You're totally correct :man_facepalming: I filed a Boulder issue with more details, but there is definitely a bug and I apologize! I'll aim to get that fixed for the next release.

Thank you for spotting that!

3 Likes
5

No worries. Glad to help!

1 Like
6

This is fixed in Boulder as of 5a1c18d. It'll go to staging and prod on the usual release schedule. If all goes according to plan that would mean it will be fixed in staging with the June 25th update and in prod on June 27th.

Thanks again!

7

I'm +1 for writing an API announcement. Great idea. I can volunteer to do that. Given we have a bug in the live implementation I'm going to delay posting it until after the 25th :sweat_smile:

4 Likes
8

Confirmed staging is now properly sending subproblems in error responses. It appears to include them even if there’s only one identifier and one problem.

For instance, sending an order with the following payload:

{
   "identifiers":[
      {
         "value":"_example.org",
         "type":"dns"
      }
   ]
}

Results in the following error body:

{
  "type": "urn:ietf:params:acme:error:rejectedIdentifier",
  "detail": "Error creating new order :: Invalid character in DNS name",
  "status": 400,
  "subproblems": [
    {
      "type": "malformed",
      "detail": "Error creating new order :: Invalid character in DNS name",
      "status": 400,
      "Identifier": {
        "type": "dns",
        "value": "_example.org"
      }
    }
  ]
}

Not a problem, just an observation.

3 Likes
9

Perhaps a sub-problem of sub-problems? :sweat_smile:

I'll take a look. That doesn't match what I intended to happen in this case.

10

Thanks for the report @rmbolger, this is fixed in 2d1a0d8 and will hit staging on July 2nd. We're not doing a production release this week so the buggy subproblems currently in staging won't be promoted to prod today.

2 Likes
11

I giggled at the branch name in your PR. Who knew subproblems were so annoying to implement?

2 Likes
12

Because of the July 4th holiday next week we ended up doing an out of cycle staging deploy today. The fix from 2d1a0d8 is now live in staging.

2 Likes
13

Confirmed no more subproblems on single error responses. Same payload as before now returns:

{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Error creating new order :: Invalid character in DNS name",
  "status": 400
}

I hate to continue being a bother, but the other thing I notice is that when they payload contains multiple identifiers and only one of them has a problem, the error detail doesn’t indicate which one had the problem. So the error response above is identical if I change the payload to this:

{
   "identifiers":[
      {
         "value":"_example.org",
         "type":"dns"
      },
      {
         "value":"example.com",
         "type":"dns"
      }
   ]
}
6 Likes
14

Good catch, @rmbolger! Thanks for helping us debug this new feature. Filed an issue: https://github.com/letsencrypt/boulder/issues/4311

3 Likes
15

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