(1 votes, average: 5.00 out of 5, rated)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

June 5, 2024 Comments closed

15 Steps for Setting Up Your Own Certificate Authority

in Hashing Out Cyber Security, Monthly Digest

A private certificate authority can significantly increase the security of your internal network systems and data… but only if the CA is correctly set up. Here’s how to do it correctly.

Data from a 2022 survey indicates that more than half of organizations admit they don’t follow the key management best practice of storing their cryptographic keys on hardware security modules (HSMs).

But generating and storing cryptographic keys on an HSM is just one of many private CA cybersecurity best practices businesses must adhere to when securing their internal infrastructures and data using public key infrastructure (PKI). There’s more to it than that, and we’re here to break it down.

This article will walk you through the process of setting up a certificate authority (CA),  so you know how to do it right and don’t leave your organization open to disaster.

Let’s hash it out.

Why Self-Signed and Public CA Certificates Won’t Cut It in Private PKI

Have you ever wondered whether you can use self-signed certificates or certificates from a public CA to secure your internal networks? The answer is a resounding NO — and this is the case for several key reasons:

• Self-signed certificates aren’t trusted because anyone can issue them.
• Self-signed certs can’t be revoked, which spells bad news. 
• Self-signed certificates should be limited to use in testing environments.
• Public CAs can’t issue certificates for private domains, device IDs, etc.
• Using publicly trusted certificates for strictly internal uses may be expensive and cumbersome at scale (depending on your organization’s specific use cases).
• Publicly trusted CAs are more rigid in terms of usability and don’t have the same level of flexibility or customization as a private CA.

For these reasons (and others), it’s imperative for organizations to set up private certification authorities to secure their internal networks and resources. Knowing this, let’s jump straight into setting up your own certificate authority for internal uses.  

Setting Up Your Private Certificate Authority: There Are 2 Ways to Do It

Option #1: Set Up Your Own Private CA

You can host a private CA on-prem or in the cloud to secure your internal resources. Depending on your needs, available skill sets, and budget, you may prefer one option over the other. Each has its own pros and cons; you just have to pick the option that meets your needs (e.g., cloud-based private PKI is cheaper than on-prem solutions).

There’s a time and place for do-it-yourself (DIY) jobs. For example, replacing your sink faucet isn’t rocket science, and it’s certainly doable for the average homeowner. However, setting up a private CA is infinitely more complicated and requires someone with the know-how and skills to set up and operate. Unfortunately, many companies choose to “DIY” their private CA, but they cut corners to save time… which results in an insecure, inefficient, or difficult to use system.

An Overview of What Goes Into Setting Up a Private CA

So, what exactly does setting up a private CA entail? Here’s a quick overview:

• Setting up a multi-tiered private PKI infrastructure from scratch.
• Securing your private CA to keep it secure and free of tampering risks.
• Defining certificate issuance policies to enable trust in the private CA-issued certificates.
• Setting explicit application and device configurations in order for them to trust certificates issued by the private CA. 
• Creating a new system or integrating a third-party vendor solution that enables certificate lifecycle monitoring and management to maintain reliability and uptime. (If your private CA goes down unexpectedly, it doesn’t do you any good, does it?)
• Maintaining reliable audit logs for certificate management, record-keeping, and compliance-related purposes.

But building a private CA from scratch isn’t for everybody. And this is why we have an alternative approach…

Option #2: Opt For a Managed PKI (mPKI) Solution for Your Private CA

A managed private CA, or managed PKI (mPKI), is the more cost-effective option in the long run. It requires less up-front and ongoing financial resources in terms of IT hardware, personnel, and operational costs. (You’ll see what we mean as we go through the list of manual steps for setting up your own certificate authority on your own.)

It also offers greater protection for you and your company in that the service provider handles operational processes and management, and you’re not left on your own to figure out how to fix things that would otherwise go wrong.

