Kenapa Umur Sertifikat SSL/TLS Berkurang Menjadi 47 Hari?

27-05-2026

Hari ini saya sedang melakukan renewal salah satu sertifikat SSL/TLS dari DigiCert, hal ini sudah berkali-kali saya lakukan sampai rasanya agak jenuh karena setiap tahun harus melakukan renewal.

Tapi ada sesuatau yang sedikit berbeda.

Setelah sertifikat selesai diterbitkan, saya sempat melihat tanggal expired-nya dan langsung merasa ada yang aneh. Masa berlakunya lebih pendek dari biasanya. Awalnya saya pikir mungkin salah lihat, atau mungkin saya salah melakukan order paket sertifikat. Selama melakukan renewal, sertifikat SSL/TLS biasanya berlaku satu tahun atau 365 hari. Bahkan ketika ada perubahan yang menurunkan masa berlaku sertifikat menjadi 398 hari (sebelumnya bisa sampai 2 tahunan).

Tapi sertifikat ini bukan 365 hari.

Masa berlakunya cuma sekitar 200 hari.

Detail tersebut itu malah membawa saya ke rasa mencari tahu tanpa akhir, semakin jelas bahwa ini bukan sekadar perubahan dari DigiCert atau kebijakan sementara dari certificate authority tertentu setelah melakukan komparasi.

Seluruh ekosistem TLS Certificate ternyata berubah ke masa berlaku sertifikat yang jauh lebih pendek.

Dan pada akhirnya, di tahun 2029 nanti, sertifikat TLS publik kemungkinan hanya akan berlaku selama 47 hari saja.

CA/Browser Forum Diam-Diam Mengubah Ekosistem Keamanan Internet

Kebanyakan orang di luar tim infrastruktur atau security mungkin belum pernah mendengar tentang CA/Browser Forum.

Padahal, hampir semua orang yang menggunakan internet bergantung pada keputusan yang dibuat oleh forum tersebut.

CA/Browser Forum sendiri adalah konsorsium industri yang berisi:

Vendor browser
Certificate authority
Perusahaan security

Anggotanya termasuk perusahaan seperti:

Google
Apple
Mozilla
DigiCert
Sectigo
GlobalSign

Grup ini yang menentukan banyak aturan operasional dan standar keamanan di balik sertifikat TLS publik.

Mereka juga yang mendorong perubahan besar di internet seperti:

Penghentian sertifikat SHA-1
Penghapusan kriptografi yang lemah
Pengurangan masa berlaku sertifikat TLS/SSL
Standar validasi sertifikat yang semakin ketat

Dan perubahan masa berlaku sertifikat ini sebenarnya sudah berjalan pelan-pelan selama beberapa tahun terakhir.

The certificate validity reduction timeline has slowly evolved over the years:

Periode	Maksimum Masa Berlaku Sertifikat TLS
< 2015	5–10 years
2015	39 months
2018	825 days
2020	398 days
Masa transasi baru	~200 days
Target 2029	47 days

Sekilas, pengurangan masa berlaku sertifikat TLS/SSL memang terdengar lebih merepotkan daripada bermanfaat karena semakin sering sysadmin melakukan deployment.

Lalu kenapa renewal harus dibuat lebih sering? Kenapa operational overhead justru ditambah?

Tapi begitu mengetahui dampaknya kalau sertifikat atau private key jatuh ke tangan Threat Actor, alasan kenapa forum mulai mengurangi masa berlaku TLS certificate jadi terasa cukup masuk akal.

Apa yang Terjadi Kalau Sertifikat TLS Bocor?

Sertifikat TLS itu sendiri sebenarnya bukan bagian yang paling berbahaya.

Risiko terbesarnya ada di private key yang terhubung dengan sertifikat tersebut.

Jika Threat Actor berhasil mendapatkan private key dari sebuah sertifikat TLS, mereka bisa saja:

Menyamar sebagai website asli
Melakukan intercept terhadap trafik terenkripsi
Menjalankan man-in-the-middle attack
Membuat infrastruktur phishing yang terlihat meyakinkan
Melewati warning atau trust system atau security protection tertentu

