Skip to main content

Generating the SSL/TLS certificate and creating the Kubernetes Secret

Secure communication between external users and Adeptia Automate requires an SSL/TLS certificate. This document explains how to generate a certificate and create the Kubernetes TLS secret that the gateway uses to terminate HTTPS traffic.

This secret is referenced in the Gateway resource for the following gateway options:

  • Application Gateway for Containers (AGC)
  • Envoy Gateway

AWS ALB users: TLS termination on ALB is handled using an AWS Certificate Manager (ACM) certificate, not a Kubernetes TLS secret. The Kubernetes secret described here is used only for backend TLS validation in ALB deployments. See Setting up AWS ALB with Gateway API for details.

Prerequisites​

The steps in this document use the keytool utility, which is included with the Java Development Kit (JDK). If keytool is not available on your system, install the JDK before proceeding. Refer to the Oracle JDK documentation for installation instructions.

Generating the certificate​

You can use either a self-signed certificate (for testing and internal environments) or a CA-signed certificate (for production).

Self-Signed certificate​

Open PowerShell and run the following keytool command to generate a keystore with a self-signed certificate.

Using an IP address (SAN):

keytool -genkey -keyalg RSA \
  -alias selfsigncert \
  -keystore certs.jks \
  -storepass changeit \
  -validity 365 \
  -keysize 2048 \
  -ext san=ip:<FQDN_OR_IP_OF_GATEWAY>

Using a DNS name (SAN):

keytool -genkey -keyalg RSA \
  -alias selfsigncert \
  -keystore certs.jks \
  -storepass changeit \
  -validity 365 \
  -keysize 2048 \
  -ext san=dns:<YOUR_DOMAIN>

Parameter reference

ParameterDescription
-keyalgKey algorithm. Use RSA.
-aliasA unique name to identify this entry in the keystore.
-keystorePath and filename where the keystore will be saved.
-storepassPassword to protect the keystore. Default is changeit.
-validityNumber of days before the certificate expires.
-keysizeKey size in bits. Use 2048 or higher.
-ext san=ip: or -ext san=dns:Subject Alternative Name — the IP address or DNS name of the gateway.

CA-Signed certificate​

Use this option for production environments where a trusted CA-issued certificate is required.

Step 1: Generate the Keystore​

keytool -genkey -keyalg RSA \
  -alias server \
  -keystore certs.jks \
  -storepass changeit \
  -validity 365 \
  -keysize 2048

If the certificate will cover multiple domain names, include a Subject Alternative Name:

keytool -genkey -keyalg RSA \
  -alias server \
  -keystore certs.jks \
  -storepass changeit \
  -validity 365 \
  -keysize 2048 \
  -ext SAN=ip:<FQDN_OR_IP_OF_GATEWAY>

Step 2: Generate a Certificate Signing Request (CSR)​

keytool -certreq \
  -alias server \
  -file <domainname>.csr \
  -keystore certs.jks \
  -storepass changeit

If using multiple domain names, include the SAN in the CSR:

keytool -certreq \
  -alias server \
  -file <domainname>.csr \
  -keystore certs.jks \
  -storepass changeit \
  -ext san=ip:<FQDN_OR_IP>

Submit the generated .csr file to your Certificate Authority (CA).

Step 3: Import the CA-Signed certificates​

After your CA returns the signed certificates, import them into the same keystore used to generate the CSR. Import them in the following order.

Import the trusted root certificate:

keytool -import -trustcacerts \
  -alias root \
  -file <root_certificate>.crt \
  -keystore certs.jks

Import the intermediate certificate (if provided by your CA):

keytool -import -trustcacerts \
  -alias intermediate \
  -file <intermediate_certificate>.crt \
  -keystore certs.jks

Import the domain (leaf) certificate:

keytool -import -trustcacerts \
  -alias server \
  -file <domain_certificate>.crt \
  -keystore certs.jks

Important: Use the same .jks keystore file that was used to generate the CSR. You will be prompted for the keystore password during import.

Exporting the certificate and key for Kubernetes​

Kubernetes TLS secrets require PEM-format files: a certificate (tls.crt) and a private key (tls.key).

If your CA has already provided the certificate and private key as PEM files (.crt and .key), skip this section and proceed directly to Creating the Kubernetes TLS secret.

Export the certificate from the keystore:

keytool -exportcert \
  -alias <alias_name> \
  -keystore certs.jks \
  -storepass changeit \
  -rfc \
  -file tls.crt

Convert the keystore to PKCS12, then extract the private key:

keytool -importkeystore \
  -srckeystore certs.jks \
  -destkeystore certs.p12 \
  -deststoretype PKCS12 \
  -srcalias <alias_name>

openssl pkcs12 \
  -in certs.p12 \
  -nocerts \
  -nodes \
  -out tls.key

Creating the Kubernetes TLS secret​

Navigate to the directory containing tls.crt and tls.key:

cd "<path to certificate directory>"

Create the TLS secret:

kubectl create secret tls <tls_secret_name> \
  --key="tls.key" \
  --cert="tls.crt" \
  --namespace <application_namespace>
errorThe certificate must contain a Common Name (CN) or Subject Alternative Name (SAN) that matches the fully qualified domain name (FQDN) used to access Adeptia Automate — for example, myapp.example.com. Certificates without a matching CN or SAN will cause TLS validation errors.

Verify the secret was created:

kubectl get secrets -n <application_namespace>
kubectl describe secret <tls_secret_name> -n <application_namespace>

The output should show Type: kubernetes.io/tls with non-zero file sizes for both tls.crt and tls.key.

Next steps​

Use the TLS secret name when configuring the Gateway resource for your gateway: