Panduan SSL Lengkap 2026: Let’s Encrypt vs ZeroSSL vs Cloudflare Origin, Mana yang Saya Pakai untuk Apa

Tiga minggu lalu, klien Surabaya yang baru selesai migrasi VPS Ubuntu 24.04 (referensi: setup VPS Ubuntu 24.04 dari nol dengan certbot) WhatsApp saya jam 11 malam dengan screenshot dashboard Cloudflare:

“Bro, di Cloudflare SSL/TLS tab ada warning Origin Server: Not Secured, padahal SSL Mode-nya Full. Bahaya?”

Saya: “Bukan bahaya. Cloudflare cuma bilang dia tidak verifikasi cert origin Anda, itu beda dengan ‘cert origin Anda tidak ada’. Fix-nya: ganti ke Full Strict + install Cloudflare Origin Certificate.”

“Tapi saya kan udah pasang Let’s Encrypt 2 bulan lalu?”

“LE tetap di origin. CF Origin paralel. Dual-cert strategy.”

“Bisa pasang 2 cert di server yang sama?”

“Bisa. Beda server block. Saya kasih konfigurasi-nya, 45 menit setup.”

45 menit kemudian: SSL Labs A+, Cloudflare Full (Strict), zero warning. SSL handshake time turun dari 117 ms ke 42 ms (TLS 1.3 + ECDSA cert). Klien chat lagi: “Lah, kok jadi lebih cepat juga sambungannya?” Sejak hari itu saya selalu kasih klien dengan Cloudflare proxy: dual-cert strategy. 30% site klien saya sekarang dual-cert.

Artikel ini bukan “Let’s Encrypt vs ZeroSSL siapa menang”. Saya pakai ketiga-nya. Setiap CA punya niche yang dua lainnya tidak bisa cover sendirian. Di bawah ini saya breakdown setiap pilihan dengan use case spesifik, decision matrix, 3 sub-tutorial, dan Nginx config template yang saya pakai untuk 24 site klien selama 14 bulan terakhir.

1. Kenapa SSL 2026 Bukan Hanya ‘Pasang Let’s Encrypt’

Lima tahun lalu rekomendasi default-nya jelas: pasang certbot, jalankan certbot --nginx, selesai. Di tahun 2026 lanskap-nya beda:

• ZeroSSL sudah mature sebagai ACME-compatible alternative, kompatibilitas hampir 100% dengan tool yang sama (certbot, acme.sh, lego), tapi dengan rate limit + region availability berbeda. Bukan plugin, bukan workaround, ini second public CA serious yang bisa Anda pilih untuk fallback otomatis.
  • Cloudflare Origin Certificate availabel di semua plan termasuk Free sejak peluncuran tahun 2016 – sekarang di tahun 2016 sudah mature dengan ECDSA support default. Validity 15 tahun + ECDSA P-256 = handshake lebih cepat + nol renewal headache. Untuk site yang DNS-nya behind Cloudflare proxy, ini sweet spot yang Let’s Encrypt tidak bisa replicate.
• Dual-cert strategy (public CA + private CA paralel di server yang sama) sudah jadi pola standar di agency yang manage banyak klien. Bukan eksotis lagi.

Klaim utama artikel ini sederhana: saya pakai ketiga-nya. Distribusi current setelah saya standardisasi 14 bulan terakhir adalah 50% LE only, 21% CF Origin only, 29% dual-cert. Setiap pilihan punya alasan teknis dengan angka. Cert renewal failure rate turun dari 8–12% per quarter ke <1% per quarter setelah saya adopt strategy cross-CA fallback.

Takeaway: SSL 2026 = multi-CA, bukan single-CA dengan workaround.

2. Let’s Encrypt: Default Choice Saya untuk 50% Site

2.1. Karakter Teknis