Dan yang bikin cukup mengkhawatirkan, Kasus sertifikat bocor dan penyalahgunaan/abuse certificate trust sudah berkali-kali terjadi.

Real Cases Penyalahgunaan Sertifikat Bocor

Sudah ada banyak kasus nyata di mana sertifikat yang dicuri atau disalahgunakan dipakai attacker untuk melewati trust system, menyebarkan malware, sampai melakukan intercept trafik terenkripsi.

DigiNotar Breach (2011)

Salah satu insiden terbesar dalam sejarah certificate authority terjadi saat DigiNotar, sebuah CA asal Belanda, berhasil diretas attacker pada tahun 2011.

Dari penyalahgunaan certificate tersebut, attacker berhasil membuat sertifikat palsu untuk domain besar seperti:

Google
Yahoo
Microsoft

Salah satu sertifikat Google palsu bahkan dilaporkan digunakan untuk operasi surveillance dan interception trafik dalam skala besar.

Yang membuat situasi ini berbahaya adalah karena browser pada saat itu masih mempercayai DigiNotar sebagai certificate authority resmi. Artinya, user yang terkena dampak kemungkinan tidak langsung melihat warning atau tanda mencurigakan saat mengakses website.

Dampaknya cukup besar:

Browser mulai mencabut trust terhadap DigiNotar
Pemerintah turun melakukan investigasi
DigiNotar akhirnya bangkrut dan berhenti beroperasi

Insiden ini kemudian menjadi salah satu turning point terbesar dalam sejarah keamanan sertifikat TLS dan public PKI.

Stuxnet dan Sertifikat Code-Signing yang Dicuri

Malware Stuxnet menggunakan sertifikat code-signing asli yang dicuri dari perusahaan hardware seperti Realtek dan JMicron.

Karena malware tersebut ditandatangani menggunakan sertifikat digital yang valid:

Windows menganggap file tersebut sebagai software terpercaya
Beberapa security tools menjadi lebih tidak curiga
Malware berhasil melewati sebagian mekanisme trust protection

Kasus ini menunjukkan seberapa berbahayanya sertifikat yang jatuh ke tangan attacker.

Begitu attacker berhasil mendapatkan trusted certificate identity, malware yang seharusnya terlihat mencurigakan justru tampak seperti software legitimate di mata operating system.

ASUS ShadowHammer Attack (2019)

Dalam serangan supply chain ASUS ShadowHammer, attacker berhasil mendapatkan akses infrastruktur software update milik ASUS dan menyebarkan malware melalui update resmi.

Binary berbahaya tersebut ditandatangani menggunakan sertifikat ASUS yang legitimate.

Akibatnya:

Malware terlihat seperti update resmi ASUS
Proses deteksi antivirus menjadi lebih sulit
Banyak user menginstall malware tanpa curiga

Pada laporan terdapat ratusan ribu sistem menerima update berbahaya tersebut sebelum serangannya berhasil terdeteksi.

SolarWinds Supply Chain Attack (2020)

SolarWinds menjadi salah satu supply chain attack paling besar dalam sejarah modern keamanan siber.

Attacker berhasil menyisipkan malware ke dalam update resmi software Orion yang kemudian didistribusikan ke pengguna SolarWinds di seluruh dunia.

Karena update tersebut tetap ditandatangani secara legitimate:

Customer menganggap software tersebut aman dan terpercaya
Sistem security enterprise tetap mengizinkan instalasi
Attacker berhasil mendapatkan akses awal ke jaringan pemerintah dan perusahaan besar

Kasus ini menunjukkan bahwa mekanisme software signing dan machine identity yang seharusnya menjadi lapisan kepercayaan justru bisa berubah menjadi jalur serangan jika berhasil dikompromikan.

Compromised VPN and Internal Certificates

Dalam banyak kasus breach di lingkungan enterprise, attacker sering menargetkan sertifikat internal setelah berhasil mendapatkan initial access.

