How to handle cert transfers from one account to another? How to administer existing accounts as 3rd party?

[garte]

There seem to be some open questions to us as a webhosting provider regarding implementation of Let's Encrypt as a service for our customers:

How is it possible to transfer a Let's Encrypt certificate from one account to another?

As a hosting provider we'd like to be able to install new LE certs or transfer existing LE certs installed on another hosting provider via some sort of administrative API, how would we be able to handle that, given the restriction that every account only has one keypair? Of course, our users would have to grant us the permissions to do so, but this kind of third party involvement does not seem to be fleshed out anywhere in the current ACME specs nor the boulder implementation, is that correct? How would we go about that?

How would we automatically import a LE cert from another hosting provider for a given user?

[garte]

Why did this issue get closed without further comment, @jsha?

[jsha]

Oops, sorry about that @garte! I did not mean to close it, but meant to come back later and write a longer comment. I must have hit the close button by accident. My apologies.

There are a few different possibilities for transferring certs. For instance, I'm sure you are aware that you can have your customers upload their existing cert and private key to be used by you. However, ideally you want to have an account key that is authorized for your customers' DNS names, so that you can automatically renew their certificates for them.

Right now the protocol doesn't support a notion of transferring authorizations for DNS names from one account to another. However, the protocol leaves it as a matter of policy whether CAs will allow a single identifier to be authorized for multiple account keys. In practice, the Boulder codebase (and therefore Let's Encrypt) allows multiple account keys to hold the same identifier, so this is probably the best solution.

When enrolling a customer, you'll go through the authorization process for their domain names. If that customer already has a certificate for those names, Let's Encrypt will require you to respond to a Proof of Possession challenge for that certificate's private key in addition to the normal SimpleHTTP or DVSNI challenges. You can implement that challenge either by having the customer provide their existing private key or, if they are using that key for multiple certificates and don't wish to share it, you will be able to send the customer a piece of data for them to sign with their private key and return to you to complete the challenge.

Does that approach work for you?

[garte]

Thanks for the insights, your answer has been very helpful.

However, the protocol leaves it as a matter of policy whether CAs will allow a single identifier to be authorized for multiple account keys.

How would that work in practice, though?

Does that mean a customer would have to assign our account via our public key to an authorized domain of his / her? This would only work for already authorized domains, though.

Would it be possible, then, to authorize a domain which is hosted by us via our own account key-pair and assigning the account of our customer afterwards?

If that's the case a customer of ours should be able to kick us off the identifier (=de-assign us, so to speak) if (s)he wants to transfer to another hosting provider - is that possible?

What - if anything - will be provided by Let's Encrypt, be it at launch or later?

[jsha]

If that's the case a customer of ours should be able to kick us off the identifier (=de-assign us, so to speak) if (s)he wants to transfer to another hosting provider - is that possible?

This is a good point. There is currently no way for an ACME client to request invalidation of existing authorizations on account keys they do not own.

Here's another approach: We are planning to allow key rotation for account keys, by posting an update to the /acme/reg/1234 url with the new public key in the key field. When onboarding a customer, you could generate a new account key specific to them, and send it to them as JWK with instructions on how to post an update to their registration object. Since you would hold the private key, you would now be "taking over" their whole account. When the customer wants to go to another hosting provider, they could send you a new public key (either theirs or the new provider's), and you could repeat the process.

[garte]

There's a catch with your approach, though: If a customer has some certs with us and some with another provider (s)he needs to re-assign the keys for every transaction with a different hosting provider - and they're basically giving all their control away over their own certificates.

But it would be nice if there was some kind of access control mechanism which lets an account owner assign "administrative" keys to their account. These administrative keys would enable third parties to execute challenges and revoke certs made by them. And only owners could remove those admin keys whereas admin keys could not remove owners.

Would that be a possibility in future releases?

Starting off we're probably going to administer all LE certs ourselves for our customers. They then can revoke certificates made by us and move on to other hosters if they wish to do so.

[cristiangraz]

@jsha Do you recommend managing customer certificates using the vendor's "account", or creating a separate account for each customer? We are currently managing thousands of domains for customers and were planning on having everything under our "account" rather than creating separate accounts per customer since it's all transparent.

[jsha]

Both approaches work! We don't have a specific recommendation at the moment. We'd be curious for feedback about what works best for you.

One thing to keep in mind: If you are creating many accounts from a single IP you will run into the registrationsPerIP rate limit pretty fast. We can lift this, but it takes a week or so lead time to deploy to prod at the moment (we want to speed that up). We'd also like to streamline the rate limit request process, but for now email Josh (I believe his email is on the LE website).

[cristiangraz]

Thanks, @jsha! I'll look up Josh's email and reach out soon. Will be moving a few thousand domains spaced out over the next week to try things out with some more volume.

[rolandshoemaker]

Closing due to inactivity, most integrator questions are now addressed in our Integration Guide.