DigiCert estimates that setting up and operating a private PKI costs businesses more than $368,000 in “total acquisition and deployment costs” across three key areas. The CA’s calculations put three-year costs at more than $545,000 based on one-time costs + recurring annual costs. 

DigiCert Trust Lifecycle Manager

DigiCert Trust Lifecycle Manager is an all-in-one hosted solution that enables you to manage the lifecycles of your private PKI digital assets at scale. It’s a managed PKI solution that integrates with many organizations’ existing architectures.

Using a managed private CA also enables you to skip most of the tasks involved with setting up your own certificate authority because the majority of those functions are handled for you.

Your network devices and data are only as secure as the measures you implement. And a poorly implemented private CA is as useful as having no private PKI at all.

A 15-Step Guide for Setting Up Your Private Certificate Authority

If you decide to go the DIY route, there are steps you’ll need to take to get your private certificate authority up and running. We’ve broken this section down into three overarching implementations.

Section #1: Create the Underlying Infrastructure

1. Choose a Software Platform to Manage Your PKI

When setting up your own certificate authority, you’ll need to choose a software tool that allows you to manage your private PKI. Keyfactor’s data shows that less than one-third (32%) of organizations are employing dedicated certificate lifecycle management software.

Many organizations using Microsoft systems opt for using Microsoft CA through Microsoft Active Directory Certificate Services (AD CS) because it allows you to leverage AD. Microsoft CA is the “devil you know”; it integrates nicely with third-party tools and services and is great for on-prem deployments.

Other popular open-source alternatives to Microsoft CA include:

• OpenSSL utility: OpenSSL is a fairly basic, bare-bones solution that will work for launching and managing small PKIs. But if you’re planning to have more than just a handful of certificates, you’d be better served using a more comprehensive PKI management system.
• EJBCA: Formerly called Enterprise Java Beans Certificate Authority, this open-source tool is a more robust and scalable option for certificate issuance, validation, and management than its OpenSSL utility counterpart.  

2. Set Up a Secure CA Database and Certificate Database Log

This step involves specifying the database location and setting up whatever access controls and permissions are necessary to ensure that only those you assign access to have it.

The certificate database log tracks data relating to every transaction that’s taken place involving the certificate database. In addition to the CA certificates and keys, the CA database and the CA database log are resources you’ll regularly want to back up.

3. Set Up Secure Environments for Your Offline (Root) and Online (Issuing) CAs

This step in setting up your own certificate authority is all about crossing your T’s and dotting your I’s regarding security. You must execute a mix of physical and digital security measures to protect your private CA ecosystem against as many attack vectors as possible.

Physical Security Measures

• Implement separation of duties and dual-custody authentication for access and to perform any operations relating to the root CA.
• Administer physical security measures (think ID key card access, physically locked cages, USB port blockers, cameras, motion sensors, 24/7 access monitoring, armed guards, etc.). We’ll speak more about these later in the article, too, when discussing how to secure your trusted root.
• Use an online hardware security module (HSM) to securely generate and store your online intermediate or issuing CA private keys. This makes the keys available for cryptographic operations without giving direct access to them.
  • Use FIPS 140-2 Level 2 or higher compliant HSM devices for your root and issuing CAs.
  • Be sure to clone your private keys and store them on two or more HSMs (of the same make and model). It’s never a good idea to have a key in production that doesn’t have a secure backup in place that you can fall back on.
    • Root CAs: Store these secure backups in separate geographic locations, ideally hundreds of miles apart, in secure data centers. This will provide added security should something go wrong in one geographic region (think hurricane, wildfire, or other physical threats), ensuring you have one or more secure backups.
    • ICAs: Maintain both online and offline backups of your intermediate or issuing CA in the same way.

Digital Security Measures

When setting up your intermediate CA server, you’ll also need to apply digital security to the equation as well:

• Install and maintain current anti-virus and anti-malware solutions on your issuing CA server(s).
• Set up software-based firewalls
• Use vulnerability scanner solutions
• Implement other server-hardening techniques

