Difference between various Public Key Infrastructure (PKIs)

Read time: 12 minutes

PKI, the abbreviation for Public Key Infrastructure, is a set of roles, procedures, and policies needed to create, distribute, manage, use, and revoke digital certificates and manage public-key encryption. PKI is used to confirm the identity of a user by providing ownership of a private key. It is a trusted service to verify that a sender or receiver of data is exactly who they claim to be.

PKI is built around components and procedures for managing the key pairs (public and private key pairs).

A typical PKI is made up of the following components:

1. Certificate Authority (CA): A trusted CA is the only entity in PKI that can issue trusted digital certificates. CA accepts requests for certificates and verifies the information provided by the applicants based on certificate management policy. CA will sign the certificates with its private key and issue them to the applicants if the information is legal.
2. Registration Authority (RA): RA is responsible for receiving certificate signing requests for the initial enrollment or renewal of certificates from users, servers, other applications. RA verifies the identity of an end-entity and forwards the request to a certificate authority (CA).
3. Public Key: Public key can be distributed widely and does not require secure storage. Its corresponding private key can only decrypt messages/Data encrypted by the public key.
4. Private Key: Private keys are used by the recipient to decrypt the message/data encrypted by its corresponding public key. This establishes the ownership of the private and public key pair, ensuring the message is only read by the approved parties
5. Root Certificate Authority (Root CA): A certificate is considered valid when a trusted Root CA sign it. A Root CA is entitled to verify a person’s identity and signs the root certificate that is distributed to a user.
6. Intermediate Certificate Authority: An Intermediate CA is also a trusted CA and is used as a chain between the root CA and the client certificate that the user enrolls for. Since the Root CA has signed and trusts the intermediate CA, certificates generated from the intermediate CA are also trusted.
7. Hardware security module: A Hardware Security Module isn’t a mandatory component of a PKI, but it improves the security of the PKI when implemented. This device protects and manages digital keys and serves as the groundwork for building a secure enterprise PKI infrastructure. The HSM manages the complete lifecycle of cryptographic keys, including creation, rotation, deletion, auditing, and support for APIs to integrate with various applications.

Now we have a fair idea about some of the PKI components, let’s talk about different PKI vendors and their best practices:

Microsoft PKI

Below is few best practices that are recommended to use Microsoft PKI effectively.

• Make a detailed plan of your PKI infrastructure before deployment.
• Avoid installing ADCS on a domain controller.
• Root CA should be standalone and offline.
• Do not issue certificates to end-entity from a Root CA.
• Enable auditing events for both Root and Issuing CA.
• Secure the Private key with HSM (FIPS 140-2 level 3)
• Install Enterprise CA only if your CA issues a certificate for devices or users.
• It is not recommended to use default certificate templates.
• CRL distribution point should be highly available.
• Publish Root CA CRL to Active directory.
• Hash Algorithm should be at least SHA-2 (SHA 256 bit).
• The end-entity certificate validity period should be a maximum of 2 years.

AWS Certificate Manager

Here are the top 10 best practices we identified for AWS Certificate Manager (ACM):

• ACM Certificate expiry check: Ensure removal of expired SSL/TLS certificates managed by ACM. This eliminates the risk of deploying an invalid SSL/TLS certificate in resources that trigger the front end. This might cause a loss of credibility for business as well.
• ACM Certificate validity check: Ensure requests that arrive during the SSL/TLS certificate issue or renewal process are validated regularly.
• Root Certificate Authority (CA) usage: It is always a best practice to minimize the use of Root CA. Amazon recommends creating a separate account for Root CA.
• Transport layer protection is vital to ensure security. It is recommended to use only TLS version 1.1 or above and not use SSL as it is no longer secure.
• Whenever you import certificates instead of ACM-issued certificates, ensure keys used to generate SSL/TLS certificate private keys have high key strength to avoid a data breach.
• Avoid using wildcard domain certificates. Instead, try to issue ACM single domain certificate for each domain and subdomain with its own private key.
• Allow usage of imported certificates only from authenticated and trusted partners of your organization in ACM. When wildcard certificates are imported into AWS Certificate Manager (ACM), security threat risk is high as the user might hold an unencrypted copy of the certificate’s private key.
• Recommended best practice is to always use a Fully Qualified Domain Name (FQDN) in SSL/TLS ACM certificates.
• To avoid misuse of generated certificates, perform frequent audits of AWS environment for trusted certificates and validate audit reports.
• Turn on AWS CloudTrail and CloudWatch alarms: CloudTrail logging helps track the history of AWS API calls and monitor AWS deployments. CloudTrail can be integrated with applications for performing automated logging and monitoring activities. Enabling the CloudWatch alarm feature helps in alerting through notifications when configured metrics breach.

