Feature request: Per-user certificate issuance quota with time window

[jaredbarez]

Hi,
I'd like to propose a feature for enforcing a per-user certificate issuance quota in TameMyCerts, if possible.
The idea is relatively simple:

Define a quota (e.g. MaxIssuedCerts = 5) per user. User is standard AD user account who requests the issuance from CA (ADCS).

Tie it to a rolling or fixed time window (e.g. per day, or configurable duration).

Only successful issuances count toward the quota (rejected requests don't).

Once the quota is reached, any further requests from that user are denied until the time window resets.

This would be useful to prevent abuse or accidental bulk issuance, especially in internal environments which rely solely on TameMyCerts policy template for making decision on issuing of certificates, i.e. no human intervention (CA Manager or some enrollment agent).

Thanks

[PaulBlenderman]

I love your idea. (As a VMS veteran, I love the idea of quotas in general.). It's similar to Let's Encrypt's Rate Limits. I've seen problems with certificates being re-requested and re-issued again and again (e.g. through autoenrollment, where we typically do not need or use TMC so far). I'm afraid it is not trivial to implement, though. Let's see what Uwe thinks.

[Sleepw4lker]

Hi, and thanks for the suggestion.
Though I fear it wont be "easily" possible as we cannot query the CA database from the policy module. Therefore now way to gain knowledge which other certificates the user has.

[jaredbarez]

Hi and thanks for your quick reply.

I think you are absolutely right, without access to the CA database the policy module can't retroactively check what certificates have already been issued. But I believe that may not be strictly necessary in this case. What I had in mind is a more stateless, in-memory approach, handled entirely within the TameMyCerts policy module during runtime, as follows:

When a certificate is successfully issued, TameMyCerts stores a simple in-memory counter tied to the user identity (e.g. domain\username or user SID), along with a timestamp. The counter increments with each successful issuance within a defined time window (e.g. 24 hours). If the counter hits the configured quota, further requests from that user are rejected until the window expires.
Old entries naturally expire as the window slides forward.
So, there is no need to persist state beyond process lifetime. It's more of a best-effort rate limiting mechanism rather than strict historical auditing, and in most environments, that could be sufficient to prevent abuse or bulk requests.

I beleive TMC already has access to the request's user identity during evaluation, so I believe this could work without touching the CA database at all.

Of course, restarting ADCS (and TMC) the counter would reset but I believe that in practice it si acceptable for many use cases.

Thanks

[PaulBlenderman]

Wow. That is almost the same solution I was thinking of. My idea was a list with rows:

identity:template:timestamp

on each invocation:

• delete all rows with timestamp more than timewindow old
• count all rows with matching identity and template
• if count >= maxrequests reject
• (else) add row

If I interpret your text correctly, you propose:

identity:template:timestamp:count

on each invocation:

• delete all rows with timestamp more than timewindow old
• select row with matching identity and template
• if present and count >= maxrequests reject
• (else) increment count and update timestamp

Your solution is simpler and more efficient, mine is nearer to Let's Encrypt's "token bucket" algorithm. Both do not achieve that one request can be made every timewindow / maxrequests minutes. Worst-case one will have to wait an entire timewindow .

The parameters timewindow and maxrequests should be checked against sanity limits.

What would be the identity? I'm afraid it needs to be yet another parameter. We may often want to take the requester, but that way we cannot handle requests submitted on behalf of others. Unless we also want to protect the CA against an overly active RA, "tame my RA"... In other cases it could be the certificate subject, but the subject field can remain empty, in wich case we take a SAN.

This unfortunately looks like more than a few lines of code...

[jaredbarez]

Yes, the logic is based on a single in-memory record per identity:template combination, which tracks a single count and timestamp. On each invocation (i.e. request), if the timestamp is within the configured time window and the count exceeds the quota, the request is rejected. Otherwise, the count is incremented or reset depending on the time delta.

This does allow for "burst" issuance (e.g. 5 certs in 5 minutes), after which the user must wait for the full window (e.g. 24 hours) before being allowed again, and that’s intentional. We have scenarios where users (or automation accounts) legitimately need to issue a small burst of certificates, e.g. during system deployments or rollouts and then remain idle for the rest of the day. For those users, the idea of distributing requests evenly over time (as in token bucket) is not practical. Forcing them to wait e.g. 4.8 hours between requests would just lead to frustration and manual workarounds.
So while token bucket provides better fairness across time, this simpler model offers predictable enforcement with minimal complexity, and that's preferable (in my context, of course).

As for the identity, I completely agree that this should be exposed as a parameter. In many cases, using the requester (RequesterName) could be sufficient, especially when requests are submitted directly by the end user. But as you pointed out, that won’t help in cases where certificates are requested on behalf of others (e.g. via a Registration Authority or service account).

So I’d suggest making this configurable with something like:
"RateLimitIdentityAttribute": "RequesterName" | "Subject" | "SAN:upn" | "SAN:dns" | ...

Operator "|" here means only one identity source should be selected per policy i.e. this is a mutually exclusive choice, not a combination, in order to avoid ambiguity and complexity. That way, the feature can support different models: whether the goal is to limit per user, per device, per service principal, or even per common name.

It’s true this adds a bit of complexity, but I think it’s worth it to make the feature generally useful and adaptable beyond basic self-service cases.

[Sleepw4lker]

Hi all.
I'm working on restructuring the project to support an Exit Module.

Once we got this we can implement the following features:

• Exit Module writes entire Database Row to XML or JSON or YAML file. Script could pickt it up and do whatever it wants, like send via Email, or import into a SQL database. This would also bring an option for sending Emails from a Server Core CA, and do it asynchroneously, not blocking the CA process when the SMTP server is down.
• Exit Module writes Public Key Hashes to file. Policy Module can "touch" the file, and if it exists, deny the CSR (prevent re-usage of keys)
• Exit Module writes maybe a hash of the identities collection, Policy Module can "touch" the file, and if exists, check it's timestamp, and deny the CSR - I think this would properly suit your use case.
• And while we're on it, I would also implement "touching" Yubikey Serial Numbers, then we can make the PM issue only when the Yubikey is known to the organization.

Note: I plan to use "touching" files like ADCS would do when TPM Key Attestation is configured in EKPUB mode - as this is super-lightweight dependency- and performance-wise.

Comments on this?
Cheers

[jaredbarez]

Hi Uwe,

The idea of using file "touch" method for keeping track of quota sounds very promising to me. Other features are definitely very good to have, thanks. I just have a few clarifying questions (regarding quota):

1. Identity configuration and quotas
   Do you plan to configure identity types and their quota values per-template in the existing TMC XML policy file?
   Each XML policy file could define multiple identity sources (e.g. Subject, SAN:upn, RequesterName), each with its own MaxRequests and TimeWindowHours setting for quota.
   While this may allow some user to request more certificates by switching among different identities, I don’t consider that a significant concern. It's still a huge win compared to a misbehaving script being issued thousands of certs unchecked or some user using ADCS too relaxed :-)

2. Touchfile filename format
   Just to confirm, the filename would be a hash of the (IdentityValue + TemplateName) combination, right?

3. Quota tracking logic
   If the quota logic relies solely on the file’s NTFS timestamp (e.g. LastWriteTime) as you mentioned, that effectively limits it to a single issuance per identity:template per time window. That’s excellent for replay-prevention or strict one-time issuance. However, in my case, a burst issuance model is more appropriate e.g. allow up to 5 certs in 24h, then block further issuance. To support that, we’d need the touch file to store a small state (e.g. JSON/YAML) including:

• last issuance timestamp,
• current count of issued certificates.
  The Policy Module could then parse that state on each request and decide based on time delta and count. This allows for more flexible quota enforcement.

Thanks for your effort on this.