Running a Private CA Inside Your Own AWS Account: Four Design Decisions
A private CA runs inside your own AWS account when three things are true at once: the CA private key is an AWS KMS asymmetric key under a key policy you write, the signing code is stateless compute you deploy from your own pipeline, and the AIA and CRL distribution URLs stamped into every certificate resolve to a hostname you control. If any one of those is false, you have a hosted CA with an account-shaped wrapper around it.
Most vendor material treats in-account deployment as a packaging choice — a box on a pricing page next to "SaaS". It isn't. It is a consequence of four architectural decisions, and a CA that hasn't made those decisions cannot be retrofitted into your account afterwards. This page sets out the four, and what each one changes in a security review.
AxelSpire's analysis here is not theoretical. The four decisions come from a high-level design written by Dan Cvrcek for an enterprise certificate management service spanning several national markets, tens of thousands of certificates, and a compliance surface that included PCI-DSS and UK telecoms security regulation. That design went through a security architecture review conducted, correctly, on the assumption that the vendor was a liability to be contained.
Almost none of the decisions that mattered were about issuance. Signing a CSR is the easy ten percent. The decisions that mattered were about where things live, who holds what, and what is left standing when the vendor goes away. Four of them shaped 3AM Mint, AxelSpire's KMS-backed private CA, directly.
For the cross-platform evaluation, see the Private CA Platform Comparison.
The four decisions, compared across deployment models
| Vendor SaaS CA | Managed cloud CA AWS Private CA | Self-hosted CA software EJBCA, step-ca | In-account stateless CA 3AM Mint | |
|---|---|---|---|---|
| CA private key custody | Vendor HSM, vendor policy | Your account, AWS-managed HSM | Wherever you put it — software keys by default in OSS builds | Your account, your KMS key policy |
| Who can invoke Sign | Vendor infrastructure | IAM principals you define | Whoever holds the key file or HSM credentials | IAM principals you define; revocable by key-policy edit |
| AIA / CRL hostname | Vendor domain | AWS-hosted or your S3 | Yours, if you build it | Yours, mandatory |
| Authorisation / policy engine | Vendor-side, vendor release cadence | Templates + IAM | In-product, your upgrade cadence | Outside the CA — your ITSM, OPA, or S3 policy file |
| Long-lived state you operate | None (vendor holds it) | AWS-managed | Database, HA pair, backups, patching | None — CRLs in S3, inventory in your CMDB |
| Disaster recovery model | Vendor runbook | AWS-managed | Restore from backup | Redeploy from IaC |
| What survives vendor exit | Certificates, until the CRL endpoint stops answering | Everything | Everything | Everything — key, bucket and domain were never the vendor's |
| Cost driver | Certificate volume | Per-CA per month + per certificate | Engineering time | Neither key nor volume creates vendor-side state |
Cost is deliberately out of scope on this page. See the private CA platform comparison for licence-versus-operating-cost analysis, including the double-running overlap that dominates any migration.
PKI Health Radar
Drag the sliders to assess your current posture — scores update instantly.
1. Key custody: where does the CA private key live, and who else has one?
The CA private key is a KMS asymmetric key in your account. Subject keys are generated on the endpoint and never traverse the network. Neither is ever held by AxelSpire.
The original design made two separate commitments about key material, and they reinforce each other.
The first: CA private keys never leave a FIPS-validated hardware boundary unencrypted — the standard requirement for any real PKI. Within AWS there are two credible ways to satisfy it: AWS Private CA, or an asymmetric key in AWS KMS with stateless compute acting as the CA. AWS KMS HSMs are validated to FIPS 140-3 Level 3 (NIST CMVP Certificate #4884), which raises the floor rather than changing the argument.
The second commitment is the interesting one. Automation was built around a pull model: endpoints generate their own key pair locally and ask only for a signature. A push model — where a connector generates the key centrally and ships it to the host over SSH — was permitted only for the narrow set of cases where a mature privileged-access system already existed. That was not fastidiousness. It was the only model the business teams would accept, because their applications already generated keys locally and had no intention of stopping.
Mint inherits both halves. The CA private key is a KMS asymmetric key in your account, under a key policy you write. Mint calls Sign. It cannot call anything that exports the key, because KMS exposes no operation that returns private key material. Subject keys are generated on the endpoint by an off-the-shelf ACME client. Push-based issuance remains available — all the compute is under your control, so the choice is yours rather than the vendor's — but pull is the default, and the default is the one that survives review.
Why it matters in your account: the two questions that stall every PKI security review — can the vendor sign as us? and does the vendor ever hold our private keys? — become questions you answer from CloudTrail rather than from a vendor attestation PDF. Withdrawing Mint's ability to sign is a key-policy edit you make yourself, at 3am, without opening a support ticket or reading the contract.
Related: key custody models in HashiCorp Vault PKI — the same question, asked of the most common open-source starting point.
2. Authorisation placement: why the CA should be deliberately dumb
Mint contains no policy engine, no directory sync, no identity model and no concept of a "team". It signs, and it calls out to whatever your organisation already uses to decide.
ServiceNow. Jira. An OPA endpoint. A JSON file in S3 that three people can edit. Each integration is a module or an additional stateless Lambda, deployed alongside the CA rather than inside it. The analogy is a car: the engine and the brakes work whether or not the head-up display has crashed.
Why it matters in your account: this is the reason in-account deployment is viable at all. A CA with opinions about your organisation must stay synchronised with your organisation — which means replicated state, a database, credentials on a rotation schedule, and an upgrade cadence you do not control. A CA with no opinions is a Lambda and a key. The whole footprint we deploy for you is less than $500 / month in AWS list price.
It also puts the fastest-moving part of the system — policy — on your side of the boundary, where you change it on a Tuesday instead of waiting for a vendor release. And it is why certificate volume does not move the price: there is no vendor-side state that grows with your estate.
3. Hostname ownership: one FQDN, on your domain, carrying everything
Every endpoint collapses onto a single fully-qualified domain name per environment, on your own domain: issuance API, CRL distribution points, OCSP responder, and the reference trust stores used to bootstrap clients that trust nothing yet.
TLS on 443 for the API; plaintext on 80 for revocation data and the trust-store bootstrap, for the obvious reason that a host with an empty trust store cannot fetch its trust store over TLS.
Why it matters in your account: the AIA and CRL distribution URLs you stamp into a certificate are load-bearing for that certificate's entire life, and CA certificates live for years. If those URLs sit on a vendor's domain, every certificate you have ever issued becomes collateral in your next contract renewal. Pointed at your own S3 bucket behind your own CloudFront distribution, on a Route 53 zone you delegated, they outlive the vendor relationship entirely.
The operational payoff is smaller but you feel it sooner: one name and two ports through network approval, once — rather than a fresh firewall exception every time a team onboards.
4. State and retention: what the service stores, and for how long
Mint's data table is mostly empty by design. Authorisation tokens are invalidated within minutes of issuance. No PII is held anywhere in the service. CRLs are objects in your bucket. Operational logs go to your SIEM. The technical service must be fully rebuildable from Infrastructure as Code within its recovery objective.
The only genuinely long-lived record — the certificate inventory itself — lives in your CMDB. Issuance is stateless. The CA key is in your KMS. Logs are CloudTrail and CloudWatch, already in the account your SOC is already watching.
Why it matters in your account, in ascending order of significance:
- Disaster recovery becomes a redeploy, not a restore. No snapshot to hold, no data to migrate, no vendor runbook to follow under pressure.
- Compliance scoping shrinks. A component that stores no PII and holds no long-lived secrets is a materially shorter conversation with a PCI assessor than a managed service with a database behind it.
- The exit is real. Tear down the stack and your chain still validates, because the key, the bucket and the domain were never ours to take with us.
Why this is becoming urgent rather than interesting
The CA/Browser Forum ballot SC-081v3 steps maximum public TLS certificate lifetime down from 398 days to 200, then 100, then 47 (200 days from 15 March 2026; 100 days from 15 March 2027; 47 days from 15 March 2029). It governs publicly trusted certificates, not private PKI — but internal expectations follow public practice within a cycle or two, and estates that renew manually stop being viable well before the 47-day step lands.
Shorter lifetimes multiply issuance events. Multiplied issuance events make the four questions above operational rather than architectural: every one of them is a thing you will be doing weekly instead of annually. See the PKI assessment guidelines for how to establish where your estate currently sits.
The point
None of this is about issuance. Anyone can sign a CSR — step-ca, EJBCA, cfssl, two hundred lines of Go. What is hard is where the key lives, who approves, whose domain the revocation URLs sit on, and what remains when the relationship ends.
That design was written for an organisation that was going to ask all four questions in a formal review, on the record, with an architect in the room whose job was to say no. Running inside the customer's account is not a deployment mode bolted on afterwards. It is what you are left with once you have answered those four questions honestly.
Automation is the protocol. Integration is the product.
See how 3AM Mint implements this →
Frequently asked questions
Can a certificate authority genuinely run inside our own AWS account?
Yes, provided the CA private key is a KMS key under your key policy, the signing compute is deployed from your pipeline, and the AIA and CRL URLs resolve to your domain. If the vendor holds the key or hosts the revocation endpoints, the CA is hosted regardless of where the code executes.
Does the vendor ever hold our CA private key?
With an in-account KMS design, no. The key is created in your account and KMS exposes no operation that returns private key material. The CA calls Sign; every call is recorded in your CloudTrail. Access can be withdrawn by editing the key policy, without vendor involvement.
What happens to our certificates if we stop using the vendor?
Nothing, if the architecture is right. The key remains in your KMS, the CRL and OCSP endpoints remain on your domain, and the certificate inventory remains in your CMDB. Certificates issued before the relationship ended continue to validate for their full lifetime.
Is AWS Private CA the same as running a CA in your own account?
Both keep the key in your account. They differ in what else you control: AWS Private CA supplies the policy and template model, priced per CA and per certificate, whereas a KMS-backed stateless CA places authorisation outside the CA in systems you already run. The comparison is a cost and control trade-off, not a security one.
Why would a CA deliberately have no policy engine?
Because a policy engine has to know about your organisation, and anything that knows about your organisation needs synchronised state, credentials and an upgrade cadence. Moving authorisation out of the CA is what reduces the deployed footprint enough to run it inside a customer account.
How is disaster recovery handled for a stateless CA?
By redeployment rather than restoration. The service holds no long-lived data, so recovery means re-running Infrastructure as Code against the existing KMS key and S3 bucket. There is no snapshot to maintain and no vendor-held state to recover.
Private CA Platform Comparison — 3AM Mint (the product this design became) — AWS Private CA (the other in-account custody model) — Vault PKI root of trust (key custody, OSS starting point) — step-ca alternatives (where key custody forces the exit) — EJBCA alternatives (where self-hosted state forces the exit).
Establishing where your estate sits today: PKI assessment guidelines. Contact AxelSpire or Ask Axel to walk through this against your own account architecture.
Written by Dan Cvrcek, founder of AxelSpire. Dan led enterprise PKI programmes at major financial institutions and telecoms operators, held a post-doctoral research position at the University of Cambridge, and has presented at Black Hat and DEF CON. He authored the high-level design referenced throughout this page.
Disclosure: AxelSpire builds 3AM Mint, one of the products discussed above. Comparison entries were selected on the basis of deployment model — SaaS, managed cloud, self-hosted, and in-account — rather than market share, and cover the four architectures a private CA can realistically take. Product claims about third-party software reflect their default configurations at the date of last review; corrections are welcome.