Ketika Migrasi CA Chain Merusak Kepercayaan Mobile

Dua klien independen melaporkan kegagalan SSL yang memengaruhi pengguna Android, meskipun sertifikat mereka valid dan terpasang dengan benar. Browser desktop tidak menunjukkan error, sementara perangkat mobile tertentu menolak koneksi sebagai tidak terpercaya.

Ringkasan Studi Kasus

• Masalah: CA chain baru tidak dipercaya oleh perangkat Android lama.
• Dampak: Pengguna mobile melihat error SSL meskipun sertifikat valid.
• Akar masalah: Android trust stores tertinggal dari migrasi CA chain.
• Solusi: Terbitkan ulang menggunakan legacy atau cross-signed chains, atau migrasi ke CA dengan kompatibilitas mobile yang lebih baik.
• Wawasan kunci: Kepercayaan SSL tergantung pada platform klien, tidak hanya validitas sertifikat.

---

Sebuah sertifikat SSL dapat secara teknis valid tetapi tetap gagal dalam produksi. Validitas sertifikat hanya mengonfirmasi bahwa sertifikat tersebut telah diterbitkan dan secara kriptografis benar. Ini tidak memastikan kepercayaan universal di semua perangkat.

Inilah yang terjadi selama migrasi CA chain. Certificate Authorities merotasi root dan intermediate untuk keamanan, kepatuhan, dan keberlanjutan jangka panjang. 

Namun platform klien, terutama sistem operasi mobile, memperbarui trust stores mereka dengan lebih lambat dan tidak konsisten. Hasilnya adalah keretakan antara infrastruktur sertifikat modern dan kepercayaan perangkat lama.

Dalam studi kasus ini, kami meneliti dua insiden nyata di mana perubahan CA chain menyebabkan sertifikat SSL yang valid gagal pada perangkat Android. Kami menunjukkan bagaimana kegagalan ini muncul dalam produksi, mengapa diagnostik standar tidak langsung mengungkap penyebabnya, dan bagaimana jalur resolusi yang berbeda memulihkan kompatibilitas mobile di setiap kasus.

Xamisoft: Ketika Upgrade Server Merusak Kepercayaan Android

Xamisoft mengembangkan aplikasi pembelajaran bahasa yang digunakan di platform desktop dan mobile. Infrastruktur mereka telah berjalan tanpa masalah SSL di Windows Server 2019. Browser desktop dan perangkat Android bekerja normal, dan deployment sertifikat mengikuti setup IIS standar. Masalah muncul hanya setelah upgrade rutin.

Masalahnya

Mereka migrasi environment dari Windows Server 2019 ke Windows Server 2025 dan menginstal ulang sertifikat SSL menggunakan metode yang sama yang sebelumnya berhasil. Dari perspektif server, semuanya benar. 

Sertifikat terpasang, sertifikat root dan intermediate ada, dan browser desktop tidak menunjukkan peringatan. Tidak ada yang menunjukkan konfigurasi SSL yang rusak.Kemudian pengguna Android mulai melaporkan kegagalan. Pada versi Android lama, terutama Android 6, situs menampilkan error: “Sertifikat ini bukan dari otoritas terpercaya.”

Dalam beberapa kasus, error serupa muncul bahkan pada build Android yang lebih baru. Itu membuat situasi lebih sulit untuk diinterpretasikan. Pada pandangan pertama, sepertinya server yang salah konfigurasi atau file sertifikat yang hilang.

Dari sudut pandang klien, situasi ini tidak masuk akal:

• Sertifikat yang sama tidak memiliki masalah di Windows Server 2019.
• Sekarang gagal di Windows Server 2025.
• Browser desktop masih bekerja.
• Hanya pengguna mobile yang terblokir.

Analisis Akar Masalah

Ini adalah skenario klasik “semuanya valid, namun pengguna terkunci”. Pada titik ini, dua dimensi teknis mulai muncul.