Sertifikat yang biasanya menjadi target meliputi:

VPN authentication certificates
Internal PKI certificates
Service mesh identities
SSO authentication certificates

Begitu sertifikat ini berhasil dicuri, dampaknya bisa langsung terasa di level infrastruktur.

Attacker bisa:

Menyamar sebagai sistem yang sah
Bergerak lateral di dalam jaringan
Mempertahankan akses secara diam-diam (persistence)
Melewati beberapa kontrol MFA di kondisi tertentu
Menghindari deteksi berbasis identity

Di arsitektur modern Zero Trust, sertifikat pada dasarnya sudah menjadi “machine passport” untuk setiap service.

Dan ketika identity ini berhasil dicuri, attacker bisa langsung melakukan take over akses terpercaya di seluruh environment.

Kenapa Sertifikat TLS yang Lebih Pendek Itu Penting

Salah satu alasan utama di balik pengurangan masa berlaku TLS/SSL certificate adalah untuk mengurangi risiko ketika terjadi kompromi private key atau pencurian sertifikat.

Saat attacker berhasil mendapatkan private key dari sebuah TLS certificate, mereka bisa:

Menyamar sebagai website asli
Melakukan intercept terhadap traffic HTTPS terenkripsi
Menjalankan serangan man-in-the-middle (MITM)
Mempertahankan akses di lingkungan enterprise
Menyalahgunakan machine identity yang dipercaya

Dalam model lama, sertifikat yang sudah dikompromikan bisa tetap valid selama berbulan-bulan bahkan bertahun-tahun. Ini menciptakan jendela serangan yang sangat panjang, terutama ketika sistem revocation tidak berjalan efektif atau bahkan tidak digunakan sama sekali.

Secara teori, sertifikat yang sudah dicabut bisa diblokir melalui:

OCSP (Online Certificate Status Protocol)
CRL (Certificate Revocation List)

Namun dalam praktiknya, sistem revocation ini memang tidak selalu bisa diandalkan. Ada aplikasi yang tidak benar-benar mengecek status revocation, dan ada juga sistem yang tetap berjalan meskipun layanan OCSP/CRL tidak tersedia.

Inilah salah satu alasan utama kenapa CA/Browser Forum mendorong penggunaan short-lived TLS certificates, dengan arah menuju 47-day certificate lifetime pada tahun 2029.

Dengan masa berlaku yang lebih pendek:

Sertifikat yang dicuri cepat menjadi tidak berguna
Peluang persistence attacker menjadi lebih kecil
Lifecycle machine identity menjadi lebih ketat
Organisasi terdorong untuk melakukan rotasi kredensial secara rutin

Pendekatan ini menggeser fokus dari revocation menuju model yang lebih modern: automatic expiration dan continuous certificate rotation.

Perubahan ini sejalan dengan prinsip keamanan modern seperti:

Zero Trust security
Ephemeral credentials
Workload identity
Machine identity management
Automated certificate lifecycle management

Pada akhirnya, arah TLS memang jelas bergerak ke sistem yang lebih otomatis, lebih dinamis, dan berbasis trust yang terus berganti secara berkala.

Tujuan Besar di Balik Ini: Memaksa Internet untuk Beralih ke Automasi

Setelah membaca lebih dalam diskusi di CA/Browser Forum, semakin terasa bahwa arah perubahan ini bukan cuma soal keamanan, tapi juga soal mendorong seluruh ekosistem internet untuk otomatisasi.

Karena pada kenyataannya, manual certificate management memang sudah tidak cocok lagi dengan 47-day TLS certificates serta dampaknya ketika jatuh ditangan orang yang salah

Menariknya, masih banyak organisasi yang mengandalkan:

Spreadsheet untuk tracking sertifikat
Email reminder untuk renewal
Approval lewat ticket system
Upload manual ke server
Maintenance window terjadwal
Proses deployment yang masih dikerjakan manusia

Model seperti ini masih bisa berjalan saat masa berlaku sertifikat tahunan.

