Who can issue a digital certificate? public vs private certificate authorities for corporate pki

Who has the authority to issue a digital certificate?

At the heart of every Public Key Infrastructure (PKI) is a simple question: who can issue a digital certificate, and under what controls? For IT, IAM, PKI owners and Security Architects, the answer is both technical and organizational. It combines cryptographic controls (root CA protection, HSMs, key ceremonies), policy enforcement (certificate profiles, issuance rules), and operational tooling (certificate automation, certificate lifecycle management or CLM).

High-level categories: public CAs, private CAs and self-signed certificates

Public CAs are third-party trust anchors whose root certificates are embedded in operating systems and browsers. They are the usual choice when you need global trust for TLS certificates used on public-facing services. Issuance from a public CA means your certificate is broadly trusted without manual configuration on client devices — but it also requires adherence to external audit requirements, CA/Browser Forum Baseline Requirements and often stricter validation processes.

Private CAs are controlled by an organization (on-premises or hosted in a trusted environment). They issue certificates for internal services, machine identity, code signing, and user authentication within the enterprise trust boundary. Private CAs give you control over policies, lifetime, and automation while keeping cryptographic keys and sensitive identity data under sovereign management.

Self-signed certificates are created by an entity that signs its own certificate. They can be useful for testing or isolated systems but are not suitable for broad trust unless recipients explicitly trust the certificate. Self-signed certs increase operational friction and risk if used in production without careful governance.

RFC 5280: "A certification authority (CA) is an entity that issues public key certificates" — this simple definition underscores that the authority to issue is a function of trust, policy and technical control.

Who is allowed to issue certificates in a corporate environment?

Practically, there are several authorized issuers inside a corporate ecosystem:

• Central corporate private CAs operated by the security or PKI team (root and issuing hierarchies).
• Delegated subordinate CAs or RA (Registration Authority) systems used by business units under stricter policy control.
• Automated machine identity platforms that request and retrieve certificates on behalf of services (DevOps pipelines, Kubernetes, load balancers).
• External public CAs for services requiring external trust.

Authorization is not just who can press the button. It is about policy (what profile, what lifetime), technical constraints (which keys, which algorithms), and procedural controls (multi-party approval, key ceremony, HSM-backed keys).

Delegation and role separation

Delegating issuance to subordinate CAs or automated agents is common. But delegation must implement strong policy enforcement: certificate templates, allowed Subject Alternative Names (SANs), allowed key usages, and maximum TTL. This prevents misuse — for example, an internal service issuing a TLS certificate for an external domain it doesn't own.

Role separation is critical. personnel who manage the CA should not be the same who request certificates for production systems. Audit trails, RBAC and approval workflows are mandatory to maintain trust and meet compliance (e.g., eIDAS, NIS2) requirements.

Technical controls that define who can issue

From a technical viewpoint, who can issue is enforced by:

• Root CA security: roots must be protected (HSM, offline storage, strict access controls). If a root is compromised, all downstream trust is void.
• Subordinate CA issuance policies: certificate profiles define what can be issued and by whom.
• Key management: cryptographic keys used to sign certificates must follow lifecycle best practices, including key generation, backup, rotation and destruction.
• Audit and logging: every issuance event should be logged and linked to an identity (user, machine, or service account).

These controls are the technical backbone that determines who actually can issue a certificate, not just who is allowed on paper.

Operational practice: certificate automation and CLM

Manual issuance does not scale. Certificate automation and CLM platforms reduce human error, prevent certificate expiry incidents and enforce consistent policy across public and private CAs. Automation can: provision requests, validate identities, retrieve signed certificates, and deploy them to endpoints — all while maintaining auditable approval flows.

CLM integrates with DevSecOps pipelines, orchestration systems and IAM directories to ensure machine identity requests come from authorized actors and that TLS renewal happens before certificate expiry. This is essential to avoid service outages caused by certificate expiry or misconfiguration.

Architectural choices: when to use public vs private CA

Decide by trust scope and control requirements:

• Use public CAs when you need broad, browser-level trust for public APIs and customer-facing websites.
• Use private CAs for internal services, machine identities, and cross-service authentication where you want sovereignty, lower issuance cost and fine-grained policy control.
• Hybrid models combine public and private CAs: public for internet-facing endpoints, private for internal workloads and machine identities.

Private CA deployments also enable advanced patterns: short-lived certificates for zero-trust architectures, dynamic issuance for ephemeral containers, and tailored post-quantum preparation for internal endpoints.

