Segmenting the PKI using EJBCA Peer

Segmenting a Public Key Infrastructure (PKI) helps reduce risk by isolating trust domains, limiting the impact of a potential compromise, and supporting stronger governance and compliance practices.

EJBCA Peer facilitates secure segmentation within the EJBCA PKI infrastructure. The following introduces EJBCA Peer, provides configuration guidance, and outlines how to automate peer configurations in EJBCA deployments using the EJBCA ConfigDump tool and JSON.

Overview

EJBCA Peer is used to establish secure, scalable, and segmented communication between components in an EJBCA-based PKI deployment. In most production environments, the Certification Authority (CA) is placed in a secure network zone, often behind a firewall, with strict controls on inbound traffic.

EJBCA is commonly deployed with the following components:

Certification Authority (CA)
Registration Authority (RA)
Validation Authority (VA) — including CRL and OCSP services

In this architecture, RA and VA components are considered peers of the CA. RA and VA typically reside in less restricted or public-facing networks and do not initiate contact with the CA. Instead, the CA initiates outbound connections to the RA and VA to pull data such as pending certificate requests. This approach eliminates the need for inbound connections to the CA, thereby reducing the attack surface.

The CA is also typically integrated with a Hardware Security Module (HSM) that stores and protects sensitive private keys. The combination of HSM integration and peer-based communication makes segmentation a critical security control in the overall PKI design.

EJBCA Peer Communication Protocol

The EJBCA Peer protocol handles communication between the CA and its peers. This protocol enables outbound connections secured using mutual TLS (mTLS), with data exchange based on serialized Java objects. As a proprietary communication model, it ensures tight integration and secure interaction between EJBCA components.

How to Configure Peer Connections?

Both the CA and its peers (VA, RA, or CA) need to be configured so that they are aware of each other and can establish controlled access.

On the CA

Configuration begins on the CA side, where:

The CA must know the URLs or IP addresses of the RA/VA peers.
It must authenticate these peers.
Authorization rules must be defined—for example, what operations a peer is allowed to perform (certificate issuance, revocation, identity creation, etc.).
Secure connectivity is established via Remote Authentication with Key Bindings, using mTLS certificates.

On the Peer (RA/VA)

On the RA/VA (peer) side, a similar configuration is needed:

Define the CA as a remote peer.
Set permissions and authenticate the CA.
Import CA certificates and finalize access rules.

EJBCA provides a dedicated user interface for Peer System Configurations, Roles, and Access Rules, making this setup manageable from browsers. However, automation is highly recommended to create reproducible environments and PKI with a large number of peers.

What is ConfigDump?

The EJBCA ConfigDump tool allows you to define your EJBCA deployment configuration as a JSON or YAML file.

ConfigDump supports the import and export of key EJBCA resources, including:

Certification Authorities (CAs)
Certificate Profiles and End Entity Profiles (which define certificate contents)
Protocol configurations (such as ACME, CMP, EST, SCEP, and others)
Access rules
Peer connections

You can export a JSON-based ConfigDump from an existing EJBCA instance or create one manually. The configuration can then be imported into a Helm chart deployment by either:

Specifying the configuration directly in your values.yaml file, or
Creating a Kubernetes ConfigMap and referencing it via an attribute in values.yaml

At startup, EJBCA reads these configurations and establishes connections with remote peers (such as RAs and VAs), assuming the configuration and certificates are valid.

Using Exported Configuration

You can configure your peers using the EJBCA user interface, then export the configuration using the ConfigDump REST API.

This allows you to copy, edit, and reuse the JSON configuration across multiple environments—such as development, QA, and production—supporting consistent and repeatable deployments.

Deployment automation with ConfigDump

To streamline the setup and follow modern DevOps practices, EJBCA supports deployment automation through the EJBCA ConfigDump tool. ConfigDump supports all relevant EJBCA configurations, including Peer setup.

This configuration-as-code approach enables efficient EJBCA PKI deployment and repeatability, aligning with modern Infrastructure-as-code principles.

In this section, we provide a high-level overview of how to configure peers using ConfigDump.

The examples focus on ConfigDump excerpts of relevant resources. Additional attributes and options are available but are omitted here for brevity.

