OpenShift TLS and Secure Routes

Learn how TLS works in OpenShift, understand secure Routes, SSL certificates, Edge, Passthrough and Re-encrypt termination, and implement secure Spring Boot APIs with enterprise best practices.


Introduction

Security is one of the most important aspects of any cloud-native application. Whether you're building an online banking platform, healthcare system, insurance portal, or SaaS application, every request travelling over the Internet must be encrypted.

Without encryption, attackers can intercept usernames, passwords, API tokens, credit card numbers, and confidential business information.

OpenShift provides Secure Routes using TLS (Transport Layer Security) to encrypt communication between clients and your Spring Boot applications.

In this article, you'll learn how TLS works, how OpenShift implements secure Routes, and how to configure secure HTTPS endpoints for Spring Boot applications.


Learning Objectives

By the end of this article, you will understand:

  • What is TLS?
  • Difference between SSL and TLS
  • Why HTTPS is important
  • OpenShift Secure Routes
  • TLS Architecture
  • Edge Termination
  • Passthrough Termination
  • Re-encrypt Termination
  • Spring Boot HTTPS deployment
  • Certificates
  • Production best practices

What is TLS?

TLS (Transport Layer Security) is a cryptographic protocol that encrypts data transmitted between two systems.

It ensures:

  • Confidentiality
  • Integrity
  • Authentication

Without TLS:

  • Anyone can read network traffic.
  • Passwords travel in plain text.
  • API tokens can be stolen.

With TLS:

  • Data is encrypted.
  • Only the sender and receiver can read the information.

HTTP vs HTTPS

HTTP HTTPS
Plain Text Encrypted
Port 80 Port 443
Not Secure Secure
Easily Intercepted Protected by TLS
No Certificate Requires Certificate

Why HTTPS Matters

Imagine a customer logging into an online banking application.

Without HTTPS:

Username : john

Password : MyPassword123

Anyone monitoring the network can read this information.

With HTTPS:

Encrypted Binary Data

a9f8d7h61j2k...

Even if intercepted, it is unreadable.


SSL vs TLS

Many developers still use the term SSL, but modern systems use TLS.

SSL TLS
Older Protocol Modern Protocol
Deprecated Active Standard
Less Secure More Secure
SSL 3.0 TLS 1.2 / TLS 1.3

When people say "SSL Certificate", they usually mean a TLS certificate.


OpenShift Secure Route Architecture

flowchart LR
    User[Internet User]
    Browser[Web Browser]
    Route[OpenShift Secure Route]
    Service[ClusterIP Service]
    Pod1[Spring Boot Pod 1]
    Pod2[Spring Boot Pod 2]
    DB[(PostgreSQL)]

    User --> Browser
    Browser --> Route
    Route --> Service
    Service --> Pod1
    Service --> Pod2
    Pod1 --> DB
    Pod2 --> DB

Every external request passes through the Secure Route.


Request Flow

sequenceDiagram

participant User

participant Browser

participant Route

participant Service

participant SpringBoot

participant Database

User->>Browser: Open HTTPS URL

Browser->>Route: TLS Handshake

Route->>Service: Forward Request

Service->>SpringBoot: Load Balance

SpringBoot->>Database: Execute Query

Database-->>SpringBoot: Response

SpringBoot-->>Browser: JSON Response

How TLS Works

TLS establishes a secure encrypted connection before data is exchanged.

High-level process:

  1. Client connects.
  2. Server sends certificate.
  3. Client verifies certificate.
  4. Encryption keys are generated.
  5. Secure communication begins.

TLS Handshake

sequenceDiagram

participant Client

participant Route

Client->>Route: Client Hello

Route->>Client: Server Certificate

Client->>Route: Verify Certificate

Client->>Route: Exchange Keys

Route-->>Client: Secure Connection Established

After the handshake, every request is encrypted.


Digital Certificate

A TLS certificate contains:

  • Domain Name
  • Organization
  • Public Key
  • Certificate Authority
  • Expiration Date

Example:

CN=api.codewithvenu.com

Issuer=Let's Encrypt

Valid Until=2027

Certificate Authority (CA)

Certificates are issued by trusted organizations called Certificate Authorities.

Examples:

  • Let's Encrypt
  • DigiCert
  • GlobalSign
  • Sectigo
  • Entrust

Browsers automatically trust certificates signed by recognized CAs.


Route TLS Termination

OpenShift supports three secure TLS termination modes.

flowchart TD

TLS

--> Edge

TLS

--> Passthrough

