AWS Certificate Manager public certificate characteristics and 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.
- Browser and application trust
-
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.
-
Public certificates that you request through ACM are obtained from Amazon Trust Services
, an Amazon managed public certificate authority (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. 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.
- Domain Validation (DV)
-
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 and AWS Certificate Manager DNS validation.
- Intermediate and root CA rotation
-
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
." 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.
- Firewall access for revocation
-
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.
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.
-
OCSP
http://ocsp.?????.amazontrust.com
http://ocsp.*.amazontrust.com
-
CRL
http://crl.?????.amazontrust.com/?????.crl
http://crl.*.amazontrust.com/*.crl
-
- 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 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.
-
RSA 1024 bit (
RSA_1024
) -
RSA 2048 bit (
RSA_2048
)* -
RSA 3072 bit (
RSA_3072
) -
RSA 4096 bit (
RSA_4096
) -
ECDSA 256 bit (
EC_prime256v1
)* -
ECDSA 384 bit (
EC_secp384r1
)* -
ECDSA 521 bit (
EC_secp521r1
)
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
, shows representative security strength of RSA and ECDSA with keys of various sizes. All values are in bits. Comparing security for algorithms and keysSecurity strength
RSA key size
ECDSA key size
128
3072 256 192
7680 384 256
15360 521 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.
For information to help you choose an algorithm, see the AWS blog post How to evaluate and use ECDSA certificates in AWS Certificate Manager
. Important
Note that integrated services 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.
-
For Elastic Load Balancing, see HTTPS Listeners for Your Application Load Balancer.
-
For CloudFront, see Supported SSL/TLS Protocols and Ciphers.
-
- Managed Renewal and Deployment
-
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.
- Multiple Domain Names
-
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 namewww.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. - Punycode
-
The following Punycode
requirements relating to Internationalized Domain Names must be fulfilled: -
Domain names beginning with the pattern "<character><character>--" must match "xn--".
-
Domain names beginning with "xn--" must also be valid Internationalized Domain Names.
Punycode examplesDomain Name
Fulfills #1
Fulfills #2
Allowed
Note
example.com
n/a
n/a
✓
Does not start with "<character><character>--"
a--example.com
n/a
n/a
✓
Does not start with "<character><character>--"
abc--example.com
n/a
n/a
✓
Does not start with "<character><character>--"
xn--xyz.com
Yes
Yes
✓
Valid Internationalized Domain Name (resolves to 简.com)
xn--example.com
Yes
No
✗
Not a valid Internationalized Domain Name
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
protectswww.example.com
andimages.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 protectlogin.example.com
andtest.example.com
, but it cannot protecttest.login.example.com
. Also note that*.example.com
protects only the subdomains ofexample.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 protectsexample.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.
-
ACM does not provide certificates for anything other than the SSL/TLS protocols.
-
You cannot use ACM certificates for email encryption.
-
ACM does not currently permit you to opt out of managed certificate renewal for ACM certificates. Also, managed renewal is not available for certificates that you import into ACM.
-
You cannot request certificates for Amazon-owned domain names such as those ending in amazonaws.com, cloudfront.net, or elasticbeanstalk.com.
-
You cannot download the private key for an ACM certificate.
-
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.
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. For general information about transparency logs, see Certificate Transparency Logging.