Deploy Nexus Certificate Manager, Protocol Gateway, and Hermod on One Kubernetes Cluster

Step-by-step deployment guide | Kubernetes + Helm + Nexus Smart ID

Yes, you can deploy all three components in a single Kubernetes cluster. You do not need separate Kubernetes clusters for Certificate Manager (CM), Protocol Gateway (PGWY), and Hermod.

The important point is that these products have different installation methods and dependencies. I checked Nexus’s published deployment documentation:

Certificate Manager 8.15.x: Kubernetes deployment using official Nexus Helm charts.
Protocol Gateway: Kubernetes deployment using the Helm charts included with Certificate Manager.
Hermod 4.x: Kubernetes deployment using the vendor-provided container image, configuration, and Kubernetes manifests.

Nexus officially documents all three deployment paths. Nexus Documentation+1

This guide assumes a new installation, not a migration from an existing production CA.

1. Recommended architecture

I recommend starting with one Kubernetes cluster, one dedicated namespace, private networking for CM, and externally accessible HTTPS only where required.

Applications / Devices / PKI Administrators

Certificate requests and authentication

Kubernetes Cluster

Namespace: nexus

Protocol Gateway

PGWY · Helm deployment

Enrollment and integration

Hermod

Kubernetes Deployment

Authentication and signing

Private service communication

Nexus Certificate Manager (CF + embedded CIS)

Helm-managed StatefulSet · Protected PKI core

SQL databases

CMDB + Hermod DB

HSM / Key storage

Protected signing keys

Logical architecture. Databases and HSMs may run outside Kubernetes and are shown as supporting dependencies.

Important Kubernetes-specific difference

In Certificate Manager 8.15’s Kubernetes deployment, Certificate Factory (CF) runs Certificate Issuing System (CIS) internally. You should not create an independent CIS deployment following an older, traditional server architecture.

Nexus also specifies that CIS audit logging goes to the database unless disabled in its configuration. Nexus Documentation

2. Deployment components and responsibilities

Component	Kubernetes resource	Access	Function
CM / CF	Helm-managed StatefulSet	Private	Certificate issuance and PKI management
PGWY	Helm-managed application	Private / controlled external	ACME, EST, SCEP, APIs
Hermod	Deployment + Service	HTTPS accessible to required clients	Authentication and signing
CMDB	External managed DB preferred	Private	Certificate Manager database
Hermod DB	External managed DB preferred	Private	Hermod operational database
HSM	External hardware/service, if configured	Restricted	CA private-key protection
Ingress / Load Balancer	Kubernetes networking	Controlled	Selected HTTPS endpoints

CM and Hermod can use the same supported database server with separate databases and users, but should not share application tables or credentials.

3. Prerequisites

3.1 Software and infrastructure

The official Nexus CM 8.15 Helm guide specifies Kubernetes 1.33.8 or later, Helm 3.6.2 or later, and kubectl 1.33.8 or later. Nexus Documentation

Requirement	What you need
Kubernetes	1.33.8+ for the documented CM 8.15 deployment
Helm	3.6.2+
kubectl	1.33.8+
Nexus CM	Licensed 8.15.x distribution with Helm charts
PGWY	Container image and charts from the CM distribution
Hermod	Licensed/supported Hermod 4.x container distribution
Database	Supported SQL database(s), initialized for each product
Container registry	Private registry accessible to cluster nodes
Persistent storage	CSI StorageClass supporting ReadWriteMany for CF
DNS and TLS	Certificates and DNS names for exposed services
HSM	Production-grade protected CA key storage where required
Administrative clients	Nexus Administrator’s Workbench and applicable enrollment clients

You must obtain the licensed Nexus artifacts from your vendor portal or organization. The following instructions do not assume that Nexus images are publicly downloadable.

3.2 Verify your Kubernetes cluster

Run these commands from a workstation with access to the cluster:

kubectl config current-context
kubectl cluster-info
kubectl version
helm version
kubectl get nodes -o wide
kubectl get storageclass
kubectl get namespaces

Confirm that:

All expected nodes are Ready.
You have permission to create deployments, services, secrets, and PVCs.
The cluster can pull images from your private registry.
The configured storage supports the access modes required by Nexus.

Critical storage requirement: The vendor’s CF Helm chart requires a ReadWriteMany (RWX) StorageClass for its main persistent volume. Many default block-storage classes support only ReadWriteOnce. Do not assume the cluster’s default storage class will work. Nexus Documentation

3.3 Create the namespace

For this tutorial, all components will initially run in the same namespace.

kubectl create namespace nexus

Verify:

kubectl get namespace nexus

Expected result:

NAME    STATUS   AGE
nexus   Active   ...

If the namespace already exists, reuse it rather than running the create command again.

4. Prepare the databases

I recommend PostgreSQL for a lab because both CM and Hermod support it.

For production, a managed database service is preferable when supported by your chosen database version and vendor requirements.

Use two logical databases:

Database	Example name	Used by
Certificate Manager database	`cmdb`	CM / Certificate Factory
Hermod database	`hermod`	Hermod Services

