Error on newAccount JWS verification error

Client dev
1

I'm calling to post a request on the new-account URL after getting the new-account URL from the response to the directory request "https://acme-staging-v02.api.letsencrypt.org/directory" and the new-nonce request header for JWS.

My post request body:

{
    "protected": "ew0KICAiYWxnIjogIlJTMjU2IiwNCiAgImp3ayI6IHsNCiAgICAiZSI6ICJBUUFCIiwNCiAgICAia3R5IjogIlJTQSIsDQogICAgIm4iOiAiblR5OTRkWWdGWG9ST1pkTEdYR3NJR00zNXVTVDBsVEFMbGRqaHZfTnFHTFNOWWtKeTZPZmNtQkFGQTIybEZJX0pRemhBRFhVRWpKcmNEaGs3UW02T29XSTBIRXRHenJtTzVaUXJNZ0g0ZzJ5QjdCcWFyNkRoS2hzRmZobWRHNW1TTEZpMXk5U2I4U0RQNnBBRXBmZ0cyVjRkWFVPYVUtZWVqTXBWek1jbHpsWDN1YkJDZDNidTZ4T2FERzhnRUJBUFprZkt6dE9YbGtqc3BOTi1JTVBCSzdUR0VaTVpwUWwzVXMyaF9Kb25MSmVsWUVmWVNOYXE4TXBBaTk5YVpjV0I3NGZmSUcwMXZoUnowYkRYUVhRR1N3YngxNVBIN1BlQ18ycUpMaUttMkxmakcxeHZBR1hsczc1eWt0bnFnb1R4Q3A2UHFsaXJlSncyajgtaUNiek9RIg0KICB9LA0KICAibm9uY2UiOiAiMDAwMlVhZ3JpZC02UUpJRzgwWHVwcUZUOE9XSXBqTlFxUlptWnp3UmY1UGVONzAiLA0KICAidXJsIjogImh0dHBzOi8vYWNtZS1zdGFnaW5nLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvbmV3LWFjY3QiDQp9",
    "payload": "eyJ0ZXJtc09mU2VydmljZUFncmVlZCI6dHJ1ZSwiY29udGFjdCI6WyJtYWlsdG86bWVAZ21haWwuY29tIl19",
    "signature": "U-y-jdTuub4_7u_SGjG1ZMKeDmOInRHkf9TW5RLvvyTfdTExoMzMl-agYR3MkfEWFKr-cdo5vE-oFG7ROTS16i1Lscx5ekVadfVCd3khvxuZ5I-K9U2pfM3Oe4gyMwoZXfvhxI6gh6pZlCvkjzSeVtzP5SHNMPBLzhL3EmpDC9gwP89TfBXJrOPBkEIYfFPBeBkNt_2nOMEESI3rw786WCMMQyGJU9TS6IAFpBDr0ibGbSAVBByFzdn3BzVZkFODuDYyJn0vu0ZMAYBYAFt1RyL1OqwH2cEanY0sJ5rwGXz1YxHpO7oBqVa3sBG1e2HEUQlNyHFiZwTiPXvnYTZcsw"
}

and getting response as shown below;

{
    "type": "urn:ietf:params:acme:error:malformed",
    "detail": "JWS verification error",
    "status": 400
}

I'll be thankful, to those who will help me to resolve my issue.

The technology that is being used is the Dotnet c# console app.

Thank you Let's Encrypt for such a great community!

1 Like
2

I don't know what's wrong with your request. It seems likely something is wrong with the way your signature was constructed. In your code, can you validate your own signature before sending the request?

I do have a suggestion. If you are developing a new client, I would suggest running a copy of Pebble:

Then you can examine both "ends" of the connection, including adding debuggers or extra print statements to pebble as needed. It seems like for this particular case of an invalid signature, it may also have more verbose errors.

6 Likes
3

Thank you for replying to me on my topic.

I'm sharing the console app GitHub repo of this topic, to continue to resolve my issue by checking all the code for signature generation and other stuff where I'm doing wrong things.

ServerManagerConsoleApp repo link: GitHub - AshfaqAliZardariOfficial/ServerManagerConsoleApp

Once again thank you Let's Encrypt and @mcpherrinm for the best community!

