Skip to main content
Skip table of contents

Using EJBCA as a Certificate Management System (CMS)

The following covers information on using EJBCA as a Certificate Management System (CMS), also known as Certificate Lifecycle Management (CLM), and gives a short overview of the CMS/CLM concept, followed by an outline of EJBCA functionality areas and third-party CMS/CLM products.

CMS Overview

The meaning of the CMS (or CLM) concept has changed over the years, creating a need to describe it in more detail, as it may mean different things for different people.

Originally, CMS was synonymous with Certificate Issuance and Management System, which is the CA technology for a Certificate Authority (CA). This is what EJBCA is. As the need grew over the years, more features have been consolidated into the term CMS.

According to Gartner a CMS is:

"Certificate management system software is used to discover, identify, track, 
 notify, and ultimately automatically renew and audit the installation of X.509 
 certificates.” 
(Gartner, 2016)

Today the following main functional areas are available:

  • Certificate Ownership
    • Knowledge of which entities need to have a certificate, and why.
    • Controlling costs of obtaining certificates.
  • Certificate Reporting
    • Overview of certificates being active/used by end entities.
    • Assurance that end entities use only intended certificates, that is, do not have other valid certificates
  • Certificate Provisioning
    • Provisioning and activating of certificates on end entities.
    • Renewal of certificates on end entities.
  • Certificate Validation
    • Efficient way for relying parties to validate certificates.
  • Certificate Discovery

    • Not having a clear understanding of where, and how, certificates are used may cause issues such as service disruptions, security breaches, uncontrolled costs, and non-compliance.

In addition, many CMS use cases are related to performing the above functionality with multiple logically and physically separated CAs. For example, several Public CAs, for issuing publicly trusted web server certificates, and several internal CAs, installed with different vendor products.

Certificate Management can be performed using EJBCA itself, or using a third party CMS product that integrates with EJBCA. EJBCA supports the first four functions described above. The difference between using EJBCA itself and a third party CMS product is that EJBCA manages certificates issued and managed within the EJBCA instance and thus each EJBCA instance is its own certificate management system. A third party CMS product is typically used to manage multiple logical and physically separated PKIs, for example, certificates issued by one (or more) in-house EJBCA instances as well as certificates issued by one (or many) external PKIs such as publicly trusted CAs.

The following sections cover EJBCA CMS functionality areas and then the CMS Product Integration section outlines third-party CMS products.

EJBCA CMS Functionality

The following sections outline the CMS functionality offered within an EJBCA instance:

Certificate Ownership 

Using EJBCA you control which entities are issued with certificates. The flexible configuration of certificate profiles, authorization and protocols allow you to strictly control what needs to be controlled and automate what needs to be automated.

The below examples give an overview of a small subset of options to control certificate issuance.

  • Manually managing certificate requests that require approval.

Manually Managing Certificate Request

  • Manually approving certificate requests in an approval work-flow.

Manually Approving Certificate Requests

  • Immediate download of the requested certificate.

Certificate Reporting 

After issuing certificates there is also a need to be able to investigate, among other things, which certificates have been issued and when certificates expire. EJBCA provides search and notification functions in order to give insight into certificate use.

Note that the below screenshots only give an overview of a small subset of options to search and report.

The EJBCA RA provides rich search capabilities to search for both certificates and end entities, to among other things see:

  • Which certificates are issued to a specific end entity (for example a device, user or server).

  • Which certificates have been issued with a specified name, serial number, hostname and so on.

  • Which unique end entities have been registered with a specified name, serial number, hostname and so on.

  • Which certificates are about to expire within a specified time interval.

  • You can also configure a Service to report, by email, a defined period of time before certificates expire.

Certificate Provisioning 

Certificate Provisioning is the process of registering a device, generating keys, generating a certificate request, issuing the certificate and finally installing the certificate on the device. How this should be done is highly use case dependent and can vary from time-consuming manual processes to highly automated industrial, IoT or cloud processes. Provisioning typically refers more to the process on the device side than the process on the CA side. How this is done on the client-side naturally differs quite some. In general, the options are:

  • Built-in device functions, for example in your firewall, router and so on.
  • Client-side SDKs when you develop your own software on the device.
  • Client tools installed on the device.
  • Certificate Management Agents installed on the device.

