How-To: Create a Root CA in Azure

Do I Need a Root CA?

One of the most common questions we get in our free PKI assessments is if they need to create Root CA or if they should create a SCEP CA as the Root CA. PKI Best practices recommend a two tier PKI where you have your offline Root CA and then your online issuing CAs that each issued a different type of certificate (this is to prevent impersonation by someone issuing a certificate for a different purpose). This allows you to push the Root to all your devices and don’t have to manually trust each individual CA. However, if you are cost constrained and you are not issuing certificates for different purposes in the future (remember CAs last up to 10 years), you can create a single tier PKI where your SCEP CA is your Root CA.

Prerequisites

1. Registering the application in your tenant
2. Selecting a Plan

How To Create a Root CA in Azure - Video Version

Overview - How To Create a Root CA in Azure

As mentioned in the CA Overview a Root CA is needed to be the root of trust for your PKI Deployment. In this page we will guide you on how you can create your own Root CA either using EZCA or creating your own offline CA.

Getting Started on Creating Your Root CA

To begin creating a new Root CA in EZCA, follow these steps:

1. Go to https://portal.ezca.io/
2. Login with an account that is registered as a PKI Admin in EZCA.
3. Navigate to Certificate Authorities.
4. Click on the Create CA
5. Select Root CA.
6. Click Next

Entering CA Information

In Step 2, you will configure the basic identifying information for your Root CA.

1. Enter Common Name: This is the name of the CA how it will appear in the certificate.

2. (optional) Enter a CA Friendly Name. This is the name that will appear in the EZCA portal, by default we will use the Common Name

3. (optional) Enter an Organization. The Organization field is an optional certificate field that usually has the company name.

4. (optional) Enter an Organization Unit. The Organization Unit field is an optional certificate field that usually contains the unit that runs this CA (For example: IT or HR).

5. (optional) Enter a Country Code. The Country Code field is an optional certificate field that identifies the country where this CA is located.

6. Click Next.

   

Cryptographic Requirements

In Step 3, you will configure the cryptographic settings for your Root CA. Unless you have specific compliance or security requirements, leave the default cryptographic values for best security and compatibility and click Next.

Validity Period

In Step 4 you can configure the lifecycle management of your Root CA, such as validity period and notification settings.

1. Select your CA Validity Period, in years. Learn more about Validity Period best practices

2. Enter a Notification Email. This email address will receive notification emails when the CA is approaching expiry, in addition to your PKI Administrators.

3. Select the Lifecycle Action you want EZCA to take when expiry of the CA is approaching, either Email or Auto Renew & Email.

   Note

   For Root CAs we recommend to have a manual Lifecycle since the new Root will have to be added to the trusted root stores of your clients which requires manual steps from the IT team.

4. Select the Percentage Lifetime of the CA when you want EZCA to take the selected lifecycle action.

   

CA Certificate Revocation List

1. Select if you want to enable CRL (Certificate Revocation List) Distribution for this CA. This is highly recommended and is enabled by default.

2. Optionally change any advanced settings by clicking the expand button. See below for more details.

3. Click Next.

   

CA Certificate Revocation List Advance Settings

1. Expand the Advanced Settings section.

   

2. Enter the desired CRL Validity Period in days. This is the time period that each Certificate Revocation List (CRL) is valid before a new CRL is published.

3. Enter the desired CRL Overlap Period in hours. This is the time period that the old CRL remains valid after a new CRL is published to allow for replication delays.

4. (optional) Enter the CRL Custom URL where you will publish your CRLs. By default, EZCA will host the CRL for you in EZCA’s global CDN. However, if you have specific requirements to host the CRL in your own infrastructure, you can enter the URL here. Note that you will be responsible for publishing the CRL to this URL and ensuring its availability.

   Warning

   Custom CRL endpoints are supported by EZCA by adding the CRL endpoint as the CRL endpoint in the certificate. However, your PKI admins are responsible from getting the CRL from EZCA and posting it in that specific endpoint.

5. (optional) You can Enable OCSP to allow Online Certificate Status Protocol for this CA. See below for more details.

6. Click Next.

   

How To Enable OCSP (Online Certificate Status Protocol) For Your CA

