AWS Private CA FAQs

AWS Private Certificate Authority (AWS Private CA) is a highly available, managed service for creating and maintaining an internal public key infrastructure (PKI) for your organization. AWS Private CA removes the upfront investment and ongoing maintenance costs of operating your own private certificate authority (CA) and simplifies lifecycle management of the certificates in your PKI. These certificates may be used to secure communications between networked resources such as servers, mobile and IoT devices, applications, and users. You can easily create and deploy private certificates for your AWS resources using the AWS Management Console. For Amazon Elastic Compute Cloud (EC2) instances, containers, IoT devices, and on-premises resources, you can create and track private certificates and use your own client-side automation code to deploy them. You also have the flexibility to create private certificates for applications that require custom certificate lifetimes, key algorithms, resource names, or other information.

A CA is an organizational and cryptographic entity that handles the issuance, validation, and revocation of digital certificates. Commercially, the most common type of digital certificate is based on the ISO X.509 standard. Certificates signed by a CA affirm the identity of the certificate subject and bind that identity to the public key contained in the certificate.

A CA consists of two components: the CA certificate (a cryptographic building block that allows other certificates to be issued) and a set of runtime services for maintaining revocation information through the Online Certificate Status Protocol (OCSP) or a certificate revocation list (CRL). When resources attempt to connect with one another, they check OCSP or the CRL for the status of the certificate that each entity presents.

A private CA provides the services of a CA exclusively within a private network (in other words, not on the public internet). Private CAs are free of many constraints placed on public CAs. Public CAs must follow strict rules, provide operational visibility, and meet security standards imposed by the browser and operating system vendors that decide which CAs their browsers and operating systems trust automatically. Private CA administrators, on the other hand, can make their own rules for issuing certificates, such as defining what information a certificate must include.

Digital certificates issued by a private CA can be used to secure communications between endpoints within an organization’s private network. When establishing a secure encrypted communications channel, each endpoint uses a certificate to authenticate itself to another endpoint. Internal API endpoints, web servers, VPN users, IoT devices, and many other applications use private certificates to establish encrypted communication channels that are necessary for their secure operation. Private certificates have fewer configuration constraints than publicly trusted certificates and are highly customizable. However, for private certificates to be trusted, an administrator must add the private CA that issued it to the list of trusted CAs in browsers and other network applications.

Private certificates offer flexibility; they allow you to identify nearly anything in your organization without disclosing the name publicly. Wiki.internal, IP address 192.168.1.1, fire-sensor-123, and user123 are examples of identity information that might be used in private certificates. Private certificates can include information prohibited in public certificates, which are strictly limited to identifying resources with public DNS names, such as www.example.com. Some enterprise applications could not function with public certificates since they require extra information that is not allowed in public certificates.

Self-signed certificates are issued without a CA. Unlike certificates issued from a secure root maintained by a CA, self-signed certificates act as their own root. Organizations therefore use them because they’re easy to generate, require no expertise or infrastructure, and are accepted by many applications. However, they have significant limitations. They can be used to provide on-the-wire encryption, but they cannot verify identity—and they cannot be revoked. Furthermore, it can be difficult to track the expiration dates of self-signed certificates, which may lead to outages caused by certificate expirations.

Yes, AWS Private CA has an SLA.

To get started, navigate to AWS Certificate Manager in the AWS Management Console and select AWS Private CA on the left side of the screen. Choose get started to start creating a private CA. To learn more, visit Planning your AWS Private CA deployment in the AWS Private CA User Guide.

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.