During the provisioning process, the device uses a protocol to communicate with the CA, or RA, to enroll for certificates. EJBCA has wide support for the common protocols:

Available protocols are configured in EJBCA System Configuration.

Depending on the client, different protocols are used, and many devices have built-in support for one of the protocols. ACME is a new protocol, used to automate issuance and renewal of server certificates, where there are multiple different client tools available to install on servers and devices to handle provisioning. When it comes to SDKs there are also multiple options, for example:

The SDK we support most closely is BouncyCastle, which is also the SDK EJBCA uses itself.

The following displays an example of the ACME REST-based protocol.

Certificate Management Agents are usually part of a CMS product and used in combination with that, see below.

Certificate Validation 

Certificate Validation can be divided into two parts, verifying the certificate chain, and checking if a certificate is revoked or not.

Revocation validation is supported by EJBCA through the most common means of validating if a certificate is revoked or not:

When checking whether a certificate is revoked, clients either validate against the online OCSP service (query per certificate), or download the CRL (list of all revoked certificates) to determine the revocation status of a certificate.

Ability to validate the certificate chain depends on the client having the full chain to verify. In some protocols, such as TLS, the certificate chain is normally transferred as part of the handshake part of the protocol, but in some cases, the client may need to fetch CA certificates from the server.

In EJBCA validation services are packaged in the Validation Authority (VA), a single offering of both OCSP service and CRL download, as well as CA certificate download. The EJBCA VA contains the information needed by a relying party to verify and validate certificates (as long as the relying party has established trust in the Root CA).

Client support for certificate validation is in many cases built into the clients, and it is present in the common SDKs such as Bouncy Castle, OpenSSL, and others.

Certificate Discovery 

In large organizations, it is very hard to keep track, and control, of certificate usage within the organization. Expiring certificates can be a cause of outage for important business services when the certificates have not been managed properly by a specific business unit. Certificate Discovery tools help to identify and locate certificates and provides reporting capabilities. Discovery is typically done by scanning networks, systems and applications, logging instances of certificates found. This can easily find public used certificates, such as server certificates. Client certificates are in many cases not accessible to network scanning and need to be discovered by scanning applications and registries, for example, Active Directory.

EJBCA does not provide scanning functionality to discover certificates not managed by the EJBCA instance itself. EJBCA has full control and knowledge about all certificates issued by itself when used as a CA.

CMS / CLM Product Integration 

There are multiple third-party CMS products available to discover and control certificates issued by a multitude of CAs. Products in this sector provide different functionality, some are focused solely on discovery and others on providing full lifecycle management with support for integration into other IT systems such as load balancers, EMM and MdM systems, IoT devices, etc.

KeyFactor

Keyfactor’s certificate lifecycle automation and management platform, lets you manage the lifecycle of keys and digital certificates across your business.

KeyFactor has native integration with EJBCA using the REST API. For more information, refer to the Keyfactor press release for Keyfactor 10.

AppViewX

The AppViewX Platform is a modular application that enables the automation and orchestration of network infrastructure using an intuitive, context-aware, visual workflow. It is closed-loop and state-aware, capable of verifying that intent has been achieved and providing actionable insights and automated remediation.

AppViewX has native integration with EJBCA using the REST API. For more information, refer to the PrimeKey press release AppViewX and PrimeKey’s EJBCA-integrated certificate management solution.

3Key Company

3Key Company develops and maintains several add-ons to EJBCA Enterprise. The 3Key DMR add-on offers dashboarding, monitoring, and reporting add-on functionality to EJBCA helping organizations get the most out of their state of the art PKI.

For more information, see 3Key Dashboarding, Monitoring and Reporting Add-on and 3Key RA Profiles Add-on or the PrimeKey press release PrimeKey and 3Key Company announce a new partnership, delivering PKI and Signing solutions to protect business-critical digital assets.

