How to Create a Subordinate SSL CA in Azure

Prerequisites

  1. Registering the application in your tenant
  2. Selecting a Plan
  3. Create First Root CA

How To Create Issuing/Subordinate CA - Video Version

Overview - How To Create Issuing/Subordinate CA

A Subordinate or Issuing CA is critical on any PKI hierarchy this is the Certificate Authority in charge of issuing end certificates. In this page we will guide you on how you can create your own SSL CA and chain it up to a Root CA (EZCA Root or Offline Root).

Getting Started on Creating Your Issuing CA

  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. View Your Azure CAs
  4. Click on the “Create CA” Create Azure Cloud CA
  5. Select Subordinate/Intermediate CA. Select Subordinate/Intermediate CA Type
  6. Click Next

Entering CA Information

  1. Enter Common Name: This is the name of the CA how it will appear in the certificate.
  2. (Optional) Enter 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 the Organization The Organization field is an optional certificate field that usually has the company name.
  4. (Optional) Enter the 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 the Country Code The Country Code field is an optional certificate field that identifies the country where this CA is located.
  6. Click Next. CA Details

Cryptographic Requirements

  1. Unless you have specific compliance or security requirements, leave the default cryptographic values for best security and compatibility. CA Cryptographic Details

Set Your CA Validity Period

  1. Select your Validity Period Learn more about Validity Period best practices
  2. Enter a Notification Email this email address (as well as the PKI Administrators) will get all the notifications for the lifecycle of the CA.
  3. Select the lifecycle action you want EZCA to take when expiry of the CA is approaching
  4. Select the percentage of lifetime of the certificate when you want EZCA to start taking Lifecycle actions. Certificate Authority Lifecycle Details

CA Certificate Revocation List

  1. Select if you want this CA should issue a CRL (Highly recommended)
  2. Click Next. Certificate Authority Certificate Revocation List (CRL) Details

CA Certificate Revocation List Advance Settings

Changes to this section are only recommended for PKI experts with specific requirements.

  1. Click the expand button CRL Details
  2. Enter the desired CRL Validity Period in days
  3. Enter the desired CRL Overlap Period in hours
  4. (Optional) Enter the CRL endpoint where you will publish your CRLs

    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.

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

Inside the CA Revocation advanced settings, you can enable OCSP for this CA. OCSP is only recommended if you have specific requirements for OCSP. While OCSP allows quicker revocation it increases the CA the cryptographic load and can limit the scalability of the CA (Basic CA allows 1 cryptographic activity per second, Premium CA 20 cryptographic activities per second, Isolated CA 160 cryptographic activities per second). Learn more about OCSP vs CRL

  1. If you want to enable OCSP, select the “Enable OCSP” option. Enable OCSP for your Azure PKI
  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 will be charged as an extra Certificate Authority. Enable OCSP secondary location
  3. Once you have setup your certificate revocation, click Next. Revocation Setting Details

Set The Certificate Issuance Policy

  1. The first thing we must select is what type of CA we want to create, in this example we are creating an “SSL CA” which can be used for Azure IoT our integrated Azure Key Vault, ACME or any other SSL/TLS use case. If you need a different type of CA, for example scep for an mdm or root CA, select the appropriate template. CA Type
  2. Then, Enter the largest certificate lifetime that this CA can issue. EZCA automatically calculates the recommended maximum based on CA lifecycle best practices. CA Max Certificate lifetime

Set the EKU (Extended Key Usage)

as you can see at the top of the page there is a waring about the EKUs, by default EZCA will enable the “all” EKU, which means that this CA can issue certificates for any use case. However, there are some libraries such as OpenSSL that do not support this EKU type. If you want to change the EKUs for a specific use case, you can do so by expanding the advanced settings and selecting the desired EKUs (unselect any before making other selections). CA EKU

Issuance Policy (Advanced Settings)

This section gives you grater granularity on who can request. This is not required for most organizations.

  1. Click the expand button Expand Issuance Policy

Pre-Approved List of domains

  1. Since this is not a publicly trusted CA, by default EZCA will allow requesters to register any domains. If you want to limit which domains can this CA issue, Select the “Allow Only Pre-Approved List of Domains” option. Pre Approved Domains
  2. Upload a .txt file with your Pre-Approved domains (one per line), or enter them in the portal. Pre Approved Domains