AWS ACM Private CA (ACM PCA)

Below are the recommended best practices that can help you use AWS ACM PCA more effectively.

• AWS recommends documenting all your policies and practices for operating your CA, including CA hierarchy, architecture diagram, CA validation period policies, path length, etc.
  The CA structure and policies above can be captured in two documents known as Certificate Policy (CP) and Certificate Practice Statement (CPS). Refer to RFC 3647 for a framework for capturing important information about your CA operations.
• Root CA should, in general, only be used to issue a certificate for intermediate CAs.
• Creating a Root CA and Subordinate CA in two different AWS account is recommended best practice.
• The CA administrator role should be separate from users who need access only to issue end-entity certificates.
• Turn on CloudTrail logging before you create and start operating a private CA. With CloudTrail, you can retrieve a history of AWS API calls for your account to monitor your AWS deployments.
• It is a best practice to update the private key for your private CA periodically. You can update a key by importing a new CA certificate or replacing the private CA with a new CA.
• Delete the unused private CA permanently.
• ACM 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 enemies. BPA is an S3 best practice and is enabled by default on new buckets.

Google Cloud Certificate Authority Services

This topic outlines some of the best practices that can help you use Certificate Authority Service more effectively.

• Role and access control: Individuals shouldn’t be assigned more than one role at any given time. Everyone holding an assigned role should be adequately briefed and trained on their responsibilities and security practices. If you want to assign a diverse set of permissions to an individual, it is recommended that you create a custom role using IAM.
• In most cases, it is recommended to use the Enterprise tier to create a certificate authority (CA) pool that issues certificates to other CAs and end-entities.
• While creating a CA pool, it is recommended to carefully consider the DevOps tier, as it does not support certificate revocation.
• Secure CA signing keys by leveraging Cloud HSM.
• Enable cloud audit logs to monitor access and use of Cloud HSM signing keys.
• It is recommended not to import an existing external CA with issued certificates into CA service.
• For a Root CA and Subordinate CA, it is recommended to use the most significant key size available for that algorithm family.
  • For RSA, the largest supported key size is 4096 bits.
  • For ECDSA, the largest supported key size is 384 bits.

  (For subordinate CAs with a shorter lifetime, it is sufficient to use smaller key sizes, such as 2048 bits for RSA or 256 bits for ECDSA.)

• It is recommended that the authors of the certificate template grant the CA service user role to the members in the organization who might use that certificate template.