• Sponsor: Internet Security Research Group (ISRG), non-profit, didukung Mozilla, EFF, Cisco.
• Cert validity: 90 hari. Sengaja dibuat pendek untuk drive automation; renewal manual setiap 3 bulan = mimpi buruk produksi.
• Free: tidak butuh signup. Anda kasih email saat first issuance untuk recovery, selesai.
• Rate limit (kritis): 50 cert/week per registered domain, 5 duplicate cert/week per cert set, 300 pending authorization per account.
• ACME protocol: v2 (RFC 8555). Supported oleh certbot, acme.sh, lego, win-acme, Caddy built-in.
• Trust: root ISRG Root X1 (RSA 4096). Cross-signed dengan IdenTrust DST Root CA X3 untuk legacy device compatibility (Android <7.1.1). Saat ini 99,9% browser/OS support.

2.2. Use Case yang Saya Pakai LE

1. Public-facing site direct access, site yang DNS-nya tidak behind CDN proxy (typical klien blog, brochure site, landing page).
2. Site multi-subdomain di bawah rate limit, sampai 20 subdomain per registered domain masih nyaman.
3. Klien yang sudah familiar dengan certbot, hemat onboarding time.
4. Default first issuance untuk klien baru sebelum saya tahu use case lengkap.

2.3. Kapan Saya Skip LE

Angka konkret yang bikin saya pernah skip LE: klien e-commerce dengan 23 subdomain (varian region: id.contoh-klien.com, sg.contoh-klien.com, my.contoh-klien.com, plus staging.* + dev.* + cdn.). Hari ke-2 deployment, 5 cert/week duplicate limit kena → certbot return error too many certificates already issued for exact set of domains. Stuck 7 hari sebelum rate limit window reset.

Solusi yang saya pakai sejak itu: wildcard cert untuk site multi-subdomain (*.contoh-klien.com lewat DNS-01 challenge), atau switch ke ZeroSSL untuk subdomain set yang tidak masuk wildcard.

Use case lain di mana saya pertimbangkan skip LE: site klien region remote dengan latency tinggi ke LE infrastructure (Papua 1 kasus, certbot timeout di renewal). ZeroSSL endpoint sub-domain di-route ke server yang lebih dekat untuk klien Asia Tenggara, alternative yang masuk akal.

2.4 Pro tip 💡 #1 ECDSA Cert Lebih Cepat dari RSA

Generate LE cert dengan key type ECDSA P-256 untuk handshake ~15% lebih cepat di TLS 1.3:

sudo certbot --nginx --key-type ecdsa --elliptic-curve secp256r1 \
  -d contoh-klien.com -d www.contoh-klien.com --redirect

Untuk site baru di tahun 2026, default-kan ECDSA. RSA 2048 hanya untuk legacy compatibility (audience pakai browser >5 tahun lalu, sangat jarang).

Takeaway: LE adalah default yang sehat untuk 60–80% klien Anda. Skip-nya khusus untuk multi-subdomain edge case atau region issue.

3. ZeroSSL: Fallback dan Edge Case untuk 8% Site

3.1. Karakter Teknis

• Sponsor: Cohesive Networks Inc (Austria).
• Cert validity: 90 hari free, 1 tahun di paid plan (Premium $10/bulan+).
• Free tier limit: 3 cert per account (limit account-based, bukan per-domain seperti LE). Cocok untuk freelance dengan 1–3 site, kurang ideal untuk agency dengan banyak klien.
• ACME protocol: v2 (RFC 8555). Compatible dengan certbot (via –server flag), acme.sh (native), lego.
• Trust: USERTrust → COMODO ECC Certification Authority. Roots: AAA Certificate Services (RSA), USERTrust ECC Certification Authority (ECDSA). Mature, 99,9% browser/OS support.
• Dashboard: ada UI web (kalau Anda tidak mau CLI). LE tidak punya.

3.2. Use Case yang Saya Pakai ZeroSSL

1. Fallback otomatis ketika LE rate limit kena di klien multi-subdomain.
2. Klien yang request 1-year cert (bukan 90 hari) via dashboard manual, kalau klien tidak siap automation cert dan mau renew tahunan manual, ZeroSSL Premium $10/bulan = 1 hari kerja diganti dengan langganan setahun.
3. Region issue: kasus konkret saya 1 klien dengan VPS region Vietnam. LE renewal failed 3× berturut-turut karena timeout ke ACME directory endpoint. Switch ZeroSSL dengan endpoint sub-domain di Singapore → 0 failure dalam 6 bulan.