When creating a new CA, inside the CA Revocation (Step 4) advanced settings, you can enable OCSP (Online Certificate Status Protocol). OCSP is only recommended if you have specific requirements for validating certificates. While OCSP allows quicker revocation, it increases the cryptographic load on the CA and can limit the scalability of the CA. Depending on your CA tier, this can impact your performance.

• A Basic CA allows 1 cryptographic operation per second (certificate creation or revocation check).
• A Premium CA allows 10 cryptographic operations per second.
• An Isolated CA allows 160 cryptographic operations per second.

Learn more about OCSP vs CRL in the Keytos blog.

1. If you want to enable OCSP, select the Enable OCSP option.

2. Enabling the OCSP will create an OCSP endpoint for this CA in the same region you select for your OCSP (this is included with the price of your CA). If you require extra scalability you can create multiple OCSPs for your certificate authority in different regions.

   Note

   Each extra OCSP created for your CA will be charged as an extra Certificate Authority.

   

CA Issuance Policy

Now that you have configured the basic settings for your Root CA, in Step 5 you will configure the issuance policy for your CA for how it will issue certificates.

1. Select the Certificate Template you want this CA to issue. Leave as “Subordinate CA Template” unless creating a 1-tier PKI. This is not recommended if you plan to issue different types of certificates in the future.

   

2. Enter the Maximum Certificate Validity Period. This is the largest certificate lifetime that this CA can issue. EZCA automatically calculates the recommended maximum based on CA lifecycle best practices.

   

3. (optional) Under Advanced Settings, set your EKU (Extended Key Usage) for the CA. These are the key usages that the certificates are used for, by default it is “All”. However, some RADIUS servers and Linux-based systems use OpenSSL which does not support the all EKU. If you restrict the root CA’s EKUs, include every EKU that the subordinate CAs you create under this root will need (for example Client Authentication, Server Authentication, KDC Authentication, and Smart Card Logon for SCEP, Windows Hello, and domain controller certificates), since certificates under this root cannot use EKUs the root does not allow.

4. Click Next.

Select The Location for Your Certificate Authority

1. Select the location where you want your CA to be created.

2. (optional) If you want to create a geo-redundant CA, select an additional location.

   Cost of Geo-Redundant CAs

   Each extra location will be charged as an extra Certificate Authority (CA) at the same tier as the original CA.

3. Click Create.

   

Download Your Certificate Authority Certificate

1. Once the CA is created click Download Certificate and push it to all your devices as a trusted root. Learn more in this guide

   

How To Restrict Access to Your Root CA by IP Address

By default, EZCA accepts certificate requests for your Root CA from any IP address. To add a network layer of defense to your cloud PKI, you can restrict the IP addresses that can request and revoke certificates from your CA. This way, even if a credential, secret, or challenge is leaked, it cannot be used to issue or revoke certificates from outside your trusted networks.

1. Go to your EZCA portal and sign in with an account that is registered as a PKI Admin in EZCA.

2. Navigate to Certificate Authorities and click View Details on the CA you want to restrict.

   

3. Scroll down to the Restrict Access By IP Address section. By default, All IP addresses can interact with your CA is selected, which means the CA does not filter requests by IP address.

   

4. Choose whether you want to allow only specific IP addresses (allow list) or block specific IP addresses (block list), and follow the steps in the matching tab below.

• Allow Specific IP Addresses
• Block Specific IP Addresses

Once you have added your IP addresses, finish setting up your IP restrictions:

1. Check Allow Keytos to request and manage certificates for auto-renewal and revocation (recommended). This lets Keytos keep automatically renewing your certificates (Including certificates managed by other Keytos Services such as EZRADIUS) and revoking them when needed, without those requests being blocked by your IP restrictions. If you leave it unchecked, your IP restrictions will block these Keytos actions, which can lead to expired certificates and outages.

   

2. Scroll back to the top of the page and click Save CA Changes to apply your IP restrictions.

   

How to Remove IP Restrictions in my Cloud PKI CA

To remove the restriction later, go back to the CA’s View Details page, select All IP addresses can interact with your CA, and click Save CA Changes.

Enjoying EZCA? Leave Us a Review!

We hope you’re enjoying using EZCA to issue your X.509 certificates! If you have a moment, we would greatly appreciate it if you could leave us a review on G2. Your feedback helps other IT professionals discover EZCA and helps us continue to improve our service. Thank you for your support!