TLS

--> ReEncrypt

Each mode serves a different use case.


Edge Termination

Edge termination decrypts HTTPS traffic at the OpenShift Router.

Communication between the Router and Spring Boot application is HTTP.

flowchart LR

Browser

-- HTTPS --> Router

Router

-- HTTP --> Service

Service

--> SpringBoot

Edge Termination Route

apiVersion: route.openshift.io/v1
kind: Route

metadata:
  name: payment-route

spec:

  to:

    kind: Service

    name: payment-service

  tls:

    termination: edge

When to Use Edge Termination

Recommended for:

  • Internal enterprise applications
  • Spring Boot REST APIs
  • Corporate applications
  • Developer environments
  • SaaS portals

Advantages:

  • Easy configuration
  • Excellent performance
  • Most common deployment model

Passthrough Termination

The Router does not decrypt traffic.

HTTPS traffic reaches the application unchanged.

flowchart LR

Browser

-- HTTPS --> Router

Router

-- HTTPS --> Service

Service

--> SpringBoot

The Spring Boot application manages its own certificates.


Passthrough YAML

tls:

  termination: passthrough

When to Use Passthrough

Recommended for:

  • Banking
  • Payment systems
  • Mutual TLS (mTLS)
  • PCI DSS applications
  • Highly secure APIs

Re-encrypt Termination

The Router decrypts the request and encrypts it again before forwarding it.

flowchart LR

Browser

-- HTTPS --> Router

Router

-- HTTPS --> Service

Service

--> SpringBoot

Traffic remains encrypted throughout the network.


Re-encrypt YAML

tls:

  termination: reencrypt

When to Use Re-encrypt

Recommended for:

  • Healthcare
  • Banking
  • Insurance
  • Government
  • Internal Zero Trust networks

TLS Comparison

Feature Edge Passthrough Re-encrypt
Router Decrypts Traffic
Backend Uses HTTPS
Spring Boot Manages Certificates
Performance High Medium Medium
Security High Very High Highest

Spring Boot Architecture

flowchart LR
    USER["Internet"]
    ROUTE["OpenShift Route"]
    SVC["Service"]

    subgraph APP["Spring Boot Application"]
        P1["Pod 1"]
        P2["Pod 2"]
    end

    DB["PostgreSQL"]

    USER --> ROUTE
    ROUTE --> SVC
    SVC --> P1
    SVC --> P2
    P1 --> DB
    P2 --> DB

Spring Boot Deployment

Deployment YAML

apiVersion: apps/v1
kind: Deployment

metadata:
  name: payment-api

spec:

  replicas: 3

  selector:

    matchLabels:

      app: payment-api

  template:

    metadata:

      labels:

        app: payment-api

    spec:

      containers:

      - name: payment-api

        image: quay.io/codewithvenu/payment-api:1.0

        ports:

        - containerPort: 8080

Create Secure Route

oc expose service payment-service

Configure TLS:

oc edit route payment-route

Add:

tls:
  termination: edge

Verify Route

oc get routes

Expected output:

NAME              HOST

payment-route     payment.apps.cluster.example.com

Open:

https://payment.apps.cluster.example.com

You should see the browser displaying a secure HTTPS connection.


Custom Domains

Production applications rarely use the default OpenShift hostname.

Instead of:

https://payment-api.apps.cluster.example.com

Use a custom domain:

https://api.codewithvenu.com

Benefits:

  • Better branding
  • Easier to remember
  • Trusted by users
  • Easier certificate management

Production Architecture

flowchart LR
    User[Internet User]
    DNS[Public DNS]
    LB[Load Balancer]
    Router[OpenShift Router]
    Route[Secure Route]
    Service[Payment Service]
    Pod1[Spring Boot Pod 1]
    Pod2[Spring Boot Pod 2]
    DB[(PostgreSQL)]

    User --> DNS
    DNS --> LB
    LB --> Router
    Router --> Route
    Route --> Service
    Service --> Pod1
    Service --> Pod2
    Pod1 --> DB
    Pod2 --> DB

DNS Configuration

A DNS record should point to the OpenShift Router.

Example:

api.codewithvenu.com

        ↓

OpenShift Router

DNS Types commonly used:

  • A Record
  • CNAME
  • Alias Record

Route with Custom Host

apiVersion: route.openshift.io/v1
kind: Route

metadata:
  name: payment-route

spec:

  host: api.codewithvenu.com

  to:
    kind: Service
    name: payment-service

  tls:
    termination: edge

