SSL/TLS di VPS: Let's Encrypt, nginx, dan Perpanjangan Otomatis

Sertifikat TLS hari ini gratis, otomatis, dan bisa dipasang dalam lima belas menit. Tidak ada lagi alasan sebuah VPS menyajikan panel admin atau form login lewat HTTP. Artikel ini membahas memasang SSL/TLS di VPS dengan Let's Encrypt lewat certbot, memastikan perpanjangan otomatis benar-benar berjalan, dan menguji konfigurasi sampai ke kekuatan cipher.

1. Kenapa HTTP Biasa Tidak Lagi Dapat Diterima

• Kredensial lewat dalam jelas. Satu jaringan WiFi publik cukup untuk menangkap cookie sesi dan password.
• Browser menghukum. Label "Not Secure" menurunkan konversi form, dan sebagian fitur (geolokasi, service worker, clipboard) hanya aktif di konteks aman.
• Redirect memengaruhi SEO. Campuran HTTP dan HTTPS membuat mesin pencari indeks halaman ganda.
• Regulasi menuntut. Data pribadi yang mengalir tanpa enkripsi link-layer menyulitkan kepatuhan privasi Anda.

2. Prinsip Kerja Sertifikat: Siapa Menjamin Siapa

TLS menjawab dua hal: kerahasiaan dan keaslian. Kerahasiaan dibangun lewat pertukaran kunci; keaslian lewat sertifikat yang ditandatangani Certificate Authority. Yang membuat Let's Encrypt berbeda adalah model validasinya: Anda membuktikan kendali domain, bukan mengirim dokumen.

Dua metode validasi yang perlu Anda bedakan sejak awal:

• HTTP-01 — CA mengunduh token di http://domain/.well-known/acme-challenge/. Mudah, tapi rawan bila IPv6 Anda menunjuk ke server lain.
• DNS-01 — Anda menambah TXT _acme-challenge.domain. Wajib untuk sertifikat wildcard dan lebih andal bila server di belakang CDN atau port 80 tidak bisa dibuka.

3. Persiapan: DNS, Port, dan Waktu Server

Sebelum menyentuh certbot, pastikan tiga hal ini:

dig +short A domainanda.id
dig +short AAAA domainanda.id
ss -tulpn | grep -E ':80|:443'
timedatectl | grep -i synchronized

Kesalahan yang paling sering ditemui di lapangan:

• Record A mengarah ke IP lama. Sertifikat tidak akan pernah terbit karena CA melihat server yang salah.
• IPv6 mengarah ke VPS lain. CA bisa memilih AAAA, lalu validasi gagal tanpa pesan yang jelas.
• Port 80 diblokir. Redirect ke 443 tetap harus menjawab path /.well-known/ di HTTP.
• Waktu server melenceng. Jam yang salah membuat validasi tanggal sertifikat dan log jadi membingungkan.

4. Memasang Certbot dan Sertifikat Pertama

apt -y install certbot python3-certbot-nginx
certbot --nginx -d domainanda.id -d www.domainanda.id \
  --agree-tos -m admin@domainanda.id --redirect --hsts

Atau, bila Anda ingin nginx mengambil alih tantangan HTTP sendiri (penting saat document root Anda dipakai aplikasi lain):

certbot certonly --nginx -d domainanda.id -d www.domainanda.id

Untuk wildcard, pakai DNS-01 dengan plugin provider Anda:

certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d domainanda.id -d '*.domainanda.id'

Simpan file privat di luar web root. Kredensial API DNS yang tertinggal di dalam document root akan disajikan apa adanya oleh server Anda sendiri.

5. Konfigurasi nginx yang Benar (Bukan Sekadar Pasang Sertifikat)

Sertifikat valid tidak banyak berarti bila protokol dan cipher-nya lemah. Blok berikut masih masuk akal untuk trafik umum pada 2026:

