Abstract
Running your own certificate authority sounds like the responsible choice for internal infrastructure. Distribute your root cert to every machine and issue certs internally.
In practice, you spend the next six months chasing down every device, contractor laptop, and vendor console that didn’t get root installed. The warnings come back. And when they do, people click through them, because they always have.
There’s a simpler path, and most teams don’t know it exists.
Public certificates don’t mean public servers
A common misconception is that getting a trusted certificate means your server has to be reachable from the internet. It isn’t true.
HTTP validation works by having your CA fetch a file from your server to confirm you control it. Your server has to be publicly accessible for that to work. Most people’s mental model of ACME stops here.
DNS validation works differently. Instead of reaching your server, the CA looks for a TXT record in your DNS zone. You prove control of the domain, not accessibility of the host. Your server can be on a private subnet, sitting behind a firewall, or completely unreachable from the outside world. Your CA never needs to connect to it.
This means you can issue a real, browser-trusted certificate for internalportal.example.com or vcenter.int.example.com without ever opening a port to the internet. The certificate itself is identical to the one on any public website. Chrome sees it, trusts it, and shows the padlock. No exception required.
It works for internal web portals and intranet sites. It works for internal APIs. It works for the management UI on your Palo Alto firewall, your Cisco switches, your Fortinet appliances. Anything you’ve given a DNS name in a domain you control is a candidate. You don’t distribute a root cert. You don’t run your own CA. You don’t explain to every new employee why a certain site shows a warning.
Use a wildcard and stay out of the CT logs
Rather than issuing individual certificates for every internal host, a wildcard for something like *.int.example.com covers everything under that subdomain. One cert, one renewal process, deployed once. You define your naming convention in internal DNS and point each host at its real IP.
There’s a tradeoff worth knowing about. Every public certificate gets logged to Certificate Transparency logs, and those logs are publicly searchable. If you issued individual certs for vcenter.int.example.com and firewall.int.example.com, you’ve just published a list of internal targets. A wildcard for *.int.example.com reveals only that you have internal services under that subdomain. The specific names stay out of the logs.
For most organizations, that’s a fine outcome. The attacker who knows internal services exist under int.example.com still can’t reach them. If your compliance posture or internal security policy requires that no internal topology be disclosed at all, private PKI may genuinely be the right call. But that’s a narrower set of situations than most teams assume, and it’s worth being deliberate about which one you’re actually in before taking on the maintenance burden of running your own CA.
The DNS credential problem
DNS validation has one real catch: it needs write access to your DNS zone at renewal time.
That means your certificate tooling needs credentials for your DNS provider. Handing those out is a wide blast radius if something goes wrong, and many teams are (reasonably) reluctant to do it. Some DNS providers don’t even have an API, which makes automation impossible without changing providers.
The safer solution is DNS delegation. You add a single CNAME record pointing _acme-challenge.int.example.com to a validation domain that your certificate tooling controls. From that point on, the tooling can fulfill ACME challenges for *.int.example.com by setting records in that delegated zone, without ever touching your DNS again. Your DNS credentials stay with you.
CertKit handles the CNAME delegation approach out of the box. You set up the CNAME once, and CertKit manages renewals from there without requiring ongoing access to your DNS provider. It also handles deployment to devices that can’t run a renewal agent themselves, like network appliances with an API or managed infrastructure where certificates need to be pushed rather than pulled. Plus, we handle the certificate distribution to all your intranet servers and appliances.
CertKit handles certificate lifecycle management for internal and external infrastructure, so private PKI is not your problem.
Comments