Section #2: Create and Securely Store Your Root and Issuing CAs

4. Generate a Root CA Certificate and Corresponding Key Pair

A root CA is your root of trust. It’s a self-signed entity that’s used to create and sign subordinate CAs. A subordinate CA, on the other hand, serves as a buffer and is used to issue end-entity certificates.  

To create your root CA certificate and private key, you’ll need to perform a key ceremony, which is a formal, highly secure, and carefully documented process. Here’s a quick overview of what a key signing ceremony (KSK) looks like:

• Set a password or PIN. Setting up a secure password (or, ideally, passphrase) adds another layer of security to your key to prevent someone from using it to generate a root CA certificate without your knowledge or authorization. This is a baseline FIPS 140-2 Level 2 and higher authentication security measure. (The higher the FIPS certification level of the device, the more additional security and authentication requirements are added to it beyond just a password, such as using an access token, ID access card, or biometric mechanism.)
• Choose your root CA key algorithm. Although you technically don’t have to abide by the National Institute of Standards and Technology (NIST) key management security standards for PKI deployments, they still provide a good baseline you can follow to achieve at least minimal security for your internal private key infrastructure. For example, consider using RSA 2048 as the absolute minimum.  
• Set your distinguished name fields. This includes info about our organization, including your common name (CN), organizational name, locality info, etc.
• Set your certificate parameters. This includes the CA’s name and the validity periods of the certificates it issues.

For a private CA root CA, the key will need to be generated and stored on a secure HSM that’s FIPS 140-2 Level 2 compliant (as a minimum). Compare this to a publicly trusted CA, which must use a FIPS 140-2 level 3 or higher HSM for its root of trust, according to industry baseline requirements.

5. Generate an Intermediate CA Certificate and Key Pair and Secure It Using a Unique Passphrase

Now, this next part of setting up a proper PKI architecture entails creating an intermediate CA to separate the root CA and the endpoint certificates that chain back to it. (NOTE: A subordinate CA can be either an intermediate CA or an issuing CA.)

To ensure the security of the key, you’ll generate and store it in an online HSM. As with the root CA, you’ll want to create one or more backups (clones of the key) and store them on the same make and model HSM. But unlike the root CA, an ICA has to be available (online) to sign certificates, OCSP responses and CRLs.

In a two-tier CA hierarchy, which is the most common, this subordinate CA is typically referred to as an issuing CA, and this is what this architecture looks like:

There are also three-tier CA hierarchies, which include both types of subordinate CAs. However, they’re less common and are too complicated for many organizations’ needs.

Although some organizations use one-tier hierarchies, this practice isn’t recommended because there’s no buffer between the online root of trust and the leaf certificates it issues. So, if something goes wrong with the root (e.g., it becomes compromised), then all certificates issued by it would have to be revoked and you’d have to start over with a new root. This is a nightmare that could be avoided by creating one or more buffer (intermediate) CAs.

6. Securely Store the Root CA Key Offline

Once your intermediate CA is created, it’s time to take the root and its private key offline. (Think of an air-gapped computer.) Leaving the root of trust online and accessible risks compromising everything downstream.

If your root CA private key becomes compromised, then any certificates that chain back to that key are now at risk and the devices and data they secure are vulnerable. This is why you’ll need to keep the root CA and its private key securely stored offline. The most critical way to protect your root of trust is to make it remotely inaccessible by keeping it in a secure location and protecting it against physical threats.

