Public Key Infrastructure

Public Key Infrastructure establishes trust in public keys through digitally signed certificates, usually using the X.509 standard. A certificate associates a public key with an identity and includes information such as its issuer, validity period, and permitted uses. The corresponding private key remains confidential. A certificate is not a secret, and possessing a copy does not enable an attacker to impersonate its owner without the private key.

A certificate authority (CA) signs certificates after the required identity checks and authorization steps. Clients validate a certificate chain from the presented certificate through any intermediate CAs to a root they already trust. Root trust comes from a configured trust store, not simply from a root certificate being self-signed. Production hierarchies often keep the root CA offline and use subordinate CAs for routine issuance, reducing exposure of the most consequential signing key.

During a TLS connection, the client checks the certificate chain, validity dates, intended usage, and expected identity, such as a DNS name in the subject alternative name extension. The server proves possession of the corresponding private key through the TLS protocol. TLS then uses symmetric session keys to protect application traffic; certificates do not directly encrypt all transmitted data. With mutual TLS, both peers authenticate using certificates, but applications still need authorization rules to decide what an authenticated peer may do.

Publicly trusted certificates are appropriate for endpoints accessed by ordinary browsers and other clients using public trust stores. Private certificates support internal services, enterprise devices, and workloads whose clients can be configured to trust an organizational CA. For example, an internal payment API can require client certificates issued by a dedicated subordinate CA. Issuance policy and application authorization should prevent a certificate intended for one workload from granting unrestricted access to unrelated services.

Certificate management includes secure key generation, certificate signing requests, controlled issuance, deployment, renewal, revocation, and eventual retirement. A signing request contains a public key and requested identity information, not the private key. Automating renewal reduces expiration outages, but issuing a replacement certificate is insufficient unless it reaches every endpoint and the service reloads it. Revocation through certificate revocation lists or the Online Certificate Status Protocol also depends on client support and configuration; publishing revocation information does not guarantee that every client checks it. Short-lived certificates reduce the remaining lifetime of compromised credentials but increase reliance on dependable issuance automation.

In AWS, Private Certificate Authority provides managed private CAs, while Certificate Manager handles certificate provisioning and supported deployment and renewal workflows. AWS KMS manages cryptographic keys but is not a CA and does not provide an X.509 certificate issuance lifecycle. KMS asymmetric signing can support custom signing applications, but it does not replace identity validation, certificate policy, or revocation infrastructure. Protect CA signing keys with tightly controlled access and hardware-backed cryptography, and separate certificate-request permissions from CA administration.

Multi-Region design requires separate planning for key availability, certificate deployment, and trust. One approach uses regional subordinate CAs beneath a common organizational root, allowing clients to trust a shared hierarchy while issuance remains regionally distributed. AWS Private CA resources are regional, and creating another CA does not replicate an existing CA's signing key. Likewise, related KMS multi-Region keys share key material but do not replicate certificates, trust stores, or a PKI. Certificates for regional AWS endpoints generally need deployment in the endpoint's Region; CloudFront requires ACM certificates in US East (N. Virginia). Test regional failover, renewal, and revocation access before an outage.

The main trade-off is operational control versus operational responsibility. A private hierarchy gives an organization control over identities and issuance policy, but requires trust-store distribution, monitoring, incident response, and recovery planning. A compromised leaf key usually affects its certificate identity; a compromised CA signing key can undermine every identity within that CA's scope. Minimize that scope through subordinate hierarchies, issuance restrictions, least-privilege administration, and auditable lifecycle operations.