At Anchor, we help developers deploy internal TLS by building and managing private (aka internal) Certificate Authorities (CAs). It's a lot like a public CA, but just for your organization. Give it a try with lcl.host, a free devtool to setup HTTPS in your local dev environment.
Here's something that's happened more than once in my career: a fellow developer is considering internal TLS to address a security requirement or problem, and I’m simultaneously thinking:
An internal CA could solve this problem, and
I do not want to suggest an internal CA solution.
Internal CAs have a reputation for being great on paper, but problematic in practice. Instead, we often see public CA issued certificates used for internal TLS rather than internal CA issued certificates. But that can require building complex ACME workflows to get public CA certificates onto backend servers. Developers will go to astounding, yet often justified, lengths to avoid internal CAs. The public CA approach avoids most of the problems that plague internal CAs, but has its own set of challenges: low API limits, slow certificate provisioning, and little control (more on this later).
Why do internal CAs feel extra painful to developers? At a fundamental level, there is no real difference between public and internal CAs to a TLS client or server. Once a server has its certificate and a client has its trusted CAs, connections are functionally identical. The organizational structure of the CA issuing certificates has no impact on security or feature availability. Let's look at some of the challenges specific to internal CAs, and some ways we can solve them.
Internal CA Problems
Problems with internal CAs generally fall into two categories:
Provisioning: providing certificates to servers.
Distribution: updating clients and applications to trust certificates presented by servers.
Frustratingly, certificate management solutions focus entirely on provisioning, whereas internal CA deployments struggle most with distribution. To our knowledge, Anchor is the first product to address distribution problems. Before diving into Anchor’s features, let’s look closer at both provisioning and distribution problems.
Provisioning Problems
Getting certificates to services so they can terminate TLS is the provisioning problem. Without a valid X.509 certificate, a server cannot securely serve encrypted traffic. For services that require TLS encryption, their utility depends on the ability to provision a certificate.
Ten years ago, adding certificates to servers was painful. A lack of common configuration and provisioning workflows made automation difficult. But the ACME protocol changed that by standardizing how certificates are provisioned. It’s even standardizing how applications configure and load certificates.
The good news is that ACME is just as applicable for internal CAs. In fact, simpler ACME workflows are possible since the security contexts are quite different. An internal CA can employ pre-authorization of clients by utilizing an API token based ACME workflow. This means clients don’t have to publish DNS records or respond to HTTP challenges to get certificates. (We call this zero-challenge ACME.)
Once servers have valid certificates, distribution problems begin.
Distribution problems
To validate server certificates, clients must be configured with the set of certificates for the issuing CAs. It's a lot of work to keep these sets up-to-date and distributed to browsers, OSes, and clients. Public CAs have gotten so good at this that most people (even developers) don't realize just how much work it takes.
Unfortunately, the work of these public CAs does not help internal CAs. By definition, private CAs cannot be introduced into the set of trusted public CAs, leaving the challenges of distribution and maintenance to internal CA operators. As services grow and become more interconnected, the toil of operating internal CAs grows quickly.
Luckily, most of the tooling created for public CAs is usable with internal CAs. For example, the OS package formats for installing public CAs works just as well for internal CAs. The tooling may be tedious, but public CAs demonstrate that it can work.
Anchor eliminates this tedious work by building OS and language packages to install certificate sets into your system and application runtime trust stores. You get a seamless trust store management experience more like public CAs, but tailored to developer needs.
What about Public CAs?
Using a public CA for internal TLS is popular because both provisioning and distribution problems are more or less solved. The ACME protocol is flexible enough to provision certificates for most applications and infrastructure. And distribution issues are invisibly handled by the Root CA Programs (a.k.a. the OS and browser organizations), making it almost entirely a non-issue for developers.
If shoe-horning public CAs for internal TLS works, why not use one? Although popular, this approach comes with problems:
Low API limits put in place by public CAs will impact your ability to replace and receive new certificates, causing outages and impacts to service availability.
Slow provisioning workflows means even fully automated certificate provisioning can be painfully slow due to DNS record propagation or slow ACME challenge resolution.
Public visibility of these certificates (via CT logs) may unintentionally leak details about internal infrastructure and services, or even customer details. For example, using a subdomain per customer means your customer list is public and searchable in tools like crt.sh.
Very little control or customization. Expiration periods are set by CA policy, and extensions like mTLS support may be restricted.
The problems with using public CAs for internal TLS arise from their public nature. The need to protect against fraud & abuse necessitates API limits, CT logs, and other policies that manifest as problems for internal TLS users.
Public CAs may never be a perfect fit for internal TLS, but they do get a lot right. And what public CAs do well can be incorporated into internal CAs.
Solutions
Anchor provides a better developer experience for certificate management than any public or internal CA solution that exists today. We do this by adapting and improving upon the public CA experience for internal TLS.
For certificate provisioning, our zero-challenge ACME flow provides near instant certificates. It’s fast enough to move certificate provisioning into the container and service boot process.
Our language and OS packages are a developer-friendly way to manage your client trust stores. Anchor is the only certificate management product that offers developer friendly package artifacts.
We see certificate provisioning as table-stakes for certificate management, and we’re obsessive about solving distribution problems. We want to change how developers think about internal CAs, and have confidence that an internal CA is the best option for internal TLS deployments.
If you’re interested in using Anchor for internal TLS deployments at your organization, please reach out via email to join our private beta. Or give Anchor a try right now in your development environment with lcl.host, our free devtool for quick & easy HTTPS in your local dev environment.
