In ACME account register process, Account Key is generate by client.
Then I applied for a certificate and obtained it .
So there is a question:
If I have lost my Account Key ,
And I want to renew the Certificate , I must Re-generate a new account key.
Does it works ?
Whether the certificate serial number associated with Account Key or not?
Yes.
You'll need to get a new authorization, as the previous (cached) authorization will be coupled to your previous account, but yes, you can get multiple certificates issued for the same hostname by different accounts.
By the way, renewals are simply new certificates with the same SAN as a previous cert. A renewal will have a different serial number et cetera.
Yeah, It is.
Thanks.
Does kid parameter in protected header is associated with Account Key generated by client side ?
Here is my experience:
If I use a NEW account key with a OLD kid URL parameter,
I can not get proper response.
But if I use OLD kid 's Account Key , I can get response successfully.
I have no idea what a kid parameter is, sorry.
It should all be in RFC 8555 though.
From section 6.2:
The "jwk" and "kid" fields are mutually exclusive. Servers MUST reject requests that contain both.
For newAccount requests, and for revokeCert requests authenticated by a certificate key, there MUST be a "jwk" field. This field MUST contain the public key corresponding to the private key used to sign the JWS.
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.
Yeah, it is.
Scenario is:
I generate a account key called KEY-A , then sign the /acme/new-account request
and get the account URL in response header finally. This account URL we called URL-A.
Do same process above then get KEY-B, URL-B.
If I sign the request KEY-A and use URL-B in the protected-header , I can not get the proper response.
Question is:
Does binding relation between KEY-A and URL-A is stored by LetsEncrypt ?
One account key to one URL ?
I'm not entirely following you, but yes each account uses its own key and has its own URL (where the URL basically acts as the "account number" uniquely identifying the account). Are you trying to have Account A access Account B's information somehow? What are you actually trying to accomplish by doing so?
Yes.
It doesn't work means that it's security
An account has some amount of personal information in it (at least an email address), so it makes sense to me that you can't just access one without it being your own account.
But as stated before, you can have more than one account creating certificates for the same domain name.
Yeah, it is. Thanks.
Yes. The Account endpoint/URL is a protected resource that requires a valid signature for reads and writes.
Once an AccountKey is used in the system, it is blacklisted for all other users to create new accounts with. (Someone can not create a new account with that key). [See sections 11.1 and 7.3.1]
There are 3 endpoints that involve what you want to do:
In the OP's case, the key takeaway is that "losing account keys is unfortunately pretty common, and the common fix is to generate a new account key and just do everything with a new account"
The main thing an account key does for 99.999% of users, is simplify the revoke operations (which can also be done with a Certificate+PrivateKey). For .0001% of users, they have RateLimit exceptions tied to their AccountKey. But for the rest of us, AccountKeys can be ephemeral.
It's interesting to note that while it's true that you can't create a new account with a key that's already tied to another account, hitting the NewAccount endpoint with that key will effectively give you the details for that existing account if it exists. From a client perspective, it won't know whether the response is an actual new account unless it uses the onlyReturnExisting flag first and gets a negative response.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
