auto-ssl / lua-resty-auto-ssl

On the fly (and free) SSL registration and renewal inside OpenResty/nginx with Let's Encrypt.
MIT License
1.94k stars 181 forks source link

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

Open perezbox opened 2 years ago

perezbox commented 2 years ago

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 commented 2 years ago

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:cert-admin@example.org",
       "mailto:admin@example.org"
     ],

     "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 commented 1 year ago

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.