Private Certificate Authority in PAM360
Private Certificate Authorities (CAs) play a vital role by connecting the root CA and end entities. The root CA signs the certificate of the intermediate CA with the private key, which is then responsible for issuing certificates to websites, servers, or individuals. This hierarchical setup ensures a chain of trust, with the root CA's private key kept offline for enhanced security. Private CAs provide control, flexibility, and the ability to revoke compromised certificates. Private CAs also:
- Enable scalable growth of the PKI by distributing the workload across multiple private CAs.
- Helps in cutting cost measures for procuring multiple certificates from external vendors for internal organization purposes.
- Manage the complete life cycle of certificates internally used in the organization, including creation, deployment, expiry alerts, and renewal.
Organizations can create different private CAs in PAM360 for specific purposes, regions, or units, allowing them to enforce various policies and procedures. If a private CA's private key is compromised or it violates trust, the root CA can revoke its certificate, invalidating all the certificates it has issued via PAM360. This revocation capability adds an extra layer of control and security. Private CAs allow for the scalable growth of the PKI by creating more private CAs to handle the increasing number of entities requiring certificates, ensuring efficient and responsive certificate issuance.
At the end of this document, you will learn about the following related to the Private CA module in PAM360.
- How Private CA Works in PAM360
- Creating a Root Certificate
- Certificate-Based Operations
3.1 Request Certificate
3.2 Renew Certificate
3.3 Revoke Certificate
3.4 Delete Certificate - Private CA Use-Case in an Organization
Navigate to the Private CA section in the SSL window and perform the desired operations. The sequence of these operations does not need to be followed exactly.
1. How Private CA Works in PAM360?
Within PAM360, the administrator/SSL power user who possesses the root certificate generates an intermediate certificate. Following creation, the root certificate is either kept offline or unused for heightened security. Then, the intermediate certificate can be used by the administrator or the SSL power user (self-owned/shared by the administrator) to sign the end-user certificates by assuming the role of a Private CA. As the Private CA, they can create subsequent end-user certificates or additional intermediate certificates. PAM360 will display the root, intermediate, and end certificates hierarchically, allowing users to verify the certificate chain of trust.
Note: Utilizing intermediate certificates to sign end-user certificates is strongly recommended. In the event of a private key compromise, revoking the corresponding intermediate CA solely will remove its end certificates subordinates feasibly, thus ensuring the ability to use the remaining certificates from other intermediate CAs smoothly without any complications.
2. Creating a Root Certificate
To establish a Private CA in PAM360, it is necessary to have a certificate with private key with signing capabilities. This can be self signed or third-party CA signed. If you are an administrator/SSL power user and have the certificate with a private key in your SSL repository, you can designate it as the root certificate by selecting the 'Mark as Root' option. Alternatively, you can also create a root certificate directly from the Private CA window by following these steps:
- Navigate to Certificates >> Certificates >> Private CA and click Create Root Certificate.
- In the resulting pop-up, you have the choice to either generate a new root CA within PAM360 or import a root CA by providing the Private Key Password for the certificate to be imported.
- If you opt to create a root certificate CA using PAM360, complete all the required details, and click Create.
Upon completion of these steps, you will have effectively generated a root certificate. This newly created root certificate will be visible within the Private CA window and will also be included in the SSL repository of PAM360.
Note: To ensure the effectiveness of any certificates issued by a private CA using a root/intermediate certificate within an internal environment, the corresponding root/intermediate certificate must be added to the Root/Trust/CA store. You can easily accomplish this task in PAM360 by deploying the certificate to the MS store.
3. Certificate-Based Operations
3.1 Request Certificate
For internal organizational needs, users with the administrator/SSL power user role have the ability to create certificates using the root or intermediate certificates from the private CA window. To do this, follow these steps:
- Navigate to Certificates >> Certificates >> Private CA. Here, you will find a list of root certificates available in PAM360.
- Click Request Certificate either from this section or from the respective certificate chain (root certificate >> intermediate certificate) where the certificate needs to be created.
- In the pop-up window, provide all the required details and select the certificate (root/intermediate) that will be used to sign the new certificate.
- If you are requesting a certificate to act as an intermediate certificate, which will be used by the private CA to sign further end-user certificates, enable the Sign intermediate certificate checkbox.
- If you already have a CSR (Certificate Signing Request) available in your PAM360 repository, click Select CSR next to the Common Name field and fill in the remaining entries.
- After completing the above steps, click Create to generate an intermediate/end-user certificate.
- By clicking on the CA-Server Hierarchy Graph next to the certificate in the Signed by window, you can view the detailed hierarchy of the certificate chain of trust.
Note: You can access the respective certificate chain by clicking on the Signed Certificates icon next to the corresponding root/intermediate certificate.
The details of the each certificates can also be viewed by clicking on the respective certificate from the CA-Server Hierarchy Graph.
Following these instructions will allow you to create the desired certificates using the appropriate root or intermediate certificates from the private CA window.
3.2 Renew Certificate
From the private CA window, you have the capability to renew certificates that were created from there. To do this, follow these steps:
- Navigate to the respective certificate hierarchy page and select the certificates that need to be renewed.
- Click the Renew Certificate button located in the top pane.
- Enter the desired number of validity days for the renewed certificate and click Renew.
- If you are renewing an intermediate certificate, the validity days should be less than the root/intermediate certificate used to sign the intermediate certificate.
- If you are renewing an end certificate, the validity days should be less than the root/intermediate certificate used to sign the end certificate.
Note: The validity days specified for the renewed certificate must always be shorter than the validity days of the certificate used to sign it.
For example:
By following these steps, you can successfully renew certificates from the private CA window while ensuring the validity days adhere to the signing certificate's limitations.
You can also avail of the auto-renewal feature under Admin >> SSL Certificates >> Certificate Renewal. Enable the checkbox for Private CA and enter the number of day to renew the certificate before expiry and the recurrence time. Enable the remaining requirement and click Save to complete the auto-renewal configuration.
3.3 Revoke Certificate
From the private CA window, you can revoke issued certificates. If you discover that the private key of the certificate has been compromised or if it violates the certificate chain of trust, the root CA or intermediate CA can revoke its certificate, thereby rendering all the certificates it has issued invalid.
For example, if an intermediate certificate, signed by the root certificate, has been used to sign multiple end-entity certificates and its private key is compromised, the root CA can revoke the intermediate certificates, which will subsequently revoke all the certificates issued by the compromised intermediate certificate. To revoke a certificate created under Private CA:
- Navigate to the respective certificate hierarchy page and select the certificates that need to be revoked.
- Enter the reason for revocation and click Save to revoke the selected certificates.
3.4 Delete Certificate
Within the private CA window, you can choose to delete issued certificates. To delete certificates, proceed as follows:
- Access the respective certificate hierarchy page and select the certificates you wish to delete.
- Click on Delete to remove the selected certificates.
- In the ensuing pop-up, check the box labeled Add selected certificates to 'Excluded certificates' to prevent the certificates from being discovered in subsequent deployments, if deployed.
By following these steps, you can delete certificates from the private CA window. This enables you to effectively remove the chosen certificates and exclude them from future discovery.
4. Private CA Use-Case in an Organization
Real-Time Scenario
Consider Lisa, an IT administrator responsible for managing all SSH keys and SSL certificates in her organization. With numerous user machines, resources, servers, and websites to handle, Lisa faces a significant workload. To address this challenge, she leverages PAM360' Private CA feature.
PAM360 Solution
To begin, Lisa utilizes the organization's owned/self-signed root certificate to create an intermediate certificate with certificate-signing capabilities. She then shares this intermediate certificate with another team member, granting them the administrator/SSL power user role in PAM360.
Following the PKI chain of trust, the newly authorized team member, possessing the root-signed certificate, functions as a private CA. They can now sign all the necessary certificates required for the deployment of internal team resources, effectively distributing the workload and responsibilities previously borne by Lisa.
In the event of a compromised or potentially threatening certificate shared with the private CA for signing end-user certificates, Lisa retains the ability to revoke all certificates issued by the private CA. Consequently, she can deploy a new set of required certificates to ensure continued security and mitigate any risks.