Issuing TLS Certificates

Issuing TLS certificates is a common use case including both public providers of TLS certificates and enterprise PKIs needing to provision TLS server certificates internally. In this solution, you strive for short-lived certificates and as much automation as possible and have high requirements on OCSP and CRL generation.

Since this public key infrastructure (PKI) is going to be exposed to the internet, domain security is of dire importance. EJBCA allows outward-facing nodes (Registration Authorities (RAs) and Validation Authorities (VAs)) to not only be connected to the certificate authority (CA) through mutual TLS but also with the CA behind a one-way firewall. Multitenancy support allows all your sub-organizations and divisions to share the same PKI infrastructure with extensive domain security in place to ensure that security silos are kept intact.

You're also likely to need to generate a Certificate Practice Statement (CPS) and be submitted to an external audit. The following sections cover how to set all this up with EJBCA.

Set up Initial CA Infrastructure

Common for many PKIs, you want to have a solid CA infrastructure. Your Root CA will likely be air-gapped and offline, with Sub CAs clustered to provide resilience. Your outward-facing nodes are going to be VAs and RAs, placed in front of a heavy-duty firewall only allowing outgoing connections (because you do not want your CA infrastructure exposed) and behind load balancers.

For more information on setting up the initial CA infrastructure, see:

→ How to install EJBCA
→ How to cluster EJBCA
→ How to set up EJBCA as an RA

Domain Security

Domain security is of great importance. Your VAs will likely have to be exposed to the internet at large to supply CRLs and answer OCSP requests, while your RAs will at minimum have to be exposed internally to your general network to allow users and servers to enroll for certificates, or at worst to the internet at large if you're planning on issuing certificates to third-parties. While it might be tempting to simply have all your instances in the same domain, it is very much recommended to keep your CAs behind a one-way firewall, allowing only outgoing connections. EJBCA solves this using the Peers protocol, which not only uses mutually authenticated TLS but also has the CA initiate all connections.

The following sections cover how to set up your required connections.

Create Root CA and Sub CA

Initially, you need a minimum of four instances of EJBCA, one node acting as Root CA, one Sub CA node, a Registration Authority (RA) and a Validation Authority (VA). In addition, you're going to work with three CAs:

A Management CA, placed on any node. The role of this CA is to issue internal user certificates such as the application server key store, client certificates for administrators, TLS certificates for Peer connections, etc.
A Root CA on the Root CA node, which is the head of the hierarchy.
An Issuing CA on the Sub CA node, signed by the Root CA. The purpose of having a Root CA and an Issuing CA is twofold:
- You may wish to have several different Issuing CAs in the same hierarchy for different tenants/purposes.
- Should your Issuing CA somehow become compromised, having it signed by a Root is essential to allow you to recover your PKI.

The following outlines a basic CA hierarchy and provide links to more information on how to set this up in EJBCA.

Create Root CA

First, create the Root CA on the Root CA node.

→ How to create your first Root CA

Create Issuing CA

Next, import the Root CA's certificate on the Sub CA node, then create the Issuing CA and have it signed by the Root CA.

→ How to import an External CA

→ How to create the Issuing CA and have it signed by the Root CA

Set up Certificate Transparency

If you plan to have your TLS CA recognized by the browser root stores, Certificate Transparency is one of the technologies you need to support.

→ How to add Certificate Transparency logs to EJBCA

Configure Profiles

On your issuing CA, set up Certificate Profiles and End Entity Profiles for your end entities. In short, the Certificate Profiles describe characteristics of the certificate (keys, algorithms, extensions, etc) that may be common among different end entities, while the End Entity Profiles describe fields relating to the end entity itself (Subject DN, Subject Alt Name, etc) that would be specific for an end entity but common among all of that end entity's certificates.

→ How to set up a Certificate Profile for TLS certificates

Set up VA Infrastructure