4

You call SignData without specifying the padding. It's not clear to me from the .NET documentation whether this defaults to PKCS#1 padding or not. You may need to specify it?

Maybe check out how Posh-ACME generates signatures using RSA keys.

6 Likes
5

Thank you @_az for reply me on my topic!

I have specified PKCS1 padding on my SignData.
checkout the code here: Specified PKCS#1 padding on SignData as _az · AshfaqAliZardariOfficial/ServerManagerConsoleApp@6a93644 · GitHub

But I'm getting the same error as the previous. see below that error message!

{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "JWS verification error",
  "status": 400
}

I'll be thankful, for who will solve my issue.

Thank you Let's Encrypt and @_az for such an awesome community!

1 Like
6

You appear to already be using the certes library, so you don't need to do this yourself, but if you do want to you may find clues in the certes code, in particular you need to pad the base64 encoding: certes/JwsConvert.cs at 08bf850bbed9e026c718f56f1bcc454afafb4f92 · fszlin/certes · GitHub

4 Likes
7

Thank you @webprofusion for replying to me on my topic!

I'm not using The Certes library, it will be removed in the next comment on the repo.
Don't worry about this!

1 Like
8

I have implemented certes/JwsConvert.cs at 08bf850bbed9e026c718f56f1bcc454afafb4f92 · fszlin/certes · GitHub on my ConsoleApp, look here: Pad the base64 encoding as webprofusion reply on LetsEncrypt Community. · AshfaqAliZardariOfficial/ServerManagerConsoleApp@2114e11 · GitHub

But still, the same error shows up.

new-account Request body:

{
    "protected": "ew0KICAiYWxnIjogIlJTMjU2IiwNCiAgImp3ayI6IHsNCiAgICAiZSI6ICJBUUFCIiwNCiAgICAia3R5IjogIlJTQSIsDQogICAgIm4iOiAiblR5OTRkWWdGWG9ST1pkTEdYR3NJR00zNXVTVDBsVEFMbGRqaHZfTnFHTFNOWWtKeTZPZmNtQkFGQTIybEZJX0pRemhBRFhVRWpKcmNEaGs3UW02T29XSTBIRXRHenJtTzVaUXJNZ0g0ZzJ5QjdCcWFyNkRoS2hzRmZobWRHNW1TTEZpMXk5U2I4U0RQNnBBRXBmZ0cyVjRkWFVPYVUtZWVqTXBWek1jbHpsWDN1YkJDZDNidTZ4T2FERzhnRUJBUFprZkt6dE9YbGtqc3BOTi1JTVBCSzdUR0VaTVpwUWwzVXMyaF9Kb25MSmVsWUVmWVNOYXE4TXBBaTk5YVpjV0I3NGZmSUcwMXZoUnowYkRYUVhRR1N3YngxNVBIN1BlQ18ycUpMaUttMkxmakcxeHZBR1hsczc1eWt0bnFnb1R4Q3A2UHFsaXJlSncyajgtaUNiek9RIg0KICB9LA0KICAibm9uY2UiOiAiMDAwMWV3ai1fV1BGcU1vQ1BhS3dBZlc3Y2h0eTRqaTRuTWF3aTZPTUpVTTRCalkiLA0KICAidXJsIjogImh0dHBzOi8vYWNtZS1zdGFnaW5nLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvbmV3LWFjY3QiDQp9",
    "payload": "eyJ0ZXJtc09mU2VydmljZUFncmVlZCI6dHJ1ZSwiY29udGFjdCI6WyJtYWlsdG86bWVAZ21haWwuY29tIl19",
    "signature": "U-y-jdTuub4_7u_SGjG1ZMKeDmOInRHkf9TW5RLvvyTfdTExoMzMl-agYR3MkfEWFKr-cdo5vE-oFG7ROTS16i1Lscx5ekVadfVCd3khvxuZ5I-K9U2pfM3Oe4gyMwoZXfvhxI6gh6pZlCvkjzSeVtzP5SHNMPBLzhL3EmpDC9gwP89TfBXJrOPBkEIYfFPBeBkNt_2nOMEESI3rw786WCMMQyGJU9TS6IAFpBDr0ibGbSAVBByFzdn3BzVZkFODuDYyJn0vu0ZMAYBYAFt1RyL1OqwH2cEanY0sJ5rwGXz1YxHpO7oBqVa3sBG1e2HEUQlNyHFiZwTiPXvnYTZcsw"
}