Configuration on the CA side

On the CA side, three primary components need to be configured to establish a peer connection:

Peer Connector: Defines the URL of the peer. The configuration may vary slightly depending on whether the peer is an RA or a VA.
Role Configuration: Establishes a role for the peer’s server certificate with the necessary access rules.
Remote Authenticator: An EJBCA resource responsible for establishing a TLS connection to the remote peer.

All of these components can be defined using ConfigDump.

Peer Connection Details

The peer connector defines the URL of the peer (such as an RA).

This may be an internal namespace reference or an external load-balanced endpoint.

Example JSON:

JSON

"peer-connectors": {
   "ejbca-ra1": {
      "Object Type": "Peer Connector",
      ….
      "Peer Enabled": true,
      "URL": "https://ejbca-ra-nginx.ejbcara.svc.cluster.local/ejbca/peer/v1",
      ….
      "Authentication Key Binding": "peer-key"
    }
  },

Authentication and Authorization

Both authentication (via mTLS and remote authentication key bindings) and authorization (roles and permissions) are configured.

The examples below use lenient permissions for demonstration purposes. In production environments, follow the principle of least privilege to minimize risk.

Authentication

Authentication allows securely identifying an entity using mutual TLS (mTLS), thus certificate authentication. Peering enables authenticated access for both the server and client.

In the following example, a role is defined that allows access for a peer server having a certificate with the Common Name ejbcara.testdomain.se, issued by the ManagementCA:

JSON

"admin-roles": {
    "RA-Peer-Connection": {
      "Object Type": "Role",
      .....
      "Role Members": [
        {
          "Token Type": "CertificateAuthenticationToken",
          "Issuer": "ManagementCA",
          "Match With": "WITH_COMMONNAME",
          "Match Value": "ejbcara.testdomain.se"
        }
      ],
      …..
      }
  }

Authorization

Authorization allows configuring access to an authenticated entity.

In the following example, the CA allows an RA to perform operations under the ACME protocol.

JSON