Next up is setting up your VA infrastructure to be able to respond to OCSP requests. While the CA is fully capable of replying to those on its own, you're unlikely to want the CA exposed to incoming requests from the greater web, thus the job is delegated to the VA. The role of the VA is to reply to OCSP requests by having the CA publish revocation information to it over Peers.

→ How to set up TLS authentication between the Issuing CA and a Verification Authority

→ How to connect the Issuing CA and the Verification Authority over Peers

→ How to set up a Publisher to start publishing revocation information from the Issuing CA to its VA

Set up Enrollment

When it comes to enrollment, you have several different options, depending on your use case. Are you expecting the certificate holder to manually request the certificate, do so through your own PKI team, or enroll automatically through a client over an enrollment protocol?

Set up a Registration Authority

Whatever case(s) that may apply to your PKI, you likely want to process an enrollment request through a Registration Authority (RA) to avoid exposing your CA to the world at large. As with the VA above, your RA(s) are going to be connected to the CA over the Peers protocol. You are free to use the same EJBCA instance as VA and RA if you wish.

→ How to set up TLS authentication between the Issuing CA and a Registration Authority

→ How to connect the Issuing CA and the Registration Authority over Peers

There is no limit to the number of Registration Authorities you can connect to a CA instance. Instead, you can both scale up to handle your volumes and separate them by access rules to allow true multitenancy.

Manual Enrollment

The quickest and easiest option for enrolling and issuing a certificate through EJBCA is by going through the RA UI, which can be accessed both on the Issuing CA instance or through a Registration Authority.

The RA UI works out of the box for authenticated users, but you can also set up the RA UI as an enrollment portal for users without browser certificates.

→ How to set up the RA UI for public access

Protocols

If enrollment is going to be from a client outside of EJBCA, the TLS solution has four common use cases:

ACME

The ACME protocol is tailor-made for TLS certificates, and a large number of well-supported third-party clients can be found around the web. It's designed at its core for automation and automatic renewal of short-lived certificates. EJBCA supports the entire protocol including External Account Bindings, and above and beyond the specification also allows for multiple endpoints for different certificate types on the same server.

EST

For many customers whose use cases don't exactly fit ACME, EST is a modern and lightweight protocol for enrollment, fully supported by EJBCA.

EJBCA REST API

The EJBCA REST API is the newest of our own protocols and is built with automation in mind. In it, you have all the API calls you need to be able to easily and automatically have your custom client enroll certificates through EJBCA.

EJBCA SOAP API

Our SOAP (WS) interface is older, but still in extensive use out there. Being more mature, it still has a more extensive feature set.

Access Control

It's not unlikely that your organization requires some form of dual (or multiple) access control for certain functions, such as multiple administrators approving the issuance of certificates or verifying revocation requests. EJBCA offers a powerful system of Approvals, which can either be accumulative (e.g simply requires a certain number of trusted users to sign off on the action) or more complex, with sequences running both in parallel and serially, with different roles allowed to approve or review various instances.

Validation

Throughout the issuance process, from a public key being sent in, to the certificate being issued, you'll likely want to ensure that the key you are signing passes basic security checks. You can do this by attaching Validators to your CA configurations.

Below are some example configurations that you likely need to do.

CAA Validation

If your TLS CA needs to comply with any browser root store baseline requirements, you're going to have to verify that the requested domain in the Certificate Signing Request has specified your CA as allowed. The CAA Validator will automatically perform a DNS lookup before issuing a certificate for a specific domain.

Domain Block Lists

The Domain Block List Validator allows you to upload a list of domains to not issue certificates for, in order to add some assurance to not fall for phishing scams.

Key Validation

The RSA and EC Key Validators will validate submitted public keys for known weaknesses and refuse to sign them if they don't match up. For CA's conforming to root program baseline requirements, both validators have a CA/Browser-Forum template.

Linter Validation

Last but not least, provide the External Command Certificate Validator which allows you to pipe pre-certificates through an external Linter (such as ZLint, X509Lint or a Debian Weak Keys Linter) to verify that they conform to your requirements and you don't have to risk misissuance.