3.3. Kapan Saya Skip ZeroSSL

• Default, saya tetap 75–80% pakai LE untuk site baru. ZeroSSL adalah fallback, bukan first choice.
• Klien yang butuh 100% CLI automation dengan ecosystem mature: LE punya tooling lebih lengkap (snap auto-update, systemd timer default, dokumentasi luas).
• Enterprise client dengan SLA strict 24/7: ZeroSSL premium support ada, tapi belum saya stress-test cukup.

3.4 Catatan ⚠️ #2 ZeroSSL Free 3-Cert Limit

ZeroSSL Free plan limit 3 cert per account. Untuk freelance/agency yang manage 10+ klien, ini bottleneck. Tiga opsi:

1. Upgrade ke Premium ($10/bulan untuk 100 cert per account), saya pakai ini untuk agency mode.
2. Pakai LE untuk default, ZeroSSL hanya untuk edge case (1–3 cert per klien yang butuh fallback).
3. Multiple account ZeroSSL, tidak saya rekomendasikan karena bisa flag compliance Terms of Service.

Takeaway: ZeroSSL bukan pengganti LE, dia adalah safety net. Pasang acme.sh + setup ZeroSSL account untuk hari Anda butuhkan dia.

4. Cloudflare Origin Certificate: 15-Year Private CA untuk 29% Site

4.1. Karakter Teknis

• Sponsor: Cloudflare Inc (private CA mereka sendiri).
• Cert validity: 15 tahun (5475 hari), paling panjang dari 3 CA di artikel ini.
• Free: bundled dengan Cloudflare Free plan. Tidak butuh upgrade.
• Trust: TIDAK universal-trusted. Cert ini valid HANYA untuk traffic yang masuk via Cloudflare proxy edge. Di edge, Cloudflare verifikasi cert pakai private CA mereka. Browser end-user tidak pernah lihat cert ini langsung, mereka lihat cert public Cloudflare (Universal SSL).
• Generated via: Cloudflare Dashboard UI atau API endpoint origin-ca/v1.
• Algorithm: RSA 2048 / RSA 4096 / ECDSA P-256 (recommended untuk handshake speed + size).

4.2. Use Case yang Saya Pakai CF Origin

1. Origin server BEHIND Cloudflare proxy dengan SSL Mode = Full (Strict). DNS Proxy “Proxied” (awan jingga) wajib aktif.
2. Internal admin endpoint, misalnya admin.contoh-klien.com untuk wp-admin, traffic selalu via Cloudflare, tidak ada public direct-access.
3. Dev / staging environment behind Cloudflare Access (authenticated traffic only). Cert universal-trusted tidak perlu di sini.

4.3. Kapan Saya Skip CF Origin

• Klien tidak pakai Cloudflare sama sekali, otomatis tidak relevan.
• Klien butuh public-trusted cert untuk audience yang mungkin direct-connect ke origin IP (jarang, tapi pernah: API B2B yang client-nya whitelist IP origin, bypass Cloudflare).
• Wajib pair: SSL Mode di Cloudflare = Full (Strict), DAN origin Anda punya CF Origin cert installed. Salah satu missing = warning di dashboard.

4.4. Angka Konkret: −75 ms Handshake Time

Sebelum saya adopt CF Origin di site klien dengan traffic >10k req/jam, handshake cost dari renewal cycle LE 90-hari adalah:

• Setiap renewal: cert chain berubah → session cache invalidate → 75–95 ms penalty untuk first connection per visitor selama 1–2 jam post-renewal.
• Akumulasi setahun: 4 renewal cycle × 80 ms × 6.000–8.000 first connection = 1,9–2,5 juta milliseconds latency tambahan per site per tahun.

Setelah switch ke CF Origin (15-year, no re-handshake cycle): handshake time average −75 ms per first connection post-attack-burst, plus zero penalty di renewal cycle (karena tidak ada renewal cycle 90 hari). Cumulative win jelas terlihat di SiteSpeed dashboard klien.

