Enterprise Certificate Management: Who Can Issue What, and How to Prove It

Like many other disciplines in software, certificates become a different problem at scale. As organizations grow, the problem is no longer “How do we keep certificates renewed?” but “How do we ensure the right person has access and we keep track of every certificate?”

In a startup, managing certificates better means using an ACME-compatible tool to keep certificates from expiring. But at scale, a certificate estate soon has multiple owners. The CA is now shared infrastructure and the risk is no longer just about certificate expiry, but also about permissions, authentication, and visibility.

The estate suddenly exists in multiple shapes. Certificates come from:

• A commercial CA
• An internal CA
• One certificate manager per cloud
• Kubernetes cert-manager
• Whatever somebody self-signed last quarter

And they land on load balancers, firewalls, appliances, and clusters no single console can see. Enterprises solve the problem of where every certificate actually is, who is allowed to issue what, what constrains them, and what an auditor can reconstruct.

That organizational layer is the part of certificate management that decides whether centralizing helps or just moves the bottleneck.

What changes about certificate management at enterprise scale?

The obvious change is volume. Bigger organizations have more things that need certificates. But if this was the main issue, you’d set up ACME once and call it a day. The complexity of enterprise certificate management emerges from the complexity of the organization and arrives in four main ways:

• The estate stops having one source. Certificates arrive from disparate sources, none of which can see the others.
• The CA becomes shared infrastructure. A compromised or misconfigured internal CA now affects other teams, and one team’s mistakes affect everyone else issuing certs from that CA.
• Issuance rights and infrastructure rights separate. Someone reissuing a certificate on a payments host at 2am shouldn’t be able to decide certificate validity periods or policies.
• Trust becomes a claim you have to evidence. An internal certificate asserts an identity. As soon as certificates grow beyond one team, it’s easy to lose track of what an identity means. Enterprises need a record of who issued a certificate, under what rules, and who approved it.

Volume is a bigger issue because public certificate lifetimes are shrinking to 47 days. The CA/Browser Forum's ballot SC-081v3 caps publicly trusted TLS certificates at 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. That schedule binds certificates from public CAs, which includes every single public-facing certificate. This means renewals are about to multiply. Some manual processes work at 200 day lifetimes, but break at 47 days.

This doesn’t affect internal CAs, which issue on whatever validity you set, but internal lifetimes are worth shortening anyway to reduce the potential blast radius of a compromised certificate.

This is what’s happening and why certificate management is becoming more important. But it doesn’t explain why this happens.

Why do certificates end up scattered across so many systems?

Organizations accumulate different layers that terminate TLS. Each has a way of getting a certificate, and each one arrived at a different time with a different tool.

A single organization typically ends up issuing from several sources at once:

Source	What it covers	Where it stops
Commercial CA	Public-facing TLS, EV and OV certificates	Anything internal
Microsoft ADCS	Domain-joined Windows hosts and users	Everything not domain-joined
Cloud provider certificate manager	Load balancers and CDN inside one cloud	The other clouds, and anything on-premises
Public ACME CA	Public hostnames with reachable validation	Internal names that cannot be validated publicly
Kubernetes cert-manager	Workloads inside a cluster	Everything outside the cluster
Self-signed	Whatever somebody needed working that afternoon	Any expectation that it is tracked

Each of those renews on its own schedule, reports expiry in its own console, and has its own access model. The estate's real inventory is the union of all of them, and without a dedicated tool, no single system holds that union.

This gets even more complex because certificates arrive on different surfaces:

• Load balancers
• Firewalls
• Session border controllers
• Storage appliances
• Vendor appliances
• Clusters

In many organizations, some of these certificates are placed by hand because a surface offers no other option. Those are the most dangerous because they often expire unnoticed. Any tool that would have warned you does not know they exist.

This produces a failure mode unique to complex organizations: Nobody is tracking certificates badly, but the problem is that several teams track their own slice well, so no one owns the union.

This shapes how enterprise certificate management actually works:

• Discovery is a must-have. You need a complete inventory of what’s actually deployed on your infrastructure to get a full picture of what’s up for renewal or at risk of expiry.
• Centralizing does not mean migrating to one CA. Moving every certificate to a single issuer sounds nice in theory, but is a multi-year program that usually fails. Instead, organizations usually adopt a layer above them: One place that holds the inventory, sets the policy, records who issued what, and drives renewal, with the existing issuers left in place underneath it as backends.

