Challenge Account Key

[Jett987]

Hello,

I'm needing help retrieving the account key associated with challenge validation from the let's encrypt api. My communication is via api. I've tried several different combinations for generating the account key, to include making thumbprints as the documentation suggests. Regardless of how I try to create an account key, it seems as though the let's encrypt api is storing a different account key, as the response after informing it that I'm ready to complete the challenge includes the expected value, indicating my value is incorrect.

Is there a way to poll account details to view what it thinks my account key is?

The areas I have looked are: challenge details, account creation response details, account resource details.

Any help would be greatly appreciated!

[Osiris]

I'm not sure I fully understand what it is you're trying to do, but an account key is a public/private keypair used at account registering and Let's Encrypt only has the public key part of it. The user and only the user has the private key part.

If you don't have access to the private key of the account key, you cannot use that account.

[Jett987]

Hi Osiris,

Thanks for the reply! I have access to both. The issue I'm having is providing the correct "account key" to the lets encrypt api when performing the http-01 challenge. It seems as though I'm not correctly generating the appropriate "account key", but the let's encrypt api know's what the key should be, so I would assume it's storing it and I would like to retrieve it. You can read here: Challenge Types - Let's Encrypt that it's supposed to be a thumbprint of the account key, but when I create the thumbprint according to the acme documentation, it doesn't match.

[Osiris]

I still don't fully understand what you're trying to do. Are you writing your own ACME client?

@Jett987

The issue I'm having is providing the correct "account key" to the lets encrypt api when performing the http-01 challenge.

In what way? The account key is only used for signing the communication with the ACME server and for calculating the thumbprint of said key. The key itself is not used directly.

@Jett987

It seems as though I'm not correctly generating the appropriate "account key", but the let's encrypt api know's what the key should be, so I would assume it's storing it and I would like to retrieve it.

The account key is only generated once: just before and to be used for account registration. Afterwards the account key is only used: for signing the communication as I mentioned before and for calculating the thumbprint.

The API only knows the public key, but you also already know that, so what's there to "retrieve"?

@Jett987

You can read here: Challenge Types - Let's Encrypt that it's supposed to be a thumbprint of the account key, but when I create the thumbprint according to the acme documentation, it doesn't match.

Then you're probably not calculating it correctly. Which documentation did you use? And how did you do it?

I'm considering, depending on your answers, to move this threat to Client dev by the way.. Which is more appropriate I think.

[Jett987]

Yes, I'm creating my own ACME client.

The documentation I'm using is a combination of this: draft-ietf-acme-acme-18, specifically section 8.1 and the documents it references for this, and the documentation provided on the let's encrypt website.

I'm able to create a new account, place a new order, and get the challenge details to include the token and challenge endpoint. The next step is to appropriately place a file at the designated file path that includes the token.accountkeythumbprint.

When doing that, the response indicates that the expected accountkeythumbprint doesn't match what I provided. To me, this indicates the api know's what the accountkeythumbprint should be and likely stores it with my account details, and as such I could hopefully find out what it should be. When looking at my account details, I notice that it's not included there. It only includes the information I provided when creating my account. It's not a value that I've provided to it.

I apologize if I didn't post in the appropriate place. I'm new to the community.

[Osiris]

@Jett987

The documentation I'm using is a combination of this: draft-ietf-acme-acme-18, specifically section 8.1 and the documents it references for this, and the documentation provided on the let's encrypt website.

You may want to use the final version of the ACME protocol: RFC 8555. It was published as an RFC 5 years ago Although it doesn't matter for the account thumbprint, as, besides a typo, sections 8.1 are identical.

@Jett987

To me, this indicates the api know's what the accountkeythumbprint should be (…)

Correct, as it can be calculated from the (public) key of the account key.

@Jett987

and likely stores it with my account details

Incorrect. It's calculated.

How are you calculating your thumbprint?

[aarongable]

@Jett987

The documentation I'm using is a combination of this: draft-ietf-acme-acme-18, specifically section 8.1 and the documents it references for this, and the documentation provided on the let's encrypt website.

That version is just a draft. The correct document to use is RFC 8555 - Automatic Certificate Management Environment (ACME).

@Jett987

When doing that, the response indicates that the expected accountkeythumbprint doesn't match what I provided. To me, this indicates the api know's what the accountkeythumbprint should be and likely stores it with my account details, and as such I could hopefully find out what it should be.

First, a clarification: the value that your client has to present during HTTP-01 validation is called a "Key Authorization". This value is constructed from two values: the token provided in the challenge object, and the thumbprint of the acme account key.

It sounds to me like you understand this part reasonably well, and the issue is that you are computing the thumbprint of the account key incorrectly.

RFC 8555 specifies the Key Authorization as follows:

keyAuthorization = token || '.' || base64url(Thumbprint(accountKey))

The "Thumbprint" step indicates the computation specified in [RFC7638], using the SHA-256 digest [FIPS180-4]. As noted in [RFC7518] any prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation.

As specified in the individual challenges below, the token for a challenge is a string comprised entirely of characters in the URL-safe base64 alphabet. The "||" operator indicates concatenation of strings.

So you need to make sure that you can compute a correct JWK thumbprint, and then that you can compute a correct base64url encoding of that thumbprint.

[Jett987]

Thanks for providing the final version, I'm sure it'll help me going forward!

By using a cryptography library that's available to me. Essentially it's taking my public key, converting it to a string, calculating the SHA-256 hash, and base64url encoding it.

If it's simply a calculation that can be recreated, I'll just continue working on creating the correct thumbprint. I mostly wanted to see if it was something I could get from the let's encrypt API, since it was already making the calculation itself.

[jvanasco]

The following is how I compute the thumbprint. This function first tries to compute it with pure-python, then falls back to commandline openssl.

aptise/cert_utils/blob/b60182dd9813dc2118027da3658d6b88ff10f9b9/src/cert_utils/core.py#L3660-L3728

To present the challenge, I do the following:

aptise/peter_sslers/blob/416b07fcb52fbce4e57b45d41aedf043c8445b9b/src/peter_sslers/lib/acme_v2.py#L191-L202

[Osiris]

@Jett987

By using a cryptography library that's available to me. Essentially it's taking my public key, converting it to a string, calculating the SHA-256 hash, and base64url encoding it.

Well, that's not the same as the Thumbprint as mentioned in the ACME protocol. Please see the referenced RFC 7638 from the ACME protocol as also linked in @aarongable s post above.

Edit: unless the "converting it to a string" is exactly as mentioned in RFC 7638..

@Jett987

I mostly wanted to see if it was something I could get from the let's encrypt API

Nope.

[Jett987]

Hi Aaron,

Thanks for the reply. I understand what the key authorization is, I was specifically inquiring about the base64ur(thumbprint(accountKey)) portion of the key authorization. If the account key was considered something other than what I thought it was, in this case the public key, then I wanted to know that so I could correct how I was creating my thumbprint.

I'm going to further review my thumbprint creation to see if that's where my fault is, and since I can't get that value from the api.

[Jett987]

I'll keep tinkering with it. It sounds like I'm just overlooking something

Thanks for the help!

[Osiris]

Let us know if you require help with that In that case, preferably with code

[Jett987]

You all were correct. I was calculating the thumbprint wrong. I ended up needing to re-structure my public jwk before the SHA-256 digest and base64 encoding. Thanks for the help!

[Osiris]

Yup, the order matters

[webprofusion]

Out of interest what language is your acme client being developed in? There are a number of ACME client libraries available and they've been tested against a range of ACME CAs, at the very least looking at their source code will provide guidance if you don't want to use them directly.