server {
    listen 80;
    listen [::]:80;
    server_name domainanda.id www.domainanda.id;
    location /.well-known/acme-challenge/ { root /var/www/certbot; }
    location / { return 301 https://$host$request_uri; }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name domainanda.id www.domainanda.id;

    ssl_certificate     /etc/letsencrypt/live/domainanda.id/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domainanda.id/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    add_header Strict-Transport-Security "max-age=63072000" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
}

Tiga catatan yang menentukan kualitas hasil akhir:

• Ocsp stapling hanya bekerja bila rantai sertifikat lengkap; fullchain.pem wajib dipakai, bukan cert.pem.
• HSTS jangan langsung dipasang keras. max-age panjang tanpa subdomain yang siap HTTPS bisa mengunci Anda sendiri selama setahun.
• Session tickets dimatikan bila Anda menginginkan forward secrecy yang benar-benar kuat untuk trafik penting.

6. Perpanjangan Otomatis dan Hook yang Menyelesaikan Masalah

Certbot memasang timer systemd; pastikan ia benar-benar aktif:

systemctl list-timers | grep certbot
certbot renew --dry-run

Yang sering terlupa: sertifikat terbit ulang, tapi nginx masih memegang kunci di memori. Perbaiki dengan deploy hook:

certbot renew --deploy-hook "systemctl reload nginx" \
  --quiet

Atau pasang sekali di /etc/letsencrypt/cli.ini:

deploy-hook = systemctl reload nginx
key-type = ecdsa
ecdsa-curve = secp384r1
server = https://acme-v02.api.letsencrypt.org/directory

Alternatif modern untuk lingkungan kontainer dan multi-domain: acme.sh (sangat ringan, banyak DNS provider), lego (binari tunggal, mudah ditanam di pipeline), atau cert-manager di atas Kubernetes.

7. Menguji Hasilnya

openssl s_client -connect domainanda.id:443 -servername domainanda.id </dev/null \
  | openssl x509 -noout -dates -issuer -subject

curl -sI https://domainanda.id | grep -iE "strict|location"
curl -sI http://domainanda.id | head -3

Uji protokol satu per satu untuk memastikan yang tua benar-benar ditolak:

for p in tls1 tls1_1 tls1_2 tls1_3; do
  echo -n "$p: "
  openssl s_client -connect domainanda.id:443 -$p </dev/null 2>&1 \
    | grep -E "Protocol|handshake failure|Cipher is" | head -2 | tr '\n' ' '
  echo
done

Harapannya: TLS 1.0 dan 1.1 gagal, TLS 1.2 dan 1.3 berhasil. Untuk penilaian eksternal, layanan pemindai seperti SSL Labs akan memberi catatan pada rantai sertifikat, cipher lawas, dan header yang hilang.

8. Jebakan yang Membuat Sertifikat Tiba-Tiba Kedaluwarsa

• Cron renew ada tapi tidak ada log. Perintah tidak pernah dijalankan karena PATH salah atau certbot tidak terpasang di user yang benar.
• Rate limit Let's Encrypt. Terlalu banyak permintaan gagal untuk satu domain menyebabkan bloque sementara; periksa email dari CA.
• Domain baru dipindah tapi renew lama menunjuk document root lama — validasi HTTP-01 kehilangan path.
• Server di belakang CDN memakai sertifikat sendiri sehingga perpanjangan di origin tidak terlihat dari luar.
• Monitoring tanpa cek tanggal. Pasang alarm pada openssl x509 -enddate dan pantau lewat HTTP probe nyata.

Kunci debug yang jarang dicoba saat panik:

tail -f /var/log/letsencrypt/letsencrypt.log
journalctl -u certbot.renew --since "-7 days"

9. TLS Internal: Panel Admin Juga Butuh Enkripsi

Panel berbasis IP seperti https://IP:8443 sering dibiarkan HTTP "karena cuma saya yang pakai". Cukup satu hotspot publik untuk membocorkan sesi. Solusi murah:

• Beri subdomain khusus (mis. panel.domainanda.id) agar bisa dapat sertifikat Let's Encrypt yang sah.
• Atau gunakan ACME profile internal dengan CA sendiri, dan percaya CA tersebut di perangkat kerja.
• Atau bungkus akses dengan SSH tunnel / VPN, sehingga port panel tidak pernah muncul di internet — lihat Firewall VPS.

Kesimpulan

Pasang sertifikat, tapi anggap pekerjaan selesai hanya setelah tiga hal terbukti: renew otomatis berjalan dengan hook reload, HTTP diarahkan 301 ke HTTPS dengan HSTS, dan protokol lama benar-benar ditolak. TLS yang tidak dipantau akan kedaluwarsa pada saat yang paling tidak Anda inginkan.

Artikel terkait: Model Tanggung Jawab Bersama Keamanan VPS | 10 Langkah Hardening VPS | Mengamankan SSH dengan Ed25519 dan Fail2ban