Technical Reference: Implementing Professional IP & DNS SSL for Kubernetes Ingress

1. Overview

This reference guide covers the transition from basic self-signed SSL to a professional-grade certificate provided by an organization. This setup ensures your Kubernetes application is reachable via both Static IP (e.g., 192.168.5.x) and DNS (e.g., cloudmr.cloudmr.local) with full SSL encryption.

Environment Specification

• Cluster: RKE2 (standard distribution)
• Ingress Controller: Nginx
• Namespace: kube-system (Controller) and test (Application)

2. Phase 1: Certificate Verification

Before deployment, verify that the certificate contains both the IP and the DNS in the Subject Alternative Name (SAN) field.

# Verify the contents of the provided fullchain certificate
openssl x509 -in cloudmr_fullchain.crt -text -noout | grep -E "Subject:|DNS:|IP:"

Expected Output:

• Subject: C=MA, ST=Casablanca, O=cloudmr... CN=192.168.5.x
• DNS:cloudmr.cloudmr.local, IP Address:192.168.5.x

3. Phase 2: Updating the Kubernetes Secret

To update the SSL certificate, replace the secret in the namespace where the Ingress Controller resides.

# 1. Remove the existing fallback secret
kubectl delete secret ingress-fallback-cert -n kube-system

# 2. Re-create the secret using the manager's professional files
kubectl create secret tls ingress-fallback-cert \
  --cert=cloudmr_fullchain.crt \
  --key=cloudmr.key \
  -n kube-system

4. Phase 3: Nginx Controller Configuration

Ensure the Nginx Controller is configured to serve this certificate by default when no hostname is provided (direct IP access).

Edit the DaemonSet:

kubectl edit ds rke2-ingress-nginx-controller -n kube-system

Verify/Add the Argument:

Under spec.template.spec.containers.args, ensure this line exists:

• - --default-ssl-certificate=kube-system/ingress-fallback-cert

Force a configuration reload:

kubectl rollout restart ds rke2-ingress-nginx-controller -n kube-system

5. Phase 4: Application Ingress Setup (Helm)

Update your application's Ingress resource to support both the professional DNS name and the direct IP access.

Updated values.yaml:

ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
    # Optional: Force SSL
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  
  hosts:
    # Rule 1: Professional DNS Access
    - host: "cloudmr.cloudmr.local"
      paths:
        - path: /
          pathType: Prefix
    # Rule 2: Legacy/IP Access (Catch-all)
    - host: ""
      paths:
        - path: /
          pathType: Prefix
  tls: [] # Let the controller fallback to the default-ssl-certificate

Apply Changes:

helm upgrade frontendv2 ./cloudmrv2-front/ -n test

6. Phase 5: DNS Resolution & Client Trust

To ensure the "Green Lock" in browsers, two things must happen on the client (VPN user) side:

A. Resolution (Nicknaming the IP)

• Corporate DNS: Add an A Record pointing cloudmr.cloudmr.local to 192.168.5.x.
• Local Bypass (Windows Hosts): Add to C:\Windows\System32\drivers\etc\hosts:
  192.168.5.x cloudmr.cloudmr.local

B. Trusted Root Installation

Users must install the Root CA certificate that signed the cloudmr_fullchain.crt.

1. Open cloudmr_fullchain.crt > Install Certificate.
2. Select Local Machine.
3. Place in Trusted Root Certification Authorities.

7. Troubleshooting Checklist

• Certificate Mismatch: If the browser says "Your connection is not private" and mentions a name mismatch, ensure the URL used matches a DNS: or IP: entry in the certificate's SAN.
• Stale Cache: If the old certificate still appears, restart the Ingress Controller pods (kubectl rollout restart).
• Namespace Mismatch: Always ensure the Secret is in the same namespace as the Controller (kube-system for RKE2), otherwise, the controller cannot find the certificate.