4.5 Catatan ⚠️ #1 CF Origin Invalid Kalau Client Bypass Cloudflare

CF Origin cert hanya valid untuk traffic yang masuk via Cloudflare proxy. Kalau ada client yang direct-connect ke origin IP (DNS resolver mereka cached IP lama, atau bypass via /etc/hosts override), browser akan tampil NET::ERR_CERT_AUTHORITY_INVALID. Pastikan:

1. DNS Proxy “Proxied” (awan jingga) di Cloudflare Dashboard untuk SEMUA record yang serve traffic.
2. Origin IP locked ke Cloudflare IP range (UFW rule, lihat 3-layer defense Cloudflare WAF + Nginx + fail2ban untuk implementasi).

Takeaway: CF Origin = sweet spot untuk site behind proxy. Skip-nya hanya kalau klien tidak pakai Cloudflare.

5. Decision Matrix: Pilih CA Berdasarkan Use Case Anda

5.1. Decision Tree

Apakah site Anda BEHIND Cloudflare proxy (DNS Proxy ON, awan jingga)?
│
├─ TIDAK
│   └─ Apakah Anda butuh >20 subdomain dalam 1 cert set?
│       ├─ TIDAK → Let's Encrypt (default)
│       └─ YA → LE wildcard via DNS-01 ATAU ZeroSSL
│
└─ YA
    └─ Apakah ada endpoint yang public-direct (bypass CF)?
        │
        ├─ TIDAK
        │   └─ Cloudflare Origin SAJA (15-year, SSL Mode = Full Strict)
        │
        └─ YA
            └─ DUAL-CERT: LE/ZeroSSL untuk public-direct
                         + CF Origin untuk endpoint behind CF

Takeaway: decision tree ini saya pakai sebagai SOP onboarding klien baru. 5 menit jawaban di awal = pilihan CA yang sustainable untuk 14 bulan ke depan.

6. Tutorial 1: Setup Let’s Encrypt dengan certbot

Stack target: Ubuntu 24.04 LTS + Nginx 1.24 + certbot 2.x snap-installed.

6.1. Install certbot

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Snap-installed bukan apt karena certbot di repo Ubuntu sering lag 6–12 bulan dari upstream. Snap auto-update tiap minggu.

6.2. Initial Issue (Standalone Domain)

sudo certbot --nginx --key-type ecdsa --elliptic-curve secp256r1 \
  -d contoh-klien.com -d www.contoh-klien.com --redirect \
  --email [email protected] --agree-tos --no-eff-email

--redirect otomatis tambah Nginx config untuk redirect HTTP → HTTPS. <code”>–no-eff-email skip EFF newsletter prompt.

6.3. Verify Auto-Renew

sudo systemctl status snap.certbot.renew.timer
sudo certbot renew --dry-run

Output --dry-run harus Congratulations, all simulated renewals succeeded. Kalau gagal di tahap ini, fix sekarang sebelum production cert mendekati 30-hari-to-expire (LE kirim email warning di hari ke-20 sebelum expire).

6.4. Wildcard Certificate (DNS-01 Challenge)

Wildcard cert butuh DNS-01 (bukan HTTP-01) karena Anda harus prove control atas seluruh subdomain. Install plugin Cloudflare DNS:

sudo snap install certbot-dns-cloudflare
sudo snap connect certbot:plugin certbot-dns-cloudflare

Buat credential file:

sudo mkdir -p /root/.secrets
sudo tee /root/.secrets/cloudflare.ini > /dev/null <<'EOF'
dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN_HERE
EOF
sudo chmod 600 /root/.secrets/cloudflare.ini

Token dibuat di Cloudflare Dashboard → My Profile → API Tokens → Create → template Edit zone DNS, scope ke zone contoh-klien.com saja (least privilege).

Issue wildcard:

sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  --key-type ecdsa --elliptic-curve secp256r1 \
  -d "*.contoh-klien.com" -d "contoh-klien.com" \
  --email [email protected] --agree-tos --no-eff-email

Cert valid untuk root domain + semua subdomain level-1. Tidak cover subdomain level-2 (*.api.contoh-klien.com butuh wildcard terpisah).