"admin-roles": {
    "RA-Peer-Connection": {
      "Object Type": "Role",
      "Access Rules": {
        "/administrator/": "Allow",
        "/ca/": "Allow",
        .....
        "/endentityprofilesrules/": "Allow",
        .....
        "/protocol/acme/": "Allow",
        .....
        "/ra_functionality/create_end_entity/": "Allow",
        .....
      }
…..

Remote Authentication

EJBCA CA acts as a client when connecting to remote peer server using mTLS. To enable this:

A private key must be stored in a Crypto Token, which can be either:
- A software token, or
- An HSM-based token.
An enrolled certificate that that allows client authentication is required. This certificate is:
- Typically signed by the Management CA.
- Configured using a Certificate Profile (ENDUSER) and an End Entity Profile.

Once configured, the Remote Authenticator can be used for all connected peers.

The following example displays how all of these can be described in ConfigDump:

JSON

"internal-key-bindings": {
    "peer-key": {
      "Object Type": "Internal Key Binding",
      "Version": 1,
      "Name": "peer-key",
      "Type": "AuthenticationKeyBinding",
      "Status": "ACTIVE",
      "Crypto Token": "PeerToken",
      "Key Pair Alias": "peerkey",
      "Next Key Pair Alias": null,
      "Signature Algorithm": "SHA256WithRSA",
      "Enrollment info: Key Binding SubjectDN": "CN=peer-key",
      "Enrollment info: Signing CA SubjectDN": "CN=ManagementCA,O=EJBCA Sample,C=SE",
      "Enrollment info: Certificate profile": "ENDUSER",
      "Enrollment info: End entity profile": "EMPTY",
      "Enrollment info: Key spec or curve": "RSA2048",
      "Trusted certificates": {},
      "Signed on behalf of CAs": {},
      "Properties": {
        "Protocol and Cipher Suite": "TLSv1.2;TLS_RSA_WITH_AES_256_CBC_SHA256"
      }
    }
  }

Configurations on the Peers

On the peer side (for example, the RA), you need to set up similar configurations.

Global Peer Configuration

The peer instance needs to be configured to allow incoming connections from the CA instance. This is done by enabling the allowIncomingConnections attribute in the configuration:

JSON

{
  "peer-connectors": {
    "global-peer-configuration": {
       "Object Type": "Peer Global Configuration",
       "Version": 1,
       "Allow incoming connections": true,
       "Allow outgoing connections": false,
        …..
    }
  }
}

Authentication and Authorization

Access for the CA instance

The peer must authenticate the CA instance by verifying the certificate issued to the Remote Authenticator. This typically involves matching the CA's certificate Common Name and Issuer:

In the following example, the Common Name of the certificate is matched to the peer-key to ensure it is issued by the ManagementCA.

JSON

"admin-roles": {
   ….
   "raIncomingCaPeer": {
      ...
      "Name": "raIncomingCaPeer",
      "Role Members": [
       {
          "Token Type": "CertificateAuthenticationToken",
          "Issuer": "ManagementCA",
          "Match With": "WITH_COMMONNAME",
          "Match Value": "peer-key"
       }
       ],
       ...
       "Access Rules": {
          "/ca/ManagementCA/": "Allow",
          "/peerincoming/": "Allow",
          "/ra_slave/manage/": "Allow"
       }
}

The CA instance also needs to be granted certain access to peers. Note that these access rules vary depending on the type of peer (RA/VA).

Access for Administrative Users

In addition, access needs to be set up for normal users in peers, particularly for managing peers through browsers or equivalent interfaces. This requires assigning SuperAdmin access through roles.

SuperAdmin access can also be configured using mutual TLS (mTLS). This is useful for performing administrative tasks across multiple EJBCA installations.

In the following example, SuperAdmin access is granted to a certificate with the Common Name SuperAdmin, issued by ManagementCA, as per convention.

The CliAuthenticationToken with USERNAME as ejbca must be a SuperAdmin for the EJBCA container to function properly.

JSON

"admin-roles": {
   "Super Administrator Role": {
     ....
     "Name": "Super Administrator Role",
     "Role Members": [
       {
         "Token Type": "CertificateAuthenticationToken",
         "Issuer": "ManagementCA",
         "Match With": "WITH_COMMONNAME",
         "Match Value": "SuperAdmin"
       },
       {
         "Token Type": "CliAuthenticationToken",
         "Issuer": null,
         "Match With": "USERNAME",
         "Match Value": "ejbca"
       }
     ],
     "Namespace": "",
     "RA Style Id": 0,
     "Access Rules": {
       "/": "Allow"
     }
   },

Additional Configuration Tips

Import CA Certificates: On the peer (RA/VA) side, the CA certificate must be imported as an external CA.
Enable Required Protocols: Activate the necessary protocols, such as:
- On the RA: Enable certificate enrollment protocols like ACME, CMP, SCEP, or management APIs like REST and SOAP.
- On the VA: Activate OCSP.

JSON

"available-protocols": {
   "available-protocol-configuration": {
      "Object Type": "Available Protocols",
      ...
      "ACME": true,
      "OCSP": false,
      "REST Certificate Management": true,
      ...
   }
}

Conclusion

EJBCA Peer provides a secure and scalable way to segment your PKI architecture by isolating core CA components from external-facing services like RAs and VAs. This segmentation reduces the attack surface, improves governance, and aligns with modern security and compliance practices.

Through mutual TLS, internal key bindings, and role-based access control, EJBCA Peer ensures that only authenticated and authorized components can communicate. Configuration is handled via both UI and automation, with configdump enabling repeatable, infrastructure-as-code style deployments.

By defining your peer configuration as JSON and integrating it into Helm charts using values.yaml, you can apply consistent setups across test, QA, and production environments. This approach supports DevOps workflows and simplifies PKI management at scale.

Overview

EJBCA Peer Communication Protocol

How to Configure Peer Connections?

On the CA

On the Peer (RA/VA)

What is ConfigDump?

Deployment automation with ConfigDump

Configuration on the CA side

Peer Connection Details

Authentication and Authorization

Configurations on the Peers

Global Peer Configuration

Authentication and Authorization

Additional Configuration Tips

Conclusion

Related Content