AWS Private CA FAQs

A CA hierarchy is a structure for organizing CAs to help you control access and distribute management of the CAs across your organization’s teams. A CA hierarchy provides strong security and restrictive access controls for the most-trusted root CA at the top of the trust chain, while allowing more permissive access and bulk certificate issuance for subordinate CAs lower in the chain.

A root CA is a cryptographic building block and root of trust upon which certificates can be issued. It’s composed of a private key for signing certificates and (separately) a root certificate that defines the root CA and binds the private key to the name of the CA. The root certificate is distributed to the trust stores of each entity in an environment. Administrators construct trust stores to include only the CAs they trust, and they update or build the trust stores into the operating systems, instances, and host machine images of entities in their environment. When Resource A attempts to connect with Resource B, it checks the certificate presented by Resource B. If the certificate is valid and a chain of trust can be constructed from the certificate to a root certificate installed in the trust store of Resource A, a cryptographic handshake completes and an encrypted communication channel is established between the resources.

Beneath a root CA in a CA hierarchy are subordinate CAs. A subordinate CA can be configured to directly issue certificates, act as an intermediate CA that signs other subordinate CAs to create an organizational structure, act as an issuing CA to issue end-entity certificates, or act as both an intermediate and issuing CA. Once the root is distributed to trust stores within an organization (refer to “What is a root CA?” for more information), any certificates with an established chain to the root certificate in the trust store will also be trusted. This process is called certificate path validation. A certificate meeting this description is said to chain up to a trusted root.

Root CAs and other CAs near the top of a CA hierarchy typically have restrictive policies controlling certificate issuance and administrative access. These CAs are used infrequently and are tightly controlled and audited, resulting in a lower risk of compromise. Therefore, they are more trusted. Root CAs typically have longer lifetimes than CAs lower in the hierarchy, commensurate with the isolation and control policies governing their use.

AWS Private CA allows you to create a CA hierarchy that is five tiers deep, including a root CA, three levels of subordinate (intermediate) CAs, and one issuing CA. You can also import an on-premises CA to anchor your hierarchy—that is, a CA signed by a root authority outside of AWS Private CA.

No. You can issue end-entity certificates from a root CA; however, in most cases, security best practices call for a CA hierarchy with at least two tiers, including a root CA as the root of trust and a subordinate CA for issuing end-entity certificates.

A short-lived certificate is a certificate that has a validity period of 7 days or less.

Short-lived certificates should be used in cases where a temporary certificate are needed. For example, if you have a short-lived ad-hoc AWS workload that is issued certificates to enable TLS, then short-lived certificates would be a best practice since they will expire quickly and therefore do not need to be revoked. You can also use short-lived certificates when the certificates convey a temporary authorization as well as an identity, for example if a workstation has just recently successfully completed a health check, or the user has administrative privileges.

No, the security of short-lived certificates is based on their frequent re-issuance to reaffirm their health. Frequent re-issuance forces the subject to frequently demonstrate compliance with the certificate policy. This is the same model used by Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) tokens.

For some services such as with Active Directory smart card authentication, the revocation check process is mandatory. AWS Private CA publishes the revocation information such as CRLs and OCSP responses, for integration purposes so that these services can complete the revocation check process.

AWS Identity and Access Management (IAM) Roles Anywhere can be used to obtain temporary security credentials in IAM for workloads such as servers, containers, and applications that run outside of AWS. Your workloads can use the same IAM policies and IAM roles that you use with AWS applications to access AWS resources. Using IAM Roles Anywhere means you don't need to manage long-term credentials for workloads running outside of AWS. To use IAM Roles Anywhere, your workloads must use X.509 certificates issued by your CA. You register the CA with IAM Roles Anywhere as a trust anchor to establish trust between your PKI and IAM Roles Anywhere.

Yes, you establish trust between IAM Roles Anywhere and your CA by creating a trust anchor. A trust anchor is either a reference to AWS Private CA or another CA certificate. Your workloads outside of AWS authenticate with the trust anchor using certificates issued by the trusted CA in exchange for temporary AWS credentials. For more information, see Creating a trust anchor and profile in IAM Roles Anywhere.

Matter is a new smart home automation standard that Amazon helped co-found, managed by the Connectivity Standards Alliance. Matter provides seamless and secure cross-vendor connectivity for smart home devices, like light switches, door locks, media devices, etc. To ensure security and interoperability, Matter enforces device certification and authenticity checks before smart home devices can join a Matter smart home network (also known as fabric) and communicate with other Matter devices.

Matter uses X.509 digital certificates to identify devices and to secure communication between devices. Matter uses two types of device certificates. Device Attestation Certificates (DAC) are provisioned by device makers to identify the device vendor and product type. DACs are validated by Matter fabric administrator devices during device commissioning, which is the process of adding new devices to a Matter fabric. Node Operational Certificates (NOC) are issued by Matter administrators during commissioning and are used by devices for communicating with other Matter devices on the fabric.

Yes, you can use AWS Private CA to issue both DACs and NOCs for use with Matter. To learn more, see Adopting Matter for smart-home systems.

You can use AWS Private CA as a Delegated Service Provider to establish and operate a Product Attestation Authority (PAA) and one or more Product Attestation Intermediates to issue DACs for your Matter products. You can set up your PAA to be non-VID-scoped or VID-scoped depending on if you’re planning to issue DACs for other companies or only for your own. With AWS Private CA, you have the choice to create either type of device attestation CA. You can use the sample AWS Cloud Development Kit (CDK) scripts and AWS CloudFormation stack templates to help you create your device attestation CA. Once you have established the device attestation CA hierarchy in AWS Private CA, you can use the AWS SDKs and CLI, or the Java APIs to issue DACs. 

You can use AWS Private CA to establish and operate device attestation CA hierarchies that, in combination with other controls, can help you meet the requirements of the Matter PKI CP. Use the AWS Matter PKI Compliance Guide to learn about the shared responsibility model between you and AWS and how you can use AWS Private CA with your Matter products.

No, Matter certificates have specific requirements that are often incompatible with other certificate use case.

Please see the AWS Certificate Manager (ACM) FAQs for questions about using ACM.