3 Reasons Why You Shouldn't Use Public CAs for Internal Infrastructures

Linda Ikechukwu

Follow Smallstep

Certificates are important for secure communications. They facilitate data confidentiality, information integrity, and authentication. And, thanks to the innovation of public web Certificate Authorities (CAs) like Let’s Encrypt, you can obtain certificates for your domains almost instantly and automatically, without doing much, and for free. So why run your own CA for internal use cases, if web CAs are so good? Well, the simple answer is that public web CAs were not designed to support internal use cases, and here's why:

1. Public web CAs deny flexibility to optimize your PKI for your specific needs

Public CA organizations are governed by a set of industry bodies, and, as such, are subject to strict guidelines. As a result, you have no control over certificate policies (how and in what situations your certificates can be applied) and certificate operations (how the certificates are issued or managed).

The inability to define your own certificate policies means you’ll have little or no control over important details like certificate lifetime, revocation mechanisms, renewal processes, key types, or the issuance or verification processes. These limitations make it nearly impossible to tweak certificates to fit the exact needs of your internal network. For example, most enterprises like to integrate their own access control systems (such as single sign-ons or LDAP directories) as part of the verification process; this easily provides certificates to parties already trusted by the operator.

While on the subject of constrained flexibility, it's also worth noting that most public web CAs are rate-limited, and rate limits can be prohibitive in developer environments. There may be times when you'll need to get certificates at a higher volume than the public CA allows (i.e., restarting kubernetes clusters without persistent storage or spinning up environments that need a lot of ephemeral certificates), and you won't be able to.

Setting up your own private CA gives you complete control and flexibility to customize your certificates to suit your needs.

2. Public web CAs are prohibited from issuing certificates to domains on private TLDs

The CA/Browser Forum’s Baseline Requirements prohibit publicly trusted CAs from issuing certificates for domains that are not rooted in a registered top-level domain (TLD) like “.com” or “.net”.

When it comes to internal or private networks, the acknowledged best practice (as recommended by RFC 6762), is to use sub-domains of public domain names that are rooted in a registered top-level domain (TLD) like “.com” or “.net”. However, many people still opt to use locally defined TLDs for several reasons—such as ensuring the internal domain names are accessible even if internet access is unavailable, and to avoid the possibility of the exposure of its metadata.

If you decide to do the same, it means that you can’t use publicly trusted CAs to issue certificates to your internal web apps and services, DevOps build servers, testing resources, IoT devices, or other entities with domain names that are only valid in the context of an internal or private network (e.g. example.local, 10.0.0.0/8, or even localhost). The solution is to get your own CA.

3. Certificate transparency logs used by public web CAs expose internal networks to potential security risks

Certificate transparency (CT) logs are a distributed system of append-only and tamper-proof public logs, that keep track of all certificates issued by publicly trusted CAs. The purpose of CT is to ensure that the issuance of certificates on the web is transparent and verifiable, so that site owners can detect maliciously or accidentally mis-issued certificates that may be exploited to impersonate them. So, browsers (like Chrome and Safari) mandate publicly trusted web CAs to publish every certificate they issue to CT logs.

Though CT logs are useful for revealing fraudulent or mis-issued certificates, they pose a security risks to internal networks in private systems, making them vulnerable to threats like internal server-side request forgery (SSRF).

Using tools like crt.sh or censys.io, attackers can uncover all certificates issued to a specific organization. And, with the data contained in TLS certificates, the attacker can gather a lot of information about an organization’s infrastructure such as its internal sub-domains, email addresses, and network structure. So, CT becomes a useful tool which an attacker can use to footprint, and potentially mount an attack.

For example, in 2019, the Matrix.org Foundation wrote about how a security researcher used CT logs to uncover, reveal, and try to access a handful of internal-facing services—like dev and testing services—and AWX deployments used by their internal Modular platform.

The solution is to set up your own CA to issue certificates for your internal infrastructure. That way, you can keep your internal hosts from showing up in a public CT log.

But, setting up a private CA is no easy feat

Yep, we agree with you, and that’s why Smallstep exists—you can leave that expertise to us.

With our open-source step-ca tool, you can easily set up and self-host a CA. Or, you can use our hosted Certificate Manager platform to manage certificates for all workloads, devices, and developers within your organization.