Who should be allowed to issue certificates?

Working on your organization’s certificates usually means two important things:

• The policy: Defining what a certificate may contain: which domains, which validity periods, which key algorithms, which extensions. This should belong to a small and deliberate group.
• Obtaining certificates that follow policy: This is operations, it belongs to the teams running the services, and it should not require a ticket or a conversation.

Once those are separate, the rest follows:

Who	Administers policy	Can issue	Can see
Certificate infrastructure owner	Yes, across the organization	Not needed, but possible	Everything
Service owner	No	Their own services	Their own services
Team engineer	No	Lower environments only	Their own services
Deployment pipeline	No	Only the services it deploys	Nothing interactively
Compliance reviewer	No	Nothing	Everything in scope

An infrastructure owner can have issuance rights, but usually doesn’t need them. The compliance reviewer is the mirror image: total read access, zero issuance, which only works if the tool has a genuine read-only role rather than a lightly restricted admin.

This often requires fine-grained access controls because there are various edge cases here:

• Most engineers should be able to issue a staging certificate, but not everyone should touch prod.
• The permission to issue certificates shouldn’t automatically mean the permission to revoke a given certificate.

Where should the issuance boundary go?

The issuance boundary is where you separate CAs. Small organizations can often manage everything with one Root CA and one below it, but large companies usually have a more complex hierarchy.

Environment is the most common separation answer and works as a default. Development, staging, and production get separate certificate authorities, separate policies, and separate issuance paths, so a certificate for one cannot be produced from another.

To slice it even thinner, you can separate by region and business unit. Some of this can be driven by compliance:

• A company with strict data residency obligations per region has a real boundary there.
• A holding company whose business units run independent infrastructure has one too.

Pick the line where you would want a blast radius to stop, and accept that you are duplicating the layout on each side of it.

Give each side of the boundary its own CA where you can. Separating CAs preserves other environments, so an issue with the staging CA can’t take down prod. If any CA has to be replaced, because it was compromised, had its keys rotated, or moved provider, the others carry on untouched.

Another detail is the enrollment path. Each protocol exposes an endpoint that clients point at:

• Directory URL for ACME (RFC 8555)
• Enrollment URL for EST (RFC 7030)
• A pkiclient.exe URL for SCEP (RFC 8894).

If development and production share one ACME directory, then both environments are issuing through the same door and the boundary exists only in configuration. Give each side of the boundary its own endpoints to enforce access policies without anybody maintaining it.

What belongs in a certificate policy?

A certificate policy is the set of rules a request is validated against before anything is signed. At minimum it carries four constraints:

• Allowed names. The domains and SANs a certificate may carry.
• Maximum validity. Shorter in lower environments, since a leaked development certificate should expire on its own quickly.
• Permitted key and signature algorithms. Narrow this aggressively. Every option you leave open is one you have to support during a future migration.
• Key usages and extended key usages. A TLS server certificate that also carries code signing usage is a certificate doing two jobs, and revoking it for one reason breaks the other.

Allowed names does the structural work, because it turns the boundary from a convention into a refusal. A policy permitting only *.dev.example.com will reject a request for payments.example.com regardless of who submits it or what they intended. The team making the request does not administer the policy constraining them.

Certificate templates preset some certificate fields (e.g. lifetimes) to ensure they comply with your security posture. Any field a requester can set is a field you trust the requester with, so be intentional about it.

A policy field usually has three meaningful states, not two:

• unconstrained
• explicitly forbidden
• constrained to a list

Being extremely strict slows down teams, but being too permissive compromises security. That’s why it’s worth checking which of the three a tool can express while you are still comparing certificate management tools because migrating certificate managers later is a pain.

How do you define certificate policies for CI pipelines and machine identities?

Give each pipeline its own identity, scoped per environment, and treat it as a member of the services it deploys rather than as an exception to the model.

The usual shortcut of creating a shared service account with broad issuance rights used for every pipeline is dangerous. That account becomes the answer to "who issued this certificate" for everything, which makes the audit trail useless.

