Cloud-based PKI

Cloud-based PKI is a managed service where a cloud provider operates the Certificate Authority infrastructure — HSMs, key storage, availability, and signing operations — while you define the hierarchy, policies, and certificate templates. Instead of running your own offline Root CA hardware, managing HSM firmware, and staffing key ceremonies, you create a CA via API and start issuing certificates in minutes. The trade-off: you gain operational simplicity but accept vendor dependency for a critical trust anchor.

Why it matters

• No HSM management — cloud providers store CA private keys in FIPS 140-2 Level 3 HSMs. You never touch the hardware, handle firmware updates, or manage physical security.
• Instant availability — creating a new CA takes an API call, not a procurement cycle. Useful for ephemeral environments, per-team CAs, or rapid PKI bootstrapping.
• Built-in redundancy — cloud CAs are multi-AZ by default. No single point of failure for signing operations. On-premises HSMs require expensive HA configurations.
• Pay-per-certificate pricing — no upfront hardware cost, but costs scale with issuance volume. At high volumes (10,000+ certs/month), cloud PKI can be significantly more expensive than self-managed.
• API-native — integrates directly with cloud-native services (EKS, GKE, Lambda, IoT Core) without custom glue code.

How it works

1. Create Root CA — define key algorithm (RSA 2048/4096, ECDSA P-256/P-384), subject, and validity period via API or console
2. Create Subordinate CA — create an intermediate CA signed by the Root. This handles daily issuance.
3. Define templates — specify allowed key usages, extended key usages, validity periods, and SAN patterns
4. Issue certificates — applications request certificates via API (or through integrations like cert-manager, IoT Core, ACM)
5. Distribute trust — install the Root CA certificate in your organization’s trust stores (GPO, MDM, container base images)
6. Monitor and audit — cloud providers log all issuance events (CloudTrail, Cloud Audit Logs) for compliance

In real systems

AWS Private CA:

# Create a Root CA
aws acm-pca create-certificate-authority \
  --certificate-authority-type ROOT \
  --certificate-authority-configuration \
    "KeyAlgorithm=EC_prime256v1,SigningAlgorithm=SHA256WITHECDSA,\
     Subject={CommonName='My Org Root CA',Organization='My Org'}" \
  --tags Key=Environment,Value=production

# Issue a certificate
aws acm-pca issue-certificate \
  --certificate-authority-arn arn:aws:acm-pca:us-east-1:123456789:certificate-authority/abc \
  --csr fileb://server.csr \
  --signing-algorithm SHA256WITHECDSA \
  --validity Value=365,Type=DAYS

Pricing: ~$400/month per CA + $0.75 per certificate issued. At 1,000 certs/month, that’s $1,150/month.

Google Cloud Certificate Authority Service (CAS):

gcloud privateca roots create my-root-ca \
  --pool=my-ca-pool \
  --key-algorithm=ec-p256-sha256 \
  --subject="CN=My Org Root CA, O=My Org" \
  --max-chain-length=1

Integrates natively with GKE via cert-manager and Workload Identity.

Kubernetes cert-manager with AWS Private CA:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: aws-pca-issuer
spec:
  acme: null  # Not ACME — uses AWS PCA plugin
---
apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
  name: aws-pca-issuer
spec:
  arn: arn:aws:acm-pca:us-east-1:123456789:certificate-authority/abc
  region: us-east-1

Where it breaks

Cost explosion at scale — a team starts with AWS Private CA for 50 internal certificates. It works well at $437/month. Then the service mesh rollout requires mTLS for 5,000 microservice instances with 24-hour certificate rotation. Suddenly the bill is $400 (CA) + $3,750/month in issuance fees — and that’s one environment. The fix: use short-lived certificates issued by a local signing agent (like Istio’s citadel or SPIRE) that chains to the cloud CA, rather than hitting the cloud CA API for every pod certificate.

Vendor lock-in on trust anchors — your Root CA lives in AWS Private CA. Its certificate is distributed to 10,000 devices, embedded in partner integrations, and hardcoded in mobile apps. Migrating to Google CAS or on-premises means creating a new Root, re-distributing trust to every device, and re-issuing every certificate. The CA private key cannot be exported from the cloud HSM. Plan for this by using a cross-signed intermediate or keeping your Root CA on-premises with only the Intermediate in the cloud.

Availability dependency — if the cloud CA service has an outage, no new certificates can be issued. Existing certificates continue to work (they’re already deployed), but new deployments, scaling events, and renewals fail. For short-lived certificates (hours), a multi-hour CA outage means services can’t get new certs and start failing. Mitigation: cache certificates with sufficient remaining validity, or maintain a secondary CA in a different region/provider.

Operational insight

The hidden cost of cloud PKI isn’t the per-certificate fee — it’s the architectural coupling. Once your Root CA is in a cloud provider’s HSM, you can’t extract the private key. Your entire trust hierarchy is permanently bound to that provider. The pragmatic approach: keep your Root CA offline and self-managed (even a simple air-gapped machine with an HSM USB token), and use cloud PKI only for Intermediate/Issuing CAs. This preserves portability — you can create new Intermediates in any provider, signed by your portable Root, without re-distributing trust.

Related topics

• What is a Certificate Authority
• Root CA vs Intermediate CA
• Public CA vs Private CA
• PKI Hierarchy Design
• Certificate Automation at Scale