Memastikan Certificate Chain Utuh Saat Pindah Terminasi SSL ke Edge Proxy

Pernahkah kamu memindahkan terminasi SSL/TLS dari web server origin ke edge proxy, lalu mengira semuanya selesai karena gembok hijau di peramban menyala normal, tapi beberapa jam kemudian muncul laporan tiket komplain dari pengguna perangkat lama atau sistem backend mitra? Pengguna aplikasi mobile versi lama tiba-tiba mengeluhkan galat koneksi SSL, dan skrip otomatisasi yang memakai curl memunculkan peringatan bahwa penerbit sertifikat tidak dikenal (unable to get local issuer certificate). Situasi ini sangat lumrah terjadi di meja bantuan teknis hosting ketika sebuah layanan mulai mendistribusikan beban trafik ke edge server terdekat. Saat terminasi enkripsi dipindahkan ke proxy terdepan, konfigurasi sertifikat kerap dipasang terburu-buru. Orang sering hanya menyalin sertifikat domain utama tanpa menyertakan sertifikat perantara (intermediate CA). Browser modern di komputer kita biasanya tampak aman karena mereka menyimpan cache sertifikat perantara dari sesi browsing sebelumnya atau memiliki mekanisme otomatis untuk mengunduh sertifikat yang hilang. Sayangnya, sistem operasi lawas, aplikasi mobile berbasis webview lama, dan pustaka HTTP di bahasa pemrograman backend tidak memiliki toleransi yang sama. Berikut adalah checklist prioritas yang perlu kamu periksa satu per satu untuk memastikan rantai validasi sertifikat (certificate chain) tetap utuh saat terminasi SSL berpindah ke edge proxy.

1. Pastikan File Berisi Fullchain, Bukan Hanya Leaf Certificate