TLS Certificates

Every HTTPS Route requires a certificate.

Certificate contains:

  • Public Key
  • Organization
  • Domain
  • Expiration
  • Certificate Authority
Certificate

├── Public Key

├── Domain

├── Issuer

└── Expiration

Let's Encrypt

Most organizations use automatic certificate generation.

flowchart LR
    Route[OpenShift Route]
    --> LetsEncrypt[Let's Encrypt]

    LetsEncrypt
    --> Certificate[TLS Certificate]

    Certificate
    --> Browser

Advantages:

  • Free
  • Automatic renewal
  • Trusted by browsers

Certificate Secret

Certificates are stored securely inside OpenShift.

flowchart TD
    Certificate[TLS Certificate]

    --> Secret[OpenShift Secret]

    Secret

    --> Route

    Route

    --> Browser

Create TLS Secret

oc create secret tls payment-cert \
--cert=tls.crt \
--key=tls.key

Verify:

oc get secrets

Secure Route Using Secret

spec:

  tls:

    termination: edge

    certificate: |

      -----BEGIN CERTIFICATE-----

      ...

      -----END CERTIFICATE-----

    key: |

      -----BEGIN PRIVATE KEY-----

      ...

      -----END PRIVATE KEY-----

HTTPS Spring Boot

Spring Boot itself can also expose HTTPS.

Example:

server.port=8443

server.ssl.enabled=true

server.ssl.key-store=classpath:keystore.p12

server.ssl.key-store-password=password

server.ssl.keyStoreType=PKCS12

However, in OpenShift this is typically not required when using Edge termination, because HTTPS is terminated at the Router.


Mutual TLS (mTLS)

Some enterprise applications require both:

  • Server Authentication
  • Client Authentication

This is called Mutual TLS (mTLS).

sequenceDiagram
    participant Client
    participant Router
    participant SpringBoot

    Client->>Router: Client Certificate

    Router->>Client: Server Certificate

    Router->>SpringBoot: Verified HTTPS

    SpringBoot-->>Client: Secure Response

Banking Example

Payment API requiring Mutual TLS.

flowchart LR
    MOBILE["Mobile App"]
    HTTPS["HTTPS / mTLS"]
    ROUTE["OpenShift Route"]
    GATEWAY["API Gateway"]
    PAYMENT["Payment Service"]
    DB[("Oracle DB")]

    MOBILE --> HTTPS
    HTTPS --> ROUTE
    ROUTE --> GATEWAY
    GATEWAY --> PAYMENT
    PAYMENT --> DB

Only trusted mobile applications can connect.


Healthcare Example

flowchart TD
    DOCTOR["Doctor Portal"]
    ROUTE["OpenShift Route"]
    EMR["EMR Service"]
    DB[("Patient Database")]

    DOCTOR -- "HTTPS" --> ROUTE
    ROUTE --> EMR
    EMR --> DB

Patient information remains encrypted.


E-Commerce Example

flowchart LR
    CUSTOMER["Customer"]
    ROUTE["OpenShift Route"]
    SHOP["Shopping Service"]
    PAYMENT["Payment Gateway"]
    DB[("Database")]

    CUSTOMER -- "HTTPS" --> ROUTE
    ROUTE --> SHOP
    SHOP --> PAYMENT
    PAYMENT --> DB

Customer payment information stays secure.


API Gateway Architecture

Most enterprises expose only an API Gateway.

flowchart LR
    BROWSER["Browser"]
    ROUTE["HTTPS Route"]
    GATEWAY["API Gateway"]

    PAYMENT["Payment Service"]
    CUSTOMER["Customer Service"]
    NOTIFY["Notification Service"]

    PAYMENTDB[("Payment DB")]
    CUSTOMERDB[("Customer DB")]

    BROWSER --> ROUTE
    ROUTE --> GATEWAY

    GATEWAY --> PAYMENT
    GATEWAY --> CUSTOMER
    GATEWAY --> NOTIFY

    PAYMENT --> PAYMENTDB
    CUSTOMER --> CUSTOMERDB

Security Layers

flowchart LR
    INTERNET["Internet"]
    WAF["WAF"]
    LB["Load Balancer"]
    ROUTER["OpenShift Router"]
    SVC["Service"]

    subgraph APP["Spring Boot Application"]
        POD1["Pod 1"]
        POD2["Pod 2"]
    end

    INTERNET --> WAF
    WAF --> LB
    LB --> ROUTER
    ROUTER --> SVC
    SVC --> POD1
    SVC --> POD2

Multiple security layers protect enterprise applications.


Route Monitoring

Monitor:

  • Request Count
  • Latency
  • TLS Errors
  • Certificate Expiration
  • HTTP Status Codes

Common tools:

  • Prometheus
  • Grafana
  • OpenShift Monitoring
  • Datadog

Common TLS Errors

Certificate Expired

Symptoms:

  • Browser warning
  • SSL handshake failure

Solution:

Renew certificate.


Hostname Mismatch

Example:

Certificate

api.company.com

Route

payment.company.com

Solution:

Use matching domains.


Invalid Certificate

Possible causes:

  • Self-signed certificate
  • Unknown Certificate Authority

Solution:

Use trusted CA certificates.


TLS Handshake Failure

Possible causes:

  • Unsupported TLS version
  • Wrong cipher suite
  • Invalid certificate chain

Verify:

oc describe route payment-route

Browser Shows Not Secure

Verify:

  • HTTPS URL
  • Certificate validity
  • DNS configuration
  • TLS termination type

Useful OpenShift Commands

List Routes

oc get routes

Describe Route

oc describe route payment-route

List Secrets

oc get secrets

Describe Secret

oc describe secret payment-cert

Edit Route

oc edit route payment-route

Production Best Practices

✅ Always use HTTPS.

✅ Use TLS 1.2 or TLS 1.3.

✅ Disable HTTP whenever possible.

✅ Use trusted Certificate Authorities.

✅ Renew certificates automatically.

✅ Monitor certificate expiration.

✅ Use Mutual TLS for highly secure APIs.

✅ Expose only API Gateway services.

✅ Never expose databases.

✅ Store certificates as OpenShift Secrets.

✅ Enable HSTS headers.

✅ Configure secure cipher suites.


Common Mistakes

❌ Using HTTP in production.

❌ Expired certificates.

❌ Hardcoding certificates inside container images.

❌ Sharing private keys.

❌ Exposing internal microservices directly.

❌ Forgetting DNS updates after migration.


Enterprise Deployment Workflow

flowchart LR
    DEV["Developer"]
    GIT["Git"]
    JENKINS["Jenkins"]
    BC["BuildConfig"]
    IS["ImageStream"]
    DEPLOY["Deployment"]
    SVC["Service"]
    ROUTE["Secure Route"]
    LB["Load Balancer"]
    USERS["Internet Users"]

    DEV --> GIT
    GIT --> JENKINS
    JENKINS --> BC
    BC --> IS
    IS --> DEPLOY
    DEPLOY --> SVC
    SVC --> ROUTE
    ROUTE --> LB
    LB --> USERS

Banking Production Architecture

flowchart LR
    CUSTOMER["Customer"]
    WAF["WAF"]
    ROUTER["OpenShift Router"]
    GATEWAY["API Gateway"]

    subgraph SERVICES["Microservices"]
        PAYMENT["Payment Service"]
        FRAUD["Fraud Detection"]
    end

    DB[("Oracle RAC")]

    CUSTOMER -- "HTTPS" --> WAF
    WAF --> ROUTER
    ROUTER --> GATEWAY
    GATEWAY --> PAYMENT
    PAYMENT --> FRAUD
    PAYMENT --> DB
    FRAUD --> DB

This architecture is commonly used in financial institutions requiring PCI DSS compliance.


Summary

TLS and Secure Routes are fundamental components of production-grade OpenShift deployments.

Key takeaways:

  • TLS encrypts communication between clients and applications.
  • OpenShift Routes provide secure external access to Services.
  • Edge termination is the most common choice for Spring Boot REST APIs.
  • Passthrough and Re-encrypt provide stronger end-to-end encryption when required.
  • Certificates should be stored securely using OpenShift Secrets.
  • Custom domains and trusted Certificate Authorities improve security and user trust.
  • Enterprises often expose only an API Gateway while keeping backend services private.

Interview Questions

  1. What is TLS, and why is it important?
  2. What is the difference between SSL and TLS?
  3. What are the three TLS termination modes in OpenShift?
  4. When should you use Edge termination?
  5. When should you choose Passthrough termination?
  6. What is Re-encrypt termination?
  7. What is Mutual TLS (mTLS)?
  8. Where should TLS certificates be stored in OpenShift?
  9. Why should production applications use custom domains?
  10. How do you troubleshoot TLS handshake failures?
  11. What causes a browser to display "Not Secure"?
  12. What are the best practices for securing Spring Boot APIs in OpenShift?