Konsep SSL/TLS #

Sebelum masuk ke konfigurasi, ada baiknya memahami apa yang sebenarnya terjadi di balik HTTPS. Pemahaman ini akan membuat konfigurasi SSL di Nginx jauh lebih masuk akal — kenapa butuh ssl_certificate dan ssl_certificate_key, apa itu sertifikat CA, dan mengapa handshake TLS perlu dioptimalkan.

SSL vs TLS: Meluruskan Terminologi #

“SSL” sering digunakan secara umum untuk merujuk ke protokol keamanan yang mengenkripsi koneksi web. Tapi secara teknis, SSL (Secure Sockets Layer) sudah tidak digunakan sejak lama — versi terakhirnya, SSL 3.0, resmi dianggap tidak aman dan dinonaktifkan di semua browser modern.

Yang digunakan saat ini adalah TLS (Transport Layer Security), yang merupakan penerus SSL. Versi aktif yang direkomendasikan adalah TLS 1.2 dan TLS 1.3. Ketika orang menyebut “SSL” dalam konteks web modern, mereka hampir selalu sebenarnya merujuk ke TLS.

Nginx menggunakan terminologi yang konsisten: directive konfigurasinya menggunakan nama ssl (karena warisan historis), tapi yang sebenarnya dikonfigurasi adalah TLS.

Komponen Utama: Sertifikat dan Private Key #

Dua file yang selalu dibutuhkan untuk mengaktifkan HTTPS di Nginx:

Sertifikat (ssl_certificate) — file publik yang berisi identitas server (domain name, informasi organisasi) dan public key. Dikirim ke browser saat koneksi dibuka. Siapapun bisa melihat isinya.

Private key (ssl_certificate_key) — file rahasia yang hanya boleh ada di server. Digunakan untuk membuktikan bahwa server yang kamu hubungi benar-benar memiliki sertifikat yang ditampilkan. Tidak boleh dibagikan atau diekspos.

Analogi:
  Sertifikat = kartu nama yang bisa dilihat semua orang
               (berisi: "ini server example.com, public key-nya adalah ini")
  
  Private key = tanda tangan asli yang bisa membuktikan kartu nama itu milikmu
                (hanya kamu yang bisa membuat tanda tangan yang cocok)

Apa Itu Certificate Authority (CA) #

Browser perlu tahu apakah sertifikat yang ditampilkan server bisa dipercaya. Inilah peran Certificate Authority — pihak ketiga yang terpercaya yang memverifikasi identitas pemilik domain dan “menandatangani” sertifikat mereka.

Rantai kepercayaan:

Browser         → percaya kepada →  CA Root (DigiCert, Let's Encrypt, dll.)
CA Root         → menandatangani → Intermediate CA
Intermediate CA → menandatangani → Sertifikat server kamu
Browser         → verifikasi rantai → Percaya koneksi ke server

Inilah mengapa file ssl_certificate di Nginx biasanya berisi chain — sertifikat server ditambah sertifikat intermediate CA — agar browser bisa memverifikasi seluruh rantai kepercayaan.

Self-signed certificate adalah sertifikat yang ditandatangani sendiri oleh server, tanpa CA. Browser akan menampilkan peringatan “Not Secure” karena tidak ada pihak ketiga yang memverifikasi identitas server. Berguna untuk development, tidak untuk production.

TLS Handshake: Apa yang Terjadi Saat Koneksi Dibuka #

Setiap kali browser membuka koneksi HTTPS baru, ada proses negosiasi yang terjadi sebelum data bisa dikirim:

TLS 1.3 Handshake (disederhanakan):

1. Browser → Server: "Client Hello"
   (versi TLS yang didukung, cipher suites, random value)

2. Server → Browser: "Server Hello"
   (pilih cipher, kirim sertifikat, kirim public key)

3. Browser verifikasi sertifikat
   (cek CA chain, cek domain cocok, cek belum expired)

4. Browser dan Server derive session keys
   (menggunakan Diffie-Hellman key exchange)

5. Handshake selesai
   (data mulai mengalir, terenkripsi)

TLS 1.3 menyelesaikan ini dalam 1 round-trip (1-RTT)
vs TLS 1.2 yang butuh 2 round-trip (2-RTT)

Di sinilah pentingnya session resumption — untuk koneksi berulang dari klien yang sama, handshake bisa dipersingkat menggunakan session ticket atau session cache, menghindari overhead full handshake.

Apa yang Dienkripsi (dan Tidak) #

HTTPS mengenkripsi:

Seluruh body request dan response
URL path dan query string (/search?q=password tidak terlihat)
Semua HTTP headers

HTTPS tidak menyembunyikan:

IP address server tujuan (terlihat di paket TCP)
Domain yang diakses (terlihat di TLS handshake melalui SNI dan DNS query)
Jumlah dan ukuran data yang ditransfer (metadata trafik)

Ini penting untuk dipahami — HTTPS bukan anonimitas, tapi kerahasiaan konten.

SNI: Satu IP untuk Banyak Domain HTTPS #

Server Name Indication (SNI) adalah ekstensi TLS yang memungkinkan klien memberitahu server domain mana yang ingin dihubungi di awal handshake, sebelum sertifikat dikirim. Ini yang memungkinkan virtual hosting HTTPS — banyak domain dengan sertifikat berbeda di satu IP address.

Tanpa SNI: satu IP = satu sertifikat = satu domain HTTPS
Dengan SNI: satu IP = banyak sertifikat = banyak domain HTTPS

Semua browser modern mendukung SNI. Nginx secara otomatis menggunakan SNI untuk menentukan server block mana yang harus melayani koneksi HTTPS, sama seperti header Host untuk HTTP.

Ringkasan #

TLS (bukan SSL) adalah protokol yang digunakan saat ini — SSL sudah tidak aman dan tidak digunakan. Nginx menggunakan nama “ssl” secara historis, tapi sebenarnya mengkonfigurasi TLS.
Dua file yang wajib ada: sertifikat (publik, berisi identitas + public key) dan private key (rahasia, tetap di server).
Certificate Authority memverifikasi identitas domain dan menandatangani sertifikat — ini yang membuat browser mempercayai koneksi. Self-signed cert tidak memiliki verifikasi ini.
SNI memungkinkan banyak domain HTTPS berbeda di satu IP address — Nginx mendukung ini secara native.
TLS 1.3 lebih cepat (1-RTT handshake) dan lebih aman dari TLS 1.2 — prioritaskan mengaktifkan keduanya.

← Sebelumnya: Health Check Berikutnya: Self-Signed Certificate →