#	Categories	Microsoft PKI	AWS Certificate Manager (ACM)	AWS ACM Private CA (ACM PCA)	Google Cloud – Certificate Authority Services (CAS)
1	Root CA	Root CA is deployed on-premises and kept offline	AWS Certificate Manager is a service using which you can easily provision, manage and deploy public/private SSL/TLS certificates for use with AWS services and internal connected resources.	Root CA can be deployed in AWS cloud or Issuing CA CSR can be Signed by the External Root CA.	Root CA can be deployed in the google cloud – certificate authority services or Issuing CA CSR can be signed by the External Root CA.
2	Certificate Template	It is not recommended to use the default Certificate template. Certificate templates can be configured.	Use AWS CloudFormation templates to issue private certificates using AWS Certificate Manager (ACM).	ACM Private CA supports four varieties of certificate template.   Base template – pre-defined templates in which no passthrough parameters are allowed. CSRPassthrough templates – Templates that extend their corresponding base template versions by allowing CSR passthrough. APIPassthrough templates – Templates that extend their corresponding base template versions by allowing API passthrough. APICSRPassthrough templates – Templates that extend their corresponding base template versions by allowing both API and CSR passthrough.	A new Certificate template can be created in each project and location in Google cloud CAS service.
3	key algorithm and Key Size	Microsoft PKI supports the Key size as per NIST 800 standards. The minimum key size is 2048- bit. However, for any CA that has certificate expiration more than 15 years in the future, it is recommended to use RSA must be 4096 or greater or, if the CA key uses ECC, the CA key must use either the P-384 or P-521 curve.	The following public key algorithms and key sizes are supported by ACM: 2048-bit RSA (RSA_2048) 3072-bit RSA (RSA_3072) 4096-bit RSA (RSA_4096) Elliptic Prime Curve 256 bit (EC_prime256v1) Elliptic Prime Curve 384 bit (EC_secp384r1) Elliptic Prime Curve 384 bit (EC_secp384r1)	AWS ACM Private CA supports the following cryptographic algorithm and Key size for private key generation. With the advanced option, following algorithms are available: (This list applies only to certificates issued directly by ACM Private CA through its console, API, or command line.)   RSA 2048 RSA 4096 ECDSA P256 ECDSA P384	The following key algorithm and key size is used in Google cloud:   2048-bit RSA (RSA_2048) 3072-bit RSA (RSA_3072) 4096-bit RSA (RSA_4096) ECDSA P256 ECDSA P384 For a new root CA or a subordinate CA that is expected to have a lifetime in the order of years, google recommends that you use the largest key size available for that algorithm family. (For RSA, the largest supported key size is 4096 bits. and for ECDSA, the largest supported key size is 384 bits.)
4	Hashing algorithm	It is recommended to use the advance hashing algorithm (SHA 256 and above) for the new deployment and the existing PKI.	Certificates managed in AWS Certificate Manager use RSA keys with a 2048-bit modulus and SHA-256. ACM does not currently have the ability to manage other certificates such as ECDSA certificates.	ACM Private CA supports the following certificate signing algorithm. This list applies only to certificates issued directly by ACM Private CA through its console, API, or command line.   SHA256WITHECDSA SHA384WITHECDSA SHA512WITHECDSA SHA256WITHRSA SHA384WITHRSA SHA512WITHRSA	Google cloud certificate authority services supports SHA256, SHA384.
5	RFC Compliance	CA Certificates within the Microsoft IT PKI shall be X.509 Version 3 and shall conform to the RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, dated May 2008. As applicable to the Certificate type, Certificates conform to the current version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates.	AWS Certificate Manager is responsible for protecting the infrastructure that runs AWS services in the AWS cloud. AWS also provides services that can be used securely. Third-party auditors regularly test and verify the effectiveness of the security as part of the AWS Compliance Programs (https://aws.amazon.com/compliance/programs/)	Certain constraints appropriate to a private CA are enforced as per RFC 5280. However, ACM Private CA does not enforce all constraints defined in RFC 5280.	Certificate Authority Service uses the ZLint tool to ensure that X.509 certificates are valid as per RFC 5280 rules. However, CA Service does not enforce all RFC 5280 requirements, and it is possible for a CA created using CA Service to issue a non-compliant certificate.
6	CRL (Certificate Revocation List) Distribution point	Microsoft PKI deposits the CRL under LDAP (Lightweight directory access protocol) and HTTP.	AWS support centre can help to revoke a certificate in AWS Certificate Manager. You need to raise a support ticket/case for the same.	ACM Private CA automatically deposits the CRL in the Amazon S3 bucket you designate.	CRL Publication must be enabled on a CA pool for it to publish the CRL. CRL publication can be enabled during the creation of a CA pool.
7	Storage of Private Keys	It is recommended to store the private keys in a FIPS 140-2 level 3 compliant HSM	AWS certificate Manager stores the certificate and its corresponding private key and uses AWS Key Management Service (AWS KMS) to help protect the private key.	By default, the private keys for private CAs are stored in AWS-managed hardware security model (HSMs). The HSMs comply with FIPS PUB 140-2 Security Requirements for Cryptographic Modules.	CA keys are stored in Cloud HSM, FIPS 140-2 Level 3 validated and available in regions across the Americas, Europe, and the Asia Pacific.
8	Audit reports	Auditing can be enabled on a CA in windows server to provide an audit log for all certificate services management tasks.	AWS Certificate Manager (ACM) is integrated with AWS CloudTrail, a service that records actions taken by a user, role, or an AWS service in ACM. CloudTrail is enabled by default on your AWS account.	Audit reports are created to list all the certificates that ACM private CA has issued or revoked. The report is saved in a new or existing specified S3 bucket.	Cloud Audit logs can be used in Certificate Authority Services. Cloud Audit Logs provides the following audit logs for each Cloud project, folder, and organization:   Admin Activity audit logs Data Access audit logs System Event audit logs Policy Denied audit logs
9	Best Practices (high-level)	Make a detailed plan of your PKI infrastructure before deployment. Avoid installing ADCS on a domain controller. Root CA should be standalone and offline. Do not issue certificates to end-entity from a Root CA. Enable auditing events for both Root and Issuing CA. Secure the Private key with HSM (FIPS 140-2 level 3) (More details on the previous section)	ACM Certificate expiry check: Ensure removal of expired SSL/TLS certificates managed by ACM. This eliminates the risk of deploying an invalid SSL/TLS certificate in resources that trigger the front end. This might cause a loss of credibility for business as well.   ACM Certificate validity check: Ensure requests that arrive during the SSL/TLS certificate issue or renewal process are validated regularly. Root Certificate Authority (CA) usage: It is always a best practice to minimize the use of Root CA. Amazon recommends creating a separate account for Root CA. Transport layer protection is vital to ensure security. It is recommended to use only TLS version 1.1 or above and not use SSL as it is no longer secure. (More details on the previous section)	Recommended best practices to use ACM PCA effectively:   Documenting CA structure and Policies. Minimize use of Root CA. Give the Root CA its own AWS Account. Separate administrators and issuer roles. Turn on CloudTrail login. Rotate the CA private Key. Delete an unused CA (AWS bills you for a CA until it is deleted).	Role and access control: Individuals shouldn’t be assigned more than one role at any given time. Everyone holding an assigned role should be adequately briefed and trained on their responsibilities and security practices. If you want to assign a diverse set of permissions to an individual, it is recommended that you create a custom role using IAM.   In most cases, it is recommended to use the Enterprise tier to create a certificate authority (CA) pool that issues certificates to other CAs and end-entities. While creating a CA pool, it is recommended to carefully consider the DevOps tier, as it does not support certificate revocation. (More details on the previous section)
10	CA hierarchy	In a hierarchical PKI (a typical deployment), there are generally three types of hierarchies – one-tier, two-tier, and three-tier.	AWS Certificate Manager is a service using which you can easily provision, manage and deploy public/private SSL/TLS certificates with AWS services and internal connected resources.	With ACM PCA, you can design and create a hierarchy of certificate authorities with up to five levels.	When creating a subordinate CA that chains up to an external Root CA, the properties included in the CSR generated by CA Service must be preserved in the CA certificate signed by the external Root CA. The external CA can add additional extensions if it preserves the properties in the CSR. For example, the signed subordinate CA certificate must also include the same path length restriction if the CSR contains a path length restriction.
11	Redundancy and Disaster Recovery	Redundancy and disaster recovery plans should be complete during a PKI deployment’s designing and implementation planning phase.	ACM does not have an SLA. The ACM Private Certificate Authority managed private CA service has an SLA.	ACM Private CA is available in multiple Regions, allowing the user to create redundant CAs. The ACM Private CA service operates with a service level agreement (SLA) of 99.9% availability.	Google Cloud Certificate Authority services (CAS) are available in multiple regions, which allows redundancy. Google Cloud (CAS)operates with a service level agreement (SLA) of 99.9% availability.

Resources:

PcaWelcome

Certificate Authority Service

Microsoft PKI Services CP