AWS acm documentation change
Summary
Restructured and expanded documentation on ACM certificate characteristics, including HTTP validation, CA hierarchy, domain validation, revocation firewall rules, key algorithms, managed certificates, and limitations. Added details on CloudFront-managed certificates, HTTP validation workflow, and security considerations for key sizes and validation methods.
Security assessment
The changes enhance documentation of security-related features like domain validation methods (HTTP/DNS), certificate revocation mechanisms (OCSP/CRL firewall rules), and cryptographic best practices (ECDSA vs. RSA key strengths). While these updates clarify security controls and configurations, there is no explicit evidence of addressing a specific vulnerability or incident. The additions improve awareness of security practices but do not directly patch a security flaw.
Diff
diff --git a/acm/latest/userguide/acm-certificate-characteristics.md b/acm/latest/userguide/acm-certificate-characteristics.md index e440d839d..d880036e1 100644 --- a//acm/latest/userguide/acm-certificate-characteristics.md +++ b//acm/latest/userguide/acm-certificate-characteristics.md @@ -5,2 +4,0 @@ -Limitations - @@ -9 +7,29 @@ Limitations -Public certificates provided by ACM have the characteristics and limitations described on this page. These characteristics apply only to certificates provided by ACM. They might not apply to [ imported certificates](./import-certificate.html). +Public certificates provided by ACM have the following characteristics and limitations. These apply only to certificates provided by ACM. They might not apply to [imported certificates](./import-certificate.html). + +** + +Browser and application trust** + + +ACM certificates are trusted by all major browsers including Google Chrome, Microsoft Edge, Mozilla Firefox, and Apple Safari. Browsers display a lock icon when connected by TLS to sites using ACM certificates. Java also trusts ACM certificates. + +** + +Certificate authority and hierarchy** + + +Public certificates requested through ACM come from [Amazon Trust Services](https://www.amazontrust.com/repository/), an Amazon-managed public [certificate authority (CA)](https://docs.aws.amazon.com/acm/latest/userguide/acm-concepts.html#concept-ca). Amazon Root CAs 1 to 4 are cross-signed by Starfield G2 Root Certificate Authority – G2. Starfield root is trusted on Android (later Gingerbread versions) and iOS (version 4.1+). Amazon roots are trusted by iOS 11+. Browsers, applications, or OSes including Amazon or Starfield roots will trust ACM public certificates. + +ACM issues leaf or end-entity certificates to customers through intermediate CAs, randomly assigned based on the certificate type (RSA or ECDSA). ACM doesn't provide intermediate CA information due to this random selection. + +** + +Domain Validation (DV)** + + +ACM certificates are domain validated, identifying only a domain name. When requesting an ACM certificate, you must prove ownership or control of all specified domains. You can validate ownership using email or DNS. For more information, see [AWS Certificate Manager email validation](./email-validation.html) and [AWS Certificate Manager DNS validation](./dns-validation.html). + +** + +HTTP validation** + @@ -11 +37 @@ Public certificates provided by ACM have the characteristics and limitations des -**Browser and application trust** +ACM supports HTTP validation for domain ownership verification when issuing public TLS certificates for use with CloudFront. This method uses HTTP redirects to prove domain ownership and offers automatic renewal similar to DNS validation. HTTP validation is currently only available through the CloudFront Distribution Tenants feature. @@ -12,0 +39 @@ Public certificates provided by ACM have the characteristics and limitations des +** @@ -14 +41 @@ Public certificates provided by ACM have the characteristics and limitations des -ACM certificates are trusted by all major browsers including Google Chrome, Microsoft Internet Explorer and Microsoft Edge, Mozilla Firefox, and Apple Safari. Browsers that trust ACM certificates display a lock icon in their status bar or address bar when connected by SSL/TLS to sites that use ACM certificates. ACM certificates are also trusted by Java. +HTTP redirect** @@ -16 +42,0 @@ ACM certificates are trusted by all major browsers including Google Chrome, Micr -**Certificate authority and hierarchy** @@ -17,0 +44 @@ ACM certificates are trusted by all major browsers including Google Chrome, Micr +For HTTP validation, ACM provides a `RedirectFrom` URL and a `RedirectTo` URL. You must set up a redirect from `RedirectFrom` to `RedirectTo` to demonstrate domain control. The `RedirectFrom` URL includes the validated domain, while `RedirectTo` points to an ACM-controlled location in the CloudFront infrastructure containing a unique validation token. @@ -19 +46 @@ ACM certificates are trusted by all major browsers including Google Chrome, Micr -Public certificates that you request through ACM are obtained from [Amazon Trust Services](https://www.amazontrust.com/repository/), an Amazon managed public [certificate authority (CA)](https://docs.aws.amazon.com/acm/latest/userguide/acm-concepts.html#concept-ca). Amazon Root CAs 1 to 4 are cross-signed by an older root named Starfield G2 Root Certificate Authority - G2. The Starfield root is trusted on Android devices starting with later versions of Gingerbread, and by iOS starting at version 4.1. Amazon roots are trusted by iOS starting at version 11. Any browser, application, or OS that includes the Amazon or Starfield roots will trust public certificates obtained from ACM. +** @@ -21 +48 @@ Public certificates that you request through ACM are obtained from [Amazon Trust -The _leaf_ or _end-entity_ certificates that ACM issues to customers derive their authority from an Amazon Trust Services root CA through any of several intermediate CAs. ACM randomly assigns an intermediate CA based on the type of certificate (RSA or ECDSA) requested. Because the intermediate CA is randomly selected after the request is generated, ACM does not provide intermediate CA information. +Managed by** @@ -23 +49,0 @@ The _leaf_ or _end-entity_ certificates that ACM issues to customers derive thei -**Domain Validation (DV)** @@ -24,0 +51 @@ The _leaf_ or _end-entity_ certificates that ACM issues to customers derive thei +Certificates in ACM managed by another service show that service's identity in the `ManagedBy` field. For certificates using HTTP validation with CloudFront, this field displays "CLOUDFRONT". These certificates can only be used through CloudFront. The `ManagedBy` field appears in the **DescribeCertificate** and **ListCertificates** APIs, and on the certificates inventory and details pages in the ACM console. @@ -26 +53 @@ The _leaf_ or _end-entity_ certificates that ACM issues to customers derive thei -ACM certificates are domain validated. That is, the subject field of an ACM certificate identifies a domain name and nothing more. When you request an ACM certificate, you must validate that you own or control all of the domains that you specify in your request. You can validate ownership by using email or DNS. For more information, see [AWS Certificate Manager email validation](./email-validation.html) and [AWS Certificate Manager DNS validation](./dns-validation.html). +The `ManagedBy` field is mutually exclusive with the "Can be used with" attribute. For CloudFront-managed certificates, you can't add new usages through other AWS services. You can only use these certificates with more resources through the CloudFront API. @@ -28 +55 @@ ACM certificates are domain validated. That is, the subject field of an ACM cert -**Intermediate and root CA rotation** +** @@ -29,0 +57 @@ ACM certificates are domain validated. That is, the subject field of an ACM cert +Intermediate and root CA rotation** @@ -31 +58,0 @@ ACM certificates are domain validated. That is, the subject field of an ACM cert -To maintain a resilient and agile certificate infrastructure, Amazon may at any time choose to discontinue an intermediate CA without advance notice. Changes of this kind have no impact on customers. For more information, see the blog post, ["Amazon introduces dynamic intermediate certificate authorities](https://aws.amazon.com/blogs/security/amazon-introduces-dynamic-intermediate-certificate-authorities/)." @@ -33 +60 @@ To maintain a resilient and agile certificate infrastructure, Amazon may at any -In the unlikely event that Amazon discontinues a root CA, the change will occur as promptly as circumstances require. Because of the large impact of such a change, Amazon will use every mechanism available to notify AWS customers, including the AWS Health Dashboard, email to account owners, and outreach to technical account managers. +Amazon may discontinue an intermediate CA without notice to maintain a resilient certificate infrastructure. These changes don't impact customers. For more information, see ["Amazon introduces dynamic intermediate certificate authorities"](https://aws.amazon.com/blogs/security/amazon-introduces-dynamic-intermediate-certificate-authorities/). @@ -35 +62 @@ In the unlikely event that Amazon discontinues a root CA, the change will occur -**Firewall access for revocation** +If Amazon discontinues a root CA, the change will occur as quickly as needed. Amazon will use all available methods to notify AWS customers, including the AWS Health Dashboard, email, and outreach to technical account managers. @@ -36,0 +64 @@ In the unlikely event that Amazon discontinues a root CA, the change will occur +** @@ -38 +66 @@ In the unlikely event that Amazon discontinues a root CA, the change will occur -If an end-entity certificate is no longer trustworthy, it will be revoked. OCSP and CRLs are the standard mechanisms used to verify whether or not a certificate has been revoked. OCSP and CRLs are the standard mechanisms used to publish revocation information. Some customer firewalls may need additional rules to permit these mechanisms to function. +Firewall access for revocation** @@ -40 +68,4 @@ If an end-entity certificate is no longer trustworthy, it will be revoked. OCSP -The following example URL wildcard patterns can be used to identify revocation traffic. An asterisk (*) wildcard represents one or more alphanumeric characters, a question mark (?) represents a single alphanumeric character, and a hash mark (#) represents a numeral. + +Revoked end-entity certificates use OCSP and CRLs to verify and publish revocation information. Some customer firewalls may need additional rules to allow these mechanisms. + +Use these URL wildcard patterns to identify revocation traffic: @@ -56,0 +88,2 @@ The following example URL wildcard patterns can be used to identify revocation t +An asterisk (*) represents one or more alphanumeric characters, a question mark (?) represents a single alphanumeric character, and a hash mark (#) represents a numeral. + @@ -62,5 +95 @@ Key algorithms** -A certificate must specify an algorithm and key size. Currently, the following RSA and Elliptic Curve Digital Signature Algorithm (ECDSA) public key algorithms are supported by ACM. ACM can request the issue of new certificates using algorithms marked by an asterisk (*). The remaining algorithms are supported only for [imported](./import-certificate.html) certificates. - -###### Note - -When you request a private PKI certificate signed by a CA from AWS Private CA, the specified signing algorithm family (RSA or ECDSA) must match the algorithm family of the CA's secret key. +Certificates must specify an algorithm and key size. ACM supports these RSA and ECDSA public key algorithms: @@ -85 +114,7 @@ When you request a private PKI certificate signed by a CA from AWS Private CA, t -ECDSA keys are smaller, offering security comparable to RSA keys but with greater computing efficiency. However, ECDSA is not supported by all network clients. The following table, adapted from [NIST](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), shows representative security strength of RSA and ECDSA with keys of various sizes. All values are in bits. +ACM can request new certificates using algorithms marked with an asterisk (*). Other algorithms are for [imported](./import-certificate.html) certificates only. + +###### Note + +For private PKI certificates signed by a AWS Private CA CA, the signing algorithm family (RSA or ECDSA) must match the CA's secret key algorithm family. + +ECDSA keys are smaller and more computationally efficient than RSA keys of comparable security, but not all network clients support ECDSA. This table, adapted from [NIST](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf), compares RSA and ECDSA key sizes (in bits) for equivalent security strengths: @@ -93 +128 @@ Comparing security for algorithms and keys Security strength | RSA key size | -Security strength, understood as a power of 2, is related to the number of guesses required to break the encryption. For example, both a 3072-bit RSA key and a 256-bit ECDSA key can be retrieved with no more than 2128 guesses. +Security strength, as a power of 2, relates to the number of guesses needed to break the encryption. For example, both a 3072-bit RSA key and a 256-bit ECDSA key can be retrieved with no more than 2128 guesses. @@ -95 +130 @@ Security strength, understood as a power of 2, is related to the number of guess -For information to help you choose an algorithm, see the AWS blog post [How to evaluate and use ECDSA certificates in AWS Certificate Manager](https://aws.amazon.com/blogs/security/how-to-evaluate-and-use-ecdsa-certificates-in-aws-certificate-manager/). +For help choosing an algorithm, see the AWS blog post [How to evaluate and use ECDSA certificates in AWS Certificate Manager](https://aws.amazon.com/blogs/security/how-to-evaluate-and-use-ecdsa-certificates-in-aws-certificate-manager/). @@ -99 +134 @@ For information to help you choose an algorithm, see the AWS blog post [How to e -Note that [integrated services](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) allow only algorithms and key sizes they support to be associated with their resources. Further, their support differs depending on whether the certificate is imported into IAM or into ACM. For more information, see the documentation for each service. +[Integrated services](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) allow only supported algorithms and key sizes for their resources. Support varies based on whether the certificate is imported into IAM or ACM. For details, see each service's documentation: @@ -103 +138 @@ Note that [integrated services](https://docs.aws.amazon.com/acm/latest/userguide - * For CloudFront, see [ Supported SSL/TLS Protocols and Ciphers](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers). + * For CloudFront, see [Supported SSL/TLS Protocols and Ciphers](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html). @@ -108 +143,3 @@ Note that [integrated services](https://docs.aws.amazon.com/acm/latest/userguide -**Managed Renewal and Deployment** +** + +Managed Renewal and Deployment** @@ -111 +148 @@ Note that [integrated services](https://docs.aws.amazon.com/acm/latest/userguide -ACM manages the process of renewing ACM certificates and provisioning the certificates after they are renewed. Automatic renewal can help you avoid downtime due to incorrectly configured, revoked, or expired certificates. For more information, see [Managed certificate renewal in AWS Certificate Manager](./managed-renewal.html). +ACM manages the renewal and provisioning of ACM certificates. Automatic renewal helps prevent downtime from misconfigured, revoked, or expired certificates. For more information, see [Managed certificate renewal in AWS Certificate Manager](./managed-renewal.html). @@ -113 +150 @@ ACM manages the process of renewing ACM certificates and provisioning the certif -**Multiple Domain Names** +** @@ -114,0 +152 @@ ACM manages the process of renewing ACM certificates and provisioning the certif +Multiple Domain Names** @@ -116 +153,0 @@ ACM manages the process of renewing ACM certificates and provisioning the certif -Each ACM certificate must include at least one fully qualified domain name (FQDN), and you can add additional names if you want. For example, when you are creating an ACM certificate for `www.example.com`, you can also add the name `www.example.net` if customers can reach your site by using either name. This is also true of bare domains (also known as the zone apex or naked domains). That is, you can request an ACM certificate for www.example.com and add the name example.com. For more information, see [AWS Certificate Manager public certificates](./gs-acm-request-public.html). @@ -118 +155 @@ Each ACM certificate must include at least one fully qualified domain name (FQDN -**Punycode** +Each ACM certificate must include at least one fully qualified domain name (FQDN) and can include additional names. For example, a certificate for `www.example.com` can also include `www.example.net`. This applies to bare domains (zone apex or naked domains) too. You can request a certificate for www.example.com and include example.com. For more information, see [AWS Certificate Manager public certificates](./gs-acm-request-public.html). @@ -119,0 +157 @@ Each ACM certificate must include at least one fully qualified domain name (FQDN +** @@ -121 +159,4 @@ Each ACM certificate must include at least one fully qualified domain name (FQDN -The following [Punycode](https://datatracker.ietf.org/doc/html/rfc3492) requirements relating to [Internationalized Domain Names](https://www.icann.org/resources/pages/idn-2012-02-25-en) must be fulfilled: +Punycode** + + +The following [Punycode](https://datatracker.ietf.org/doc/html/rfc3492) requirements for [Internationalized Domain Names](https://www.icann.org/resources/pages/idn-2012-02-25-en) must be met: @@ -139,19 +180 @@ ab--example.com | No | No | ✗ | Must start with "xn--" -**Validity Period** - - -The validity period for ACM certificates is 13 months (395 days). - -**Wildcard Names** - - -ACM allows you to use an asterisk (*) in the domain name to create an ACM certificate containing a wildcard name that can protect several sites in the same domain. For example, `*.example.com` protects `www.example.com` and `images.example.com`. - -###### Note - -When you request a wildcard certificate, the asterisk (`*`) must be in the leftmost position of the domain name and can protect only one subdomain level. For example, `*.example.com` can protect `login.example.com` and `test.example.com`, but it cannot protect `test.login.example.com`. Also note that `*.example.com` protects _only_ the subdomains of `example.com`, it does not protect the bare or apex domain (`example.com`). However, you can request a certificate that protects a bare or apex domain and its subdomains by specifying multiple domain names in your request. For example, you can request a certificate that protects `example.com` and `*.example.com`. - -## Limitations - -The following limitations apply to public certificates. - - * ACM does not provide extended validation (EV) certificates or organization validation (OV) certificates. +** @@ -159 +182 @@ The following limitations apply to public certificates. - * ACM does not provide certificates for anything other than the SSL/TLS protocols. +Validity Period** @@ -161 +183,0 @@ The following limitations apply to public certificates. - * You cannot use ACM certificates for email encryption. @@ -163 +185 @@ The following limitations apply to public certificates. - * ACM does not currently permit you to opt out of [managed certificate renewal](./managed-renewal.html) for ACM certificates. Also, managed renewal is not available for certificates that you import into ACM. +ACM certificates are valid for 13 months (395 days). @@ -165 +187 @@ The following limitations apply to public certificates. - * You cannot request certificates for Amazon-owned domain names such as those ending in amazonaws.com, cloudfront.net, or elasticbeanstalk.com. +** @@ -167 +189 @@ The following limitations apply to public certificates. - * You cannot download the private key for an ACM certificate. +Wildcard Names** @@ -169 +190,0 @@ The following limitations apply to public certificates. - * You cannot directly install ACM certificates on your Amazon Elastic Compute Cloud (Amazon EC2) website or application. You can, however, use your certificate with any integrated service. For more information, see [Services integrated with ACM](./acm-services.html). @@ -171 +192 @@ The following limitations apply to public certificates. - * Unless you choose to opt out, publicly trusted ACM certificates are automatically recorded in at least two certificate transparency databases. You cannot currently use the console to opt out. You must use the AWS CLI or the ACM API. For more information, see [Opting out of certificate transparency logging](./acm-bestpractices.html#best-practices-transparency). For general information about transparency logs, see [Certificate Transparency Logging](./acm-concepts.html#concept-transparency). +ACM allows an asterisk (*) in the domain name to create a wildcard certificate protecting multiple sites in the same domain. For example, `*.example.com` protects `www.example.com` and `images.example.com`. @@ -172,0 +194 @@ The following limitations apply to public certificates. +In a wildcard certificate, the asterisk (`*`) must be leftmost in the domain name and protects only one subdomain level. For instance, `*.example.com` protects `login.example.com` and `test.example.com`, but not `test.login.example.com`. Also, `*.example.com` protects _only_ subdomains, not the bare or apex domain (`example.com`). You can request a certificate for both a bare domain and its subdomains by specifying multiple domain names, such as `example.com` and `*.example.com`. @@ -173,0 +196 @@ The following limitations apply to public certificates. +###### Important @@ -174,0 +198 @@ The following limitations apply to public certificates. +If you use CloudFront, note that HTTP validation does not support wildcard certificates. For wildcard certificates, you must use either DNS validation or email validation. We recommend DNS validation because it supports automatic certificate renewal.