6.5. Troubleshooting: Rate Limit

Kalau Anda hit too many certificates already issued:

sudo certbot certificates  # list cert yang sudah issued

Tunggu 7 hari (rate limit window), atau switch ke ZeroSSL (lihat Tutorial 2 di bawah).

6.6 Pro tip 💡 #2 Pakai Staging Server Sebelum Production

Saat migrasi site dari hosting lama ke VPS baru, JANGAN langsung point DNS ke VPS sebelum cert installed dan diverifikasi. Test dengan LE staging server dulu:

sudo certbot --nginx --staging \
  -d contoh-klien.com --email [email protected] --agree-tos

Staging cert tidak dipotong dari rate limit production. Setelah verifikasi handshake OK, hapus staging cert dan issue production cert.

Takeaway: certbot snap + ECDSA + DNS-01 wildcard = 95% kebutuhan SSL saya selesai dengan 1 tool.

7. Tutorial 2: Setup ZeroSSL dengan acme.sh

acme.sh adalah pure-bash implementation ACME, tidak butuh Python dependency seperti certbot. Lebih ringan, lebih portable, dan default-nya sudah switch dari LE ke ZeroSSL sejak v3.

7.1. Install acme.sh

curl https://get.acme.sh | sh -s [email protected]
source ~/.bashrc

Install ke ~/.acme.sh/ + tambah crontab entry untuk auto-renew (jalan harian).

7.2. Switch Default CA ke ZeroSSL

~/.acme.sh/acme.sh --set-default-ca --server zerossl

Verifikasi:

~/.acme.sh/acme.sh --info | grep CA

7.3. Register Account ZeroSSL

~/.acme.sh/acme.sh --register-account --server zerossl \
  -m [email protected]

Output kasih EAB credential (External Account Binding), disimpan di config acme.sh, Anda tidak perlu input manual lagi.

7.4. Issue Cert

~/.acme.sh/acme.sh --issue --server zerossl \
  -d contoh-klien.com -d www.contoh-klien.com \
  -w /var/www/contoh-klien.com \
  --keylength ec-256

-w = webroot path (untuk HTTP-01 challenge). --keylength ec-256 = ECDSA P-256.

7.5. Install Cert ke Nginx

~/.acme.sh/acme.sh --install-cert -d contoh-klien.com --ecc \
  --key-file       /etc/nginx/ssl/contoh-klien.com.key \
  --fullchain-file /etc/nginx/ssl/contoh-klien.com.crt \
  --reloadcmd      "systemctl reload nginx"

acme.sh akan otomatis call --reloadcmd setelah setiap renewal. Tidak butuh wrapper script tambahan.

7.6. Verify Auto-Renew

crontab -l | grep acme.sh

Output:

0 */12 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null

acme.sh jalan tiap 12 jam, cek cert yang dekat expire (30 hari sebelum), renew kalau perlu.

7.7. Pro tip 💡 #3 Backup Folder acme.sh + letsencrypt

Hilang ~/.acme.sh/ (untuk ZeroSSL) atau /etc/letsencrypt/ (untuk LE) = certbot/acme.sh tidak tahu cert mana yang dia manage, dan akan reissue cert baru (kena rate limit). Tambahkan dua folder ini ke daily backup rclone Anda:

rclone copy /etc/letsencrypt/ b2:bucket-name/backup/letsencrypt/ --transfers 4
rclone copy /root/.acme.sh/  b2:bucket-name/backup/acme.sh/    --transfers 4

Detail backup workflow lengkap: backup otomatis rclone scripted.

Takeaway: acme.sh + ZeroSSL = setup paralel siap-pakai. Pasang sekarang, pakai saat LE rate limit kena.

8. Tutorial 3: Setup Cloudflare Origin Certificate

Tutorial yang paling sederhana dari 3, semua via Dashboard UI, no CLI required.

8.1. Generate Cert di Cloudflare Dashboard

