Story
A long time ago, the company I was working do not have any private CA. When people deployed internal applications, they created with a self-signed certificates themselves. Every time I accesses these applications, my browser always showed a "Your connection is not private warning". It was annoying, and indeed also a security risk. As a DevSecOps engineer, this was a time that I should stand out and addressed this issue.
We need a private CA to issue certificates for internal applications.
Overview
Our operation is based on AWS. Luckily, AWS has a service called ACM Private CA, which allows us to create private CA hierarchies, including root and subordinate CAs.
The idea is simple.
- Create a root CA using ACM Private CA.
- Install the root CA to every employee's computer to make it to be trusted.
- Create a list of subordinate CAs for each department using ACM Private CA.
- Use the root CA to sign these subordinate CAs.
- Share these subordinate CAs to different AWS accounts through AWS Resource Access Manager (RAM), where these AWS accounts are managed by a particular department.
- Issue private certificates with their owned subordinate CAs using AWS Certificate Manager (ACM)
- Everyone gets rid of the warning.
Tutorial
Login to your AWS account and search for AWS ACM.
Step 1
There are two options to create private CA. For the root CA, click the first one. For the subordinate CAs, click the second one.
Step 2
Fill in the blank as your like.
Step 3
Choose RSA 4096 for root CA, RSA 2048 for subordinate CAs. You can also explore other options.
Step 4
These are some advanced features you can explore. For the tutorial purpose we just skip it.
Step 5
Always a good practice to tag your resource.
Step 6
Allow AWS to auto renew your private CAs.
Step 7
Check the checkbox before you have reviewed all the information.
Step 8
For your subordinate CAs, remember to sign it with your root CA.
Click the install CA certificate button. Then choose the ACM private CA option.
Select your root CA as the Parent private CA.
Notice that you will need to adjust the Path length per your need. Since a subordinate CA can be the parent of another subordinate CA, path length sets the number of subordinate CA certificates that may exist in the chain below it.
For example, if you don't want people to use this subordinate CA to sign another subordinate CA, choose 0 as the value.
You can find the definition in AWS documentation.
https://docs.aws.amazon.com/acm-pca/latest/userguide/PcaTerms.html#terms-pathlength
Step 9
Now you can share your subordinary CAs to different accounts using AWS RAM.
Keep the default setting.
Set the AWS account ID. Then review and create.
Step 10
From the destination account, you need to accept the shared subordinary CA.
Step 11
Now if you go to the AWS ACM and request a private certificate, you will be able to use the shared subordinary CA to issue your certificate.
Step 12
After you issue a certificate, you can export the certificate if you need.
Step 13
Lastly do not forget to install the root CA certificate to employees' computer. There are multiple way to do so, depends on your OS, which you can search it online.
Download your root CA certificate in here.
Conclusion
In security perspective, we have a private CA now, everyone expects they won't see the warning again. If they do see the warning, then we know the certificate in use is not properly issued, or maybe it is even a bogus website.
In operation perspective, everything is managed properly. We have a place to manage CAs and a place to manage our certificates. No messy self-signed certificates anymore.
Top comments (0)