Amazon Private CA best practices
Best practices are recommendations that can help you use Amazon Private CA effectively. The following best practices are based on real-world experience from current Amazon Certificate Manager and Amazon Private CA customers.
Documenting CA structure and policies
Amazon recommends documenting all of your policies and practices for operating your CA. This might include:
-
Reasoning for your decisions about CA structure
-
A diagram showing your CAs and their relationships
-
Policies on CA validity periods
-
Planning for CA succession
-
Policies on path length
-
Catalog of permissions
-
Description of administrative control structures
-
Security
You can capture this information in two documents, known as Certification Policy (CP)
and Certification Practices Statement (CPS). Refer to RFC 3647
Minimize use of the root CA if possible
A root CA should in general only be used to issue certificates for intermediate CAs. This allows the root CA to be stored out of harm's way while the intermediate CAs perform the daily task of issuing end-entity certificates.
However, if your organization's current practice is to issue end-entity certificates directly from a root CA, Amazon Private CA can support this workflow while improving security and operational controls. Issuing end-entity certificates in this scenario requires an IAM permissions policy that permits your root CA to use an end-entity certificate template. For information about IAM policies, see Identity and Access Management (IAM) for Amazon Private Certificate Authority.
Note
This configuration imposes limitations that might result in operational challenges. For example, if your root CA is compromised or lost, you must create a new root CA and distribute it to all of the clients in your environment. Until this recovery process is complete, you will not be able to issue new certificates. Issuing certificates directly from a root CA also prevents you from restricting access and limiting the number of certificates issued from your root, which are both considered best practices for managing a root CA.
Give the root CA its own Amazon Web Services account
Creating a root CA and subordinate CA in two different Amazon accounts is a recommended best practice. Doing so can provide you with additional protection and access controls for your root CA. You can do so by exporting the CSR from the subordinate CA in one account, and signing it with a root CA in a different account. The benefit of this approach is that you can separate control of your CAs by account. The disadvantage is that you cannot use the Amazon Web Services Management Console wizard to simplify the process of signing the CA certificate of a subordinate CA from your root CA.
Important
We strongly recommend the use of multi-factor authentication (MFA) any time you access Amazon Private CA.
Separate administrator and issuer roles
The CA administrator role should be separate from users who need only to issue end-entity certificates. If your CA administrator and certificate issuer reside in the same Amazon Web Services account, you can limit issuer permissions by creating an IAM user specifically for that purpose.
Implement managed revocation of certificates
Managed revocation automatically provides notice to certificate clients when a certificate has been revoked. You might need to revoke a certificate if its cryptographic information has been compromised or if it was issued in error. Clients typically refuse to accept revoked certificates. Amazon Private CA offers two standard options for managed revocation: Online Certificate Status Protocol (OCSP), and certificate revocation lists (CRLs). For more information, see Setting up a certificate revocation method.
Turn on Amazon CloudTrail
Turn on CloudTrail logging before you create and start operating a private CA. With CloudTrail, you can retrieve a history of Amazon API calls for your account to monitor your Amazon deployments. This history includes API calls made from the Amazon Web Services Management Console, the Amazon SDKs, the Amazon Command Line Interface, and higher-level Amazon services. You can also identify which users and accounts called the PCA API operations, the source IP address the calls were made from, and when the calls occurred. You can integrate CloudTrail into applications using the API, automate trail creation for your organization, check the status of your trails, and control how administrators turn CloudTrail logging on and off. For more information, see Creating a Trail. Go to Using CloudTrail to see example trails for Amazon Private CA operations.
Rotate the CA private key
It is a best practice to periodically update the private key for your private CA. You can update a key by importing a new CA certificate, or you can replace the private CA with a new CA.
Note
If you replace the CA itself, be aware that the ARN of the CA changes. This would cause automation relying on a hard-coded ARN to fail.
Delete unused CAs
You can permanently delete a private CA. You might want to do so if you no longer need the CA or if you want to replace it with a CA that has a newer private key. To safely delete a CA, we recommend that you follow the process outlined in Deleting your private CA.
Note
Amazon bills you for a CA until it has been deleted.
Block public access to your CRLs
Amazon Private CA recommends using the Amazon S3 Block Public Access (BPA) feature on buckets that contain CRLs. This avoids unnecessarily exposing details of your private PKI to potential adversaries. BPA is an S3 best practice and is enabled by default on new buckets. Additional setup is needed in some cases. For more information, see Enabling S3 Block Public Access (BPA) with CloudFront.
Amazon EKS application best practices
When using Amazon Private CA to provision Amazon EKS with X.509 certificates, follow the
recommendations for securing multi-tenant environments in the Amazon EKS Best Practices Guides