1. Login Cloudflare Dashboard → pilih domain (contoh-klien.com).
2. Tab SSL/TLS → Origin Server → Create Certificate.
3. Pilihan kunci:
   • Generate private key and CSR with Cloudflare: YES (default, biar Cloudflare yang generate, ringan).
   • Private key type: ECDSA (recommended) atau RSA 2048.
   • Hostnames: contoh-klien.com, *.contoh-klien.com (wildcard native support, gratis).
   • Certificate Validity: 15 years (default, biarkan).
4. Klik Create → muncul modal dengan dua text area: Origin Certificate (PEM) dan Private Key (PEM).

Copy paste-kan keduanya ke file di server SEKARANG. Private Key hanya ditampilkan sekali, kalau Anda close dialog tanpa save, harus generate ulang.

8.2. Save Cert + Key di Server

sudo mkdir -p /etc/nginx/ssl
sudo tee /etc/nginx/ssl/cf-origin-contoh-klien.com.crt > /dev/null <<'EOF'
-----BEGIN CERTIFICATE-----
... paste isi Origin Certificate dari Cloudflare ...
-----END CERTIFICATE-----
EOF

sudo tee /etc/nginx/ssl/cf-origin-contoh-klien.com.key > /dev/null <<'EOF'
-----BEGIN PRIVATE KEY-----
... paste isi Private Key dari Cloudflare ...
-----END PRIVATE KEY-----
EOF

sudo chmod 600 /etc/nginx/ssl/cf-origin-contoh-klien.com.key
sudo chmod 644 /etc/nginx/ssl/cf-origin-contoh-klien.com.crt

8.3. Configure Nginx Server Block

server {
    listen 443 ssl http2;
    server_name admin.contoh-klien.com;

    ssl_certificate     /etc/nginx/ssl/cf-origin-contoh-klien.com.crt;
    ssl_certificate_key /etc/nginx/ssl/cf-origin-contoh-klien.com.key;

    # OCSP stapling OFF untuk CF Origin (private CA, no OCSP responder)
    ssl_stapling off;

    # ... sisa config sama dengan template di Section 11 ...
}

Reload Nginx:

sudo nginx -t && sudo systemctl reload nginx

8.4. Set SSL Mode di Cloudflare ke Full (Strict)

Cloudflare Dashboard → SSL/TLS → Overview → SSL/TLS encryption mode → pilih Full (strict).

Tanpa Full Strict, CF Origin cert tidak diverifikasi oleh Cloudflare edge, defeats the purpose.

8.5. Lock Origin ke Cloudflare IP Range

Wajib supaya tidak ada bypass ke origin IP:

sudo ufw default deny incoming
sudo ufw allow from 173.245.48.0/20 to any port 443 proto tcp comment 'CF range 1'
sudo ufw allow from 103.21.244.0/22 to any port 443 proto tcp comment 'CF range 2'
sudo ufw allow from 103.22.200.0/22 to any port 443 proto tcp comment 'CF range 3'
sudo ufw allow from 103.31.4.0/22  to any port 443 proto tcp comment 'CF range 4'
sudo ufw allow from 141.101.64.0/18 to any port 443 proto tcp comment 'CF range 5'
sudo ufw allow ssh
sudo ufw enable

Full list IP range Cloudflare: https://www.cloudflare.com/ips/ , update jika Cloudflare publish range baru (jarang).

8.6. Pro tip 💡 #4 Authenticated Origin Pulls

Setelah CF Origin aktif, aktifkan extra layer: Cloudflare Dashboard → SSL/TLS → Origin Server → Authenticated Origin Pulls (Zone-level) → ON. Ini bikin Cloudflare attach client certificate saat connect ke origin. Origin tolak koneksi yang tidak punya cert ini. Hasilnya: bahkan kalau attacker tahu IP origin Anda dan UFW belum locked, attacker tidak bisa establish HTTPS connection tanpa client cert Cloudflare.

8.7. Verify via curl

curl -v https://contoh-klien.com 2>&1 | grep -E 'subject|issuer'

Lihat di output:

*  subject: CN=contoh-klien.com
*  issuer: O=Cloudflare, Inc.; CN=Cloudflare Origin SSL Certificate Authority

Kalau issuer-nya Let's Encrypt artinya CF masih serve cert lama, clear cache di Cloudflare → Caching → Purge Everything.

