Best practice about user registrations for a large certificate portfolio?


#1

I’d like to know what is the recommended practice regarding user registrations for a service that manages several certificates for different domains (e.g. hosting provider or service/library) and customer.

I noticed that:

  • if you hit the new-reg with a <key,contact> pair that already exists, LE rejects the registration with a 409 (per the ACME policy)
  • if you hit the new-reg with a <key,contact> pair where the contact already exists (e.g. same email) but the key is different, a new user is registered (and that was surprising to me, I can essentially have infinite users with the same email but different keys)

What is then the recommended practice in this case? Should I:

  1. issue a new registration for each customer, and use it for the domains connected to the customer
  2. issue a new registration for each domain
  3. issue a new registration once, as a single account, and reuse the same account to request the certs for each domain and customer?

What’s the current policy adopted by the official client?


Same or different account public key for multiple certifcates?
#2

Anybody at Let’s Encrypt can provide some recommendation or guidance?


#3

Generally, we’ve been advising hosts to minimize the number of registrations, both for our database sizes and for simplicity in revocations.

I would recommend that the balancing point depends on who is responsible, in this system, for managing the certificates. If the certs are entirely handled by an automated system, the simplest approach for the system would be to use one registration for all customer domains. Then if you need to revoke one, it’s simple to do, and it minimizes data storage on both sides. However, if users are involved, you may want one registration per user account. That keeps isolation between users, and would permit the use of the email field for notifications, if you want.

I would not recommend a new registration per certificate. The rate limit on new registrations is intended to discourage that.


#4

Excellent! This is the path I was considering, but I wanted to check if my assumption was correct.

Thank you very much for your response.