A good rule of thumb is to store your root CA key in an offline HSM that’s stored in a secure, locked environment. Think of your own version of Fort Knox. Organizations often use PKI-based key cards to restrict access to the room and motion sensors and cameras to detect and record activities inside and outside of that space. (Think of the physical security measures we mentioned in step #1 for the ICA.) But for root CAs, take that security and kick it into a higher gear. So, be sure to clone your root CA offline in two or more HSMs that are stored in physically secure environments in different geographic locations.

What about a Faraday cage to block electromagnetic channel attack vectors? Sure, go for it. And while you’re at it, consider shielding your cables and implementing USB port blockers, too. The point here is to add as many layers of protection to your root CA as possible to keep it free of compromise risks.  

Section #3: Create and Enforce Policies and Rules

7. Set Your Private CA Roles to Define Responsibilities and Permissions

In organizations that have just a handful of individuals handling all of these tasks and responsibilities, it’s likely that you’re going to have fewer people wearing more hats. This means you need people who have broader skill sets to handle everything, or you need to hire a third party to handle setting up a certificate authority for you.

Compare this to larger organizations, where it’s likely that you’ll have greater bandwidth and resources to implement more granular control over your CA, so each person may handle more limited tasks individually.

It’s best to separate these roles and not have too many hands in too many pots. But what are examples of the granular roles you’re likely to find within a private PKI environment? According to Microsoft, the following roles exist within Microsoft private CA implementations:

• Backup Operator or Administrator: Although we haven’t yet discussed CA backups, this role is responsible for ensuring that at least one current CA database backup exists (ideally, multiple copies to ensure redundancy) and handling data restoration in the event something goes wrong.
• CA Administrator: This individual manages CA access, certificate revocation mechanisms, and the processes involved in certificate issuance. This position overlaps the next two on the list; in some organizations, a CA Admin may handle all three roles’ responsibilities).
• Enrollment Agent: This role manages the certificate templates and enrolling certificates for authorized users.
• Key Recovery Manager: This person is responsible for everything relating to archiving and recovering cryptographic private keys.
• Certificate Manager: This person is responsible for managing the lifecycles of your digital certificates and cryptographic keys.
• Security Auditor: This person’s job is to review CA audit logs to ensure certificates are being issued and revoked according to your CA policies.

8. Specify How the CA Will Issue and Revoke Digital Certificates

• Cert profiles and types. This is where you set up custom certificate profiles (certificate templates) for specific types of use cases and user groups. For example, custom or end-entity TLS certificates, end-entity client authentication certificates, code signing certificates, CA certificates, document signing certificates, email signing and encryption certificates, etc.)
• Document rules and processes for validation and certificate issuance. This is one of the beautiful (and onerous) parts of operating a private CA: you have the ability to implement your own rules and processes regarding certificate validation and issuance. Want every certificate to include key pieces of info? No problem. Just add it as a rule and go about your day. 
• Set up robust written certificate policies. A certificate policy provides a statement outlining the trustworthiness and applicability of the digital certificates that a CA issues. This is true of certificates for both publicly trusted and private CAs.
• Define the key types you’ll allow in your issuance policy. Figure out which type(s) of keys you want to support — e.g., RSA, ECC, ECDSA — for use within your private PKI.

9. Ensure You’ve Got Your Certificate Revocation Bases Covered

This step involves setting up your certificate authority’s revocation mechanisms. After all, if you want to issue trusted digital certificates, then you must also have a way to revoke them in the event that their keys get compromised later or it’s discovered that the certificates were improperly issued.

Here, you’ll need to decide whether to use a certificate revocation list (CRL) or set up an online certificate status protocol (OCSP) server. These mechanisms inform clients when they should no longer trust a certificate by communicating its revocation status.

10. Install Root CA in Trust Stores Across Your Network Devices

Simply creating a root of trust isn’t enough; you’ll need to deploy it across your network(s) in order for devices to trust it.

However, deploying your private root CAs manually is a tedious process. It entails going from one device to the next to install the certificate onto each device’s certificate trust store using the Microsoft Management Console (MMC) with the Certificates snap-in. Otherwise, the private root CA won’t be trusted by other devices on the network.

Needless to say, this time-consuming approach will take you or your team away from other functions that require critical thinking. The good news is that there’s a way around this issue: use a centralized certificate management platform that allows you to deploy these certificates to trust stores across your network remotely.

11. Create an API for Certificate Requests & Issuance

