ACM certificate characteristics - AWS Certificate Manager

ACM certificate characteristics

Public certificates provided by ACM have the characteristics described on this page.

Note

These characteristics apply only to certificates provided by ACM. They might not apply to certificates that you import into ACM.

Certificate authority and hierarchy

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.

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.

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

    If a CRL partition exists, the additional URL has the following format: http://crl.?????.amazontrust.com/?????p##.crl

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 Email validation and DNS validation.

Validity Period

The validity period for ACM certificates is 13 months (395 days).

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 renewal for ACM certificates.

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 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 Requesting a public certificate.

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.

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 keys

Security strength

RSA key size

ECDSA key size

128

3072 256

192

7680 384

256

15360 512

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.

Punycode

The following Punycode requirements relating to Internationalized Domain Names must be fulfilled:

  1. Domain names beginning with the pattern "<character><character>--" must match "xn--".

  2. Domain names beginning with "xn--" must also be valid Internationalized Domain Names.

Punycode examples

Domain 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--"

Exceptions

Note the following:

  • 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 AWS Certificate Manager.