manifest.conf — profile: platform-engineer
← kembali ke catatan
2026-09-16

Renewal SSL Ingress OpenShift 4.x (Public vs Private CA)

openshiftkubernetessecurityssltlsingresshaproxy

Saat masa berlaku sertifikat Ingress OpenShift (wildcard *.apps) akan habis, diperlukan proses SSL renewal. Pembaruan ini harus dilakukan dengan standar pembentukan TLS chain yang tepat agar komponen internal dan eksternal dapat melakukan komunikasi tanpa handshake error.

1. Aturan Chain: Leaf + Intermediate (Tanpa Root CA)

Dalam standar TLS (RFC 5246 / RFC 8446), berkas bundle sertifikat (tls.crt) yang dipasang pada Ingress OpenShift hanya boleh berisi Leaf dan Intermediate CA.

+-------------------------------------------------------------+
| 1. Leaf / Wildcard Cert (*.apps.<cluster>.<domain>)         | -> Masuk ke tls.crt
+-------------------------------------------------------------+
| 2. Intermediate CA (Penandatangan leaf)                     | -> Masuk ke tls.crt
+-------------------------------------------------------------+
| 3. Root CA (Trust Anchor)                                   | -> DILARANG di tls.crt
+-------------------------------------------------------------+

Mengapa Root CA Dilarang Masuk ke tls.crt?

  • Mekanisme Validasi TLS: Klien (browser, OS, pod) memverifikasi sertifikat secara hierarki dari bawah ke atas hingga menemukan Trust Anchor yang telah tersimpan secara lokal di mesinnya. Klien tidak pernah mempercayai Root CA yang disodorkan secara sepihak oleh server di tengah sesi TLS handshake.
  • Handshake Overhead: Mengirimkan Root CA hanya membuang bandwidth dan memperbesar ukuran frame TLS handshake tanpa memberikan fungsi validasi valid apa pun.

Kapan Perlu Mendaftarkan CA ke Cluster?

  • Public CA (Production): Root CA publik (DigiCert, Let’s Encrypt, Sectigo, dsb.) sudah tersedia secara bawaan di trust store sistem operasi Linux (RHCOS) dan image container. Mendaftarkan ulang trust store cluster tidak diperlukan.
  • Private / Internal CA (Development/On-Premise): Komponen internal OpenShift (seperti OAuth, Console, Image Registry, Tekton, dan internal pods) memanggil API dan rute aplikasinya sendiri via domain *.apps. Karena Root CA internal belum dikenali oleh OS container, panggilan tersebut akan memicu error x509: certificate signed by unknown authority. Root CA internal (root-ca.crt) wajib didaftarkan ke proxy/cluster (spec.trustedCA) agar OpenShift otomatis mendistribusikannya ke seluruh node RHCOS dan trust store pod di dalam cluster.

2. Persiapan File Sertifikat

Sebelum memulai renewal, pastikan berkas-berkas berikut telah diletakkan pada satu working directory:

  • wildcard.crt : Sertifikat leaf domain (*.apps).
  • intermediate.crt : Sertifikat Intermediate CA.
  • wildcard.key : Private key (pastikan decrypted / tanpa passphrase).
  • root-ca.crt : Sertifikat Root CA (hanya diperlukan jika menggunakan Private CA).

3. Menyiapkan Bundle tls.crt dan tls.key

Gabungkan sertifikat Leaf dan Intermediate ke dalam satu file tls.crt. Pastikan urutannya benar (Leaf di posisi teratas).

# 1. Gabungkan leaf dan intermediate
cat wildcard.crt intermediate.crt > tls.crt
cp wildcard.key tls.key

# 2. Verifikasi rantai sertifikat di dalam tls.crt
# Root CA tidak boleh muncul pada output ini
openssl crl2pkcs7 -nocrl -certfile tls.crt \
  | openssl pkcs7 -print_certs -text -noout \
  | grep -E "Subject:|Issuer:"

4. Inject Trust Store Cluster (Khusus Private CA)

Lewati langkah ini jika menggunakan sertifikat dari Public CA resmi.

# 1. Daftarkan Root CA internal ke ConfigMap openshift-config
# Key 'ca-bundle.crt' bersifat wajib (hardcoded requirement oleh Proxy Operator)
oc create configmap custom-ca-bundle \
  --from-file=ca-bundle.crt=root-ca.crt \
  -n openshift-config \
  --dry-run=client -o yaml | oc apply -f -

# 2. Tautkan ConfigMap ke proxy/cluster
oc patch proxy/cluster \
  --type=merge \
  -p '{"spec":{"trustedCA":{"name":"custom-ca-bundle"}}}'

5. Terapkan Secret ke IngressController

Terapkan TLS secret baru pada ingress router default milik cluster.

export SECRET_NAME="router-certs-default"

# 1. Buat secret TLS di namespace openshift-ingress
oc create secret tls "${SECRET_NAME}" \
  --cert=tls.crt \
  --key=tls.key \
  -n openshift-ingress

# 2. Arahkan IngressController default ke secret baru
oc patch ingresscontroller.operator/default \
  -n openshift-ingress-operator \
  --type=merge \
  -p "{\"spec\":{\"defaultCertificate\":{\"name\":\"${SECRET_NAME}\"}}}"

# 3. Monitor proses rolling update pod router HAProxy
watch 'oc get co; oc get po -n openshift-ingress'
oc rollout status deployment/router-default -n openshift-ingress --timeout=180s

6. Validasi Endpoint

Uji sertifikat yang sedang aktif disajikan oleh HAProxy Ingress via protokol TLS.

export CLUSTER_APPS_DOMAIN="apps.ocp.iqiterate.id"

openssl s_client -connect "console-openshift-console.${CLUSTER_APPS_DOMAIN}:443" \
  -servername "console-openshift-console.${CLUSTER_APPS_DOMAIN}" \
  < /dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

7. Prosedur Rollback Darurat

Jika sertifikat baru mengalami kendala (handshake mismatch atau chain error), IngressController dapat di-rollback ke state sebelumnya secara instan dengan melakukan rollback patch ke nama secret yang lama.

export OLD_SECRET_NAME="<nama-secret-lama>"

oc patch ingresscontroller.operator/default \
  -n openshift-ingress-operator \
  --type=merge \
  -p "{\"spec\":{\"defaultCertificate\":{\"name\":\"${OLD_SECRET_NAME}\"}}}"

watch 'oc get co; oc get po -n openshift-ingress'
oc rollout status deployment/router-default -n openshift-ingress

Dengan memahami fungsi masing-masing sertifikat dan mekanisme trust store di level komponen internal, proses pembaruan SSL pada OpenShift dapat dilakukan tanpa risiko downtime atau x509 errors pada workloads.