One account vs multi account in multi team organization


#1

Hi,
we are currently working in a multi team organization (four teams growing).
We would like to delegate responsibilites to each team as much as possible.

Currently every team runs under one single top level domain “xyz.com” and they have a delegated subdomain they can manage on their own “team1.xyz.com”, “team2.xyz.com” etc.

We would like to use lets encrypt for our infrastructe. But with the above setup we will hit the rate limits very quick. So we will use the rate limit form to ask for a rate limit increase.
The idea was to give every team an own account with an increased rate limit on the account.

But during filling out the form I came accross the thought “how is the rate limit counted if several accounts issue certificates for the same domain?”
Do someone know how this works?

And/or do you have a suggestion if this is a good approach and if not, what a better approach would be?

thanks in advance!


#2

Hi @chbiel

isn’t it enough to use wildcard-certificates?

*.team1.xyz.com + team1.xyz.com
*.team2.xyz.com + team2.xyz.com

Then team1 can use this certificate with mail.team1.xyz.com, webserver.team1.xyz.com, dev.team1.xyz.com usw.


#3

This is irrespective of account. The domain limits (five identical certificates per seven days and twenty certificates per domain per seven days) doesn’t factor in which accounts requested those certificates at all.


#4

IMHO, I would have an internal tool/person centralize and orchestrate everything, and handle everything through DNS challenges on an instance of acme-dns. It would allow you to finetune which certs get issued within your org.

This is because the domain rate limits are global (across accounts), so you will constantly run into issues. You also shouldn’t rely on a ratelimit exception being made – those are usually only granted in very select situations, not because of design/architectures.

i would also group everyone under something like internal.example.com and issue a wildcard for *.internal.example.com which anyone can checkout as a backup. (I would not use *.example.com, because that cert would work on your public site)

there are at least a half dozen threads on this forum that go into detail about building a centralized tool for an organization to handle this. usually they are in threads from research groups or universities.


#5

Ok thanks for that suggestion.


#6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.