Boulder: New account creation returns 200 and an empty response

[daramousk]

Here is my request:
URL: https://acme-staging-v02.api.letsencrypt.org/acme/new-acct
data: the mapping below is sent as a string
{\n "protected": "huge_string_here", \n "payload": "another_huge_string_here", \n "signature": "last_huge_string"\n}
headers: {'headers': {'Content-Type': 'application/jose+json'}}

What I get back:

HTTP_STATUS_CODE: 200 OK
HTTP_CONTENT: '' (an empty string)

Now, this behaviour crashes the client because it expects json in the response, specifically it crashes right here:
https://github.com/certbot/certbot/blob/0.26.x/acme/acme/client.py#L70 (response.json())

Now, going through https://tools.ietf.org/html/draft-ietf-acme-acme-12#page-31 I am able to see that upon successful registration, the CA returns a 201 status code with some data as well (no keyword is specified there that imposes a requirement level as per RFC 2119)

Also, I do not see something here

https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md#boulder-divergences-from-acme

Any ideas? Am I missing something?

[cpu]

Hi @daramousk,

Are you using Certbot as a command line application, or are you using Certbot's acme module programmatically? I'm surprised to hear that whatever you are doing is crashing the client since account registration is used extensively without error by many Certbot users and our integration tests.

data: the mapping below is sent as a string {\n "protected": "huge_string_here", \n "payload": "another_huge_string_here", \n "signature": "last_huge_string"\n}

Can you share the JWS payload you are sending?

What I get back:
HTTP_STATUS_CODE: 200 OK
HTTP_CONTENT: '' (an empty string)

Can you share the full HTTP response you receive with all response headers? Based on what you've shared I suspect you're POSTing newAccount with a JWS authenticated by an already registered account. In this case the protocol specifies that a 200 OK is returned with a Location header pointing to the existing account:

If the server already has an account registered with the provided
account key, then it MUST return a response with a 200 (OK) status
code and provide the URL of that account in the Location header
field.

That's the only case in the ACME v2 new account implementation that returns a 200 (http.StatusOk):
https://github.com/letsencrypt/boulder/blob/a6f93ffca4d6c93bbc10c4c3bfb6d9ebfe5f7e87/wfe2/wfe.go#L468-L473

When there isn't an existing account we do correctly return HTTP status 201 (http.StatusCreated) as specified:
https://github.com/letsencrypt/boulder/blob/a6f93ffca4d6c93bbc10c4c3bfb6d9ebfe5f7e87/wfe2/wfe.go#L539

[daramousk]

I suspect you're POSTing newAccount with a JWS authenticated by an already registered account.

That was correct, I do get that the Location header that indeed points to the account, thanks for pointing that out.

So, I assume that I should file a bug with the client app I am using at this case.

Thanks for your time.

[cpu]

Happy to help!

So, I assume that I should file a bug with the client app I am using at this case.

Probably! If the account already exists for the keypair in use then the client shouldn't be POSTing newAccount to create an account for that keypair, or it should respect the HTTP Status 200 response and treat it as a no-operation because the account exists.