1. CA Chain Itu Sendiri

Di Windows Server 2019, sertifikat telah diterbitkan di bawah hierarki CA Sectigo RSA Domain Validation Secure Server yang lama. Chain ini dipercaya secara luas, termasuk oleh versi lama.

Di Windows Server 2025, sertifikat yang sama sekarang terhubung ke: Sectigo Public Server Authentication CA DV R36.

Ini adalah bagian dari hierarki kepercayaan Sectigo yang lebih baru. Ini valid dan dipercaya oleh sistem modern, tetapi beberapa Android trust stores belum memasukkannya. Untuk perangkat tersebut, certificate chain simply tidak memiliki anchor terpercaya.

2. Pengiriman Certificate Chain

Windows Server 2019 mengisi sertifikat intermediate yang hilang menggunakan system store. IIS dapat mengambil intermediate di belakang layar dan menyajikan chain lengkap kepada klien, bahkan jika administrator tidak secara eksplisit menginstal setiap komponen.Windows Server 2025 mengubah perilaku itu. Ini memerlukan chain lengkap untuk dikonfigurasi secara eksplisit. Jika ada sertifikat intermediate yang hilang atau salah urut, beberapa klien akan gagal validasi bahkan jika browser dapat memulihkan chain melalui AIA (Authority Information Access) fetching.

Ini berarti Xamisoft menghadapi dua masalah yang tumpang tindih:

1. Beberapa perangkat Android tidak mempercayai hierarki Sectigo baru.
2. Beberapa klien tidak menerima chain lengkap dengan benar dari server.

Salah satu masalah saja dapat merusak SSL. Bersama-sama, mereka mengaburkan penyebab sebenarnya.

Ini menjelaskan mengapa:

• Browser desktop masih bekerja.
• Tools pengujian SSL menunjukkan hasil yang sebagian besar hijau.
• Perangkat Android gagal secara tak terduga, tergantung pada versi dan build vendor.

Diagnosis Kami

Pertama, kami mengklarifikasi bahwa perangkat Android tidak pernah menggunakan trust store server. Menginstal sertifikat root di Windows tidak melakukan apa-apa untuk Android. Keputusan kepercayaan dibuat sepenuhnya di perangkat.

Kedua, kami menjelaskan bahwa Windows Server 2025 memerlukan kelengkapan chain eksplisit. Server perlu menyajikan:

• Sertifikat server
• Sertifikat intermediate yang benar
• Dalam urutan yang benar

Mengandalkan pengambilan implisit tidak lagi dapat diandalkan.

Solusinya

Daripada mencoba memaksa IIS untuk menangani ini dengan andal, Xamisoft mengimplementasikan perbaikan struktural. Mereka menempatkan Nginx di depan IIS sebagai proxy dan mengkonfigurasi Nginx untuk menyajikan certificate chain lengkap secara eksplisit.

Ini mencapai dua hal:

• Chain lengkap dikirimkan secara konsisten kepada setiap klien.
• Perangkat Android yang masih mempercayai bagian lama dari hierarki dapat memvalidasi dengan benar.

Setelah perubahan, error SSL menghilang dan perangkat Android 6 dapat mengakses situs lagi. Tidak diperlukan perubahan pada sertifikat itu sendiri.

Kasus ini menyoroti bahwa kegagalan SSL seringkali tidak disebabkan oleh satu kesalahan, tetapi muncul dari interaksi antara evolusi CA chain, platform trust stores, perilaku perangkat lunak server, dan mekanisme pengiriman sertifikat.Perbaikan Xamisoft memperbaiki jalur pengiriman antara infrastruktur CA modern dan kepercayaan klien lama.

Coppernic: Android 6 Gagal Setelah Penerbitan Ulang Sertifikat

Coppernic adalah perusahaan teknologi Prancis yang merancang dan mengembangkan solusi perangkat keras dan perangkat lunak mobile profesional untuk identifikasi, kontrol akses, dan sistem pengumpulan data.

