# What is AWS Private CA?
AWS Private CA enables creation of private certificate authority (CA) hierarchies, including root and subordinate CAs, without the investment and maintenance costs of operating an on-premises CA. Your private CAs can issue end-entity X.509 certificates useful in scenarios including:
+ Creating encrypted TLS communication channels
+ Authenticating users, computers, API endpoints, and IoT devices
+ Cryptographically signing code
+ Implementing Online Certificate Status Protocol (OCSP) for obtaining certificate revocation status
AWS Private CA operations can be accessed from the AWS Management Console, using the AWS Private CA API, or using the AWS CLI.
**Topics**
+ [
## Regional availability for AWS Private Certificate Authority
](#PcaRegions)
+ [
## Services integrated with AWS Private Certificate Authority
](#PcaIntegratedServices)
+ [
## Supported cryptographic algorithms in AWS Private Certificate Authority
](#supported-algorithms)
+ [
## RFC 5280 compliance in AWS Private Certificate Authority
](#RFC-compliance)
+ [
## Pricing for AWS Private Certificate Authority
](#PcaPricing)
+ [
# Terms and concepts for AWS Private CA
](PcaTerms.md)
## Regional availability for AWS Private Certificate Authority
Like most AWS resources, private certificate authorities (CAs) are Regional resources. To use private CAs in more than one Region, you must create your CAs in those Regions. You cannot copy private CAs between Regions. Visit [AWS Regions and Endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#pca_region) in the *AWS General Reference* or the [AWS Region Table](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) to see the Regional availability for AWS Private CA.
**Note**
ACM is currently available in some regions that AWS Private CA is not.
## Services integrated with AWS Private Certificate Authority
If you use AWS Certificate Manager to request a private certificate, you can associate that certificate with any service that is integrated with ACM. This applies both to certificates chained to a AWS Private CA root and to certificates chained to an external root. For more information, see [Integrated Services](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) in the AWS Certificate Manager User Guide.
You can also integrate private CAs into Amazon Elastic Kubernetes Service to provide certificate issuance inside a Kubernetes cluster. For more information, see [Secure Kubernetes with AWS Private Certificate Authority](PcaKubernetes.md).
**Note**
Amazon Elastic Kubernetes Service is not an ACM integrated service.
If you use the AWS Private CA API or AWS CLI to issue a certificate or to export a private certificate from ACM, you can install the certificate anywhere you want.
## Supported cryptographic algorithms in AWS Private Certificate Authority
AWS Private CA supports the following cryptographic algorithms for private key generation and certificate signing.
**Supported algorithm**
| Private key algorithms | Signing algorithms |
| --- | --- |
| ML\$1DSA\$144 ML\$1DSA\$165 ML\$1DSA\$187 RSA\$12048 RSA\$13072 RSA\$14096 EC\$1prime256v1 EC\$1secp384r1 EC\$1secp521r1 SM2 (China Regions only) | ML\$1DSA\$144ML\$1DSA\$165ML\$1DSA\$187 SHA256WITHRSASHA384WITHRSASHA512WITHRSASHA256WITHECDSA SHA384WITHECDSASHA512WITHECDSASM3WITHSM2 |
This list applies only to certificates issued directly by AWS Private CA through its console, API, or command line. When AWS Certificate Manager issues certificates using a CA from AWS Private CA, it supports some but not all of these algorithms. For more information, see [Request a Private Certificate](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html) in the AWS Certificate Manager User Guide.
**Note**
For RSA or ECDSA, the specified signing algorithm family must match the key algorithm family of the CA's private key.
For ML-DSA, the hash function is defined as part of the algorithm itself. There is no option to select a different hash function with ML-DSA. To maintain backward compatibility with the APIs, the same value is used for key algorithm and signing algorithm.
## RFC 5280 compliance in AWS Private Certificate Authority
AWS Private CA does not enforce certain constraints defined in [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280). The reverse situation is also true: Certain additional constraints appropriate to a private CA are enforced.
**Enforced**
+ [Not After date](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5). In conformity with [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280), AWS Private CA prevents the issuance of certificates bearing a `Not After` date later than the `Not After` date of the issuing CA's certificate.
+ [Basic constraints](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9). AWS Private CA enforces basic constraints and path length in imported CA certificates.
Basic constraints indicate whether or not the resource identified by the certificate is a CA and can issue certificates. CA certificates imported to AWS Private CA must include the basic constraints extension, and the extension must be marked `critical`. In addition to the `critical` flag, `CA=true` must be set. AWS Private CA enforces basic constraints by failing with a validation exception for the following reasons:
+ The extension is not included in the CA certificate.
+ The extension is not marked `critical`.
Path length ([pathLenConstraint](PcaTerms.md#terms-pathlength)) determines how many subordinate CAs may exist downstream from the imported CA certificate. AWS Private CA enforces path length by failing with a validation exception for the following reasons:
+ Importing a CA certificate would violate the path length constraint in the CA certificate or in any CA certificate in the chain.
+ Issuing a certificate would violate a path length constraint.
+ [Name constraints](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10) indicate a name space within which all subject names in subsequent certificates in a certification path must be located. Restrictions apply to the subject distinguished name and subject alternative names.
**Not enforced**
+ [Certificate policies](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4). Certificate policies regulate the conditions under which a CA issue certificates.
+ [Inhibit anyPolicy](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.14). Used in certificates issued to CAs.
+ [Issuer Alternative Name](https://datatracker.ietf.org/doc/html/rfc5280#section-section-4.2.1.7). Allows additional identities to be associated with the issuer of the CA certificate.
+ [Policy Constraints](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.11). These constraints limit a CA's capacity to issue subordinate CA certificates.
+ [Policy Mappings](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.5). Used in CA certificates. Lists one or more pairs of OIDs; each pair includes an issuerDomainPolicy and a subjectDomainPolicy.
+ [Subject Directory Attributes](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.8). Used to convey identification attributes of the subject.
+ [Subject Information Access](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.2.2). How to access information and services for the subject of the certificate in which the extension appears.
+ [Subject Key Identifier (SKI)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.2) and [Authority Key Identifier (AKI)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1). The RFC requires a CA certificate to contain the SKI extension. Certificates issued by the CA must contain an AKI extension matching the CA certificate's SKI. AWS does not enforce these requirements. If your CA Certificate does not contain an SKI, the issued end-entity or subordinate CA certificate AKI will be the SHA-1 hash of the issuer public key instead.
+ [SubjectPublicKeyInfo](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1) and [Subject Alternative Name (SAN)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6). When issuing a certificate, AWS Private CA copies the SubjectPublicKeyInfo and SAN extensions from the provided CSR without performing validation.
## Pricing for AWS Private Certificate Authority
Your account is charged a monthly price for each private CA starting from the time that you create it. You are also charged for each certificate that you issue. This charge includes certificates that you export from ACM and certificates that you create from the AWS Private CA API or AWS Private CA CLI. You are not charged for a private CA after it has been deleted. However, if you restore a private CA, you are charged for the time between deletion and restoration. Private certificates whose private key you cannot access are free. These include certificates that are used with [Integrated Services](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) such as Elastic Load Balancing, CloudFront, and API Gateway.
For the latest AWS Private CA pricing information, see [AWS Private Certificate Authority Pricing](https://aws.amazon.com/private-ca/pricing/). You can also use the [AWS pricing calculator](https://calculator.aws/#/createCalculator/certificateManager) to estimate costs.
# Terms and concepts for AWS Private CA
The following terms and concepts can help you as you work with AWS Private Certificate Authority.
**Topics**
+ [
## Trust
](#terms-trust)
+ [
## TLS server certificates
](#terms-tlscert)
+ [
## Certificate signature
](#terms-signing)
+ [
## Certificate authority
](#terms-ca)
+ [
## Root CA
](#terms-rootca)
+ [
## CA certificate
](#terms-ca-cert)
+ [
## Root CA certificate
](#terms-root)
+ [
## End-entity certificate
](#terms-endentity)
+ [
## Self-signed certificates
](#terms-selfsignedcert)
+ [
## Private certificate
](#terms-pca-cert)
+ [
## Certificate path
](#terms-certpath)
+ [
## Path length constraint
](#terms-pathlength)
## Trust
In order for a web browser to trust the identity of a website, the browser must be able to verify the website's certificate. Browsers, however, trust only a small number of certificates known as CA root certificates. A trusted third party, known as a certificate authority (CA), validates the identity of the website and issues a signed digital certificate to the website's operator. The browser can then check the digital signature to validate the identity of the website. If validation is successful, the browser displays a lock icon in the address bar.
## TLS server certificates
HTTPS transactions require server certificates to authenticate a server. A server certificate is an X.509 v3 data structure that binds the public key in the certificate to the subject of the certificate. A TLS certificate is signed by a certificate authority (CA). It contains the name of the server, the validity period, the public key, the signature algorithm, and more.
## Certificate signature
A digital signature is an encrypted hash over a certificate. A signature is used to affirm the integrity of the certificate data. Your private CA creates a signature by using a cryptographic hash function such as SHA256 over the variable-sized certificate content. This hash function produces an effectively unforgeable fixed-size data string. This string is called a hash. The CA then encrypts the hash value with its private key and concatenates the encrypted hash with the certificate.
## Certificate authority
A certificate authority (CA) issues and if necessary revokes digital certificates. The most common type of certificate is based on the ISO X.509 standard. An X.509 certificate affirms the identity of the certificate subject and binds that identity to a public key. The subject can be a user, an application, a computer, or other device. The CA signs a certificate by hashing the contents and then encrypting the hash with the private key related to the public key in the certificate. A client application such as a web browser that needs to affirm the identity of a subject uses the public key to decrypt the certificate signature. It then hashes the certificate contents and compares the hashed value to the decrypted signature to determine whether they match. For information about certificate signing, see [Certificate signature](#terms-signing).
You can use AWS Private CA to create a private CA and use the private CA to issue certificates. Your private CA issues only private SSL/TLS certificates for use within your organization. For more information, see [Private certificate](#terms-pca-cert). Your private CA also requires a certificate before you can use it. For more information, see [CA certificate](#terms-ca-cert).
## Root CA
A cryptographic building block and root of trust upon which certificates can be issued. It comprises a private key for signing (issuing) certificates and a root certificate that identifies 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 that they trust. Administrators update or build the trust stores into the operating systems, instances, and host machine images of entities in their environment. When resources attempt to connect with one another, they check the certificates that each entity presents. A client checks the certificates for validity and whether a chain exists from the certificate to a root certificate installed in the trust store. If those conditions are met, a “handshake" is accomplished between the resources. This handshake cryptographically proves the identity of each entity to the other and creates an encrypted communication channel (TLS/SSL) between them.
## CA certificate
A certificate authority (CA) certificate affirms the identity of the CA and binds it to the public key that is contained in the certificate.
You can use AWS Private CA to create a private root CA or a private subordinate CA, each backed by a CA certificate. Subordinate CA certificates are signed by another CA certificate higher in a chain of trust. But in the case of a root CA, the certificate is self-signed. You can also establish an external root authority (hosted on premises, for example). You can then use your root authority to sign a subordinate root CA certificate hosted by AWS Private CA.
The following example shows the typical fields contained in an AWS Private CA X.509 CA certificate. Note that for a CA certificate, the `CA:` value in the `Basic Constraints` field is set to `TRUE`.
```
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4121 (0x1019)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Seattle, O=Example Company Root CA, OU=Corp, CN=www.example.com/emailAddress=corp@www.example.com
Validity
Not Before: Feb 26 20:27:56 2018 GMT
Not After : Feb 24 20:27:56 2028 GMT
Subject: C=US, ST=WA, L=Seattle, O=Examples Company Subordinate CA, OU=Corporate Office, CN=www.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c0: ... a3:4a:51
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
F8:84:EE:37:21:F2:5E:0B:6C:40:C2:9D:C6:FE:7E:49:53:67:34:D9
X509v3 Authority Key Identifier:
keyid:0D:CE:76:F2:E3:3B:93:2D:36:05:41:41:16:36:C8:82:BC:CB:F8:A0
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Digital Signature, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
6:bb:94: ... 80:d8
```
## Root CA certificate
A certificate authority (CA) typically exists within a hierarchical structure that contains multiple other CAs with clearly defined parent–child relationships between them. Child or subordinate CAs are certified by their parent CAs, creating a certificate chain. The CA at the top of the hierarchy is referred to as the root CA, and its certificate is called the root certificate. This certificate is typically self-signed.
## End-entity certificate
An end-entity certificate identifies a resource, such as a server, instance, container or device. Unlike CA certificates, end-entity certificates cannot be used to issue certificates. Other common terms for end-entity certificate are "client" or "leaf" certificate.
## Self-signed certificates
A certificate signed by the issuer instead of a higher CA. Unlike certificates issued from a secure root maintained by a CA, self-signed certificates act as their own root, and as a result they have significant limitations: They can be used to provide on the wire encryption but not to verify identity, and they cannot be revoked. They are unacceptable from a security perspective. But organizations use them nonetheless because they are easy to generate, require no expertise or infrastructure, and many applications accept them. There are no controls in place for issuing self-signed certificates. Organizations that use them incur greater risk of outages caused by certificate expirations because they have no way to track expiration dates.
## Private certificate
AWS Private CA certificates are private SSL/TLS certificates that you can use within your organization, but are untrusted on the public internet. Use them to identify resources such as clients, servers, applications, services, devices, and users. When establishing a secure encrypted communications channel, each resource uses a certificate like the following as well as cryptographic techniques to prove its identity to another resource. 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. By default, private certificates are not publicly trusted. An internal administrator must explicitly configure applications to trust private certificates and distribute the certificates.
```
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
e8:cb:d2:be:db:12:23:29:f9:77:06:bc:fe:c9:90:f8
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=WA, L=Seattle, O=Example Company CA, OU=Corporate, CN=www.example.com
Validity
Not Before: Feb 26 18:39:57 2018 GMT
Not After : Feb 26 19:39:57 2019 GMT
Subject: C=US, ST=Washington, L=Seattle, O=Example Company, OU=Sales, CN=www.example.com/emailAddress=sales@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00...c7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Authority Key Identifier:
keyid:AA:6E:C1:8A:EC:2F:8F:21:BC:BE:80:3D:C5:65:93:79:99:E7:71:65
X509v3 Subject Key Identifier:
C6:6B:3C:6F:0A:49:9E:CC:4B:80:B2:8A:AB:81:22:AB:89:A8:DA:19
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://NA/crl/12345678-1234-1234-1234-123456789012.crl
Signature Algorithm: sha256WithRSAEncryption
58:32:...:53
```
## Certificate path
A client that relies on a certificate validates that a path exists from the end-entity certificate, possibly through a chain of intermediate certificates, to a trusted root. The client checks that each certificate along the path is valid (not revoked). It also checks that the end-entity certificate has not expired, has integrity (has not been tampered with or modified), and that constraints in the certificate are enforced.
## Path length constraint
The basic constraints *pathLenConstraint* for a CA certificate sets the number of subordinate CA certificates that may exist in the chain below it. For example, a CA certificate with a path length constraint of zero cannot have any subordinate CAs. A CA with a path length constraint of one may have up to one level of subordinate CAs underneath it. [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9) defines this as, “the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path." The path length value excludes the end-entity certificate, though informal language about the "length" or "depth" of a validation chain may include it...leading to confusion.