Difference between various Public Key Infrastructure (PKIs)

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.

Conclusion  

Public Key Infrastructure (PKI) plays a vital role in ensuring secure communication by utilizing digital certificates. The combination of key components like Certificate Authorities (CAs) and Registration Authorities (RAs) work together to authenticate entities and manage certificate lifecycles. By utilizing encryption through public and private key pairs, PKI ensures data confidentiality and authenticity, ensuring infrastructure security.

Different vendors provide tailored PKI solutions, each with different merits serving unique use cases. Microsoft PKI advocates for secure key management with offline Root CAs and Hardware Security Modules (HSMs). AWS Certificate Manager (ACM) offers automated certificate management, focusing on validation and security for cloud resources. Google Cloud’s Certificate Authority Service emphasizes role-based access control and the use of strong encryption keys. These vendor-specific recommendations ensure highly secure PKI deployment across various platforms and environments.

How can Encryption Consulting help?

At Encryption Consulting, we specialize in designing and migrating PKI infrastructures that align perfectly with your organization’s unique security needs. We provide comprehensive PKI design and implementation services for both existing and new PKI infrastructures. Our on-premises solutions include Microsoft PKI, while our cloud-based PKI solutions utilize leading cloud service providers such as AWS Certificate Manager, AWS Certificate Manager Private CA (ACM-PCA), Azure PKI, and Google Cloud Certificate Authority Manager.

Resources:

PcaWelcome

Certificate Authority Service

Microsoft PKI Services CP