Make your private PKI as user-friendly as possible with an intuitive application programming interface (API). This is the tool authorized users will use to request, renew, revoke, or download their digital certificates.

But setting up your own certificate authority from scratch often means building a custom API. One approach could involve using RESTful libraries. But what if creating this type of custom tool isn’t something that’s in your wheelhouse? It can cause a lot of headaches for you and your team. But the good news is that there are third-party solutions that have APIs built into them.

Section #4: Prepare for the Worst, Hope for the Best…

12. Set Up Backup Systems for Your Private PKI Certificates and Database

Before you go any further, take the time to create backups of your cryptographic keys (via cloning, which we addressed earlier), certificates, database, and other PKI-related digital assets. This is what will get your business back up and running when something goes wrong that affects the security of your digital certificates and the assets they secure.  

The process of creating and maintaining your private PKI backups will vary depending on the tools and software you use to create and manage your PKI. According to Microsoft, you can do this for Microsoft CA via the Certificate Authority snap-in in AD CS. Here’s a quick video that shows how to back up your certificate authority on Windows Server 2022:

13. Include Your Private CA in Your Business Continuity and Disaster Recovery Plans

Life sometimes throws curveballs and things go wrong. You could be the victim of a robust cyber attack or a natural disaster could occur. Regardless of why something bad happens, it’s crucial that you have plans in place to keep your business operational while you’re in the thick of it and get you back to 100% afterward you’ve resolved the situation.

One of the biggest mistakes you can make when implementing a private PKI is to not include it in your emergency plans. Your company’s private CA trust chain is a crucial element in keeping your most sensitive data secure despite the circumstances. To ensure they remain secure, you need to incorporate your private PKI into those pans.

Section #5: Operate and Manage Your Private Certificate Authorities

14. Enable Certificate Automation to Mitigate Risks

Keyfactor’s data shows that 71% of surveyed IT professionals indicate they don’t have enough staff to maintain their PKIs, and 75% say they need more resources.

Certificate automation takes the burden of monotonous tasks off your employees’ shoulders. Implementing automation helps you ensure that the certificates and keys are properly requested, issued, managed, and revoked according to industry standards and best practices.

According to the National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards and Technology (NIST), automating certificate management minimizes human error and maximizes efficiency at scale. So, what does NCCoE/NIST recommend organizations include in their guidelines and policies?

“Automation should be used wherever possible for the enrollment, installation, monitoring, and replacement of certificates, or justification should be provided for continuing to use manual methods that may cause operational security risks.”

However, implementing effective certificate automation is more than just having the right tools in place. It’s also about:

• Setting the appropriate policies, processes, roles, and responsibilities.
• Regularly evaluating the tools, systems, and processes in place to ensure scalability and continued effectiveness as your business grows and changes over time.
• Freeing up your employees from monotonous tasks so they can focus on other mission-critical functions.  

15. Start Issuing Certificates to Secure Your Internal Sites, Users, Apps, and Devices

Alright, it’s time: We’ve now reached the point of this process where you can start putting all of your hard work to good use. Start issuing privately trusted certificates from your subordinate CA(s) to secure everything from your intranet sites and apps to your network users and other connected devices.

Setting up your own certificate authority enables you to secure communications across your network(s) and ensure that only authorized, authenticated individuals can access your most sensitive systems and data.

Final Thoughts on Setting Up a Certificate Authority for Your Business

No two organizations are identical. Each company varies in terms of having different security needs, financial resources, capabilities (i.e., personnel skills and knowledge), and resources. This is why it’s crucial for businesses to carefully weigh the benefits and drawbacks of different PKI deployment methods to choose the right private CA deployment solution for them.

Setting up your own CA can be a daunting, expensive, and time-consuming endeavor. But the good news is that you don’t have to do it alone. Whether you’re setting up an on-prem private CA or want to learn more about mPKI solutions, we’re here to help. Learn more about our managed PKI solutions.

• #Certificate Authority
• #Private PKI
• #Set Up Private CA