DEV Community

Cover image for Private Certificate Authorities: Building Trust Inside Your Organization
Divyanshu Soni
Divyanshu Soni

Posted on

Private Certificate Authorities: Building Trust Inside Your Organization

#security #devops #architecture #certificate

Suppose you’re building a system with multiple moving parts:

  • An API gateway at the front.
  • A bunch of microservices handling authentication, payments, notifications, and analytics.
  • A Kubernetes cluster managing deployments.
  • A team of developers, CI/CD pipelines, and staging environments.

Everything works fine until you realize:

  • How do I make sure only my services can talk to each other securely?
  • How do I rotate credentials across services without manually updating configs?
  • How do I prevent one compromised service from impersonating another?

Tokens in environment files can get leaked. Shared API keys are brittle. Static secrets don’t scale.

What you really need is a system of trust that proves who each service is and secures every connection. That's where Certificate Authorities (CAs) and, more importantly, Private CAs come in. So let's understand what Certificate Authorities are and, most importantly, how you can build a Private CA with one of the most amazing developer tools out there.

What are Certificate Authorities (CAs)

A Certificate Authority(CA) is a trusted organization that plays a crucial role in digital security. Its main job is to make sure that when you connect to a website, service, or system, you're really talking to the right one and not to an imposter.

Here's what a CA actually does:

1. Verifies identity

  • Before issuing a certificate, the CA checks who you are.
  • For example, if a company applies for api.mybank.com, the CA confirms that this company really owns that domain.
  • In higher levels of validation, CAs may even check business registrations, addresses, or legal documents.

2. Issues digital certificates

  • After verification, the CA gives you a digital certificate.
  • This certificate contains your public key plus identity details (like your domain name or company info).
  • It's cryptographically signed by the CA, which makes it trustworthy.

3. Maintains ongoing trust

  • A CA doesn't just hand out certificates and disappear.
  • It also manages them:
    • Signs certificates so others can verify authenticity.
    • Revokes certificates if they're compromised, expired, or misused.
    • Publishes revocation lists or online status checks so browsers and systems know which certs to trust.

I know this is getting a bit too theoretical, so let’s use a real-world analogy to make Certificate Authorities easier to understand.

Think of a CA like a passport office for the internet:

  • You show proof of identity → the passport office checks it.
  • They issue you a passport → this acts like your certificate.
  • Other countries trust your passport because they trust the authority that issued it.

In the digital world:

  • Your "passport" is the certificate.
  • The CA's "stamp/signature" proves it's real.
  • Other servers, browsers, or users trust you because they trust the CA behind your certificate.

Types of Certificate Authorities

Now that you know what a CA is, let's talk about the types you'll encounter as a developer.

1. Public CAs:

  • These are the big names like Let’s Encrypt, DigiCert, and GlobalSign.
  • Their root certificates are baked into browsers, operating systems, and devices.
  • That's why when you open https://google.com, your browser trusts it instantly.
  • Perfect for public-facing websites and APIs.

2. Private CAs:

  • These are CAs you (or your company) run internally.
  • Their certificates aren't trusted by the entire world, only by the systems where you explicitly install the CA's root certificate.
  • Perfect for microservices, Kubernetes clusters, staging environments, and DevOps pipelines.

3. Root vs Intermediate CAs:

  • Root CA: The ultimate trust anchor. It's like the government's central passport office. Rarely used directly, kept offline for safety.
  • Intermediate CA: Think of it as a regional passport office that does the day-to-day work. It's signed by the root and issues certificates to services, servers, and developers.
  • Why? This separation keeps the root safe while still letting you issue certificates flexibly.

Why Do Private CAs Exist If We Already Have Public CAs?

Public CAs like Let’s Encrypt or DigiCert are perfect when you need global trust, for example, securing https://myapp.com so any browser in the world knows it's safe.

But inside your organization, you often don't need (or even want) that global trust.

  • Your services talk to each other using internal hostnames (for eg, payments.svc.cluster.local), which public CAs won't issue certificates for.
  • You may need hundreds of certificates for microservices, clusters, and pipelines, and paying a public CA for each would be expensive and unnecessary.
  • You want full control over certificate policies, lifetimes, and revocation, and not depend on an external company.
  • Security teams often follow a zero-trust model, where every internal request must be authenticated, something that's easier with your own CA.

Both have their place, but only a Private CA can give you scalable, flexible, and cost-effective trust for internal systems.

What a Private CA Looks Like in Practice