Masalahnya

Masalah muncul selama penggantian sertifikat rutin hanya pada perangkat Android lama. Coppernic sedang dalam proses beralih dari sertifikat SSL yang ada ke yang baru dipesan. 

Instalasi itu sendiri berjalan sesuai yang diharapkan. Browser desktop menerima sertifikat tanpa peringatan. Tidak ada miskonfigurasi server-side yang terlihat. Namun, terminal Android 6.0.1 tidak lagi dapat membuat koneksi terpercaya. 

Sertifikat itu valid, terpasang dengan benar, dan diterbitkan oleh Certificate Authority yang sah, namun perangkat tersebut menolaknya. Sertifikat sebelumnya telah bekerja. Tidak ada hal lain dalam infrastruktur yang berubah.

Analisis Akar Masalah

Satu-satunya perbedaan adalah chain. Sertifikat baru diterbitkan di bawah hierarki Sectigo yang diperbarui, menggunakan intermediate R46. Chain ini adalah bagian dari proses migrasi root Sectigo. Ini sesuai dan dipercaya oleh platform modern, tetapi banyak Android trust stores lama tidak berisi anchor yang diperlukan untuk memvalidasinya.

Coppernic mengidentifikasi situasi dengan tepat:

“Sepertinya sertifikat CA baru (R46) tidak tertanam.”

Mereka mencoba memulihkan kompatibilitas dengan menambahkan sertifikat USERTrust, tetapi itu tidak membantu. Perangkat Android masih menolak chain. Masalahnya bukan file yang hilang di server, tetapi ketiadaan jalur kepercayaan yang kompatibel pada perangkat itu sendiri.

Pada titik itu, pertanyaan bergeser dari instalasi ke kompatibilitas.

Diagnosis Kami

Tim support kami mengonfirmasi bahwa perilaku ini sesuai dengan migrasi CA chain Sectigo. Mulai pertengahan 2025, sertifikat baru diterbitkan di bawah hierarki yang diperbarui secara default, termasuk chain R46. Meskipun valid dan dipercaya oleh platform modern, jalur kepercayaan itu tidak ada dalam banyak Android trust stores lama.

Kami juga mengklarifikasi bahwa menambahkan sertifikat seperti USERTrust tidak akan memengaruhi perangkat Android. Android memvalidasi kepercayaan secara eksklusif terhadap store internalnya. Jika perangkat tidak mengenali jalur penerbitan, tidak ada perubahan server-side yang dapat mengatasi kegagalan.

Solusinya

Solusi praktis adalah menerbitkan ulang sertifikat menggunakan CA cross-signed.

Setelah Coppernic menghubungi Sectigo, sertifikat diterbitkan ulang di bawah chain cross-signed yang mempertahankan jalur ke root lama yang masih dipercaya. Tidak diperlukan perubahan infrastruktur. Hanya jalur kepercayaan yang disesuaikan.

Setelah sertifikat yang diterbitkan ulang dipasang:

• Perangkat Android 6.0.1 terhubung normal.
• Platform desktop terus mempercayai sertifikat.
• Inkompatibilitas menghilang segera.

Kasus ini penting karena mengisolasi masalah ke satu variabel. Tidak ada migrasi server atau inkonsistensi pengiriman chain. Kedua sertifikat valid, tetapi hanya satu yang dapat digunakan dalam produksi.

Pengalaman Coppernic menunjukkan seberapa cepat kompatibilitas dapat runtuh ketika Certificate Authority memindahkan penerbitan default mereka ke depan. Jalur kepercayaan yang lebih baru tidak otomatis menjadi yang lebih luas. Dalam lingkungan yang masih bergantung pada armada Android lama, itu bisa menjadi lebih sempit dan lebih rapuh.

Bagaimana Perangkat Memutuskan Apakah Akan Mempercayai Sertifikat

Ketika perangkat memeriksa sertifikat SSL, ia membangun jalur kepercayaan dari sertifikat situs melalui satu atau lebih intermediate ke sertifikat root yang sudah ada dalam trust store-nya. Jika perangkat tidak dapat menyelesaikan jalur itu menggunakan sertifikat yang dipercayainya, koneksi gagal, bahkan jika sertifikat itu sendiri valid.

Android terfragmentasi secara desain. Manufaktur mengirimkan versi yang berbeda, jadwal pembaruan bervariasi, dan banyak perangkat berhenti menerima pembaruan sistem lama sebelum diganti. Ponsel dapat tetap aktif selama bertahun-tahun setelah pembaruan keamanan atau trust store terakhirnya. Dari perspektif sertifikat, perangkat itu menjadi kapsul waktu.

Trust stores hidup di dalam sistem operasi. Jika OS tidak diperbarui, trust store juga tidak. Itu berarti perangkat dapat terus mengandalkan root sertifikat dan jalur kepercayaan yang berlaku bertahun-tahun yang lalu, tetapi tidak lagi selaras dengan bagaimana Certificate Authorities modern menerbitkan chain.

Mengapa Masalah Ini Sulit Didiagnosis

Diagnostik SSL standar mengonfirmasi bahwa sertifikat valid, chain lengkap, dan server menyajikannya dengan benar. Apa yang tidak mereka validasi adalah apakah setiap perangkat klien dalam ekosistem dapat mempercayai chain tersebut.

Dalam kasus kami, semua pemeriksaan konvensional lulus. Tools pengujian SSL mengembalikan hasil hijau, konfigurasi server benar, dan browser desktop bekerja tanpa error. Dari sudut pandang infrastruktur, tidak ada yang rusak.

Kegagalan terjadi di luar ruang lingkup diagnostik tradisional. Hanya kelas perangkat tertentu (versi Android lama dengan trust stores yang ketinggalan zaman) yang terpengaruh. Karena sebagian besar alur kerja validasi tidak termasuk pengujian kompatibilitas kepercayaan tingkat perangkat, masalah tetap tidak terlihat sampai pengguna nyata mengalaminya.Ini menciptakan titik buta diagnostik: sebuah sertifikat dapat valid, terpasang dengan benar, dan sepenuhnya sesuai, sambil tetap menampilkan error untuk pengguna yang tidak curiga.

Bagaimana Kami Mendiagnosis Masalah

Kami mengidentifikasi masalah melalui pengenalan pola.

Ketika sertifikat valid bekerja di platform desktop tetapi gagal pada lingkungan mobile tertentu, itu mengarah dari konfigurasi server dan menuju kompatibilitas trust store. Ini tidak jelas kecuali Anda memiliki paparan sebelumnya terhadap migrasi CA dan perilaku kepercayaan tingkat platform.

Munculnya kegagalan spesifik Android bersamaan dengan CA chain yang baru diperkenalkan langsung mempersempit ruang lingkup investigasi. Masalahnya tidak lagi “mengapa SSL rusak,” tetapi “trust stores mana yang tidak lagi menerima jalur kepercayaan ini.”

Ini memerlukan pemisahan dua konsep yang sering tercampur:

• validitas sertifikat (ketepatan kriptografis)
• kepercayaan perangkat (penerimaan platform)

Mengenali perbedaan itu memungkinkan kami untuk mendiagnosis masalah dengan cepat dan akurat.

Jalur Resolusi Yang Kami Tawarkan

Setelah kami mengonfirmasi masalah kompatibilitas kepercayaan, memperbaikinya menjadi masalah strategi daripada perbaikan. Setiap opsi mewakili keseimbangan yang berbeda antara stabilitas jangka pendek dan keselarasan jangka panjang dengan ekosistem kepercayaan.

