How do you build an internal PKI for service-to-service TLS without leaking trust outside your network?

How do you build an internal PKI for service-to-service TLS without leaking trust outside your network?

Internal services need TLS, but public CAs publish names to CT logs and cannot issue for non-public hostnames. A private PKI (Public Key Infrastructure) keeps internal names off the public record. Build playbook.

— Create an offline root CA, kept air-gapped, whose only job is signing one or more online intermediate CAs. The root's private key never touches a network-connected host.
— Issue from intermediates, so you can revoke and rotate an intermediate without redistributing the root.
— Distribute only the root certificate to internal trust stores (OS, container base images, language runtimes); never distribute private keys.
— Keep certificate lifetimes short (days to weeks) and automate issuance via an internal ACME server, so compromise windows stay small and revocation matters less.
— Constrain the root with name constraints (RFC 5280 section 4.2.1.10) limiting it to your internal domain, so a leaked intermediate cannot mint certs for public names.

Evidence vs. speculation: name constraints are enforced by validators that support them; older clients ignore the extension, so do not rely on it alone.

Further reading: RFC 5280 sections 4.2.1.9-4.2.1.10; RFC 8555 for internal ACME.

Bottom line: offline root, short-lived leaves, and name constraints keep internal trust internal.