How to Run an Internal CA for Micro Apps While Still Using Let’s Encrypt for Public Endpoints

Stop getting surprised by cert errors: run an internal CA for local micro apps and keep Let's Encrypt for public endpoints

Hook: If you manage a fleet of micro apps — internal dashboards, ephemeral developer services, and tiny APIs — you’re juggling two painful problems: public TLS for internet-facing endpoints and trusted certificates for private, internal-only hosts. Let’s Encrypt is perfect for public endpoints, but it can’t (and shouldn’t) issue certs for non-public names. The result: expired certs, ad-hoc mkcert hacks, and insecure bypasses. This article shows a pragmatic, production-ready hybrid approach in 2026 that puts automation, trust-store management, and developer experience first.

Why this matters in 2026

Micro apps exploded in 2023–2025 thanks to generative AI and low-code tooling. Teams ship many small services that are internal by design, often short-lived and owned by a single dev. In late 2025, ACME ecosystem tooling matured: cert-manager, step-ca, and mkcert added better automation and trust-store integration. That means you can—and should—run a secure internal CA for private endpoints while continuing to use Let’s Encrypt for public-facing services.

Executive summary (the most important part)

• Use Let’s Encrypt (ACME) for internet-routable, public domains and wildcard certificates (via DNS-01).
• Run an internal CA (step-ca, Vault PKI, or CFSSL) for private endpoints, micro apps, and hostnames that are not publicly verifiable.
• Automate certificate issuance and renewal with cert-manager (Kubernetes) or simple cron/ACME clients for VMs.
• Distribute trust: push your internal CA to platform and OS trust stores (GPO, MDM, Docker images, Kubernetes) to avoid bypassing TLS in dev and prod.
• Bridge the gap: present public Let’s Encrypt certs at the edge (reverse proxies, CDN, ingress) and keep internal CAs for east-west traffic and developer machines.

When to use an internal CA vs Let’s Encrypt

Make the decision based on the namespace of the hostname and operational requirements.

• Let’s Encrypt — use for: public-facing domains (example.com), subdomains published to the internet, API endpoints meant for external clients, and wildcard certs for public DNS zones. Benefit: trusted by browsers and clients out-of-the-box, free, and automated via ACME.
• Internal CA — use for: hostnames in private namespaces (host.local, service.cluster, *.internal), ephemeral developer environments, services that never touch the public Internet, and mTLS between microservices. Benefit: full control over issuance policies, longer lifetimes, and support for names that are not publicly resolvable.

Architectural patterns (hybrid workflows)

Here are three operationally proven hybrid patterns you can adopt depending on whether you run Kubernetes, VMs, or a mixed environment.

1) Edge-terminating TLS + internal mTLS (recommended for most orgs)

1. Put a reverse proxy, CDN, or cloud load balancer at the edge and obtain Let’s Encrypt certificates for public hostnames.
2. Inside the cluster or VPC, use an internal CA to issue short-lived certs for service-to-service encryption and optional mTLS.
3. Use cert-manager or an in-house agent to automate issuance from the internal CA.

Advantage: public clients never see internal certs; internal services have stronger identity guarantees using mTLS.

2) Split-horizon DNS with TLS split (for hybrid networks)

1. Use the same hostname externally and internally (api.example.com) with split-horizon DNS.
2. At the edge, terminate TLS with a Let’s Encrypt certificate. Internally present an internal CA certificate to east-west clients.
3. Prefer TLS-aware proxies that can perform TLS passthrough for specific flows when certificate identity matters.

Challenge: manage consistency between external and internal certs and carefully configure HTTP Host/ServerName expectations.

3) Developer-first ephemeral environments

1. Use mkcert for local development to create certificates signed by a developer-local CA that’s installed into the dev machine’s trust store.
2. For shared staging or preview environments, use an internal CA or an ACME-compatible internal CA (step-ca) via DNS-01 on your internal DNS provider.

Best for micro apps and

Related Reading

• Why Provenance Sells: Telling Supplier Stories Like an Art Auctioneer
• Small-Batch Thinking for Gear: Lessons from a DIY Cocktail Brand for Customizing Outdoor Equipment
• Family Connectivity Map: Which U.S. National Parks Have Cell Coverage and Which Phone Plans Work Best
• CES 2026 Surf Tech Roundup: 7 Gadgets We’d Buy for Your Quiver
• How to Spot a Wellness Fad: Red Flags From the Tech and Consumer Gadget World