Allow Wildcard Domains

By default EZCA does not allow users to request certificates with wildcard domains (a domain that starts with *. which allows you to use that same certificate for all other subdomains). If you want EZCA to issue wildcard certificates, select the “Allow wild-card certificates” option. Allow Wildcard Domains

Certificate Issuance Rules

To enable more granular control who can request domain ownership in EZCA, we created to extra knobs PKI administrators can adjust to control domain ownership.

  1. Require domain registration approval. This option enables PKI administrators to set a group of approvers that must approve each domain registration before a user or group of users are registered as domain owners.

    1. To enable this option select the “require approval” option.
    2. Enter the users or AAD groups that can approve domain requests. Require Approval

  2. The second way PKI administrators can control the registration of domains is to only allow specific users to request domains. This option enables PKI administrators to set a list of users that can request domains for this CA.

    1. To enable this option deselect the “Allow all users” option.
    2. Enter the users or AAD groups that can register domains. Specific Domain Admins

  3. Once you are done setting up your issuance policy, click Next. Next

Select Location

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

How To Add Geo-Redundancy to Your PKI

EZCA Allows you to create multiple CAs across many regions to create Geo-Redundancy.

Each location will be charged as an extra Certificate Authority.

  1. Click the “Add Secondary Location” Button. Create Secondary Location for Geo-Redundant PKI
  2. Enter the Location information. Add Secondary Location to Your CA
  3. Add as many locations as needed.

Create CA

  1. Click Create. Create Certificate Authority in the Cloud

Chaining to EZCA Root CA

  1. Once the CA is requested, a Certificate Signing Request (CSR) will be created for each location. Certificate Authority CSR Created
  2. If your desired Root CA is an EZCA CA, Select it from the dropdown and click create CA. Chain to Existing Root CA Created
  3. Repeat these steps for each location.
  4. Your CA is ready to be used!
  5. Next step: Register your first domain

Chaining to Offline Root CA

If you prefer to chain your CA to an offline Root CA, follow these steps.

  1. Once the CA is requested, a Certificate Signing Request (CSR) will be created for each location. CSR Created
  2. Click the “Save CSR” Button. Save CA CSR
  3. Once the CSR is download, follow your internal guidance to transfer that CSR to your offline Root CA.
  4. Open your “Certificate Authority” in Windows. Windows ADCS Root CA
  5. Right click the CA.
  6. Select All Tasks -> Submit new Request. Submit new CA Request to ADCS
  7. Select the downloaded CSR. Add Your CSR to Windows PKI
  8. Click on pending requests. See Windows PKI Pending CA Requests
  9. Right click on the newly created request.
  10. Select All Tasks -> Issue.
  11. Click on Issued Certificates. Issue your CA certificate in ADCS
  12. Double click on the newly created certificate. Export Certificate From Windows ADCS
  13. Click on Details. View Certificate Details in Windows
  14. Click on the “Copy ti File…” Button. Copy Windows Certificate to File
  15. Click next
  16. Select the “Base-64 encoded X.509 (.CER) option. Export Certificate as Base 64
  17. Click next.
  18. Select where you want to save the newly created certificate. Save the Exported Certificate
  19. Click next.
  20. Click Finish. Finish the certificate exportation in windows
  21. This should create a .cer file in the location you selected. view certificate in windows
  22. Follow you PKI team’s guidance on transferring the certificate file out of the offline CA into an internet connected computer.
  23. Once you have the certificate in an internet connected computer, go to https://portal.ezca.io/
  24. Login with an account that is registered as a PKI Admin in EZCA.
  25. Navigate to Certificate Authorities. CA Menu
  26. Click View details of the CA you want to import the certificate for. View your pending CA
  27. Scroll down to the location you want to import, and click the “Upload CA Certificate” button. Import CA Certificate for Cloud PKI
  28. Select the newly created certificate file. Select the created certificate
  29. Click on the “Save Certificate” button Finish your Subordinate CA creation
  30. Repeat these steps for each location.
  31. Your CA is ready to be used!
  32. Next step: Register your first domain