Tapi ketika siklusnya menjadi bulanan, pendekatan manual seperti ini mulai benar-benar tidak efektif.

Di sisi lain, infrastruktur modern sekarang sudah menuntut:

Automated certificate issuance
Automated renewal process
Certificate discovery di seluruh environment
Dynamic trust distribution
Lifecycle management untuk machine identity

Inilah alasan kenapa tools dan standar seperti:

ACME
cert-manager
Vault PKI
SPIFFE / SPIRE

semakin menjadi bagian penting dari ekosistem modern infrastructure dan security.

Semua ini mengarah ke satu hal: certificate management tidak lagi bisa dipisahkan dari automation.

Masalah Terbesar: Banyak Perusahaan Belum Siap

Salah satu tantangan terbesar dari pengurangan masa berlaku sertifikat TLS adalah banyak organisasi yang masih belum memiliki sistem inventory dan manajemen lifecycle sertifikat yang baik.

Banyak perusahaan besar sebenarnya masih tidak benar-benar tahu:

berapa banyak sertifikat yang mereka miliki
di mana saja sertifikat tersebut digunakan
sistem mana yang terbuka ke internet
tim mana yang bertanggung jawab atas renewal

Di banyak lingkungan, sertifikat tersebar di berbagai tempat seperti:

load balancer lama
subdomain yang terlupakan
perangkat legacy
sistem embedded
shadow IT

Seiring masa berlaku sertifikat semakin pendek, celah visibilitas ini berubah menjadi risiko operasional.

Karena setiap proses renewal sertifikat sekarang bukan lagi sekadar tugas rutin:

menjadi deployment event
berpotensi menyebabkan outage
menjadi titik kegagalan otomatisasi

Dan di dunia nyata, sudah banyak kasus outage yang disebabkan oleh sertifikat yang kedaluwarsa atau renewal yang terlewat.

Masa Depan TLS adalah Continuous Rotation

Saya yakin sertifikat TLS 47 hari bukanlah tujuan akhir. Lebih tepatnya, ini adalah awal dari pergeseran besar menuju rotasi sertifikat otomatis dan machine identity yang bersifat sementara (short-lived).

Arah perkembangan internet saat ini sudah cukup jelas:

ephemeral credentials
workload identity
automated trust systems
continuous authentication
dynamic machine identity

Di beberapa sistem modern, rotasi sertifikat mungkin sudah dilakukan:

setiap hari
setiap jam
otomatis saat deployment

Model lama “setup dan lupakan” pada SSL certificate perlahan mulai hilang, digantikan oleh manajemen sertifikat otomatis dan lifecycle TLS yang semakin pendek.

Dan jujur, perubahan ini benar-benar terasa saat saya melihat masa berlaku 200 hari yang tidak saya duga pada saat melakukan renewal DigiCert yang saya kira hanya rutinitas biasa.

Membangun Platform Otomasi Sertifikat

Satu hal yang semakin jelas ketika saya mempelajari roadmap CA/Browser Forum menuju sertifikat TLS 47 hari adalah, distribusi sertifikat secara manual akan ditinggalkan.

Terutama di lingkungan yang menggunakan wildcard certificate seperti:

load balancer
reverse proxy
Kubernetes ingress
API gateway
banyak application server

Di banyak organisasi, proses renewal malah masih manual:

renew certificate → export bundle → copy file → restart service

Alur tersebut sering menyebabkan downtime, apalagi jika masa berlaku sertifikat semakin pendek.

Karena itu, saya sedang membangun sebuah Open Source Project yang berfokus pada otomasi sertifikat dan distribusi certificate secara aman.

Konsepnya simple:

Inventory sertifikat terpusat
Deployment sertifikat otomatis
Sinkronisasi renewal
Monitoring expiry
Distribusi yang lebih mudah

Proyek ini masih bersifat private dan dalam tahap pengembangan.

Tapi kamu sedang menghadapi masalah yang sama terkait otomasi certificate, PKI, atau machine identity, boleh banget untuk diskusi.