1. Context

Certificates are an essential part of secure communication. Using the cert-manager Operator on OCP, we will show how to use them in Camel.

2. Prerequisites

A Camel integration to be deployed on OpenShift and the cert-manager Operator for Red Hat OpenShift installed with an Issuer configured correctly.

3. Goal

Provide a guide on how to use generated certificates by the cert-manager Operator in Camel applications deployed on OCP.

4. Usage

Using the cert-manager.io/Certificate object, the cert-manager will produce a secret containing the keystores and truststores needed to secure your Camel application. The generated secret includes the following files:

  • tls.crt for the certificate

  • tls.key for the private key

  • ca.crt for the CA certificate (if needed)

  • truststore.jks for the Trustore

  • keystore.jks for the Keystore

Each of these can then be loaded in your Camel application either by mounting the secret as a volume in the Camel pod or fetch them directly in the application using the syntax

secret:name/key[:defaultValue]

Make sure the application has the appropriate rights to read Kubernetes Secrets (see our Secrets guide for more information).

Example certificate.yaml file:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: <tls_cert>
  namespace: <issuer_namespace>
spec:
  isCA: false
  commonName: '<common_name>'
  secretName: <secret_name>
  dnsNames:
  - "<domain_name>"
  issuerRef:
    name: <issuer_name>
    kind: Issuer

For the case to protect HTTPS endpoints with a Certificate, you can annotate an Ingress resource with cert-manager that will trigger the creation of an Certificate (so you don’t have to create it) and associate it to the HTTPS endpoint.

For a pratical example, you can follow our examples for both the runtimes supported by Red Hat Build of Apache Camel. It shows how to secure communication between a client and a server using mutual TLS (mTLS) :