Step 4.1 — Initialize the CM database

Do not create only an empty PostgreSQL database and assume CM will generate all tables.

Nexus provides database initialization scripts inside the CM server distribution:

cm_server_<version>.zip
└── program_files/
    └── install/
        └── PostgreSQL/
            ├── create_db_and_role.sql
            └── create_cmdb.sql

First inspect create_db_and_role.sql and replace its default password.

For PostgreSQL 15 or later, Nexus documents these commands:

psql -X -v ON_ERROR_STOP=1 \
  -h <postgres-host> -U postgres -d postgres \
  -f create_db_and_role.sql

psql -X -v ON_ERROR_STOP=1 \
  -h <postgres-host> -U postgres -d cmdb \
  -f create_cmdb.sql

The first script establishes the required database and role. The second creates the CM database tables.

For PostgreSQL 14 or earlier, the documented table-creation procedure uses the lcmreq user instead. Nexus Documentation

Use a supported PostgreSQL version and configure authenticated, encrypted database connections. For managed PostgreSQL, review and adapt the vendor scripts to the permissions available to your database administrator.

Step 4.2 — Initialize the Hermod database

Hermod has its own database and schema.

Create an independent database and account, then apply the initialization scripts appropriate to the selected Hermod release.

Nexus distributes SQL files in Flyway-compatible format and documents version-dependent database updates. Nexus Documentation

Be aware that the example Hermod configuration uses:

spring:
  jpa:
    hibernate:
      ddl-auto: validate

This means you should not rely on Hibernate automatically creating the database schema.

Step 4.3 — Test database access

Before deploying the applications, verify that your Kubernetes worker nodes and Pods can resolve and connect to the database host.

A temporary PostgreSQL client Pod can help test DNS and network connectivity:

kubectl run pg-network-test \
  -n nexus \
  --image=postgres:17 \
  --restart=Never \
  --command -- sleep 3600

Then check DNS and TCP connectivity:

kubectl exec -n nexus pg-network-test -- \
  pg_isready -h <postgres-host> -p 5432

Remove the test Pod:

kubectl delete pod pg-network-test -n nexus

pg_isready confirms server responsiveness, not database-user authorization or TLS correctness. Those must be verified separately.

5. Obtain the Nexus container images and Helm charts

Unlike ordinary open-source applications, Nexus provides its software through its customer distribution packages.

Step 5.1 — Download the packages

Obtain from the Nexus Support Portal:

Certificate Manager 8.15.x server distribution.
Certificate Manager client distribution.
Hermod 4.x distribution.
Your organization-specific license file.

Extract the archives into a working directory on your administration workstation.

Step 5.2 — Locate the Helm charts

The CM distribution includes four charts:

helm/
├── cf/
├── cf-example/
├── pgw/
└── pgw-example/

These are actual vendor-supplied chart names, not invented examples. Nexus Documentation

Chart	Purpose
`cf`	Base Certificate Factory chart
`cf-example`	Configurable parent chart for CM
`pgw`	Base Protocol Gateway chart
`pgw-example`	Configurable parent chart for PGWY

Use cf-example and pgw-example as your initial configuration templates. Their dependencies point to the matching base charts.

Step 5.3 — Load the container images

From the extracted CM distribution:

docker image load \
  --input images/cf-server-image-<version>.tar

docker image load \
  --input images/pgw-image-<version>.tar

Load the Hermod image from its downloaded distribution as well.

Check the resulting image names and tags:

docker images

Step 5.4 — Push the images to a private registry

Example:

docker tag <loaded-cf-image>:<version> \
  registry.example.com/nexus/cf:<version>

docker push registry.example.com/nexus/cf:<version>

Repeat for PGWY and Hermod using their actual loaded image names and approved registry destinations.

The final images could be organized as:

registry.example.com/nexus/cf:<cm-version>
registry.example.com/nexus/pgw:<cm-version>
registry.example.com/nexus/hermod:<hermod-version>

These image names are examples; they are not public Nexus image locations.

Nexus explicitly prohibits publishing the supplied CM images to public registries. Use an access-controlled private registry and follow your organization’s Nexus license terms. Nexus Documentation

Configure image-pull access using your cloud platform’s workload/node identity where available, or a restricted Kubernetes image pull secret.

6. Deploy Nexus Certificate Manager (CM)

Deploy Certificate Manager first, because PGWY requires access to a working CF back end.

Step 6.1 — Prepare the chart

Navigate to the extracted Helm directory:

cd helm/cf-example

Inspect:

cat Chart.yaml
cat values.yaml

Check that the cf dependency points to the correct local chart directory.

Step 6.2 — Install the license and configuration

The vendor’s cf-example chart includes a files directory containing CM configuration files and supporting resources.

A typical structure is:

cf-example/
├── Chart.yaml
├── values.yaml
└── files/
    ├── config/
    │   ├── cm.conf
    │   └── cis.conf
    ├── inputviews/
    ├── keystore/
    ├── license/
    ├── pinprocedures/
    └── truststore/

Place the licensed CM file under:

