A private certificate authority for your internal infrastructure, without running it yourself.
Managed PKI is a private certificate authority operated as a service. You get to issue certificates for internal hostnames, IP addresses, and client authentication, without standing up CA servers, guarding a root key, or hosting revocation lists yourself.
Public certificate authorities can only issue for domain names that resolve publicly and that
you can prove you control. Things like your website, but not
db01.corp.internal, a load balancer by IP address, or the
client certificates your services use to authenticate.
For those you need your own certificate authority, which is what a private PKI is.
Running your own certificate authority means you need a CA server, a root key you have to protect for a decade, published revocation lists, and a rollout to get your root trusted on every device. Managed PKI is paying someone like us to operate that infrastructure for you. This could also be called PKI as a service, PKIaaS, or a hosted private CA.
| Public CA | Private CA | |
|---|---|---|
| Trusted by | Every browser and OS by default | Devices where you install the root |
| Can issue for | Any publicly resolvable domains you control | Any name you choose, including internal names and IPs |
| Validation | Domain control check on every issuance | None, because you are the authority |
| Maximum lifetime | 200 days today, 47 days by 2029 | 825 days |
| Good for | Server authentication on the public internet | Internal services, mTLS, devices, lab and test systems |
Most organizations need both, which is the practical argument for running them through one system like CertKit.
Names like db01.corp.internal, single-label hostnames, and internal DNS zones
that no public CA is permitted to issue for.
Services addressed by IP rather than hostname, including private RFC 1918 ranges that cannot be validated publicly.
Client authentication certificates for service-to-service calls and device identity. Public CAs are exiting this entirely, so the last public client certificates expire in October and a private CA is the only option left.
Up to 825 days, while public certificate lifetimes keep shrinking toward 47 days. Useful for equipment that is hard to reach on a short cycle.
From an operational perspective, CertKit is easy to deploy and manage. The ability to configure unique and specialized certificates is key to replacing our manual certificate processes.
Laura Thomas, Senior Central Systems Administrator, University of St. Thomas
The choice comes down to whether you already operate an internal root certificate authority. Both paths issue the same certificates and both are managed the same way after setup.
Standalone Bring your own root
┌────────────────┐ ┌────────────────────┐
│ CertKit root │ │ Your root CA │
│ CA │ │ (AD CS, offline, │
│ │ │ HSM appliance) │
└───────┬────────┘ └─────────┬──────────┘
│ │ signs CSR
▼ ▼
┌────────────────┐ ┌────────────────────┐
│ CertKit │ │ CertKit │
│ issuing CA │ │ subordinate CA │
└───────┬────────┘ └─────────┬──────────┘
│ │
▼ ▼
┌────────────────┐ ┌────────────────────┐
│ your software │ │ your software │
│ and devices │ │ and devices │
└────────────────┘ └────────────────────┘
CertKit creates a root certificate authority and an issuing CA beneath it. You install the root's public key once on the devices that need to trust it, and everything below is handled for you automatically.
This is the option for teams with no internal PKI today, or with one they want to retire. It is a complete internal certificate authority, and there is nothing for you to operate.
If you already run Active Directory Certificate Services, an offline OpenSSL root, or an HSM-backed appliance, CertKit becomes a intermediate CA (or subordinate CA) underneath it. CertKit generates the subordinate key and a signing request, your CA signs it against a subordinate CA template, and you import the result. Issuance, renewal, deployment, and revocation below that point are then automated.
Two things make this worth doing. Your devices already trust your root, so there is no trust rollout at all. And your root key never touches CertKit, because CertKit holds only the subordinate key while the root stays exactly where it lives today.
Active Directory Certificate Services is free, built into Windows Server, and good at what it was designed for, which is issuing certificates to domain-joined Windows machines through auto-enrollment. There is no reason to replace it.
Where it gets clunky is everything outside the domain. Getting an internally trusted certificate onto nginx, a FortiGate, an F5, or any appliance that has never heard of Active Directory means exporting by hand, converting formats, and installing it yourself, every time it renews.
That is the gap CertKit fills. Your AD CS root signs the CertKit subordinate, and CertKit issues and deploys internally trusted certificates to the systems auto-enrollment was never going to reach.
Issuing a certificate is the easy part of PKI management. Everything around it is the work, and it is what separates an enterprise PKI you can depend on from a service that signs whatever you ask for. PKI providers differ most here, so before you commit to one, check that all of it is included rather than left to you.
The last two are where most private CA products stop. An internal CA that issues certificates but leaves you to install them by hand has moved the problem rather than solved it, and internal certificates are usually the ones on the hardest systems to reach.
Comparing options more broadly? See how CertKit measures up against enterprise CLM platforms like Venafi, Keyfactor, and Sectigo, and against open-source ACME clients.
Private certificates flow through the same process as public ones. The same renewal engine, the same agents deploying to your servers and appliances, the same keystore support, and the same expiration alerting. The only thing that changes is who signs the certificate, which means one inventory and one process across your whole estate rather than a separate internal system to babysit.
You create a CA in a few minutes, choosing a key algorithm and optional name constraints that restrict which names and IP ranges it is allowed to issue for. Certificates issued from it skip domain validation entirely, because proof of domain control serves no purpose when you are the authority. SANs can be internal names, single-label hostnames, wildcards, or IP addresses, and each certificate can be marked for server authentication, client authentication, or both.
Revocation lists are hosted for you, and every certificate points at them. Renewal happens ahead of expiry and agents pick up the new certificate on their next sync, exactly as they do for a public certificate. This is certificate lifecycle management applied to your internal infrastructure instead of only the public-facing part of it.
CertKit has been a fantastic solution for automating our environment’s SSL/TLS certificates. With a single pane of glass for centralized management, visibility, and monitoring and the highly customizable interface for granular control over individual systems, we have found great value in reducing the time and complexity of managing an ad-hoc ACME solution for individual certificate automation.
Seth Allums, Lead Systems and Information Security Engineer, Clackamas Community College
Private PKI describes what it is, a certificate authority that only your systems trust. Managed PKI describes who operates it. A private PKI you run on your own servers and a managed PKI run as a service issue the same certificates. The difference is whether you are responsible for the CA infrastructure, the root key, and the revocation endpoints.
PKI as a service, sometimes written PKIaaS, is another name for managed PKI. A provider operates the certificate authority infrastructure and you use it to issue certificates. Some vendors use the term to mean issuance only, so it is worth confirming whether deployment, revocation hosting, and monitoring are included or sold separately.
No, and usually you should not. AD CS handles domain-joined Windows machines well through auto-enrollment, and it comes with Windows Server. CertKit chains to your existing AD CS root as a subordinate CA and covers what AD CS struggles with, which is issuing and installing internally trusted certificates on systems that are not domain-joined.
The root certificate has to be installed in the trust store of every device that will validate those certificates. With a CertKit root, the agent can install it for you. If you chain to a root your organization already uses, nothing needs to be distributed, because your devices trust it already.
Up to 825 days. The cap is deliberate, because Apple platforms reject TLS server certificates valid for longer than that even when they chain to a privately installed root. A certificate is also never issued past the expiry of the CA that signs it.
Yes, and that is the point of running them together. CertKit issues public certificates from Let's Encrypt or any ACME certificate authority, and private certificates from your own CA, with one inventory, one renewal engine, and one set of deployment agents across both.
Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.