eIDAS and NIS2 emphasize accountability and traceability in trust services and critical infrastructure — enterprises must align certificate issuance practices with these regulatory expectations.

Common problems and practical solutions

Problem: certificate expiry causing outages

Solution: automated TLS renewal integrated with CLM and monitoring. Enforce renewal windows (e.g., start renewal at 30 days before expiry), and implement certificate automation that can replace certificates without human intervention.

Problem: shadow PKI and inconsistent policies

Solution: centralized policy harmonization and visibility. Discover all CAs and issued certificates across the estate, consolidate templates, and apply consistent lifetimes and key algorithms. Policy enforcement prevents deprecated algorithms from being used and aligns lifetimes with short-lived certificate strategies.

Problem: managing machine identity at scale

Solution: issue machine identities through automated CA agents with RBAC, integrate with orchestration systems, and use short-lived certificates where possible so compromised keys have limited impact.

Modern trends changing who can issue

The landscape is evolving: short-lived certificates reduce the window for compromise; automation platforms enable trusted machines to request certs programmatically; and post-quantum readiness starts to influence issuance policies and key choices. These trends make it essential to combine cryptographic agility with robust policy enforcement.

Even more, organisations are moving toward scalable, automated private PKI to reclaim sovereignty while benefiting from cloud-like agility. That requires platforms that can act as controlled issuing authorities while integrating seamlessly with enterprise CLM.

How Evertrust approaches who can issue certificates

Evertrust provides a combined approach to answering this question in practice. Two complementary offerings illustrate this:

• Evertrust Stream — a modern PKI and private CA designed for scalability and automation. Stream enables delegated, policy-driven issuance with HSM-backed keys and strong role separation. It supports short-lived certificates, fine-grained templates and prepares organisations for post-quantum transitions.
• Evertrust Horizon — a Certificate Lifecycle Management (CLM) platform that provides complete visibility across public and private CAs, automates TLS renewal, enforces policies and reduces incidents related to certificate expiry; all while aligning with eIDAS and NIS2 compliance needs.

Evertrust's values are reflected in these capabilities: European sovereignty of cryptographic assets, deep automation to reduce human error, compliance support for eIDAS/NIS2, and pragmatic features for post-quantum readiness. Together, Stream and Horizon give IAM, PKI owners, DevSecOps and I&O teams the technical controls and operational workflows to decide who can issue certificates — and to enforce that decision at scale.

Practical example: automated internal TLS issuance

Consider an organisation deploying microservices in a hybrid cloud. A secure model uses Stream as the private issuing CA with policy templates controlling SANs and key algorithms. Horizon discovers all issued certificates, triggers automated renewal before certificate expiry, and enforces rotation policies. DevSecOps pipelines request certs via authenticated APIs, while IAM policies restrict which teams can obtain which certificate profiles.

This removes manual steps, reduces outages, and ensures each issuance event is auditable and compliant.

"Short-lived certificates and automation are effective mitigations against key compromise and human error." — operational guidance reflected in modern PKI best practices.

Operational checklist: who should be able to issue in your organisation?

Use this short checklist to align issuance authority with risk appetite:

• Inventory all CAs and their trust scopes.
• Define certificate policies: lifetimes, allowed algorithms, and templates.
• Implement role separation and RBAC for issuance and CA administration.
• Protect root and subordinate keys in HSMs; document key ceremonies.
• Automate issuance and renewal via CLM; monitor certificate expiry and TLS health.
• Plan for post-quantum readiness: algorithm agility and migration paths.

These controls determine not only who is permitted to issue but who effectively can issue without introducing risk.

Next steps and where to learn more

If your organisation needs to clarify issuer authority, eliminate expiry incidents, or modernize PKI while retaining sovereignty, consider a combined approach: implement a controlled private CA for internal identities and a CLM layer for automation and visibility.

Evertrust Horizon and Evertrust Stream are designed to work together to solve these exact problems. They provide the policy enforcement, certificate automation, and operational telemetry required by IAM, PKI owners, Security Architects and DevSecOps teams. To explore how this applies to your environment, request a technical demo or download our whitepaper on modern private PKI and CLM to see concrete architectures and migration patterns.

Interested in a hands-on walkthrough? Contact Evertrust for a demo of Horizon and Stream tailored to your PKI and certificate lifecycle needs.