cf-example/files/license/

Configure the required CA-related files, trust stores, key stores, database settings, and signing-key integration according to the vendor’s installation package.

Use Kubernetes Secrets or an approved secret-management integration for sensitive material. Be aware that the example charts can package files into Helm release data; avoid committing or distributing private keys, passwords, or confidential keystores.

Step 6.3 — Configure `values.yaml`

The official chart exposes a database configuration structure similar to:

config:
  database:
    name: "jdbc:postgresql://postgres.internal:5432/cmdb"
    user: "lcmreq"
    password: "<securely-supplied-password>"
    connections: "20"

Set the actual database endpoint and credentials.

This snippet shows the vendor’s configuration structure. A plain placeholder does not automatically fetch a Kubernetes Secret. Before production, adapt the chart to inject the credentials securely and avoid keeping them in Git or plaintext Helm values.

Configure the private container image:

image:
  repository: registry.example.com/nexus/cf
  tag: "<cm-version>"
  pullPolicy: IfNotPresent

Configure the storage:

pvc:
  cf:
    storageClassName: <rwx-storage-class>
    size: 200Mi
  cis:
    storageClassName: <supported-storage-class>

The 200Mi value is from the example configuration, not a universal production sizing recommendation. Storage sizing should reflect the actual product deployment and retention requirements.

Use a real RWX-capable StorageClass for the CF volume. Nexus Documentation

Step 6.4 — Build the Helm dependencies

helm dependency build

Render and inspect the templates:

helm template cm . \
  --namespace nexus \
  --debug > /tmp/nexus-cm-rendered.yaml

Inspect the rendered resource configuration without publishing sensitive contents.

Step 6.5 — Install CM

helm install cm . \
  --namespace nexus \
  --wait \
  --timeout 15m

Check the status:

helm list -n nexus

kubectl get pods -n nexus

kubectl get statefulsets -n nexus

kubectl get pvc -n nexus

The official chart uses a StatefulSet named cm-cf. Nexus Documentation

Check its status:

kubectl describe statefulset/cm-cf \
  -n nexus

For logs, first identify the actual CF Pod name:

kubectl get pods -n nexus

Then run:

kubectl logs <cf-pod-name> \
  -n nexus --tail=100

Step 6.6 — Test CM connectivity

The official guide provides access to the internal Certificate Manager service through port 5009.

kubectl port-forward \
  -n nexus service/cm-cf 5009:5009

This is intended for controlled local testing using the Nexus CM client tools, not as a public application endpoint.

Use Administrator’s Workbench or the supported Certificate Manager client tools to verify connection and authentication.

Step 6.7 — Complete PKI initialization

A healthy Kubernetes Pod does not mean that you have a production-ready CA.

After installation, complete the Nexus initial configuration and bootstrap procedures.

The bootstrap procedure establishes the organization’s CA hierarchy, officer identities, security credentials, and required system keys.

It also replaces the temporary bootstrap identity infrastructure. The bootstrap CA is revoked once the replacement configuration and officer access have been verified.

Follow Nexus’s Certificate Manager bootstrap procedure before using the installation for production certificate issuance. Nexus Documentation

7. Deploy Nexus Protocol Gateway (PGWY)

After CM is operational, deploy PGWY.

Step 7.1 — Prepare the chart

Navigate to the vendor’s PGWY example chart:

cd ../pgw-example

Inspect:

cat Chart.yaml
cat values.yaml

The chart provides configuration for the Tomcat-based PGWY application.

Step 7.2 — Configure the CM connection

PGWY must know how to reach the Certificate Factory service.

Because both applications are in the nexus namespace, the CM service DNS name is:

cm-cf.nexus.svc.cluster.local

In the chart’s values.yaml, set the documented cmhost parameter to the CF service hostname, using the format expected by your chart version.

Also configure the private PGWY image repository and tag.

Step 7.3 — Configure TLS and authentication

The vendor’s PGWY example chart includes:

pgw-example/files/
├── certdir/
│   ├── bootca.cer
│   └── trusted.jks
├── conf/
│   ├── acme.properties
│   ├── api.properties
│   ├── auth.properties
│   ├── cm-gateway.properties
│   └── boot_vro.p12
└── tomcat/
    ├── server.xml
    ├── context.xml
    └── web.xml

For the vendor’s default Tomcat TLS configuration, you must provide the tomcat-tls.p12 certificate container, or adjust server.xml to refer to your chosen keystore.

The file is not included in the base distribution. Nexus Documentation

Also verify:

PGWY trusts the appropriate CM CA certificates.
The virtual registration officer (VRO) is configured correctly.
Service-to-service TLS authentication works.
The required enrollment protocols are enabled.
Only necessary interfaces are exposed.

Important: The example PGWY deployment installs its protocol servlets, but they are not started by default. A running PGWY Pod alone does not mean ACME, SCEP, EST, or REST enrollment is functional.

Step 7.4 — Build and install the chart

helm dependency build

helm template pgw . \
  --namespace nexus \
  --debug > /tmp/nexus-pgw-rendered.yaml

Install PGWY:

helm install pgw . \
  --namespace nexus \
  --wait \
  --timeout 15m

Verify:

helm list -n nexus

kubectl get deployments,pods,svc \
  -n nexus

Inspect application logs:

kubectl get pods -n nexus

kubectl logs <pgw-pod-name> \
  -n nexus --tail=100

Step 7.5 — Access PGWY locally

The official deployment guide specifies these default service ports:

Port	Purpose
8080	HTTP / probe configuration
8443	HTTPS protocol interfaces
8444	Additional configured HTTPS interface

For controlled local testing:

kubectl port-forward \
  -n nexus service/pgw \
  8080:8080 8443:8443 8444:8444

Do not expose port 8080 publicly merely because it exists in the vendor example.

The exact functions available on 8443 and 8444 depend on the configured Tomcat connectors, authentication requirements, and enabled services. Nexus Documentation

8. Deploy Hermod Services

Hermod uses a different installation approach from CM and PGWY. Nexus provides a container image and a Kubernetes deployment example rather than the CM Helm charts.

The published Kubernetes documentation includes an example for Hermod 4.0.4. There is also guidance for 4.0.7, including changes to Spring Boot configuration. Use the version available in your approved Nexus distribution and its corresponding configuration files. Nexus Documentation+1

Step 8.1 — Prepare the Hermod configuration

Extract the simple-setup.zip supplied with Hermod.

You will find a configuration file named application.yml. Use the one supplied with your release as the starting point.

For this example, we will expose Hermod at:

https://hermod.example.com/ms

The following is an illustrative configuration for the 4.x properties documented by Nexus:


server:
  port: 20400
  servlet:
    context-path: /
  ssl:
    enabled: false

spring:
  jpa:
    hibernate:
      ddl-auto: validate

application:
  hermod:
    rest:
      uribase: ""
      hide-exceptions: true

    events:
      hide-sensitive: true

    allowed-clients:
      - client-id: pgwy-auth
        key: "<generate-unique-secret>"
        callback-url: "https://pgwy.example.com/pgwy/auth/callback"

    message-server-library:
      public-url: "https://hermod.example.com/ms"

The server.ssl.enabled: false setting assumes that HTTPS is terminated by a secured ingress or reverse proxy and the backend is protected by your cluster’s network controls. For end-to-end TLS, configure Hermod’s own TLS keystore and the load balancer appropriately.

The allowed-clients entry is needed for the example PGWY authentication integration. Generate a unique API secret and configure the matching credential in PGWY.

Do not copy the sample API keys included in some vendor documentation into production.

Step 8.2 — Create the database secret

Create a local file named hermod-db.env:

SPRING_DATASOURCE_URL=jdbc:postgresql://postgres.internal:5432/hermod
SPRING_DATASOURCE_USERNAME=hermoduser
SPRING_DATASOURCE_PASSWORD=REPLACE_WITH_SECURE_PASSWORD

Use a properly secured PostgreSQL connection, including TLS certificate verification, for production.

Restrict the file’s permissions:

chmod 600 hermod-db.env

Create the Kubernetes Secret:

kubectl create secret generic hermod-db \
  --namespace nexus \
  --from-env-file=hermod-db.env

Spring Boot can read the datasource settings through these environment variables.

Step 8.3 — Create the Hermod application configuration secret

Because the Hermod configuration can contain authentication credentials, use a Kubernetes Secret rather than an ordinary ConfigMap for the complete file.

Assuming your customized file is application.yml:

kubectl create secret generic hermod-config \
  --namespace nexus \
  --from-file=application.yml=./application.yml

For production, consider an external secrets manager and encrypted Kubernetes Secret storage. Kubernetes Secrets are not automatically a substitute for proper key management.

Step 8.4 — Create the Kubernetes Deployment and Service

Create hermod.yaml.

This is a custom starter manifest based on the vendor’s documented container paths and service port. It has not been tested against your licensed image or cluster, so adjust the resource settings, image version, health checks, and runtime configuration as required.


apiVersion: apps/v1
kind: Deployment
metadata:
  name: hermod
  namespace: nexus
  labels:
    app: hermod

spec:
  replicas: 1
  selector:
    matchLabels:
      app: hermod

  template:
    metadata:
      labels:
        app: hermod

    spec:
      # Add imagePullSecrets if your registry
      # requires a Kubernetes pull secret.

      containers:
        - name: hermod
          image: registry.example.com/nexus/hermod:4.x
          imagePullPolicy: IfNotPresent

          args:
            - --spring.profiles.active=native

          ports:
            - name: http
              containerPort: 20400

          env:
            - name: JAVA_OPTS
              value: "-Xms256m -Xmx512m"

          envFrom:
            - secretRef:
                name: hermod-db

          volumeMounts:
            - name: hermod-config
              mountPath: /home/docker/config
              readOnly: true

          resources:
            requests:
              cpu: 250m
              memory: 512Mi
            limits:
              memory: 1Gi

          startupProbe:
            tcpSocket:
              port: 20400
            periodSeconds: 10
            failureThreshold: 30

          readinessProbe:
            httpGet:
              path: /ms
              port: 20400
            periodSeconds: 10
            timeoutSeconds: 5

          securityContext:
            runAsNonRoot: true
            runAsUser: 1000
            allowPrivilegeEscalation: false

      volumes:
        - name: hermod-config
          secret:
            secretName: hermod-config

---
apiVersion: v1
kind: Service
metadata:
  name: hermod
  namespace: nexus

spec:
  type: ClusterIP
  selector:
    app: hermod

  ports:
    - name: http
      port: 20400
      targetPort: 20400
      protocol: TCP

Replace registry.example.com/nexus/hermod:4.x with the exact private image name and tag.

The /ms readiness path matches the configured root context and empty URI base in this example. If you retain the vendor’s default /hermod/rest path, adjust the probe accordingly.

This starter configuration uses a small JVM heap for initial testing. Nexus’s Hermod 4.0.7 upgrade guidance recommends a larger heap for better performance; size the Pod memory limit above the Java heap to leave room for native memory and JVM overhead. Nexus Documentation

Step 8.5 — Apply the deployment

kubectl apply -f hermod.yaml

Check rollout status:

kubectl rollout status deployment/hermod \
  -n nexus

Inspect Pods:

kubectl get pods -n nexus \
  -l app=hermod

Inspect logs:

kubectl logs deployment/hermod \
  -n nexus --tail=100

Verify its internal Service:

kubectl get svc hermod -n nexus

The internal Kubernetes address will be:

hermod.nexus.svc.cluster.local:20400

Step 8.6 — Test Hermod locally

Start port forwarding:

kubectl port-forward \
  -n nexus service/hermod 20400:20400

In another terminal:

curl -i http://localhost:20400/ms

With the example configuration, the message-service endpoint should respond. This tests availability only; it does not prove that authentication or callbacks are configured correctly.

9. Configure HTTPS and external access

At this stage, the Kubernetes services exist, but you have not yet established the external endpoints required by certificate clients or authentication devices.

I recommend separate DNS names:

Service	Example DNS	Access policy
CM core	`cm-cf.nexus.svc.cluster.local`	Internal only
Protocol Gateway	`pgwy.example.com`	Controlled access for approved clients
Hermod	`hermod.example.com`	Accessible to intended desktop/mobile clients
CM Web UI	`pki-admin.example.com`	Restricted administrative access, if deployed

9.1 Expose Hermod through an HTTPS ingress

If your cluster already uses an ingress controller supporting Kubernetes TLS Secrets, you can create an ingress for Hermod.

First, create a TLS Secret from a valid certificate and key:

kubectl create secret tls hermod-tls \
  --namespace nexus \
  --cert=server.crt \
  --key=server.key

Then create hermod-ingress.yaml:


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hermod
  namespace: nexus

spec:
  ingressClassName: nginx

  tls:
    - hosts:
        - hermod.example.com
      secretName: hermod-tls

  rules:
    - host: hermod.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: hermod
                port:
                  number: 20400

This assumes that nginx is an installed and functioning ingress class. Replace it with your actual controller’s configuration. AWS ALB ingress, for example, has different certificate configuration.

Apply:

kubectl apply -f hermod-ingress.yaml

Inspect:

kubectl get ingress -n nexus

Configure DNS so that hermod.example.com points to the ingress endpoint.

Test:

curl -i https://hermod.example.com/ms

This should only be considered complete once TLS trust, routing, and application responses have been verified.

9.2 Expose PGWY carefully

PGWY requires additional care because some Nexus enrollment and officer-authentication integrations rely on TLS client certificate authentication.

Nexus warns that ordinary Kubernetes ingress configurations may not support the required TLS passthrough behavior by default. Nexus Documentation

For that reason, do not automatically put every PGWY interface behind a standard HTTP-terminating ingress.

A common design is:

Enrollment / Officer Client

Layer 4 TCP Load BalancerTLS passthrough where client certificate authentication is required

PGWY Tomcat HTTPS ConnectorValidates the required TLS credentials

The exact LoadBalancer Service configuration depends on your Kubernetes platform and the networking settings provided by the Nexus Helm chart.

For an internal-only deployment, start with private access and test using port forwarding before provisioning a public endpoint.

10. Connect PGWY to Hermod

Now configure the authentication integration between the components.

This integration is particularly relevant when you want to use Hermod for CM officer authentication.

Step 10.1 — Configure the Hermod API client

Your Hermod application.yml includes:

application:
  hermod:
    allowed-clients:
      - client-id: pgwy-auth
        key: "<unique-secret>"
        callback-url: "https://pgwy.example.com/pgwy/auth/callback"

The callback URL must be accessible from Hermod. It can use restricted private routing if the DNS and TLS configuration support that design.

Step 10.2 — Configure PGWY authentication

In the PGWY chart, edit:

pgw-example/files/conf/auth.properties

Enable the authentication service and configure the corresponding Hermod endpoint.

Nexus documents properties such as:

start = true
default.authservice.apikey = <hermod-api-key>
default.authservice.apiurl = https://hermod.example.com

The apiurl above assumes the customized Hermod root context and empty URI base used in this tutorial. If you use Hermod’s default REST path, configure the matching /hermod/rest URL instead.

The API key must match the credential generated for the Hermod client. Follow the vendor’s X-Api-Key format and protect this credential as a secret.

After updating the PGWY Helm configuration:

cd helm/pgw-example

helm upgrade pgw . \
  --namespace nexus \
  --wait \
  --timeout 15m

Step 10.3 — Test the integration

Validate these stages separately:

PGWY can reach Hermod over the configured HTTPS endpoint.
Hermod accepts the registered PGWY client credential.
Hermod can reach the configured PGWY callback endpoint.
The client authentication flow can be initiated.
An authorized officer can complete authentication.

Nexus’s CM Web UI integration guide provides the specific PGWY and Hermod authentication properties.

Important: What about Certificate Manager Web UI?

CM Web UI is a separate component from the three services you named.

There is an important current limitation: Nexus’s Certificate Manager Web UI 2.0.2 release notes, dated October 20, 2026, state that container-based installation of the Web UI is not supported. The supported installation method is a WAR package on Tomcat for Linux or Windows. Nexus Documentation

Therefore, if you require the full browser-based administrative UI, the supported approach is to install it on a suitable Tomcat server outside the cluster, unless Nexus confirms a supported Kubernetes option for your particular version.

Hermod itself can still run inside Kubernetes.

11. Optional: Enable ACME certificate automation

This step is valuable when the same Kubernetes cluster will request certificates from Nexus CM.

The architecture becomes:

Kubernetes cert-manager → Nexus PGWY → Nexus CM

11.1 Configure ACME in PGWY

Edit:

pgw-example/files/conf/acme.properties

A Nexus-documented configuration pattern is:

start = true

handler.0.tokenProcedure = ACME TLS Web Server Token

handler.0.baseUrl = https://pgwy.example.com/pgwy/acme

handler.0.externalAccountRequired = true

The token procedure must already exist in CM, and the PGWY license must include ACME support. This configuration alone will not establish the procedure, CA authorization policies, or external account registration. Nexus Documentation

After the required CM and PGWY configuration is complete, the ACME directory URL is typically:

https://pgwy.example.com/pgwy/acme/directory

11.2 Integrate Kubernetes cert-manager

If you install the open-source Kubernetes cert-manager controller, it can use PGWY as an ACME server.

A typical ClusterIssuer configuration would include:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: nexus-private-ca

spec:
  acme:
    email: pki-admin@example.com

    server: https://pgwy.example.com/pgwy/acme/directory

    # Include caBundle if PGWY uses a private
    # TLS issuer not trusted by cert-manager.
    # caBundle: <base64-encoded-PEM-CA-bundle>

    externalAccountBinding:
      keyID: "<registered-key-id>"
      keySecretRef:
        name: nexus-acme-eab
        key: secret

    privateKeySecretRef:
      name: nexus-acme-account-key

    solvers:
      - http01:
          ingress:
            ingressClassName: nginx

This is an integration template, not a ready-to-apply production configuration. You must configure the EAB Secret, choose a challenge solver that works with your cluster’s networking, and establish trusted TLS communication with PGWY.

The caBundle option is supported by modern cert-manager versions and is preferable to disabling TLS verification for private ACME endpoints. cert-manager Documentation

Nexus also publishes an official Kubernetes cert-manager integration example.

12. If your Kubernetes cluster is AWS EKS

For EKS, I would map the components to AWS infrastructure as follows.

Requirement	AWS service / approach
Kubernetes compute	Amazon EKS
Nexus container images	Private Amazon ECR
CM and Hermod databases	Amazon RDS PostgreSQL, subject to database version compatibility
RWX storage for CM	Amazon EFS with EFS CSI driver
PGWY TLS passthrough	Network Load Balancer with TCP forwarding
Hermod HTTPS endpoint	Supported ingress / load-balancing configuration
DNS	Amazon Route 53
TLS certificates	Approved enterprise CA or ACM where applicable
Secrets	AWS Secrets Manager with an appropriate Kubernetes integration
Monitoring	Datadog, CloudWatch, or another supported telemetry platform

AWS documents EFS CSI storage for shared mounts and NLB configuration for EKS, including EKS Auto Mode. Amazon EKS+1

For EKS Auto Mode, check the networking and storage behavior specific to your cluster. Its built-in EBS block storage does not replace the RWX filesystem required by the Nexus CF chart.

A production PKI also requires specific attention to HSM compatibility and CA key protection; do not assume that AWS KMS can directly replace the signing device expected by Nexus without confirming the supported integration.

13. End-to-end verification

After completing the installations and required product configuration, verify all three services.

Kubernetes status

kubectl get pods,svc,pvc,deploy,statefulset \
  -n nexus

Check Helm:

helm list -n nexus

An illustrative deployment could contain:

NAME                       READY   STATUS
cm-cf-0                    1/1     Running
cm-cf-1                    1/1     Running
pgw-...                    1/1     Running
pgw-...                    1/1     Running
hermod-...                 1/1     Running

Actual Pod names and replica counts depend on your charts and configuration.

Functional validation checklist

Deployment acceptance checklist

0 / 11 completeCM StatefulSet is Ready and PVCs are boundCM database schema and connectivity are verifiedCA bootstrap and officer authentication are completePGWY Pods are Ready and can reach CFRequired PGWY protocol is enabled and respondingHermod is Ready and database connectivity is verifiedHermod public HTTPS URL is trusted and reachablePGWY to Hermod API authentication worksHermod callback flow is verifiedA test certificate is issued and validatedBackup, recovery, monitoring and alerts are configured

Copy checklist

14. Common deployment problems

Symptom	Likely issue	First check
`ImagePullBackOff`	Private registry authentication or wrong image tag	Pod events and image pull credentials
CF PVC remains `Pending`	StorageClass does not support RWX	`kubectl describe pvc`
CF Pod crashes	Database, license, key store, or configuration problem	CF logs and database status
PGWY is Ready but ACME fails	ACME servlet disabled or CM procedure missing	`acme.properties` and CM policy
Hermod `CrashLoopBackOff`	Incorrect database connection, missing schema, or configuration error	Hermod logs
Hermod `/ms` returns 404	Context path / URI base mismatch	`application.yml` and ingress routing
Hermod API returns 403	Invalid API client credential	Hermod registered client and PGWY API key
PGWY TLS client authentication fails	TLS terminated before Tomcat or missing trust	Load balancer mode and Tomcat TLS configuration
CM Web UI login fails	Hermod callback, officer identity, or authorization	Authentication and PGWY logs

For upgrades, use Helm release history:

helm history cm -n nexus
helm history pgw -n nexus

A Helm rollback is not a substitute for a database rollback or safe PKI recovery procedure. Database schema changes, certificates, and cryptographic key state may require separate recovery steps.

15. Recommended installation order

Prepare Kubernetes infrastructure — Namespace, private registry, network connectivity, RWX storage, and DNS.
Prepare SQL databases — CMDB and Hermod DB, including initialization scripts.
Install Nexus CM — Deploy cf-example using Helm and verify CF and CIS operation.
Bootstrap the PKI — Configure the issuing CA, officers, trust stores, and signing keys.
Install Nexus PGWY — Deploy pgw-example, configure its CF connection, and enable required protocols.
Install Hermod — Deploy the container, configure its database, HTTPS URL, API client, and callback.
Integrate and test — Validate authentication and certificate enrollment end to end.
Production hardening — High availability, backups, TLS, RBAC, logging, monitoring, and disaster recovery.

Official deployment references

My suggested starting point: Deploy CM and PGWY first using the actual Nexus Helm charts, then deploy Hermod separately using its release-specific container configuration. Keep the CA core private, use a supported RWX storage solution, and do not enable externally accessible enrollment or authentication until the PKI bootstrap and TLS trust configuration are complete.

The commands and Hermod manifests above provide a practical deployment foundation, but the final installation cannot be considered fully validated until the licensed Nexus files, database schemas, signing-key configuration, and specific Kubernetes environment have been tested together.

Yes. There are some mandatory dependencies for deploying Nexus Certificate Manager (CM), Protocol Gateway (PGWY), and Hermod on Kubernetes.

However, you do not need existing private application URLs to start the deployment. Kubernetes can provide internal DNS names automatically.

The bigger question is whether you have access to the licensed Nexus software packages, container images, and configuration files.

1. Mandatory dependencies

Dependency	Required?	Can you arrange it yourself?
Kubernetes cluster	Yes	Already available
Nexus CM container image	Yes	Must obtain licensed distribution
Nexus PGWY container image	Yes	Must obtain licensed distribution
Nexus Hermod image	Yes	Must obtain Nexus distribution
Nexus Helm charts	Yes, for documented CM/PGWY deployment	Included with CM distribution
Nexus CM license	Yes	Must obtain through your organization/vendor
PostgreSQL or supported SQL database	Yes	Yes
Private container registry	Yes, for normal Kubernetes image pulls	Yes, create ECR or another registry
Kubernetes internal service URLs	Yes	Automatically generated
Public DNS / HTTPS endpoint	For device-facing Hermod workflows	Can configure later
RWX persistent storage	Yes, for CM Helm deployment	Yes, using a compatible CSI driver
HSM	Depends on security requirements	For a lab, evaluate supported software-key configuration

Nexus confirms that the CM distribution supplies its container images and Helm charts, while a separate Hermod distribution is obtained through the Nexus Support Portal. Nexus Documentation+1

2. What happens if you do not have private URLs?

There are three different situations.

Case A — No internal application URLs

Not a blocker. Kubernetes creates service DNS names such as cm-cf.nexus.svc.cluster.local, pgw.nexus.svc.cluster.local, and hermod.nexus.svc.cluster.local.

You can begin with ClusterIP services and test using kubectl port-forward, without creating public DNS records.

Case B — No Nexus private registry or software-download access

This is a deployment blocker unless someone provides the licensed installation packages or another authorized way to pull the images.

You cannot install the actual CM, PGWY, and Hermod products merely from the public documentation. The CM images also must not be redistributed through public registries.

Case C — No public DNS name or publicly accessible HTTPS endpoint

You can start the CM/PGWY deployment and conduct internal tests.

For full Hermod authentication involving desktop or mobile devices, you need an HTTPS endpoint reachable by those clients. Nexus documents a reachable DNS name and matching TLS certificate as Hermod deployment prerequisites. Nexus Documentation

The URLs in my previous tutorial—such as registry.example.com, postgres.internal, pgwy.example.com, and hermod.example.com—were illustrative placeholders, not actual Nexus-hosted services you need to request access to.

3. What you should request before installation

If another team or Nexus administrator manages the software, request the following:

Nexus CM package: cm_server_<version>.zip, including CF/PGWY images and Helm charts.
Nexus license file: Valid for the planned components and protocols.
Hermod package: Supported 4.x container image and configuration examples.
Database details: A supported SQL database and permission to initialize the schemas.
CA configuration: Whether this is a new test CA or an existing enterprise PKI, plus applicable certificates, trust stores, and key-management requirements.
Access requirements: Whether PGWY and Hermod are intended for internal users only or external devices as well.

The official Nexus software distribution is available through the Nexus Support Portal to authorized customers.

4. What you can prepare right now

Even without the Nexus packages, you can check Kubernetes readiness:

# Verify cluster access
kubectl cluster-info

# Verify Kubernetes version
kubectl version

# Check storage classes
kubectl get storageclass

# Check nodes
kubectl get nodes

# Create namespace
kubectl create namespace nexus

# Verify namespace
kubectl get namespace nexus

You can also provision PostgreSQL, prepare suitable shared storage, and create a private container registry.

Once you receive the software, you can upload the licensed images into your private registry and deploy them without accessing Nexus’s registry directly from Kubernetes.

5. What is possible with your current access?

What you have	What you can do
Only Kubernetes access	Prepare namespace, storage, networking, and database
Kubernetes + licensed images + Helm charts + license	Deploy CM and PGWY
Above + Hermod image + database	Deploy Hermod as well
Above + PKI initialization and credentials	Perform certificate-management tests
Above + reachable DNS, TLS, and client integration	Test complete authentication and enrollment workflows

1. Recommended architecture

Important Kubernetes-specific difference

2. Deployment components and responsibilities

3. Prerequisites

3.1 Software and infrastructure

3.2 Verify your Kubernetes cluster

3.3 Create the namespace

4. Prepare the databases

Step 4.1 — Initialize the CM database

Step 4.2 — Initialize the Hermod database

Step 4.3 — Test database access

5. Obtain the Nexus container images and Helm charts

Step 5.1 — Download the packages

Step 5.2 — Locate the Helm charts

Step 5.3 — Load the container images

Step 5.4 — Push the images to a private registry

6. Deploy Nexus Certificate Manager (CM)

Step 6.1 — Prepare the chart

Step 6.2 — Install the license and configuration

Step 6.3 — Configure values.yaml

Step 6.4 — Build the Helm dependencies

Step 6.5 — Install CM

Step 6.6 — Test CM connectivity

Step 6.7 — Complete PKI initialization

7. Deploy Nexus Protocol Gateway (PGWY)

Step 7.1 — Prepare the chart

Step 7.2 — Configure the CM connection

Step 7.3 — Configure TLS and authentication

Step 7.4 — Build and install the chart

Step 7.5 — Access PGWY locally

8. Deploy Hermod Services

Step 8.1 — Prepare the Hermod configuration

Step 8.2 — Create the database secret

Step 8.3 — Create the Hermod application configuration secret

Step 8.4 — Create the Kubernetes Deployment and Service

Step 8.5 — Apply the deployment

Step 8.6 — Test Hermod locally

9. Configure HTTPS and external access

9.1 Expose Hermod through an HTTPS ingress

9.2 Expose PGWY carefully

10. Connect PGWY to Hermod

Step 10.1 — Configure the Hermod API client

Step 10.2 — Configure PGWY authentication

Step 10.3 — Test the integration

Important: What about Certificate Manager Web UI?

11. Optional: Enable ACME certificate automation

11.1 Configure ACME in PGWY

11.2 Integrate Kubernetes cert-manager

12. If your Kubernetes cluster is AWS EKS

13. End-to-end verification

Kubernetes status

Functional validation checklist

14. Common deployment problems

15. Recommended installation order

Official deployment references

1. Mandatory dependencies

2. What happens if you do not have private URLs?

3. What you should request before installation

4. What you can prepare right now

5. What is possible with your current access?

Related Posts

Top DevOps Training & Certification with Live Projects

Google Cloud Platform (GCP): A Complete Beginner’s Guide to Cloud Computing

JavaFX In-Depth: The Ultimate Guide to Modern Java GUI Development

Step 6.3 — Configure `values.yaml`