A Private CA is simply a Certificate Authority you control, but the way it's structured is very intentional. Here's the breakdown:

Root CA

  • The root certificate is your ultimate trust anchor.
  • It's generated once and kept extremely secure, usually offline or in a hardware security module (HSM).
  • You don't use it for day-to-day work; its main job is to sign intermediate CAs.

Think of it as the government's central authority. It exists, but you don't go there every time you need a passport.

Intermediate CA

  • The intermediate CA handles daily certificate issuance.
  • It's signed by the root CA, so anything it issues is trusted.
  • This way, even if your intermediate gets compromised, the root remains safe.

This is your regional passport office, which means it's where most of the action happens.

Trust Distribution

  • Finally, you install your root CA on every server, cluster, and developer machine that should trust it.
  • Once that's done, anything signed by your intermediate is automatically trusted everywhere inside your organization.

In other words: one trust anchor, many identities.

Setting Up a Private CA

Let's say you want to try this out on your local machine. Here's a simple demo using OpenSSL:

OpenSSL is a free software toolkit that helps secure the internet. It's what makes HTTPS work by encrypting data and managing certificates so information stays private and trusted.

# Step 1: Generate a root key openssl genrsa -out rootCA.key 4096 # Step 2: Create a root certificate openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem # Step 3: Generate an intermediate key openssl genrsa -out intermediate.key 4096 # Step 4: Create a certificate signing request (CSR) for the intermediate openssl req -new -key intermediate.key -out intermediate.csr # Step 5: Sign the intermediate with the root CA openssl x509 -req -in intermediate.csr -CA rootCA.pem -CAkey rootCA.key \ -CAcreateserial -out intermediate.pem -days 1825 -sha256
Enter fullscreen mode Exit fullscreen mode

At the end you’ll have:

  • rootCA.pem → your trust anchor.
  • intermediate.pem → your working CA for issuing certificates.

From here, you can start issuing certificates for your internal services.

This manual setup works for testing, but in real systems, it quickly becomes unmanageable. Here's how:

  • Certificate renewal → If you forget to renew, your services will break the moment certs expire.
  • Revocation → If a service's key leaks, you need a fast way to revoke its certificate.
  • Scale → With dozens of microservices, you'll need hundreds of certificates rotating all the time.

This is why companies rarely manage their Private CA by hand. Instead, they use tools to automate everything. This is where Infisical comes into the picture. You may already know Infisical as a secret management platform, but it also works exceptionally well for managing internal PKI.

With Infisical, you can build an internal PKI: optionally create or import a root CA, chain one or more intermediate CAs, and enforce certification policies via templates. You can automate issuing certificates to Kubernetes through the Infisical PKI Issuer + cert-manager, and sync certificates out to external systems using Certificate Syncs. The model encourages keeping the root CA secure (e.g. offline or external), enforcing short TTLs, and leveraging RBAC and identity controls, giving you tools for safer, automated service identity and credential rotation (so long as you configure it correctly).

Best Practices for Running a Private CA

When you move beyond experimenting and actually run a Private CA in production, a few best practices go a long way:

  1. Keep your root CA offline: Generate the root key once, store it securely (HSM or encrypted offline storage), and never use it for day-to-day signing.

  2. Use intermediate CAs for daily operations: Always issue service and server certificates from intermediates. If compromised, you can revoke and replace the intermediate without touching the root.

  3. Rotate certificates frequently: Favor short-lived certificates (days or weeks, not years). Automated renewal prevents outages due to expired certs.

  4. Enforce strict issuance policies: Define what domains/hostnames are allowed (CN, SANs). Restrict key usages (serverAuth, clientAuth) so certificates can't be misused.

  5. Plan for revocation: Publish a Certificate Revocation List (CRL) or use OCSP so that compromised certificates can be invalidated quickly.

  6. Monitor and alert: Always have monitoring in place to alert you when certificates are close to expiry. Nothing breaks production faster than an expired cert.

  7. Use RBAC and logging: Control who can issue/revoke certificates. Keep an audit trail of every action taken in your PKI.

Conclusion

Certificate Authorities form the trust backbone of the internet, but private CAs give organizations the flexibility to secure their own systems. By following best practices and experimenting with small hands-on projects, developers can gain a practical understanding of how PKI works. Once you see certificates in action, from issuance to trust to revocation, you’ll realize that building a secure foundation isn’t just for big companies. It's an essential skill for anyone designing modern distributed systems.

Top comments (0)