Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Working with a Third-Party ACME Provider and Request is Incorrect #270

Open
perezbox opened this issue Dec 10, 2021 · 2 comments
Open

Working with a Third-Party ACME Provider and Request is Incorrect #270

perezbox opened this issue Dec 10, 2021 · 2 comments

Comments

@perezbox
Copy link

Hi

Not sure if someone would have some insight into what is going on. I've been trying to get this module to work with another CA, working with SmallStep/certificates cc @dopey

In the process, noticed something odd happening. I can see the requests coming in, but I'm getting this error:

WARN[1484] duration=1.837911ms duration-ns=1837911 error="kid does not have required prefix; expected https://ra.perezbox.com/acme/acme/account/, but got https://ra.perezbox.com/acme/acme/new-account/1zxm0vy2eOqxMk9YSN1aZDBiRFu5Cvu2" fields.time="2021-12-10T20:07:57Z" method=POST name=ca nonce=R3pQVXpMYjZyb0NxaTlubmp1WVRmUVpDbzdJZTB3TW0 path=/acme/acme/new-order protocol=HTTP/2.0 referer= remote-address=173.255.202.146 request-id=c6pr77a23aknuvhpop9g size=93 status=400 user-agent="dehydrated/0.6.5 curl/7.61.1" user-id=

The SmallStep is expecting /acme/account/ but the request is going to /acme/new-account/

I see it's use the Dehydrated ACME client, so I'm trying to figure out if it's an issue with this module or with how dehydrated is configured.

Btw, I did look at the Dehydrated config examples: https://raw.githubusercontent.com/dehydrated-io/dehydrated/v0.4.0/docs/examples/config but didn't see what I would expect to see to modify the KID request.

Thanks in advance to anyone that might be able to help.

Tony

@dopey
Copy link

dopey commented Dec 10, 2021

A bit more detail:

 The server creates an account and stores the public key used to
   verify the JWS (i.e., the "jwk" element of the JWS header) to
   authenticate future requests from the account.  The server returns
   this account object in a 201 (Created) response, with the account URL
   in a Location header field.  The account URL is used as the "kid"
   value in the JWS authenticating subsequent requests by this account
   (see Section 6.2).  The account URL is also used for requests for
   management actions on this account, as described below.

   HTTP/1.1 201 Created
   Content-Type: application/json
   Replay-Nonce: D8s4D2mLs8Vn-goWuPQeKA
   Link: <https://example.com/acme/directory>;rel="index"
   Location: https://example.com/acme/acct/evOfKhNU60wg

   {
     "status": "valid",

     "contact": [
       "mailto:[email protected]",
       "mailto:[email protected]"
     ],

     "orders": "https://example.com/acme/acct/evOfKhNU60wg/orders"
   }

That excerpt is from the ACME RFC section 7.3 (https://datatracker.ietf.org/doc/html/rfc8555#section-7.3). The location header returned by the new-account request should be used as the kid in future requests. But instead, we're seeing a different URL in the kid field in the JWS.

From section 6.2:

For all other requests, the request is signed using an existing
   account, and there MUST be a "kid" field.  This field MUST contain
   the account URL received by POSTing to the newAccount resource.

@byrnedo
Copy link

byrnedo commented Apr 16, 2023

Also seeing this with pebble (the kid issue):

Key ID (kid) in JWS header missing expected URL prefix

Edit: in my case using the latest dehydrated script fixed things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants