When cert-manager meets Essendi XC

After a year of running in production, I'm ready to publish the first public release of the cert-manager issuer for the Essendi XC certificate management tool. Essendi XC Essendi XC is a platform focused on managing the lifecycle of digital certificates within organizations. It centralizes tasks like issuing, renewing, and revoking certificates, supporting integration with various certificate authorities and existing IT systems. The platform is designed to reduce manual work and help prevent certificate-related outages by automating routine processes. Its interface and APIs allow for easy monitoring and reporting of certificate status. Essendi XC is commonly used in environments where certificate sprawl and compliance are concerns. cert-manager The cert-manager operator is an extension for Kubernetes that automates the handling of certificates inside clusters, becoming the de-facto standard in this area. It enables users to define certificate requests as Kubernetes resources, which are then automatically fulfilled and renewed. By connecting cert-manager to external systems like Essendi XC, organizations can use their existing certificate infrastructure within Kubernetes. This integration helps ensure applications always have valid certificates without manual intervention. The operator is widely adopted for managing TLS in cloud-native deployments with issuer like Let's Encrypt or AWS Private CA. Why integrate cert-manager with Essendi XC in enterprise Kubernetes environments? As we know, cert-manager is the go-to standard for automating the management of TLS certificates within clusters. It natively handles certificate requests, renewals, and deployments, supporting integrations with both public CAs (via ACME) and enterprise CAs like Microsoft ADCS. However, as the number of clusters and applications grows, direct integration between each cluster and multiple CAs becomes hard to govern. This approach can lead to inconsistent policies, fragmented audit trails, and increased operational complexity-especially when compliance, security, and centralised visibility are required. For organizations with strict governance and compliance needs, it’s better to introduce a single certificate management layer that acts as the policy and automation hub for all certificate operations. Essendi XC fits this role by providing a central platform for certificate lifecycle management. The integration works as follows: when a Kubernetes workload needs a certificate, a developer or operator creates a Certificate resource in the cluster. The cert-manager issuer plugin for Essendi XC intercepts the CertificateRequest and forwards the CSR (Certificate Signing Request) to Essendi XC, specifying the correct certificate profile. Essendi XC then applies organizational policies, routes the request to the appropriate CA, handles any required validations or approvals, and finally returns the signed certificate. Cert-manager receives the certificate and stores it as a Kubernetes Secret, making it available to workloads without manual intervention. Installing, configuring and using the operator In a cluster that is already running an updated cert-manager instance you can add the additional issuer operator with: helm install essendi-xc-issuer --namespace cert-manager oci://registry-1.docker.io/angeloxx/cert-manager-essendi-xc-issuer --version 0.1.0-helm Once installed, you have to define a valid Essendi XC issuer with the ClusterIssuer CRD and the Secret with the needed API credential: apiVersion: v1 kind: Secret metadata: name: essendixc-cert-manager-test namespace: cert-manager stringData: client-id: Cert-Manager-90d client-secret: my-secret signature-key: signature token: eyJhbGciOiJIUzI1NiIsInR5cCIgOi[...] --- apiVersion: essendixc.angeloxx.ch/v1alpha1 kind: ClusterIssuer metadata: name: essendixc-ad-90d spec: authSecretName: essendixc-cert-manager-test customFields: - name: Application value: '{{ .Csr.CommonName }}' - name: DeploymentTarget value: Kubernetes - name: Environment value: Testing Environment - name: NotificationMail value: cloudnatives@bigcorp.ch ignoreHostInApiResponse: true profileName: AD-90days-Kubernetes subscriberName: DevopsTeam url: https://essendixc.bigcorp.local All of these settings are derived from the Essendi XC configuration. You create a profile and a subscriber, and during the request process, the CSR is submitted along with the specified additional customFields metadata. Essendi XC APIs does not offer an option to define the certificate duration directly; instead, the duration is determined by the profile referenced by the ClusterIssuer. The profile also defines whether certificate requests can be auto-approved and enforces certain constraints. For example, SANs must match a specific regular expression (such as .*.preproduction.bigcorp.local), or a minimum key length may be requi

May 10, 2025 - 23:25

After a year of running in production, I'm ready to publish the first public release of the cert-manager issuer for the Essendi XC certificate management tool.

Essendi XC

Essendi XC is a platform focused on managing the lifecycle of digital certificates within organizations. It centralizes tasks like issuing, renewing, and revoking certificates, supporting integration with various certificate authorities and existing IT systems. The platform is designed to reduce manual work and help prevent certificate-related outages by automating routine processes. Its interface and APIs allow for easy monitoring and reporting of certificate status. Essendi XC is commonly used in environments where certificate sprawl and compliance are concerns.

cert-manager

The cert-manager operator is an extension for Kubernetes that automates the handling of certificates inside clusters, becoming the de-facto standard in this area. It enables users to define certificate requests as Kubernetes resources, which are then automatically fulfilled and renewed. By connecting cert-manager to external systems like Essendi XC, organizations can use their existing certificate infrastructure within Kubernetes. This integration helps ensure applications always have valid certificates without manual intervention. The operator is widely adopted for managing TLS in cloud-native deployments with issuer like Let's Encrypt or AWS Private CA.

Why integrate cert-manager with Essendi XC in enterprise Kubernetes environments?

As we know, cert-manager is the go-to standard for automating the management of TLS certificates within clusters. It natively handles certificate requests, renewals, and deployments, supporting integrations with both public CAs (via ACME) and enterprise CAs like Microsoft ADCS. However, as the number of clusters and applications grows, direct integration between each cluster and multiple CAs becomes hard to govern. This approach can lead to inconsistent policies, fragmented audit trails, and increased operational complexity-especially when compliance, security, and centralised visibility are required.

For organizations with strict governance and compliance needs, it’s better to introduce a single certificate management layer that acts as the policy and automation hub for all certificate operations. Essendi XC fits this role by providing a central platform for certificate lifecycle management.

The integration works as follows: when a Kubernetes workload needs a certificate, a developer or operator creates a Certificate resource in the cluster. The cert-manager issuer plugin for Essendi XC intercepts the CertificateRequest and forwards the CSR (Certificate Signing Request) to Essendi XC, specifying the correct certificate profile. Essendi XC then applies organizational policies, routes the request to the appropriate CA, handles any required validations or approvals, and finally returns the signed certificate. Cert-manager receives the certificate and stores it as a Kubernetes Secret, making it available to workloads without manual intervention.

Installing, configuring and using the operator

In a cluster that is already running an updated cert-manager instance you can add the additional issuer operator with:

helm install essendi-xc-issuer --namespace cert-manager
   oci://registry-1.docker.io/angeloxx/cert-manager-essendi-xc-issuer 
   --version 0.1.0-helm

Once installed, you have to define a valid Essendi XC issuer with the ClusterIssuer CRD and the Secret with the needed API credential:

apiVersion: v1
kind: Secret
metadata:
  name: essendixc-cert-manager-test
  namespace: cert-manager
stringData:
  client-id: Cert-Manager-90d
  client-secret: my-secret
  signature-key: signature
  token: eyJhbGciOiJIUzI1NiIsInR5cCIgOi[...]
---
apiVersion: essendixc.angeloxx.ch/v1alpha1
kind: ClusterIssuer
metadata:
  name: essendixc-ad-90d
spec:
  authSecretName: essendixc-cert-manager-test
  customFields:
  - name: Application
    value: '{{ .Csr.CommonName }}'
  - name: DeploymentTarget
    value: Kubernetes
  - name: Environment
    value: Testing Environment
  - name: NotificationMail
    value: cloudnatives@bigcorp.ch
  ignoreHostInApiResponse: true
  profileName: AD-90days-Kubernetes
  subscriberName: DevopsTeam
  url: https://essendixc.bigcorp.local

All of these settings are derived from the Essendi XC configuration. You create a profile and a subscriber, and during the request process, the CSR is submitted along with the specified additional customFields metadata.

Essendi XC APIs does not offer an option to define the certificate duration directly; instead, the duration is determined by the profile referenced by the ClusterIssuer. The profile also defines whether certificate requests can be auto-approved and enforces certain constraints. For example, SANs must match a specific regular expression (such as .*.preproduction.bigcorp.local), or a minimum key length may be required.

A new certificate request, with the defined ClusterIssuer (essendixc-ad-90d) can be generated:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: prommetheus-server-tls
  namespace: prometheus
spec:
  commonName: prometheus.metrics.test.bigcorp.local
  dnsNames:
  - prometheus.metrics.test.bigcorp.local
  - prometheus-test.bigcorp.local
  issuerRef:
    group: essendixc.angeloxx.ch
    kind: ClusterIssuer
    name: essendixc-ad-90d
  privateKey:
    rotationPolicy: Always
  renewBefore: 720h
  secretName: prometheus-server-tls
  subject:
    countries:
    - CH
    localities:
    - Mendrisio
    organizationalUnits:
    - IT Services
    organizations:
    - BigCorp SA
    provinces:
    - Ticino
  usages:
  - digital signature
  - key encipherment

Cert-manager will evaluate and approve it, then generate a certificate request, which the cert-manager-essendi-xc-issuer operator will send to Essendi XC. Once approved

Conditions:
    Last Transition Time:  2025-05-09T19:42:43Z
    Message:               Certificate request has been approved by cert-manager.io
    Reason:                cert-manager.io
    Status:                True
    Type:                  Approved
    Last Transition Time:  2025-05-09T19:43:18Z
    Message:               Signed
    Reason:                Issued
    Status:                True
    Type:                  Ready
Events:
  Type    Reason                        Age    From                                       Message
  ----    ------                        ----   ----                                       -------
  Normal  CertificateRequestReconciler  9m22s  essendi-xc-issuer                          Initialising Ready condition
  Normal  cert-manager.io               9m22s  cert-manager-certificaterequests-approver  Certificate request has been approved by cert-manager.io
  Normal  CertificateRequestReconciler  9m17s  essendi-xc-issuer                          Certificate request submitted, status: https://essendixc.bigcorp.local/api/v2/tasks/requests/25efc35a-24de-4227
-95a2-7297d007a650
  Normal  CertificateRequestReconciler  9m14s  essendi-xc-issuer                          Certificate request approved, resource: https://essendixc.bigcorp.local/api/v2/tasks/requests/25efc35a-24de-422
7-95a2-7297d007a650
  Normal  CertificateRequestReconciler  8m47s  essendi-xc-issuer                          Certificate is signed, resource: https://essendixc.bigcorp.local/api/v2/certificates/ac7f77f7194d4473d4e1ba832d
6c0182e00f927453705b59068095e2fff8d72b
  Normal  CertificateRequestReconciler  8m47s  essendi-xc-issuer                          Signed

the operator received the signed request and the application received the requested.

Some attributes, such as spec.privateKey.rotationPolicy = Always, may be mandatory. This is one of the aspects that differentiates the use of a centralised certificate manager from the direct integration of a CA. A company-wide policy might restrict the reuse of private keys. In Kubernetes, you can enforce this policy using Kyverno, but you cannot do the same outside a cluster.

Wrap up

In an enterprise environment, this operator acts as a bridge between a cloud-native platform like Kubernetes and the centralised certificate management solution, eliminating the need to connect cert-manager directly to multiple providers.

The project is available on GitHub:
https://github.com/angeloxx/cert-manager-essendi-xc-issuer