How do you debug protocol issues?

Help
1

I’m writing my own client(library) but I have protocol issues.
Answers from the v2 staging server like this :
{
“type”: “urn:ietf:params:acme:error:malformed”,
“detail”: “Method not allowed”,
“status”: 405
}

Which tools can I use to pinpoint what’s wrong with the queries that I’m sending ?

Danny

My web server is (include version): N/A (nginx)
The operating system my web server runs on is (include version): raspbian
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

https://svn.code.sf.net/p/espalarm/svncode/main/Acme.cpp

2

Hi @dannybackx

there is no tool to debug such things.

The RFC 8555

is your tool.

Method not allowed -> perhaps you use GET instead of POST:

2 Likes
3

I wouldn't think so. When querying https://acme-staging-v02.api.letsencrypt.org/acme/new-order I need to pass a JSON in the right format (I also have RFCs 7515 and following on my screen).

How can I assess whether I have all the query contents (JWK, JWS, ..) right ?

Danny

1 Like
4

If you are using an existing JOSE library, it should already have tests to ensure that it is correctly signing things and generating keys. If you are rolling your own (not recommended), the JOSE specs have test vectors that you can compare against.

At the ACME level I’d recommend setting up Pebble (github.com/letsencrypt/pebble) and testing against that. That way if you run into an error you don’t understand, you can look at the Pebble code. You can even add printf lines to help explain which code paths are being followed.

1 Like
5

Thanks, that looks like a good pointer.

I’m extending a home grown esp32 base (IOT) development so it can be reached from my smartphone. I’ve not found any JOSE or ACME libraries that’ll work in this environment.
Also I think I already have a considerable percentage of the code written, see the URL in my original post, and some more in another post two days ago. (Need help figuring out how to query)

Danny

1 Like
6

By the way, check out this thread: Using Let's Encrypt for a local web server

I’ve started strongly recommending that any IoT deployment of ACME send traffic through a proxy controlled by the developer. We’ve seen a lot of problems where IoT ACME clients have bugs that result in excessive traffic in aggregate, but that are hard for the developer to debug because they can’t see what the deployed clients are doing. Pushing traffic through the proxy means that you can see when your clients start sending too much traffic, can shut it off if necessary, and can debug and redeploy.

3 Likes
7

That's the job creating an own client. You can use a tested library. And if I know it correct, one of the required RFC had samples you can use to check that part.

It's possible, I've created my own, raw client without using an existing library.

The error messages of Letsencrypt are enough.

8

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