1. Terbitkan ulang menggunakan legacy chain: Ini langsung memulihkan kompatibilitas dengan perangkat Android lama. Itu adalah cara tercepat untuk menghilangkan error yang dihadapi pengguna dan menstabilkan lalu lintas produksi.
2. Terima kompatibilitas parsial: Beberapa lingkungan memilih untuk memprioritaskan platform modern dan menerima bahwa perangkat lama akan mengalami error SSL. Ini menyederhanakan infrastruktur, tetapi membatasi jangkauan audiens.
3. Beralih ke Certificate Authority yang berbeda: Bermigrasi ke CA lain dapat memberikan kompatibilitas mobile jangka panjang dan mengurangi ketergantungan pada trust chains transisional.

Rencanakan migrasi bertahap: Bahkan ketika menggunakan legacy chain sementara, perencanaan jangka panjang diperlukan. Model kepercayaan yang mendasari akan terus berkembang, dan admin website harus menangani kompatibilitas secara struktural.

Mengapa Menerbitkan Ulang Sertifikat Bukan Perbaikan Permanen

Menerbitkan ulang dengan legacy atau cross-signed chain menunda masalah kompatibilitas; itu tidak menghilangkannya. Chain ini ada untuk menjembatani transisi, bukan untuk menggantikan jalur kepercayaan modern.

Saat Certificate Authorities terus memodernisasi hierarki mereka, intermediate lama dan jalur kompatibilitas akan dipensiunkan. Ketika itu terjadi, pola kegagalan yang sama akan kembali jika sistem tetap bergantung padanya.

Menerbitkan ulang karena itu adalah stabilizer, bukan solusi. Itu membeli waktu. Stabilitas jangka panjang memerlukan keselarasan dengan bagaimana ekosistem kepercayaan berkembang, bukan perlawanan terhadapnya.

Itulah pelajaran struktural di balik kedua studi kasus.

Pemikiran Akhir: Mengapa Sertifikat “Valid” Masih Gagal di 2026 

Kasus ini menunjukkan bagaimana SSL/TLS bekerja dalam praktik di 2026. Certificate Authorities bergerak cepat. Mereka merotasi chain, memodernisasi jalur kepercayaan, dan merespons persyaratan keamanan baru. Perangkat tidak. Di smartphone, banyak pengguna tetap berlabuh pada model kepercayaan yang tertinggal bertahun-tahun dari infrastruktur CA saat ini.

Karena itu, “valid” tidak lagi otomatis berarti “dapat digunakan.”

Organisasi tidak boleh memperlakukan SSL sebagai setup sekali jalan. Itu harus dikelola sebagai lapisan kompatibilitas antara:

• Certificate Authorities
• Sistem operasi
• Siklus hidup perangkat
• Lingkungan pengguna

Itu berarti:

• Mengetahui perangkat apa yang sebenarnya dijalankan pengguna Anda, bukan hanya browser apa yang Anda uji.
• Menguji sertifikat terhadap platform mobile nyata, termasuk versi Android lama.
• Melacak pengumuman CA dan migrasi chain sebagai risiko operasional, bukan kebisingan latar belakang.
• Menghindari ketergantungan pada satu jalur kepercayaan atau satu CA kapanpun mungkin.

Fleksibilitas menjadi properti keamanan. Dan inilah di mana dukungan menjadi lapisan stabilitas, bukan hanya fungsi helpdesk.

Di SSL Dragon, tim support kami menerjemahkan pergeseran ekosistem menjadi keputusan yang dapat ditindaklanjuti:

• mengenali masalah kompatibilitas kepercayaan
• memisahkan perilaku platform dari error server
• memilih strategi mitigasi
• melindungi akses pengguna mobile

Kami menjembatani kesenjangan antara standar dan realitas produksi. Jika Anda melihat masalah SSL tak terduga di mobile atau ingin memverifikasi bagaimana sertifikat Anda berperilaku secara langsung, jalankan domain Anda melalui SSL Checker kami untuk melihat persis apa yang dilihat perangkat pengguna Anda.