Takeaway: 15 menit setup + zero renewal headache selama 15 tahun. Plus origin lock + Authenticated Origin Pulls = layer keamanan tambahan dari sisi SSL.

9. Nginx Server Block: A+ SSL Labs Configuration 2026

Template Nginx server block yang saya pakai default untuk semua klien, hasil SSL Labs A+ di 22 dari 24 site:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name contoh-klien.com www.contoh-klien.com;

    # Cert path (sesuaikan dengan CA yang dipakai)
    ssl_certificate     /etc/letsencrypt/live/contoh-klien.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/contoh-klien.com/privkey.pem;

    # Protocol & cipher (Mozilla intermediate 2026)
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    # Session resumption
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    # OCSP stapling (LE/ZeroSSL only — OFF untuk CF Origin)
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/contoh-klien.com/chain.pem;
    resolver 1.1.1.1 1.0.0.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # HSTS (1 year, include subdomain, preload-ready)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options nosniff always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # DH params (regenerate sebelum production)
    ssl_dhparam /etc/nginx/dhparam.pem;

    root /var/www/contoh-klien.com;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Generate DH params sekali sebelum apply (2048-bit minimum, 4096-bit untuk paranoid):

sudo openssl dhparam -out /etc/nginx/dhparam.pem 2048

9.1. Kapan OCSP Stapling Harus OFF

OCSP stapling adalah optimisasi handshake, server fetch revocation status dari OCSP responder dan staple ke handshake. Hanya valid untuk public CA (LE, ZeroSSL, DigiCert). CF Origin pakai private CA Cloudflare yang TIDAK punya OCSP responder publik. Kalau Anda paksa <code”>ssl_stapling on di server block CF Origin, Nginx error log akan dipenuhi OCSP responder timed out. Set ssl_stapling off untuk server block CF Origin.

Takeaway: template ini A+ untuk LE/ZeroSSL. Untuk CF Origin, hapus ssl_stapling + ssl_trusted_certificate + resolver.

10. Benchmark: Handshake Time Comparison

Data dari 14 bulan operating 24 site. Average TLS 1.3 handshake time, measured dengan openssl s_client -connect domain:443 dari client di Jakarta:

Verifikasi single connection:

echo | openssl s_client -connect contoh-klien.com:443 -servername contoh-klien.com 2>&1 \
  | grep -E 'Protocol|Cipher|Verify'

Output yang sehat:

Protocol  : TLSv1.3
Cipher    : TLS_AES_128_GCM_SHA256
Verify return code: 0 (ok)

Observation: perbedaan 32 ms vs 47 ms tidak terasa di single visitor. Tapi di site dengan 10k+ first connection per jam (LCP impact), cumulative 15 ms × 10.000 = 150 detik handshake time terhindarkan per jam. Untuk site behind CF proxy yang punya budget render <2,5 s LCP, ini delta yang masuk akal. Detail benefit cache + handshake gabung: trio cache stack 3-layer.

Takeaway: ECDSA + TLS 1.3 + CF Origin = handshake tercepat. RSA 2048 + LE 90-day = baseline yang mayoritas site Anda capai by default, sudah cukup untuk 80% klien.

11. Common Mistake yang Saya Lihat di Klien

Saya audit cert SSL klien setiap quarterly. Lima mistake yang berulang:

11.1. SSL Mode “Flexible” di Cloudflare

Symptom: padlock hijau di browser, tapi traffic Cloudflare-to-origin TIDAK ENCRYPTED (HTTP, bukan HTTPS). MITM attack bisa intercept antara Cloudflare edge dan origin Anda.

Fix: Cloudflare Dashboard → SSL/TLS → Overview → set ke Full minimum, Full (Strict) disarankan.

11.2. SSL Mode “Full” Tanpa “Full Strict”

Symptom: traffic encrypted edge-to-origin, tapi Cloudflare TIDAK verifikasi cert origin. Origin Anda bisa di-spoof oleh server lain yang serve cert self-signed.

Fix: ganti ke Full (Strict). Wajib pasang LE atau CF Origin cert di origin terlebih dahulu.