Langkah pertama yang wajib dicek pada konfigurasi edge proxy adalah file sertifikat publik yang dipanggil oleh direktif SSL. Edge proxy seperti Nginx, Envoy, HAProxy, atau Traefik membutuhkan rantai lengkap dari sertifikat server kamu (leaf certificate) hingga sertifikat intermediate dari Certificate Authority (CA) penerbit. Sering kali orang keliru memilih file cert.pem alih-alih fullchain.pem (jika menggunakan Let's Encrypt atau Certbot), atau hanya mengekstrak berkas .crt tunggal dari panel SSL penyedia komersial. Jika kamu hanya memasang leaf certificate, proxy hanya akan mengirimkan identitas domain kamu ke klien tanpa membuktikan siapa yang menandatanganinya. Klien yang tidak memiliki daftar intermediate cert di trust store lokalnya otomatis akan memutus koneksi TLS karena menganggap sertifikat tersebut mencurigakan atau diterbitkan oleh pihak antah-berantah.

2. Periksa Urutan Sertifikat di Dalam Bundle

Ketika kamu menggabungkan beberapa sertifikat menjadi satu berkas bundle secara manual, urutan teks di dalam file teks tersebut sangat krusial. Urutan yang benar dan standar adalah sertifikat domain kamu berada di bagian paling atas, diikuti oleh sertifikat intermediate yang langsung menandatanganinya, dan jika ada, intermediate kedua di bawahnya. Banyak kegagalan handshake TLS terjadi karena urutan ini terbalik saat proses salin-tempel. Jika sertifikat intermediate ditaruh di baris paling awal sebelum sertifikat domain, parser TLS pada edge proxy mungkin akan bingung atau mengirimkan urutan yang salah kepada klien, yang langsung menggugurkan proses validasi rantai enkripsi. Sertifikat akar (root CA) umumnya tidak perlu disertakan di dalam bundle ini, karena root CA seharusnya sudah terpasang secara permanen di dalam sistem operasi atau trust store bawaan perangkat pengguna.

3. Pahami Jebakan AIA Fetching pada Pengujian Manual

Salah satu alasan kenapa masalah sertifikat perantara sering lolos dari pengawasan tim teknis adalah bias alat uji. Banyak teknisi menguji migrasi hanya dengan membuka domain melalui browser Google Chrome di laptop kerja mereka. Peramban berbasis Chromium modern mendukung fitur bernama Authority Information Access (AIA) fetching. Jika sebuah web server lupa mengirimkan intermediate certificate, browser akan membaca ekstensi AIA di dalam leaf certificate, lalu diam-diam mengunduh intermediate certificate yang hilang tersebut melalui HTTP di latar belakang tanpa memberitahu pengguna. Akibatnya, situs terlihat hijau dan valid di mata tim internal, padahal pustaka seperti curl, runtime Python, Java, atau aplikasi Android lawas tidak menjalankan AIA fetching sama sekali dan langsung melempar galat fatal.

4. Uji Handshake Langsung Menggunakan OpenSSL CLI

Untuk mendapatkan diagnosis objektif yang tidak terpengaruh oleh cache lokal peramban, selalu gunakan perkakas baris perintah bawaan Linux. Perintah openssl s_client mensimulasikan handshake TLS murni dan mencetak seluruh rantai sertifikat yang dikirimkan oleh edge proxy ke layar terminal kamu. Jalankan perintah berikut untuk menginspeksi rantai sertifikat yang disajikan oleh proxy baru kamu:

BASH

openssl s_client -connect domain-kamu.com:443 -servername domain-kamu.com -showcerts < /dev/null

Perhatikan bagian Certificate chain pada output terminal. Kamu harus melihat minimal dua tingkat sertifikat, yaitu tingkat s: (subject domain kamu) dengan penerbit i: (intermediate CA), dan tingkat berikutnya di mana subject adalah intermediate CA tersebut. Jika output hanya menunjukkan satu tingkat sertifikat domain saja, atau memunculkan status Verify return code: 21 (unable to verify the first certificate), itu tanda mutlak bahwa edge proxy kamu belum mengirimkan intermediate certificate ke pengunjung.

5. Sinkronkan Pembaruan Otomatis ke Seluruh Node Edge

Jika kamu mendistribusikan terminasi SSL ke beberapa edge node regional (misalnya edge proxy yang ditaruh di beberapa data center lokal untuk memangkas latensi pengguna akhir), pastikan mekanisme pembaruan sertifikat otomatis mengunggah seluruh berkas bundle, bukan hanya memperbarui symlink di server utama. Banyak kasus unik terjadi di mana sistem berjalan lancar selama 60 hari pertama setelah migrasi, namun tiba-tiba rusak total saat masa perpanjangan otomatis tiba. Hal ini biasanya disebabkan oleh skrip perpanjangan ACME yang hanya memperbarui berkas di origin, sementara edge proxy regional masih menyajikan sertifikat lama atau hanya menyalin berkas sertifikat parsial saat proses sinkronisasi rsync. Buat proses reload konfigurasi proxy terjadi secara otomatis segera setelah file bundle baru selesai disalin ke seluruh edge node.

6. Hati-hati dengan Cross-Signing dan Root Lawas

Saat menyusun intermediate bundle, kenali apakah penyedia sertifikat kamu menggunakan mekanisme cross-signing. Mekanisme ini lazim digunakan oleh CA baru agar sertifikat mereka bisa dipercaya oleh perangkat-perangkat tua yang belum memperbarui daftar Root CA bawaan pabrik. Namun, menyertakan intermediate cross-signed yang sudah kedaluwarsa ke dalam bundle edge proxy dapat menyebabkan beberapa klien OpenSSL versi lawas mengalami kegagalan validasi, meskipun ada jalur validasi alternatif yang sah. Pastikan rantai yang kamu rangkai di file konfigurasi proxy hanya menggunakan intermediate aktif yang direkomendasikan secara resmi oleh penerbit sertifikat kamu saat ini. Memastikan rantai sertifikat lengkap sejak awal migrasi ke edge proxy menghemat banyak waktu investigasi. Jangan pernah menganggap konfigurasi SSL selesai hanya karena halaman web berhasil dimuat tanpa tanda bahaya di peramban pribadi kita. Pengujian dengan perintah baris perintah yang transparan adalah satu-satunya cara memastikan setiap klien, dari peramban tercanggih hingga skrip API otomatis, dapat bertukar data dengan aman dan tanpa gangguan.