Digitalberry

The Digitalberry BerryCert software automates digital certificate lifecycle management. BerryCert detects and automatically manages certificate renewal before the expiration date.

BerryCert has native integration with EJBCA using the WS API. For more information, refer to Digitalberry documentation on Integration of PrimeKey EJBCA

Lemur

Lemur is an open source CLM project originally developed by Netflix. Lemur manages TLS certificate creation. While not able to issue certificates itself, Lemur acts as a broker between CAs and environments providing a central portal for developers to issue TLS certificates with 'sane' defaults.

PrimeKey has developed a Lemur EJBCA plugin that enables native integration between Lemur and EJBCA, enabling Lemur to use EJBCA as the backend PKI seamlessly.

Venafi

The Venafi Platform is a full lifecycle management platform that discovers, manages and automates certificate usage in large organizations.

EJBCA Integration Driver

The Venafi platform has native integration into EJBCA using an Adaptable CA Driver, connecting to EJBCA using the Web Service API. Using the integration the Venafi Platform automatically handles management functions in EJBCA and can be seen as an advanced RA, from the CA perspective. This enabled an organization to manage all its certificate usage, including external and internal PKIs using a single platform.

Functions available in the Venafi-EJBCA integration includes:

  • Retrieval of CA certificates
  • Requesting and issuing certificates
  • Renewing certificates
  • Revoking certificates

Installing the Venafi-EJBCA integration Adaptable CA Driver is easily done by putting the driver script (EJBCA.ps1) and WSDL (ejbcaws.wsdl) in your Venafi Platform installation, configure a few variables in the driver including the EJBCA server address, set up the Adaptable Driver in the Venafi Platform and configure authentication, and finally associate the driver CA templates and policy inside your Venafi administration interface.

Importing existing EJBCA certificates

If you are setting up a new system, configuring the Venafi-EJBCA integration from the start gives you everything needed. If you install Venafi after you have been running EJBCA for a while, you may want to import all the issued certificates from EJBCA into Venafi.

Venafi has a method to import certificates from the filesystem, and you can export issued certificates from EJBCA using a database query. After exporting all certificates from EJBCA, this can be used to import them into the Venafi Platform.

The Base64 encoded data of certificates are stored in the column named base64Cert in the CertificateData table. You can get it by SQL like:

CODE 
select base64Cert from CertificateData where issuerDN='CN=MyCA,O=MyOrg,C=SE';

To export all certificates from the database into PEM format (e.g. as zip) with status (active, revoked) from all CAs with time period for selection, use a script like the following:

CODE 
#/bin/sh
host=localhost
user=ejbca
database=ejbca
issuerdn="CN=MyCA,O=MyOrg,C=SE"
outputDirectory=.
read -s -p "Enter database password: " password

mysql -u$user -p$password -h $host $database -s -e "SELECT serialNumber, CertificateData.status, base64Cert, name FROM CertificateData JOIN CAData ON CertificateData.issuerDN=CAData.subjectDN WHERE CertificateData.issuerDN='$issuerdn';" | while IFS=$'\t' read -r serialNumber status base64Cert issuerName; do
    mkdir -p $outputDirectory/ejbca_certificate_export/"$issuerName"/"$status"
    file=$outputDirectory/ejbca_certificate_export/"$issuerName"/"$status"/"$serialNumber".pem
echo "-----BEGIN CERTIFICATE-----" >> "$file"
echo "$base64Cert" | sed 's/\\n/\n/g' >> "$file"
  echo "-----END CERTIFICATE-----" >> "$file";

done
if [[ -d $outputDirectory/ejbca_certificate_export ]]; then
    zip -rq certificate_export.zip $outputDirectory/ejbca_certificate_export
    rm -rf $outputDirectory/ejbca_certificate_export
fi

This results in a zip file where directories are created for the CA (Common Name) and in the next level status (20 = active, 40 = revoked).

You can also do it for all CAs by removing the clause WHERE CertificateData.issuerDN='$issuerdn'.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close