I’m looking into adding Let’s Encrypt as a CA offering at our University (R1 research university). My service is part of University-wide IT and we provide free SSL certs for any University-owned domain name. Right now we get most of our web SSL certs through Comodo with an agreement through InCommon/Internet2. We’re looking at Let’s Encrypt to reduce our reliance on a single vendor.
We currently have about 4000+ active certs, mostly under the our university.edu namespace. I’m pretty sure we will need a rate limit exception but don’t expect to have a problem getting one.
What I’m trying to figure out is doing a domain vs account rate limit exception, and if I do the latter, how to funnel all requests through a single account in a distributed environment.
Our computing environment is heavily distributed–we provide a lot of central services but it’s more or less the wild west out in departments–they can set up whatever they want, however they want, if they aren’t causing problems. There are good and bad things about this approach.
With the domain rate limit approach, it’s easy to implement. I request a rate limit increase, and folks out in departments can just use ACME clients to request certs. Downsides:
-We currently have some institutional access control over who is allowed to request certs for domains. We’d lose this but I’m not sure it’s a dealbreaker
-I can envision a scenario where a person or groups of persons may accidentally or inconsiderately request enough certs to burn through even our expanded rate limit
If I chose to rate limit by account and funnel all Let’s Encrypt requests through a central portal, that’s a lot more work but I can see the following benefits:
-Maintain institutional access control on cert issuance
-Implement rate limiting at the institutional level so an accidentally bad or inconsiderate actor will just burn up their own rate limit (e.g. someone forgets to increment the counter in a loop, or isn’t using durable storage for their container keys and spins up 100 containers in one day)
-Account rate limit covers any other domains that institutional users want to use (including medical centers, etc.)
What I’m having trouble wrapping my head around is how I would implement this. I’ve been mulling over the idea of proxying ACME cert requests…tell me if this sounds crazy:
Run our own acme server–have clients on campus request certs from it. The server would implement our own access control and rate limiting, rewrite and resign the ACME request using our central account, and submit it to let’s encrypt. The proxy server would have to return the HTTP token to the client, and then let’s encrypt would do DNS/HTTP validation as normal against the original client.
The integration guide also mentions a central validation server, so I wonder if I could have our customers redirect to that server and do the domain control validation there, but still rewriting the request with our central account info as described above.
I’ll add we control DNS records for most of our domain names so that’s another option for validation–I’d like to maintain HTTP as an option since maybe 10% of customers are doing their own thing for DNS.
Am I making it way too complicated? I’m also interested in other solutions…I’m in the very early stages of evaluating this.