and the response body received:

{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "JWS verification error",
  "status": 400
}

Once again thanks to Let's Encrypt, @webprofusion and to all who responded me on my topic!

Please tell me what's wrong.

1 Like
9

I am not sure that this is the problem. At the end of each line there is a "carriage return" character, like DOS file format. May be removing those helps?
Output filtered by the cat -te command:

{^M$
  "alg": "RS256",^M$
  "jwk": {^M$
    "e": "AQAB",^M$
    "kty": "RSA",^M$
    "n": "nTy94dYgFXoROZdLGXGsIGM35uST0lTALldjhv_NqGLSNYkJy6OfcmBAFA22lFI_JQzhADXUEjJrcDhk7Qm6OoWI0HEtGzrmO5ZQrMgH4g2yB7Bqar6DhKhsFfhmdG5mSLFi1y9Sb8SDP6pAEpfgG2V4dXUOaU-eejMpVzMclzlX3ubBCd3bu6xOaDG8gEBAPZkfKztOXlkjspNN-IMPBK7TGEZMZpQl3Us2h_JonLJelYEfYSNaq8MpAi99aZcWB74ffIG01vhRz0bDXQXQGSwbx15PH7PeC_2qJLiKm2LfjG1xvAGXls75yktnqgoTxCp6PqlireJw2j8-iCbzOQ"^M$
  },^M$
  "nonce": "0001ewj-_WPFqMoCPaKwAfW7chty4ji4nMawi6OMJUM4BjY",^M$
  "url": "https://acme-staging-v02.api.letsencrypt.org/acme/new-acct"^M$
}
3 Likes
10

If JWS is fully JSON compliant, which is suggested in RFC 7515, this shouldn't matter. From RFC 7159 - The JavaScript Object Notation (JSON) Data Interchange Format

Insignificant whitespace is allowed before or after any of the six structural characters.

 ws = *(
         %x20 /              ; Space
         %x09 /              ; Horizontal tab
         %x0A /              ; Line feed or New line
         %x0D )              ; Carriage return
5 Likes
11

Thank you @bruncsak for replying to me on this topic.

I also think this does not matter as @Osiris thinks.

1 Like
12

I did not say it didn't matter. The fact it shouldn't matter is something different than it doesn't matter. Other implementations of JWS might not be RFC compliant.

5 Likes
13

Thank you @Osiris for this declaration, which is suggested in RFC 7515 From RFC 7159 - The JavaScript Object Notation (JSON) Data Interchange Format

So what's actually wrong with my code?

I will be thankful to those who will help me on this topic.

Once again thanks to Let's Encrypt, @bruncsak, @Osiris and to all who responded to me on my topic!

2 Likes
14

Guys, you may have my permission to use my GitHub public repo AshfaqAliZardariOfficial/ ServerManagerConsoleApp for code correction and then make a pull request. I'll be thankful for who will solve my topic issue. Thank you

2 Likes
15

@Osiris please specify where I'm wrong, in Other implementations of JWS might RFC be compliant?
I'll correct them to achieve a new-account request.

Thank you!

1 Like
17

I don't know. I don't code C#.

I just meant that even though a carriage return is a valid JSON whitespace, implementations such as used by the Le'ts Encrypt validation server might behave not conforming to the RFC and decide a carriage return is invalid. My point was: even though a carriage return is valid, it might be useful to see if your code suddenly works without including carriage return characters.

5 Likes
18

Thank you @Osiris for reply me once again. Yes, my code doesn't include carriage return characters.

1 Like
19

But your JWS contents does, as mentioned earlier by @bruncsak .

3 Likes
20

But you should test to see if it does make any difference.

5 Likes
21

I strongly suggest you adopt a "Test Driven Development" approach to your project. Between reading the ACME RFC and using other clients (like Certbot), you should be able to develop some unit tests to ensure you create payloads in the correct format. You can then create some integrated tests that run against the Pebble server, as suggested above.

7 Likes