Information Security 15 min read

Mastering HTTPS: From Digital Certificates to One‑Way & Two‑Way Auth in Kubernetes

This tutorial explains digital certificate fundamentals, common formats, the principles of one‑way and two‑way HTTPS authentication, and provides step‑by‑step Kubernetes configurations—including secret creation and Ingress setup—to implement secure TLS communication.

Ops Development Stories
Ops Development Stories
Ops Development Stories
Mastering HTTPS: From Digital Certificates to One‑Way & Two‑Way Auth in Kubernetes

Basic Concepts of Digital Certificates

Digital certificate standards include X.509 version, serial number, signature algorithm identifier, issuer information, validity period, subject information, issuer's digital signature, and the certificate's public key.

Common Certificate Formats

CSR: certificate signing request file.

CER: certificate file in binary or BASE64 encoding.

CRT: DER or PEM encoded certificate, common on Linux.

PEM: Base64‑encoded binary content defined in RFC1421, widely used for key management.

DER: binary DER‑encoded certificate.

JKS: Java keystore file, binary format, with separate passwords for keystore and private key.

P12/PFX: contains private key, public key and certificates, stored in binary format, importable on Windows.

What Is HTTPS One‑Way Authentication?

In one‑way authentication only the client verifies the server’s identity by checking the server’s digital certificate for validity, trusted CA, correct signature, and matching domain name.

One‑Way Authentication Process:

Client sends SSL version, cipher suites, random numbers, etc.

Server returns its SSL version, cipher suites, random numbers, and its public‑key certificate.

Client validates the server’s certificate (expiration, trusted CA, signature verification, domain match).

If validation succeeds, communication continues; otherwise it is terminated.

Client proposes supported symmetric encryption algorithms.

Server selects the strongest supported algorithm.

Server returns the chosen algorithm in plaintext.

Client generates a random code using the chosen algorithm, encrypts it with the server’s public key, and sends it to the server.

Server decrypts the random code with its private key to obtain the symmetric key; subsequent traffic is symmetrically encrypted.

What Is HTTPS Two‑Way Authentication?

Two‑way authentication requires both client and server to verify each other’s certificates, ensuring mutual trust, commonly used for high‑security data exchange.

Two‑Way Authentication Process:

Client sends SSL version, cipher suites, random numbers, etc.

Server returns its SSL version, cipher suites, random numbers, and its certificate.

Client validates the server’s certificate (same checks as one‑way).

If validation succeeds, communication proceeds.

Server requests the client’s certificate; client sends its certificate.

Server validates the client’s certificate and obtains the client’s public key.

Client proposes supported symmetric encryption algorithms.

Server selects the strongest algorithm.

Server encrypts the chosen algorithm with the client’s public key and returns it.

Client decrypts the algorithm with its private key, generates a random code, encrypts it with the server’s public key, and sends it.

Server decrypts the random code with its private key to obtain the symmetric key; subsequent traffic is symmetrically encrypted.

Configuring HTTPS One‑Way Authentication

Generate a CA certificate, server certificate, store them as a Kubernetes TLS secret, and create an Ingress resource that uses the secret.

<code># Generate CA private key (4096‑bit, AES‑256 encrypted)
openssl genrsa -aes256 -out kubesre-ca.key 4096

# Sign CA root certificate
openssl req -new -x509 -days 3650 -sha256 -extensions v3_ca -key kubesre-ca.key -out kubesre-ca.cer -subj "/C=CN/ST=shanghai/L=shanghai/O=kubesre/OU=kubesre/CN=*.kubesre.com"

# Generate server private key
openssl genrsa -out kubesre-server.key 2048

# Generate server CSR
openssl req -new -key kubesre-server.key -out kubesre-server.csr -subj "/C=CN/ST=shanghai/L=shanghai/O=kubesre/OU=kubesre/CN=demo.kubesre.com"

# Sign server certificate with CA
openssl x509 -req -days 3650 -sha256 -CA kubesre-ca.cer -CAkey kubesre-ca.key -in kubesre-server.csr -out kubesre-server.cer

# Create TLS secret
kubectl create secret tls kubesre-tls --key kubesre-server.key --cert kubesre-server.cer

# Apply Ingress
cat ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  tls:
  - hosts:
    - demo.kubesre.com
    secretName: kubesre-tls
  rules:
  - host: demo.kubesre.com
    http:
      paths:
      - path: /info
        pathType: Prefix
        backend:
          service:
            name: demo-svc
            port:
              number: 8080
  ingressClassName: nginx

kubectl apply -f ingress.yml

# Verify
curl -k https://demo.kubesre.com/info
{"message":"云原生运维圈!"}
</code>

Configuring HTTPS Two‑Way Authentication

After issuing the server certificate, generate a client certificate and store the CA certificate as a generic secret, then configure the Ingress with appropriate annotations.

<code># Generate client private key
openssl genrsa -out kubesre-client.key 2048

# Generate client CSR
openssl req -new -key kubesre-client.key -out kubesre-client.csr -subj "/C=CN/ST=shanghai/L=shanghai/O=kubesre/OU=kubesre/CN=client.kubesre.com"

# Sign client certificate with CA
openssl x509 -req -days 3650 -sha256 -CA kubesre-ca.cer -CAkey kubesre-ca.key -in kubesre-client.csr -out kubesre-client.cer

# Create CA secret
kubectl create secret generic ca-secret --from-file=ca.crt=kubesre-ca.cer

# Update Ingress with client auth annotations
cat ingress.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
  name: demo
spec:
  tls:
  - hosts:
    - demo.kubesre.com
    secretName: kubesre-tls
  rules:
  - host: demo.kubesre.com
    http:
      paths:
      - path: /info
        pathType: Prefix
        backend:
          service:
            name: demo-svc
            port:
              number: 8080
  ingressClassName: nginx

kubectl apply -f ingress.yml

# Verify (without client cert – 400 error)
curl -k https://demo.kubesre.com/info

# Verify with client cert
curl ./kubesre-ca.cer --cert ./kubesre-client.cer --key ./kubesre-client.key https://demo.kubesre.com/info
{"message":"云原生运维圈!"}
</code>

Summary

The article explains the principles of one‑way and two‑way HTTPS authentication, demonstrates end‑to‑end certificate issuance, Kubernetes secret storage, and Ingress configuration, and previews upcoming advanced Ingress rewriting techniques.

KubernetesauthenticationTLSingresshttpsdigital certificates
Ops Development Stories
Written by

Ops Development Stories

Maintained by a like‑minded team, covering both operations and development. Topics span Linux ops, DevOps toolchain, Kubernetes containerization, monitoring, log collection, network security, and Python or Go development. Team members: Qiao Ke, wanger, Dong Ge, Su Xin, Hua Zai, Zheng Ge, Teacher Xia.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.