Implementasi Wildcard SSL NGINX dengan Let's Encrypt

api.co.id – Saya akan bahas cara kerja dan praktik terbaik untuk Wildcard SSL NGINX yang sering bikin penasaran developer. Mau tahu kenapa wildcard certificate kadang lebih simpel tapi juga punya jebakan? Gini nih, artikel ini ngebahas dari konsep DNS-01 challenge sampai contoh Certbot dan cara otomatiskin perpanjangan, lengkap dengan tips troubleshooting. Kalau kamu baru ingin setup dasar dulu, cek juga artikel panduan dasar ini: https://api.co.id/blog/panduan-mudah-install-ssl-di-nginx/ untuk referensi awal.

Table of Contents

Kenapa pilih Wildcard SSL NGINX?

Tahu nggak? Wildcard bikin hidup lebih gampang kalau kamu punya banyak subdomain. Daripada bikin sertifikat per-subdomain, biasanya kita minta satu sertifikat untuk .example.com. Tapi, ada catatannya: sertifikat wildcard itu cuma nutup subdomain, nggak otomatis nutup root/apex domain kecuali kamu request juga example.com saat pembuatan.

Pro: manajemen lebih sederhana buat ratusan subdomain.
Kontra: butuh DNS-01 challenge (bukan HTTP-01), jadi harus bisa update TXT record otomatis via API atau manual.
Kontra: rate limits Let’s Encrypt berlaku juga; planning penting.

Inti teknis: DNS-01 challenge

Wildcard musti via DNS-01. Gimana kerjanya? CA minta kamu buat TXT record di DNS untuk domain tertentu, kalau valid maka CA keluarkan wildcard certificate. Pilihan praktis: pakai plugin DNS provider (Cloudflare, DigitalOcean, Route53, dll) atau manual kalau cuma sekali-sekali.

Opsi: plugin DNS (direkomendasikan)

Kalau DNS provider kamu punya API, mending pakai plugin Certbot. Contoh Cloudflare: pasang paket python3-certbot-dns-cloudflare, simpan API token di file, terus run certbot dengan opsi --dns-cloudflare --dns-cloudflare-credentials /path/to/creds. Ini solusinya kalau kamu mau otomatis tanpa masukin TXT manual tiap kali.

Opsi: manual TXT (cepat tapi repot)

Buat yang cuma mau coba dulu, jalankan certbot manual dan buat TXT record yang diminta. Pastikan TTL dan propagasi DNS; kadang butuh nunggu beberapa menit sampai record terlihat global.

Contoh perintah Certbot untuk wildcard

Contoh pakai plugin Cloudflare (ganti sesuai provider):

certbot certonly --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini -d example.com -d ".example.com" --non-interactive --agree-tos -m admin@example.com

Kalau manual (non-plugin):

certbot certonly --manual --preferred-challenges dns -d example.com -d ".example.com"

Catatan: selalu sertakan kedua domain (apex + wildcard) kalau mau cover root dan semua subdomain.

Contoh konfigurasi NGINX dengan sertifikat wildcard

Setelah emit, sertifikat biasanya ada di /etc/letsencrypt/live/example.com/. Contoh server block:

server { listen 443 ssl; server_name example.com .example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; include /etc/nginx/snippets/ssl-params.conf; location / { proxy_pass http://127.0.0.1:3000; } }

Jangan lupa tambahin redirect dari port 80 ke 443 kalau perlu.

Otomatisasi perpanjangan

Certbot biasanya bikin systemd timer atau cron job yang jalan tiap hari. Kalau kamu pakai plugin DNS berbasis API, renew biasanya mulus. Tambahin deploy hook biar NGINX reload otomatis saat renew:

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

Kalau masih pakai cara manual, perpanjangan juga manual dan itu sangat nggak praktis untuk wildcard.

Keamanan dan hardening untuk NGINX

Beberapa hal yang saya selalu terapin setelah punya sertifikat:

Gunakan cipher suite yang modern dan ssl_prefer_server_ciphers on;.
Aktifin OCSP stapling buat performa TLS handshake.
Set HSTS kalau kamu yakin semua subdomain sudah HTTPS-ready: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";.
Generate strong Diffie-Hellman params: openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048.

Studi kasus singkat: Cloudflare + NGINX

Kasus saya: banyak microservice di subdomain, DNS dikelola Cloudflare. Solusi paling rapi: buat API token terbatas buat Certbot, pasang plugin certbot-dns-cloudflare, lalu jadwalkan renew dengan deploy-hook reload. Hasilnya: nggak perlu akses DNS manual tiap perpanjangan, downtime minimal, dan konfigurasi NGINX konsisten.

Troubleshooting umum

Beberapa masalah yang sering muncul dan cara atasinya:

TXT record nggak terpropagasi: cek TTL, gunakan dig TXT _acme-challenge.example.com dan tunggu sampai terlihat publik.
Permission error saat nginx reload di deploy-hook: jalankan certbot via root atau sesuaikan sudoers untuk reload tanpa password.
Rate limit Let’s Encrypt: jangan spam percobaan. Gunakan staging server untuk tes awal dengan --staging.
Sertifikat terpasang tapi browser masih ngasih error: cek fullchain.pem vs cert.pem, dan periksa chain trust.

Alternatif: acme.sh dan solusi lain

Kalau mau ringan dan fleksibel, acme.sh juga populer buat wildcard karena dukungan banyak DNS provider dan lebih ringan dibanding Certbot. Prinsipnya tetap sama: DNS-01 challenge lewat API atau manual TXT.

Checklist sebelum production roll-out

Pastikan punya akses API DNS atau rencana manual TXT yang reliable.
Automatisasi perpanjangan dan reload NGINX.
Uji di staging Letsencrypt dulu.
Konfigurasi TLS hardening dan monitoring expiring certificate.

Kesimpulan

Jadi gini: Wildcard SSL NGINX itu powerful buat banyak subdomain, tapi harus siap atur DNS-01 challenge dan otomatisasi. Saya sarankan pakai plugin DNS provider kalau tersedia—lebih aman dan praktis. Kalau masih bingung langkah awal, baca juga referensi dasar di https://api.co.id/blog/panduan-mudah-install-ssl-di-nginx/ dan coba dulu di lingkungan staging. Semoga membantu, kalau mau aku bantu cek konfigurasi NGINX kamu, kirim screenshot konfigurasi dan kita bahas bareng.