# Architect your solution for AWS Private CA Architect your solution for AWS Private CA AWS Private CA gives you complete, cloud-based control over your organization's private PKI (public key infrastructure), extending from a root certificate authority (CA), through subordinate CAs, to end-entity certificates. Thorough planning is essential for a PKI that is secure, maintainable, extensible, and suited to your organization's needs. This section provides guidance on designing a CA hierarchy, managing your private CA and private end-entity certificate lifecycles, and applying best practices for security. This section describes how to prepare AWS Private CA for use before you create a private certificate authority (CA). It also explains the option to add revocation support through Online Certificate Status Protocol (OCSP) or a certificate revocation list (CRL). In addition, you should determine whether your organization prefers to host its private root CA credentials on premises rather than with AWS. In that case, you need to set up and secure a self-managed private PKI before using AWS Private CA. In this scenario, you then create a subordinate CA in AWS Private CA backed by a parent CA outside of AWS Private CA. For more information, see [Installing a subordinate CA certificate signed by an external parent CA](https://docs.aws.amazon.com/privateca/latest/userguide/PCACertInstall.html#InstallSubordinateExternal). **Topics** + [ # Design a CA hierarchy ](ca-hierarchy.md) + [ # Manage the private CA lifecycle ](ca-lifecycle.md) + [ # Plan your AWS Private CA certificate revocation method ](revocation-setup.md) + [ # Understand AWS Private CA CA modes ](short-lived-certificates.md) + [ # Plan for resilience in AWS Private CA ](disaster-recovery-resilience.md) # Design a CA hierarchy Design a CA hierarchy With AWS Private CA, you can create a hierarchy of certificate authorities with up to five levels. The root CA, at the top of a hierarchy tree, can have any number of branches. The root CA can have as many as four levels of subordinate CAs on each branch. You can also create multiple hierarchies, each with its own root. A well-designed CA hierarchy offers the following benefits: + Granular security controls appropriate to each CA + Division of administrative tasks for better load balancing and security + Use of CAs with limited, revocable trust for daily operations + Validity periods and certificate path limits The following diagram illustrates a simple, three-level CA hierarchy. ![\[Diagram of a simple, three-level CA hierarchy.\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/simple-ca-tree.png) Each CA in the tree is backed by an X.509 v3 certificate with signing authority (symbolized by the pen-and-paper icon). This means that as CAs, they can sign other certificates subordinate to them. When a CA signs a lower-level CA's certificate, it confers limited, revocable authority on the signed certificate. The root CA in level 1 signs high-level subordinate CA certificates in level 2. These CAs, in turn, sign certificates for CAs in level 3 that are used by PKI (public key infrastructure) administrators who manage end-entity certificates. Security in a CA hierarchy should be configured to be strongest at the top of the tree. This arrangement protects the root CA certificate and its private key. The root CA anchors trust for all of the subordinate CAs and the end-entity certificates below it. While localized damage can result from the compromise of an end-entity certificate, compromise of the root destroys trust in the entire PKI. Root and high-level subordinate CAs are used only infrequently (usually to sign other CA certificates). Consequently, they are tightly controlled and audited to ensure a lower risk of compromise. At the lower levels of the hierarchy, security is less restrictive. This approach allows the routine administrative tasks of issuing and revoking end-entity certificates for users, computer hosts, and software services. **Note** Using a root CA to sign a subordinate certificate is a rare event that occurs in only a handful of circumstances: When the PKI is created When a high-level certificate authority needs to be replaced When a certificate revocation list (CRL) or Online Certificate Status Protocol (OCSP) responder needs to be configured Root and other high-level CAs require highly secure operational processes and access-control protocols. **Topics** + [ ## Validate end-entity certificates ](#end-entity-validation) + [ ## Plan the structure of a CA hierarchy ](#ca-layers) + [ ## Set length constraints on the certification path ](#length-constraints) ## Validate end-entity certificates End-entity certificates derive their trust from a certification path leading back through the subordinate CAs to a root CA. When a web browser or other client is presented with an end-entity certificate, it attempts to construct a chain of trust. For example, it may check to see that the certificate's *issuer distinguished name* and *subject distinguished name* match with the corresponding fields of the issuing CA certificate. Matching would continue at each successive level up the hierarchy until the client reaches a trusted root that is contained in its trust store. The trust store is a library of trusted CAs that the browser or operating system contains. For a private PKI, your organization's IT must ensure that each browser or system has previously added the private root CA to its trust store. Otherwise, the certification path cannot be validated, resulting in client errors. The next diagram shows the validation path that a browser follows when presented with an end-entity X.509 certificate. Note that the end-entity certificate lacks signing authority and serves only to authenticate the entity that owns it. ![\[Validation check by a web browser.\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/chain-of-trust.png) The browser inspects the end-entity certificate. The browser finds that the certificate offers a signature from subordinate CA (level 3) as its trust credential. The certificates for the subordinate CAs must be included in the same PEM file. Alternatively, they can also be in a separate file that contains the certificates that make up the trust chain. Upon finding these, the browser checks the certificate of subordinate CA (level 3) and finds that it offers a signature from subordinate CA (level 2). In turn, subordinate CA (level 2) offers a signature from root CA (level 1) as its trust credential. If the browser finds a copy of the private root CA certificate preinstalled in its trust store, it validates the end-entity certificate as trusted. Typically, the browser also checks each certificate against a certificate revocation list (CRL). An expired, revoked, or misconfigured certificate is rejected and validation fails. ## Plan the structure of a CA hierarchy In general, your CA hierarchy should reflect the structure of your organization. Aim for a *path length* (that is, number of CA levels) no greater than necessary to delegate administrative and security roles. Adding a CA to the hierarchy means increasing the number of certificates in the certification path, which increases validation time. Keeping the path length to a minimum also reduces the number of certificates sent from the server to the client when validating an end-entity certificate. In theory, a root CA, which has no [pathLenConstraint](PcaTerms.md#terms-pathlength) parameter, can authorize unlimited levels of subordinate CAs. A subordinate CA can have as many child subordinate CAs as are allowed by its internal configuration. AWS Private CA managed hierarchies support CA certification paths up to five levels deep. Well designed CA structures have several benefits: + Separate administrative controls for different organizational units + The ability to delegate access to subordinate CAs + A hierarchical structure that protects higher-level CAs with additional security controls Two common CA structures accomplish all of this: + **Two CA levels: root CA and subordinate CA** This is the simplest CA structure that allows separate administration, control, and security policies for the root CA and a subordinate CA. You can maintain restrictive controls and policies for your root CA while allowing more permissive access for the subordinate CA. The latter is used for bulk issuance of end-entity certificates. + **Three CA levels: root CA and two layers of subordinate CA** Similar to the above, this structure adds an additional CA layer to further separate the root CA from low-level CA operations. The middle CA layer is only used to sign subordinate CAs that carry out the issuance of end-entity certificates. Less common CA structures include the following: + **Four or more CA levels** Though less common than three-level hierarchies, CA hierarchies with four or more levels are possible and may be required to allow administrative delegation. + **One CA level: root CA only** This structure is commonly used for development and testing when a full chain of trust is not required. Used in production, it is atypical. Moreover, it violates the best practice of maintaining separate security policies for the root CA and the CAs that issue end-entity certificates. However, if you are already issuing certificates directly from a root CA, you can migrate to AWS Private CA. Doing so provides security and control advantages over using a root CA managed with [OpenSSL](https://www.openssl.org/) or other software. ### Example of a private PKI for a manufacturer In this example, a hypothetical technology company manufactures two Internet of Things (IoT) products, a smart light bulb and a smart toaster. During production, each device is issued an end-entity certificate so it can communicate securely over the internet with the manufacturer. The company's PKI also secures its computer infrastructure, including the internal website and various self-hosted computer services that run finance and business operations. Consequently, the CA hierarchy closely models these administrative and operational aspects of the business. ![\[Diagram of a more complex CA hierarchy.\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/multilevel-ca-tree.png) This hierarchy contains three roots, one for Internal Operations and two for External Operations (one root CA for each product line). It also illustrates multiple certification path length, with two levels of CA for Internal Operations and three levels for External Operations. The use of separated root CAs and additional subordinate CA layers on the External Operations side is a design decision serving business and security needs. With multiple CA trees, the PKI is future-proofed against corporate reorganizations, divestitures, or acquisitions. When changes occur, an entire root CA hierarchy can move cleanly with the division it secures. And with two levels of subordinate CA, the roots CAs have a high level of isolation from the level 3 CAs that are responsible for bulk-signing the certificates for thousands or millions of manufactured items. On the internal side, corporate web and internal computer operations complete a two-level hierarchy. These levels allow web administrators and operations engineers to manage certificate issuance independently for their own work domains. The compartmentalization of PKI into distinct functional domains is a security best practice and protects each from a compromise that might affect the other. Web administrators issue end-entity certificates for use by web browsers throughout the company, authenticating and encrypting communications on the internal website. Operations engineers issue end-entity certificates that authenticate data center hosts and computer services to one another. This system helps keep sensitive data secure by encrypting it on the LAN. ## Set length constraints on the certification path The structure of a CA hierarchy is defined and enforced by the *basics constraints* extension that each certificate contains. The extension defines two constraints: + `cA` – Whether the certificate defines a CA. If this value is *false* (the default), then the certificate is an end-entity certificate. + `pathLenConstraint` – The maximum number of lower-level subordinate CAs that can exist in a valid chain of trust. The end-entity certificate is not counted because it is not a CA certificate. A root CA certificate needs maximum flexibility and does not include a path length constraint. This allows the root to define a certification path of any length. **Note** AWS Private CA limits the certification path to five levels. Subordinate CAs have `pathLenConstraint` values equal to or greater than zero, depending on location in the hierarchy placement and desired features. For example, in a hierarchy with three CAs, no path constraint is specified for the root CA. The first subordinate CA has a path length of 1 and can therefore sign child CAs. Each of these child CAs must necessarily have a `pathLenConstraint` value of zero. This means that they can sign end-entity certificates but cannot issue additional CA certificates. Limiting the power to create new CAs is an important security control. The following diagram illustrates this propagation of limited authority down the hierarchy. ![\[Diagram of a simple, three-level CA hierarchy.\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/path-length.png) In this four-level hierarchy, the root is unconstrained (as always). But the first subordinate CA has a `pathLenConstraint` value of 2, which limits its child CAs from going more than two levels deeper. Consequently, for a valid certification path, the constraint value must decrement to zero in the next two levels. If a web browser encounters an end-entity certificate from this branch that has a path length greater than four, validation fails. Such a certificate could be the result of an accidentally created CA, a misconfigured CA, or a unauthorized issuance. ### Manage path length with templates AWS Private CA provides templates for issuing root, subordinate, and end-entity certificates. These templates encapsulate best practices for the basic constraints values, including path length. The templates include the following: + RootCACertificate/V1 + SubordinateCACertificate\$1PathLen0/V1 + SubordinateCACertificate\$1PathLen1/V1 + SubordinateCACertificate\$1PathLen2/V1 + SubordinateCACertificate\$1PathLen3/V1 + EndEntityCertificate/V1 The `IssueCertificate` API will return an error if you attempt to create a CA with a path length greater than or equal to the path length of its issuing CA certificate. For more information about certificate templates, see [Use AWS Private CA certificate templates](UsingTemplates.md). ### Automate CA hierarchy setup with AWS CloudFormation When you have settled on a design for your CA hierarchy, you can test it and put it into production using a AWS CloudFormation template. For an example of such a template, see [Declaring a Private CA Hierarchy](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-acmpca-certificateauthority.html#aws-resource-acmpca-certificateauthority--examples) in the *CloudFormation User Guide*. # Manage the private CA lifecycle Manage the CA lifecycle CA certificates have a fixed lifetime, or validity period. When a CA certificate expires, all of the certificates issued directly or indirectly by subordinate CAs below it in the CA hierarchy become invalid. You can avoid CA certificate expiration by planning in advance. ## Choose validity periods The validity period of an X.509 certificate is a required basic certificate field. It determines the time-range during which the issuing CA certifies that the certificate can be trusted, barring revocation. (A root certificate, being self-signed, certifies its own validity period.) AWS Private CA and AWS Certificate Manager assist with the configuration of certificate validity periods subject to the following constraints: + A certificate managed by AWS Private CA must have a validity period shorter than or equal to the validity period of the CA that issued it. In other words, child CAs and end-entity certificates cannot outlive their parent certificates. Attempting to use the `IssueCertificate` API to issue a CA certificate with a validity period greater than or equal to the parent's CA fails. + Certificates issued and managed by AWS Certificate Manager (those for which ACM generates the private key) have a validity period of 13 months (395 days). ACM manages the renewal process for these certificates. If you use AWS Private CA to issue certificates directly, you can choose any validity period. The following diagram shows a typical configuration of nested validity periods. The root certificate is the most long-lived; end-entity certificates are relatively short-lived; and subordinate CAs range between these extremes. ![\[Subordinate and validity periods must fall within the validity periods of their parents.\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/validity.png) When you plan your CA hierarchy, determine the optimal lifetime for your CA certificates. Work backwards from the desired lifetime of the end-entity certificates that you want to issue. **End-entity certificates** End-entity certificates should have a validity period appropriate to the use case. A short lifetime minimizes the exposure of a certificate in the event that its private key is lost or stolen. However, short lifetimes mean frequent renewals. Failure to renew an expiring certificate can result in downtime. The distributed use of end-entity certificates can also present logistical problems if there is a security breach. Your planning should account for renewal and distribution certificates, revocation of compromised certificates, and how quickly revocations propagate to clients that rely on the certificates. The default validity period for an end-entity certificate issued through ACM is 13 months (395 days). In AWS Private CA, you can use the `IssueCertificate` API to apply any validity period so long as it is less than that of the issuing CA. **Subordinate CA Certificates** Subordinate CA certificates should have significantly longer validity periods than the certificates they issue. A good range for a CA certificate's validity is two to five times the period of any child CA certificate or end-entity certificate it issues. For example, assume you have a two-level CA hierarchy (root CA and one subordinate CA). If you want to issue end-entity certificates with a one-year lifetime, you could configure the subordinate issuing CA lifetime to be three years. This is the default validity period for a subordinate CA certificate in AWS Private CA. Subordinate CA certificates can be changed without replacing the root CA certificate. **Root Certificates** Changes to a root CA certificate affect the entire PKI (public key infrastructure) and require you to update all the dependent client operating system and browser trust stores. To minimize operational impact, you should choose a long validity period for the root certificate. The AWS Private CA default for root certificates is ten years. ## Manage CA succession You have two ways to manage CA succession: Replace the old CA, or reissue the CA with a new validity period. ### Replace an old CA To replace an old CA, you create a new CA and chain it to the same parent CA. Afterward, you issue certificates from the new CA. Certificates issued from the new CA have a new CA chain. Once the new CA is established, you can disable the old CA to prevent it from issuing new certificates. While disabled, the old CA supports revocation for old certificates issued from the CA, and, if configured to do so, it continues to validate certificates by means of OCSP and/or certificate revocation lists (CRLs). When the last certificate issued from the old CA expires, you can delete the old CA. You can generate an audit report for all of the certificates issued from the CA to confirm that all of the certificates issued have expired. If the old CA has subordinate CAs, you must also replace them, because subordinate CAs expire at the same time or before their parent CA. Start by replacing the highest CA in the hierarchy that needs to be replaced. Then create new replacement subordinate CAs at each subsequent lower level. AWS recommends that you include a CA generation identifier in the names of CAs as needed. For example, assume that you name the first generation CA “Corporate Root CA." When you create the second generation CA, name it “Corporate Root CA G2." This simple naming convention can help avoid confusion when both CAs are unexpired. This method of CA succession is preferred because it rotates the private key of the CA. Rotating the private key is a best practice for CA keys. The frequency of rotation should be proportional to the frequency of key use: CAs that issue more certificates should be rotated more frequently. **Note** Private certificates issued through ACM cannot be renewed if you replace the CA. If you use ACM for issuance and renewal, you must re-issue the CA certificate to extend the lifetime of the CA. ### Reissue an old CA When a CA nears expiration, an alternative method of extending its life is to reissue the CA certificate with a new expiration date. Reissuance leaves all of the CA metadata in place and preserves the existing private and public keys. In this scenario, the existing certificate chain and unexpired end-entity certificates issued by the CA remain valid until they expire. New certificate issuance can also continue without interruption. To update a CA with a reissued certificate, follow the usual installation procedures described in [Installing the CA certificate](PCACertInstall.md). **Note** We recommend replacing an expiring CA rather than reissuing its certificate because of the security advantages gained by rotating to a new key pair. ## Revoke a CA You revoke a CA by revoking its underlying certificate. This also effectively revokes all of the certificates issued by the CA. Revocation information is distributed to clients by means of [OCSP or a CRL](revocation-setup.md). You should revoke a CA certificate only if you want to revoke all of its issued end-entity and subordinate CA certificates. # Plan your AWS Private CA certificate revocation method Plan certificate revocation As you plan your private PKI with AWS Private CA, you should consider how to handle situations where you no longer wish endpoints to trust an issued certificate, such as when the private key of an endpoint is exposed. The common approaches to this problem are to use short-lived certificates or to configure certificate revocation. Short-lived certificates expire in such a short period of time, in hours or days, that revocation makes no sense, with the certificate becoming invalid in about the same time it takes to notify an endpoint of revocation. This section describes the revocation options for AWS Private CA customers, including configuration and best practices. Customers looking for a revocation method can choose Online Certificate Status Protocol (OCSP), certificate revocation lists (CRLs), or both. **Note** If you create your CA without configuring revocation, you can always configure it later. For more information, see [Update a private CA in AWS Private Certificate Authority](PCAUpdateCA.md). + **Online Certificate Status Protocol (OCSP)** AWS Private CA provides a fully managed OCSP solution to notify endpoints that certificates have been revoked without the need for customers to operate infrastructure themselves. Customers can enable OCSP on new or existing CAs with a single operation using the AWS Private CA console, the API, the CLI, or through CloudFormation. Whereas CRLs are stored and processed on the endpoint and can become stale, OCSP storage and processing requirements are handled synchronously on the responder backend. When you enable OCSP for a CA, AWS Private CA includes the URL of the OCSP responder in the *Authority Information Access* (AIA) extension of each new certificate issued. The extension allows clients such as web browsers to query the responder and determine whether an end-entity or subordinate CA certificate can be trusted. The responder returns a status message that is cryptographically signed to assure its authenticity. The AWS Private CA OCSP responder is compliant with [RFC 5019](https://datatracker.ietf.org/doc/html/rfc5019). **OCSP considerations** + OCSP status messages are signed using the same signing algorithm that the issuing CA was configured to use. CAs created in the AWS Private CA console use the SHA256WITHRSA signature algorithm by default. Other supported algorithms can be found in the [CertificateAuthorityConfiguration](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CertificateAuthorityConfiguration.html) API documentation. + [APIPassthrough and CSRPassthrough](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html#template-varieties) certificate templates will not work with the AIA extension if the OCSP responder is enabled. + The endpoint of the managed OCSP service is accessible on the public internet. Customers who want OCSP but prefer not to have a public endpoint will need to operate their own OCSP infrastructure. + **Certificate Revocation Lists (CRLs)** A certificate revocation list (CRL) is a file that contains a list of certificates revoked before their scheduled expiration date. The CRL contains a list of certificates that should no longer be trusted, the reason for revocation, and other relevant information. When you configure your certificate authority (CA), you can choose whether AWS Private CA creates a complete or partitioned CRL. Your choice determines the maximum number of certificates that the certificate authority can issue and revoke. For more information, see [AWS Private CA quotas](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca). **CRL considerations** + Memory and bandwidth considerations: CRLs require more memory than OCSP due to local download and processing requirements. However, CRLs might reduce network bandwidth compared to OCSP by caching revocation lists instead of checking status per connection. For memory-constrained devices, such as certain IoT devices, consider using partitioned CRLs. + Changing the CRL type: When changing from a complete to partitioned CRL, AWS Private CA creates new partitions as needed and adds the IDP extension to all CRLs, including the original. Changing from partitioned to complete updates only a single CRL and prevents future revocation of certificates associated with previous partitions. **Note** Both OCSP and CRLs exhibit some delay between revocation and the availability of the status change. OCSP responses may take up to 60 minutes to reflect the new status when you revoke a certificate. In general, OCSP tends to support faster distribution of revocation information because, unlike CRLs which can be cached by clients for days, OCSP responses are typically not cached by clients. A CRL is typically updated approximately 30 minutes after a certificate is revoked. If for any reason a CRL update fails, AWS Private CA makes further attempts every 15 minutes. ## General requirements for revocation configurations Requirements The following requirements apply to all revocation configurations. + A configuration disabling CRLs or OCSP must contain only the `Enabled=False` parameter, and will fail if other parameters such as `CustomCname` or `ExpirationInDays` are included. + In a CRL configuration, the `S3BucketName` parameter must conform to [Amazon Simple Storage Service bucket naming rules](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html). + A configuration containing a custom Canonical Name (CNAME) parameter for CRLs or OCSP must conform to [RFC7230](https://www.ietf.org/rfc/rfc7230.txt) restrictions on the use of special characters in a CNAME. + In a CRL or OCSP configuration, the value of a CNAME parameter must not include a protocol prefix such as "http://" or "https://". **Topics** + [ ## General requirements for revocation configurations ](#revocation-requirements) + [ # Set up a CRL for AWS Private CA ](crl-planning.md) + [ # Customize OCSP URL for AWS Private CA ](ocsp-customize.md) # Set up a CRL for AWS Private CA Set up CRL Before you can configure a certificate revocation list (CRL) as part of the [CA creation process](create-CA.md), some prior setup may be necessary. This section explains the prerequisites and options that you should understand before creating a CA with a CRL attached. For information about using Online Certificate Status Protocol (OCSP) as an alternative or a supplement to a CRL, see [](create-CA.md#PcaCreateRevocation) and [Customize OCSP URL for AWS Private CA](ocsp-customize.md). **Topics** + [ ## CRL types ](#crl-type) + [ ## CRL structure ](#crl-structure) + [ ## Access policies for CRLs in Amazon S3 ](#s3-policies) + [ ## Enable S3 Block Public Access (BPA) with CloudFront ](#s3-bpa) + [ ## Determining the CRL Distribution Point (CDP) URI ](#crl-url) + [ ## ](#crl-ipv6) ## CRL types + **Complete** - The default setting. AWS Private CA maintains a single, unpartitioned CRL file for all unexpired certificates issued by a CA that have been revoked. Each certificate that AWS Private CA issues is bound to a specific CRL through its CRL distribution point (CDP) extension, as defined in [ RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9). You can have up to 1 million private certificates for each CA with complete CRL enabled. For more information, see the [AWS Private CA quotas](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca). + **Partitioned** - Compared to complete CRLs, partitioned CRLs dramatically increase the number of certificates your private CA can issue, and saves you from frequently rotating your CAs. **Important** When using partitioned CRLs, you must validate that the CRL's associated issuing distribution point (IDP) URI matches the certificate's CDP URI to ensure the right CRL has been fetched. AWS Private CA marks the IDP extension as critical, which your client must be able to process. ## CRL structure Each CRL is a DER encoded file. To download the file and use [OpenSSL](https://www.openssl.org/) to view it, use a command similar to the following: ``` openssl crl -inform DER -in path-to-crl-file -text -noout ``` CRLs have the following format: ``` Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: /C=US/ST=WA/L=Seattle/O=Example Company CA/OU=Corporate/CN=www.example.com Last Update: Feb 26 19:28:25 2018 GMT Next Update: Feb 26 20:28:25 2019 GMT CRL extensions: 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 CRL Number: 1519676905984 Revoked Certificates: Serial Number: E8CBD2BEDB122329F97706BCFEC990F8 Revocation Date: Feb 26 20:00:36 2018 GMT CRL entry extensions: X509v3 CRL Reason Code: Key Compromise Serial Number: F7D7A3FD88B82C6776483467BBF0B38C Revocation Date: Jan 30 21:21:31 2018 GMT CRL entry extensions: X509v3 CRL Reason Code: Key Compromise Signature Algorithm: sha256WithRSAEncryption 82:9a:40:76:86:a5:f5:4e:1e:43:e2:ea:83:ac:89:07:49:bf: c2:fd:45:7d:15:d0:76:fe:64:ce:7b:3d:bb:4c:a0:6c:4b:4f: 9e:1d:27:f8:69:5e:d1:93:5b:95:da:78:50:6d:a8:59:bb:6f: 49:9b:04:fa:38:f2:fc:4c:0d:97:ac:02:51:26:7d:3e:fe:a6: c6:83:34:b4:84:0b:5d:b1:c4:25:2f:66:0a:2e:30:f6:52:88: e8:d2:05:78:84:09:01:e8:9d:c2:9e:b5:83:bd:8a:3a:e4:94: 62:ed:92:e0:be:ea:d2:59:5b:c7:c3:61:35:dc:a9:98:9d:80: 1c:2a:f7:23:9b:fe:ad:6f:16:7e:22:09:9a:79:8f:44:69:89: 2a:78:ae:92:a4:32:46:8d:76:ee:68:25:63:5c:bd:41:a5:5a: 57:18:d7:71:35:85:5c:cd:20:28:c6:d5:59:88:47:c9:36:44: 53:55:28:4d:6b:f8:6a:00:eb:b4:62:de:15:56:c8:9c:45:d7: 83:83:07:21:84:b4:eb:0b:23:f2:61:dd:95:03:02:df:0d:0f: 97:32:e0:9d:38:de:7c:15:e4:36:66:7a:18:da:ce:a3:34:94: 58:a6:5d:5c:04:90:35:f1:8b:55:a9:3c:dd:72:a2:d7:5f:73: 5a:2c:88:85 ``` **Note** The CRL will only be deposited in Amazon S3 after a certificate has been issued that refers to it. Prior to that, there will only be an `acm-pca-permission-test-key` file visible in the Amazon S3 bucket. ## Access policies for CRLs in Amazon S3 If you plan to create a CRL, you need to prepare an Amazon S3 bucket to store it in. AWS Private CA automatically deposits the CRL in the Amazon S3 bucket you designate and updates it periodically. For more information, see [Creating a bucket.](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html) Your S3 bucket must be secured by an attached IAM permissions policy. Authorized users and service principals require `Put` permission to allow AWS Private CA to place objects in the bucket, and `Get` permission to retrieve them. **Note** The IAM policy configuration depends on the AWS Regions involved. Regions fall into two categories: **Default-enabled Regions** – Regions that are *enabled* by default for all AWS accounts. **Default-disabled Regions** – Regions that are *disabled* by default, but may be manually enabled by the customer. For more information and a list of the default-disabled Regions, see [Managing AWS Regions](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html). For a discussion of service principals in the context of IAM, see [AWS service principals in opt-in Regions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services-in-opt-in-regions). When you configure CRLs as the certificate revocation method, AWS Private CA creates a CRL and publishes it to an S3 bucket. The S3 bucket requires an IAM policy that allows the AWS Private CA service principal to write to the bucket. The name of the service principal varies according to the Regions used, and not all possibilities are supported. **** | PCA | S3 | Service principal | | --- | --- | --- | | Both in same Region | `acm-pca.amazonaws.com` | | Enabled | Enabled | `acm-pca.amazonaws.com` | | Disabled | Enabled | `acm-pca.Region.amazonaws.com` | | Enabled | Disabled | Not supported | The default policy applies no `SourceArn` restriction on the CA. We recommend that you apply a less permissive policy such as the following, which restricts access to both a specific AWS account and a specific private CA. Alternatively, you can use the [aws:SourceOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid) condition key to constrain access to a specific organization in AWS Organizations. For more information about bucket policies, see [Bucket policies for Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html). If you choose to allow the default policy, you can always [modify](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) it later. ## Enable S3 Block Public Access (BPA) with CloudFront S3 BPA with CloudFront New Amazon S3 buckets are configured by default with the Block Public Access (BPA) feature activated. Included in the Amazon S3 [security best practices](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html), BPA is a set of access controls that customers can use to fine-tune access to objects in their S3 buckets and to the buckets as a whole. When BPA is active and correctly configured, only authorized and authenticated AWS users have access to a bucket and its contents. AWS recommends the use of BPA on all S3 buckets to avoid exposure of sensitive information to potential adversaries. However, additional planning is required if your PKI clients retrieve CRLs across the public internet (that is, while not logged into an AWS account). This section describes how to configure a private PKI solution using Amazon CloudFront, a content delivery network (CDN), to serve CRLs without requiring authenticated client access to an S3 bucket. **Note** Using CloudFront incurs additional costs on your AWS account. For more information, see [Amazon CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing/). If you choose to store your CRL in an S3 bucket with BPA enabled, and you do not use CloudFront, you must build another CDN solution to ensure that your PKI client has access to your CRL. ### Set up CloudFront for BPA Create a CloudFront distribution that will have access to your private S3 bucket, and can serve CRLs to unauthenticated clients. **To configure a CloudFront distribution for the CRL** 1. Create a new CloudFront distribution using the procedure in [Creating a Distribution](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-creating-console.html) in the *Amazon CloudFront Developer Guide*. While completing the procedure, apply the following settings: + In **Origin Domain Name**, choose your S3 bucket. + Choose **Yes **for **Restrict Bucket Access**. + Choose **Create a New Identity** for **Origin Access Identity**. + Choose **Yes, Update Bucket Policy** under **Grant Read Permissions on Bucket**. **Note** In this procedure, CloudFront modifies your bucket policy to allow it to access bucket objects. Consider [editing](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) this policy to allow access only to objects under the `crl` folder. 1. After the distribution has initialized, locate its domain name in the CloudFront console and save it for the next procedure. **Note** If your S3 bucket was newly created in a Region other than us-east-1, you might get an HTTP 307 temporary redirect error when you access your published application through CloudFront. It might take several hours for the address of the bucket to propagate. ### Set up your CA for BPA While configuring your new CA, include the alias to your CloudFront distribution. **To configure your CA with a CNAME for CloudFront** + Create your CA using [Create a private CA in AWS Private CA](create-CA.md). When you perform the procedure, the revocation file `revoke_config.txt` should include the following lines to specify a non-public CRL object and to provide a URL to the distribution endpoint in CloudFront: ``` "S3ObjectAcl":"BUCKET_OWNER_FULL_CONTROL", "CustomCname":"abcdef012345.cloudfront.net" ``` Afterward, when you issue certificates with this CA, they will contain a block like the following: ``` X509v3 CRL Distribution Points: Full Name: URI:http://abcdef012345.cloudfront.net/crl/01234567-89ab-cdef-0123-456789abcdef.crl ``` **Note** If you have older certificates that were issued by this CA, they will be unable to access the CRL. ## Determining the CRL Distribution Point (CDP) URI If you need to use the CRL Distribution Point (CDP) URI in your workflow, you can either issue a certificate use the CRL URI on that certificate or use the following method. This only works for complete CRLs. Partitioned CRLs have a random GUID appended to them. If you use the S3 bucket as the CRL Distribution Point (CDP) for your CA, the CDP URI can be in one of the following formats. + `http://amzn-s3-demo-bucket.s3.region-code.amazonaws.com/crl/CA-ID.crl` + `http://s3.region-code.amazonaws.com/amzn-s3-demo-bucket/crl/CA-ID.crl` If you have configured your CA with a custom CNAME, the CDP URI will include the CNAME, for example, `http://alternative.example.com/crl/CA-ID.crl` ## By default, AWS Private CA writes CDP extensions using regional, IPv4-only `amazonaws.com` endpoints. To use CRLs over IPv6, do one of the following steps so that CDPs are written with URLs that point to [S3's dualstack endpoints](https://docs.aws.amazon.com/AmazonS3/latest/API/dual-stack-endpoints.html): + Set your [CRL custom name ](create-CA.md#PcaCreateRevocation) to the S3 dualstack endpoint domain. For example, `bucketname.s3.dualstack.region-code.amazonaws.com` + Set up your own CNAME DNS record pointing at the relevant S3 dualstack endpoint, then use it as your CRL custom name # Customize OCSP URL for AWS Private CA Customize OCSP URL **Note** This topic is for customers who want to customize the public URL of the Online Certificate Status Protocol (OCSP) responder endpoint for branding or other purposes. If you plan to use the default configuration of AWS Private CA managed OCSP, you can skip this topic and follow the configuration instructions in [Configure revocation](create-CA.md#PcaCreateRevocation). By default, when you enable OCSP for AWS Private CA, each certificate that you issue contains the URL for the AWS OCSP responder. This allows clients requesting a cryptographically secure connection to send OCSP validation queries directly to AWS. However, in some cases it might be preferable to state a different URL in your certificates while still ultimately submitting OCSP queries to AWS. **Note** For information about using a certificate revocation list (CRL) as an alternative or a supplement to OCSP, see [Configure revocation](create-CA.md#PcaCreateRevocation) and [Planning a certificate revocation list (CRL)](crl-planning.md). Three elements are involved in configuring a custom URL for OCSP. + **CA configuration** – Specify a custom OCSP URL in the `RevocationConfiguration` for your CA as described in [Example 2: Create a CA with OCSP and a custom CNAME enabled](create-CA.md#example_2) in [Create a private CA in AWS Private CA](create-CA.md). + **DNS** – Add a CNAME record to your domain configuration to map the URL appearing in the certificates to a proxy server URL. For more information, see [Example 2: Create a CA with OCSP and a custom CNAME enabled](create-CA.md#example_2) in [Create a private CA in AWS Private CA](create-CA.md). + **Forwarding proxy server** – Set up a proxy server that can transparently forward OCSP traffic that it receives to the AWS OCSP responder. The following diagram illustrates how these elements work together. ![\[Custom OCSP topology\]](http://docs.aws.amazon.com/privateca/latest/userguide/images/ocsp.png) As shown in the diagram, the customized OCSP validation process involves the following steps: 1. Client queries DNS for the target domain. 1. Client receives the target IP. 1. Client opens a TCP connection with target. 1. Client receives target TLS certificate. 1. Client queries DNS for the OCSP domain listed in the certificate. 1. Client receives proxy IP. 1. Client sends OCSP query to proxy. 1. Proxy forwards query to the OCSP responder. 1. Responder returns certificate status to the proxy. 1. Proxy forwards certificate status to the client. 1. If certificate is valid, client begins TLS handshake. **Tip** This example can be implemented using [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/) and [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) after you have configured a CA as described above. In CloudFront, create a distribution and configure it as follows: Create an alternate name that matches your custom CNAME. Bind your certificate to it. Set `ocsp.acm-pca..amazonaws.com` as the origin. To use IPv6 connections, use the dualstack endpoint `acm-pca-ocsp..api.aws` Apply the `Managed-CachingDisabled` policy. Set **Viewer protocol policy** to **HTTP and HTTPS**. Set **Allowed HTTP methods** to **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**. In Route 53, create a DNS record that maps your custom CNAME to the URL of the CloudFront distribution. ## Using OCSP over IPv6 The default AWS Private CA OCSP responder URL is IPv4-only. To use OCSP over IPv6, configure a custom OCSP URL for your CA. The URL can be either: + The FQDN of the dualstack PCA OCSP responder, which takes the form `acm-pca-ocsp.region-name.api.aws` + A CNAME record that you have configured to point at the dualstack OCSP responder, as explained above. # Understand AWS Private CA CA modes CA mode AWS Private CA supports the creation of a certificate authority (CA) in either of two modes. The modes, general-purpose and short-lived certificate, affect the allowed validity period of the certificates issued by the CA. **Note** AWS Private CA does not perform validity checks on root CA certificates. ## General-purpose (default) This mode permits the CA to issue certificates with any validity period. Most applications use certificates of this type. Typically, the CA also specifies a revocation mechanism. ## Short-lived certificate This mode defines a CA that exclusively issues certificates with a maximum validity period of seven days. These short-lived certificates expire so quickly that they can be deployed without a revocation mechanism in place. For some applications, it makes more sense to frequently deploy short-lived certificates than to incur the network and processing overhead of revocation. Short-lived certificates must be the last CA in the certificate hierarchy. There is significant overhead because the private CA must be renewed every seven days. CAs with short-lived certificate mode cost less than general-purpose CAs. For more information, see [AWS Private Certificate Authority Pricing](https://aws.amazon.com/private-ca/pricing/). To create a CA that issues short-lived certificates, set the `UsageMode` parameter to short-lived certificate using the [create a CA](create-CA.md) procedure for creating a CA. **Note** AWS Certificate Manager cannot issue certificates signed by a private CA with short-lived mode. Use of short-lived certificates is supported by the following AWS services: + [Amazon AppStream](https://docs.aws.amazon.com/appstream/latest/developerguide/) + [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/) # Plan for resilience in AWS Private CA Plan for resilience The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). ## Redundancy and disaster recovery Consider redundancy and DR when planning your CA hierarchy. AWS Private CA is available in multiple [Regions](https://docs.aws.amazon.com/general/latest/gr/pca.html), which allows you to create redundant CAs in multiple Regions. The AWS Private CA service operates with a [service level agreement](https://aws.amazon.com/certificate-manager/private-certificate-authority/sla/) (SLA) of 99.9% availability. There are at least two approaches that you can consider for redundancy and disaster recovery. You can configure redundancy at the root CA or at the highest subordinate CA. Each approach has pros and cons. 1. You can create two root CAs in two different AWS Regions for redundancy and disaster recovery. With this configuration, each root CA operates independently in an AWS Region, protecting you in the event of a single-Region disaster. Creating redundant root CAs does, however, increase operational complexity: You will need to distribute both root CA certificates to the trust stores of browsers and operating systems in your environment. 1. You can also create redundant subordinate CAs to deploy in each of your AWS Regions, and chain them to the same unique root CA in a single AWS Region. The benefit of this approach is that you need to distribute only a single root CA certificate to the trust stores in your environment. The limitation is that you don’t have a redundant root CA in the event of a disaster that affects the AWS Region in which your root CA exists.