11.3. Lupa Lock Origin ke CF IP Range Setelah Pakai CF Origin

Symptom: attacker yang tahu origin IP Anda (lewat Shodan, Censys, atau DNS history) bisa direct-connect, bypass Cloudflare WAF. CF Origin cert tampak NET::ERR_CERT_AUTHORITY_INVALID di browser attacker, tapi attacker tidak peduli, dia probe pakai curl/scanner, bukan browser.

Fix: UFW lock ke Cloudflare IP range (lihat Section 10.5). Plus aktifkan Authenticated Origin Pulls (Pro tip #4).

11.4. Pakai CF Origin di Server yang Tidak Behind CF Proxy

Symptom: browser tampil NET::ERR_CERT_AUTHORITY_INVALID untuk visitor. Conversion turun, owner panik.

Fix: verify DNS Proxy “Proxied” (awan jingga) untuk record yang serve traffic. Kalau Anda butuh DNS Only (record yang exclude dari CF proxy), pakai LE/ZeroSSL untuk record itu, JANGAN CF Origin.

11.5. Force OCSP Stapling di Server Block CF Origin

Symptom: Nginx error log dipenuhi OCSP responder timed out. Latency naik 200–500 ms karena Nginx tunggu OCSP response yang tidak akan datang (CF Origin = private CA tidak ada OCSP).

Fix: ssl_stapling off di server block yang pakai CF Origin cert. OCSP stapling hanya untuk public CA.

Daftar tambahan checklist saat audit konfigurasi: cross-reference audit plugin WordPress: 5 plugin yang saya banned , beberapa plugin “SSL helper” (Really Simple SSL Premium misalnya) sebagian features overlap dengan konfigurasi Nginx native + Cloudflare. Bagian browser cache & HTTP/2 yang sering disebut “SSL improvement” sebenarnya konfigurasi server-side: lihat Nginx FastCGI Cache + HTTP/2 dan browser cache expiry via Nginx config untuk konfigurasi yang clean tanpa plugin.

Takeaway: 5 mistake di atas accounting untuk 90% audit issue di klien baru. Cross-check dengan checklist ini saat onboarding setiap site.

12. FAQ

13. Penutup

SSL 2026 bukan single-CA world. Saya pakai Let’s Encrypt untuk 50% site (public-direct default), ZeroSSL untuk 8% site (fallback edge case + region issue), Cloudflare Origin untuk 21% site (full behind proxy), dan dual-cert untuk 29% site (hybrid public + admin behind proxy). Cert renewal failure rate turun dari 8–12% per quarter ke <1% setelah saya adopt strategy cross-CA fallback ini.

Yang saya tidak bahas di artikel ini tapi worth dipelajari lanjut: Let’s Encrypt Profile ekstension yang baru rilis 2025 (alternative cert profile dengan validity period berbeda, sedang gradual rollout), mTLS untuk B2B API authentication yang lebih kuat dari client cert manual, dan Certificate Transparency log monitoring untuk detect cert yang dikeluarkan untuk domain Anda tanpa otorisasi.

Dual-cert strategy adalah sweet spot saya untuk klien behind Cloudflare yang juga punya endpoint public-direct. Setup 45 menit, payback 14 bulan tanpa drama renewal. CF Origin saja untuk klien yang 100% behind proxy. LE default untuk yang tidak pakai Cloudflare. ZeroSSL siap-pakai di background untuk hari LE rate limit kena.

Call to action: test SSL site Anda sekarang di https://www.ssllabs.com/ssltest/. Kalau grade <A, screenshot result + tag saya di X (Twitter) @larhtech, saya review konfigurasi 1-on-1 gratis. Kalau Anda sudah A+ di semua site klien Anda, kirim juga, saya kumpulkan untuk artikel follow-up “Audit SSL 100 Site WordPress Indonesia” yang sedang saya rencanakan untuk 2027.

Audit yang baik bukan mencari CA terbaik, audit yang baik mencocokkan CA dengan use case. Tiga CA, tiga niche, satu konfigurasi yang masuk akal untuk masing-masing.

Last Updated on Mei 24, 2026 by larhtechBro