Implementing AWS Private CA for internal certificate issuance

Australian IT teams need trusted identities for internal APIs, service-to-service traffic, VMware appliances and administration portals without buying a public certificate for every private hostname. AWS Private CA provides managed certificate authorities, issuance APIs, protected signing keys and revocation options within each AWS Region.

A sound design starts with a corporate trust hierarchy rather than the first API call. Keep the root offline, use regional subordinate CAs for workloads, and treat certificate distribution, renewal and revocation as an operational service for hybrid teams in Sydney, Melbourne, Brisbane and beyond.

Design a regional certificate authority hierarchy

Use a two-tier hierarchy in which an offline root CA signs one or more subordinate CAs created in AWS Private CA. The root private key remains in a controlled offline environment, while workload CAs use KMS-protected keys and AWS identity controls. Distribute the public root certificate as the organisation-wide trust anchor and retain an encrypted, access-controlled recovery copy.

AWS Private CA is regional. Organisations operating in the Sydney Region, ap-southeast-2, and Melbourne Region, ap-southeast-4, should normally run a subordinate CA in each region. This keeps issuance close to workloads, supports regional data-handling decisions and prevents a regional service disruption from becoming a certificate outage. Both CAs can chain to the same corporate root if their certificates and revocation information are managed consistently.

Prepare identity, keys and compliance controls

Place certificate authorities in a dedicated security account or restricted network segment. Access should use IAM roles and short-lived credentials rather than shared administrator keys. Grant operators permission to issue and retrieve certificates, while separating permission to import a CA, create CRLs or delete a CA. CloudTrail records AWS Private CA API activity and should feed the same SIEM used for other privileged cloud operations.

Select algorithms and lifetimes according to the organisation’s cryptography policy. AWS Private CA supports RSA and ECC signing options, including RSA-2048, RSA-4096, NIST P-256 and NIST P-384. Root CAs can have longer lifetimes than leaf certificates, but leaf validity should remain short enough to limit exposure after a private-key compromise. Use certificate templates to standardise subject fields, subject alternative names, key usage and extended key usage.

Issuance records can contain service names, identifiers and internal network information. For Australian entities subject to the Privacy Act 1988 and the Australian Privacy Principles, treat those records as operational data with defined access, retention and deletion controls. The design should also support relevant ASD guidance, including the Essential Eight and Information Security Manual, without claiming that PKI alone establishes compliance.

Create the subordinate CA and issue certificates

Generate a subordinate certificate signing request using an approved offline CA process or an AWS KMS key pair. Have the offline root sign the CSR, then provide the signed certificate and chain through the AWS Private CA creation or import process. Verify the subject, issuer, basic constraints, path length and key identifiers before activating the CA. A CA that has been created but not activated cannot issue end-entity certificates.

AWS CLI can issue a certificate directly from an active CA:

aws acm-pca issue-certificate \
  --certificate-authority-arn "$CA_ARN" \
  --csr file://service.csr \
  --signing-algorithm SHA256WITHRSA \
  --validity '{"Type":"DAYS","Value":90}' \
  --idempotency-token "$(openssl rand -hex 16)"

The response contains a certificate ARN, which can be passed to get-certificate to retrieve the PEM-encoded certificate. The private key remains with the workload or its KMS key and must never be placed in the CA response or a general-purpose application secret. The CSR must contain the required subject alternative names because the common name alone is insufficient for modern hostname validation.

Build issuance into a controlled pipeline rather than an engineer’s workstation. A small service using Lambda and Step Functions can validate the request, select the regional CA, call the issuance API and place the resulting certificate into ACM, Secrets Manager or the relevant application platform. Renewal should run well before expiry, and the idempotency token should prevent duplicate certificates when a workflow is retried.

Publish revocation information and monitor the PKI

Revocation is as important as issuance. Enable CRL distribution and OCSP, export CRLs into a tightly controlled S3 bucket, and publish them through a monitored HTTPS endpoint. Relying parties need a documented soft-fail or hard-fail policy for unreachable revocation services. Otherwise, a network outage can either block applications unexpectedly or allow revoked certificates to remain usable.

Where clients inside a VPC must reach a hosted revocation endpoint, this guide on enabling VPC internet access explains the relevant NAT and routing approach. Remote workers accessing revocation services over home broadband or mobile connections should receive the same endpoint access as office users, with DNS, proxy and endpoint availability tested across Australian locations.

Monitor issuance volume, failed requests, approaching certificate expiry, CRL age and CA status. Alert on CA creation, import, deletion and unusual administrative actions recorded in CloudTrail. If a subordinate CA or workload key is compromised, revoke the affected certificate, stop the affected issuance path and replace it from a clean CA. Compromise of the offline root requires a new trust hierarchy and coordinated distribution of a replacement trust anchor.

Recommendations for reliable internal certificate operations

Automate issuance profiles for internal APIs, administrator portals, service-to-service identities and common server platforms. Each profile should define allowed name patterns, key usage, extended key usage, lifetime and owning team. Applications should obtain their own certificates through a pipeline using an IAM role, and should never receive standing permission to operate the CA itself.

Trust distribution must cover managed devices without exposing the root private key. Australian organisations that combine Entra ID or Active Directory, VMware estates and outsourced service providers can distribute the root through Group Policy, Intune or another approved device-management platform. Unmanaged personal devices should use a separately brokered access path rather than receiving the corporate root certificate.

A practical operating baseline includes the following controls:

• Keep the root CA private key offline with dual control, encrypted backups and a documented recovery test.
• Use separate subordinate CAs by AWS Region and environment, while maintaining a consistent corporate trust hierarchy.
• Give leaf certificates short lifetimes, automate renewal and alert well before expiry.
• Test certificate trust and revocation from managed Windows, macOS and mobile devices using Sydney, Melbourne and Brisbane network paths.