A pipeline identity is also the case where the model has to bend, because a pipeline cannot wait for a human to approve anything. Scoping the identity narrowly first is what makes that exception safe to grant.

What should an auditor be able to answer?

An auditor, whether external or internal, needs to see every certificate, every policy, and every issuance event, and needs to be unable to issue anything.

The questions they should be able to answer without asking anyone:

• Which certificates exist, where they are installed, and when they expire.
• Which policy each was issued under, and what that policy permitted at the time.
• Who or what requested each one, and who approved it if approval was required.
• What has been revoked, and when.

Which certificates exist is first for a reason: every other answer is scoped by it, and a scattered estate is precisely the case where that scope is incomplete. An audit that covers only the certificates you issued deliberately is an audit of the well-behaved half. Discovery scanning is what closes the gap between the two.

When is an approval step worth the friction?

Approvals are narrower than they look. They are worth it for production and customer-facing certificates, for separation of duties where a framework requires it, and for anything a human manually initiates.

As a blanket setting, they hold up development too much. A review step applied to every request gets approved reflexively within a month, and a rubber-stamped approval is worse than none: it produces an audit record asserting that somebody checked, which is a record that says the wrong thing.

The automation tension is the one to resolve deliberately. If approval is required before issuance and a deployment pipeline needs a certificate at 3am, one of the two has to give. Let machine identities bypass the review step explicitly, and narrow what they are allowed to request to compensate. The alternative that teams drift into is a standing approval nobody reads, which removes the control while keeping the paperwork.

How do you roll this out without a big-bang migration?

Nothing about this requires reissuing certificates that already work. Existing certificates stay valid until they expire, which means the migration is a matter of changing where the next certificate comes from.

A sequence that works:

1. Inventory first. Scan for what is actually deployed before designing anything, because the design depends on what you find. This step routinely finds certificate authorities nobody knew were issuing.
2. Stand the new structure up alongside the old one. Policies and profiles cost nothing to create and issue nothing until something is pointed at them.
3. Move one service, in a lower environment. The first service through will find the things the design got wrong, and it is cheaper to find them in staging.
4. Move production issuance per service, not all at once. Each service cuts over when its renewal comes due, so the migration rides the renewal cycle instead of fighting it.
5. Decommission the old path last, and only once nothing renews through it. The old CA stays alive until the last certificate it issued has expired, which is one full validity period after the last renewal moves.

The step people skip is the first one, and it is the one that determines whether the rest is accurate.

Where Infisical fits

Infisical's Certificate Management is built for the situation this article describes: certificates arriving from several issuers, owned by several teams, with one inventory and one set of rules needed over the top.

• It sits above your existing issuers rather than replacing them. Internal CAs, Microsoft ADCS, AWS Private CA, DigiCert, and any ACME-compatible CA connect as backends and keep issuing. Adopting it does not mean reissuing certificates or retiring the CA your auditors or your Windows estate depend on.
• Discovery finds the certificates you never issued. Network scans sweep IP ranges, domains, and ports for what is actually deployed, reach private networks through a gateway, and run on a schedule. Anything found can be imported and tracked alongside the rest.
• Policies decide what a certificate may contain. Allowed domains and SANs, maximum validity, key and signature algorithms, key usages, and custom X.509 extensions. Each field is unconstrained, explicitly forbidden, or limited to a whitelist, and a request that violates the policy is never signed.
• Delegation is the default rather than a configuration exercise. Certificate authorities, policies, and profiles are administered centrally, while teams work inside Applications as Admin, Operator, or Auditor, holding different roles in different environments. Approval policies add multi-step review where it is warranted, with an explicit bypass so deployment pipelines are not left waiting.
• Enrollment uses the protocols your infrastructure already speaks. API, ACME, EST, and SCEP, so web servers, Kubernetes, network devices, and MDM-managed endpoints all enroll against the same policy layer.
• Certificates land where they are consumed. Syncs push issued certificates to AWS ACM, Azure Key Vault, Cloudflare, and other destinations, and expiry alerting covers what stays where it is.

Infisical is open source, and runs as shared cloud, dedicated cloud, or fully self-hosted.

The reference architecture documents the full layout, and the complete guide to private certificate management covers the CA hierarchy decisions underneath it.