HTTPS dan TLS: Apa yang Sebenarnya Terjadi

Hampir setiap hari kerja saya sebagai orang IT, ada saja pertanyaan yang muncul dalam bentuk "kok situsnya bilang not secure" atau "sertifikatnya invalid, gimana benerinnya". Kebanyakan orang memperlakukan HTTPS sebagai kotak hitam: pasang sertifikat, gembok hijau muncul, selesai. Masalahnya, begitu ada error di lapangan, cara pandang seperti itu bikin susah nebak apa yang salah. Menurut saya tidak perlu paham kriptografi sampai level matematis untuk bisa efektif diagnosis masalah TLS — cukup paham alur handshake-nya secara garis besar, dan di titik mana biasanya sesuatu bisa gagal.

Kenapa ada dua lapis enkripsi

TLS menyelesaikan satu masalah klasik: dua pihak yang belum pernah bertemu (browser dan server) perlu sepakat soal kunci rahasia untuk mengenkripsi data, tanpa ada yang menguping proses kesepakatan itu. Enkripsi simetris (satu kunci yang sama dipakai untuk mengunci dan membuka) itu cepat, cocok untuk trafik dalam jumlah besar, tapi bagaimana cara mengirim kunci itu dengan aman kalau salurannya sendiri belum aman? Di sinilah enkripsi asimetris (kunci publik dan privat) berperan — bukan untuk mengenkripsi seluruh trafik karena terlalu berat, melainkan dipakai di awal handshake untuk sepakat soal kunci sesi simetris sekaligus membuktikan identitas server. Setelah kunci sesi disepakati, sisa komunikasi memakai enkripsi simetris yang jauh lebih ringan. Jadi sertifikat bukan "alat enkripsi" itu sendiri, melainkan alat negosiasi dan pembuktian identitas di awal.

Alur handshake secara garis besar

Begitu browser membuka koneksi HTTPS, garis besarnya begini:

  1. Client Hello — browser mengirim versi TLS dan cipher suite yang didukungnya, plus nama domain tujuan (lewat SNI, Server Name Indication).
  2. Server Hello — server memilih versi dan cipher suite yang cocok, lalu mengirim sertifikatnya.
  3. Verifikasi sertifikat — browser mengecek apakah sertifikat ditandatangani oleh certificate authority (CA) yang dipercaya, belum kedaluwarsa, dan namanya cocok dengan domain yang diminta.
  4. Pertukaran kunci — kedua pihak menghasilkan kunci sesi simetris, tanpa kunci privat server pernah terkirim lewat jaringan.
  5. Finished — handshake selesai, dan sejak titik ini seluruh trafik HTTP di dalamnya sudah terenkripsi.

Semua ini terjadi sebelum satu byte konten HTTP pun dikirim. Kalau handshake gagal, browser tidak pernah sampai menampilkan halaman, sehingga error yang muncul biasanya generik dan membingungkan kalau tidak tahu di tahap mana gagalnya.

Rantai kepercayaan, sumber masalah paling sering

Sertifikat TLS pada dasarnya dokumen digital "saya adalah domain X", ditandatangani sebuah CA. Browser menelusuri rantai kepercayaan: sertifikat domain ditandatangani intermediate certificate, dan intermediate itu ditandatangani root certificate yang sudah tertanam di sistem sebagai titik kepercayaan awal.

Masalah yang paling sering saya temui bukan soal sertifikat domainnya sendiri, melainkan intermediate certificate yang tidak terkirim lengkap oleh server. Browser modern kadang menutupi ini karena punya cache intermediate populer, tapi curl atau library HTTP client di aplikasi biasanya lebih ketat dan langsung gagal — sebabnya sebuah situs bisa terlihat baik-baik saja di browser tapi API call ke situs yang sama malah gagal verifikasi TLS.

# cek rantai sertifikat yang dikirim server, termasuk intermediate-nya
openssl s_client -connect pujamalca.my.id:443 -servername pujamalca.my.id -showcerts

# cek tanggal kedaluwarsa dan nama domain di sertifikat
echo | openssl s_client -connect pujamalca.my.id:443 -servername pujamalca.my.id 2>/dev/null | openssl x509 -noout -dates -subject

Dua command di atas biasanya cukup untuk mendiagnosis sebagian besar keluhan "sertifikat invalid": cek apakah rantainya lengkap, tanggalnya masih berlaku, dan namanya cocok dengan domain yang diakses.

Penyebab error yang paling umum

  • Sertifikat kedaluwarsa — sering terjadi kalau perpanjangan otomatis (misalnya Let's Encrypt lewat cron certbot) berhenti diam-diam, entah karena port 80 terblokir firewall atau reload web server gagal setelah renewal.
  • Nama domain tidak cocok — sertifikat diterbitkan untuk contoh.my.id tapi diakses lewat www.contoh.my.id atau subdomain lain yang tidak tercakup di Subject Alternative Name (SAN)-nya.
  • Intermediate certificate tidak lengkap, seperti dijelaskan di atas.
  • SNI salah konfigurasi — satu reverse proxy yang melayani banyak domain dengan sertifikat berbeda-beda bisa salah mengarahkan sertifikat domain satu ke domain lain kalau virtual host-nya keliru.
  • Jam sistem tidak sinkron — validasi sertifikat bergantung pada waktu sistem yang benar; kalau jam server atau perangkat client meleset jauh, validasi tanggal berlaku bisa gagal padahal sertifikatnya sendiri baik-baik saja.

Pola diagnosis saya selalu sama: pisahkan dulu apakah masalahnya di sertifikat itu sendiri, atau di konfigurasi server yang menyajikannya. Command openssl s_client di atas cukup untuk membedakan dua kategori itu dalam hitungan detik, sebelum menebak-nebak lebih jauh.

Takeaway

HTTPS terasa seperti kotak hitam dari luar, tapi begitu paham intinya cuma negosiasi kunci sesi plus verifikasi identitas lewat rantai kepercayaan, sebagian besar error jadi lebih mudah ditebak arahnya. Lain kali menemukan keluhan sertifikat, mulai saja dari cek rantai sertifikat dan tanggal berlakunya lewat command line, sebelum berasumsi macam-macam soal penyebabnya.