NET::ERR_CERT_AUTHORITY_INVALID: Arti & Cara Mengatasi

Kartu identitas hanya berharga kalau lembaga penerbitnya dikenal. Petugas bank menerima KTP yang diterbitkan Dukcapil, tetapi menolak kartu berfoto sama yang dicetak sendiri di tempat fotokopi — sekalipun namanya benar. Yang diperiksa bukan sekadar isi kartu, melainkan siapa yang menjaminnya.

Browser melakukan pemeriksaan serupa setiap kali membuka halaman HTTPS. Server menyodorkan sertifikat, dan browser menelusuri siapa yang menandatanganinya sampai bertemu penerbit yang ada di daftar kepercayaannya. Kalau penelusuran itu berakhir di penerbit yang tidak dikenal, Google Chrome menghentikan pemuatan dan menampilkan kode NET::ERR_CERT_AUTHORITY_INVALID.

Di bawah ini kita urai arti kode itu dan menemukan penyebabnya lewat nama penerbit sertifikat. Setelah itu kita bahas cara mengatasi ERR_CERT_AUTHORITY_INVALID, baik saat Anda berkunjung maupun saat situs Anda sendiri yang bermasalah.

ERR_CERT_AUTHORITY_INVALID Artinya Penerbit Sertifikat Tidak Dikenali

ERR_CERT_AUTHORITY_INVALID adalah kode error Chrome yang berarti sertifikat situs ditandatangani oleh pihak yang tidak dipercaya browser. Pihak penerbit ini disebut Certificate Authority (CA, lembaga yang menjamin bahwa sebuah sertifikat benar milik situs tertentu). Kode angkanya −202, dan awalan NET:: hanya menandakan bahwa error ini lahir dari lapisan jaringan Chrome.

Sertifikat dan CA sendiri dibahas lebih lengkap di artikel SSL adalah. Untuk artikel ini cukup satu gambaran: di antara sertifikat situs dan CA induknya biasanya ada satu atau dua sertifikat perantara. Browser menelusuri rantai itu satu per satu, dan penelusuran baru dianggap sah bila berujung di sertifikat akar (root certificate) yang sudah tersimpan di daftar kepercayaannya.

Kode sumber Chromium menuliskan tiga kemungkinan di balik error ini:

1. Ada pihak yang menukar sertifikat: sertifikat asli diganti sertifikat lain yang ditandatangani pihak penyusup, supaya lalu lintas Anda bisa dibaca.
2. CA-nya sah, tetapi tidak dikenal Chrome: operator server memakai sertifikat dari lembaga yang tidak ada, atau tidak lagi ada, di daftar Chrome.
3. Sertifikatnya ditandatangani sendiri: server memakai sertifikat self-signed. Sertifikat ini tetap mengenkripsi, tetapi tidak bisa membuktikan bahwa server di seberang benar-benar situs yang Anda tuju.

Ketiganya bermuara pada satu pertanyaan: siapa yang menerbitkan sertifikat ini? Pertanyaan itulah yang dipakai sepanjang artikel ini untuk menemukan penyebabnya.

Tampilan Layar "Koneksi Anda Tidak Pribadi" di Chrome dan Edge

Chrome berbahasa Indonesia menampilkan judul "Koneksi Anda tidak pribadi" dengan tab bertuliskan "Kesalahan privasi". Di bawahnya tertulis bahwa penyerang mungkin mencoba mencuri informasi Anda, misalnya sandi, pesan, atau kartu kredit. Kode NET::ERR_CERT_AUTHORITY_INVALID tercetak kecil di bawah paragraf itu, dan Edge menampilkan kode yang identik.

Tombol Lanjutan membuka penjelasan tambahan. Untuk kode −202, isinya berbunyi seperti ini:

Server ini tidak dapat membuktikan bahwa ini adalah [nama situs]; sertifikat keamanannya tidak dipercaya oleh sistem operasi komputer Anda.

Di bawahnya biasanya ada tautan "Lanjutkan ke [nama situs] (tidak aman)".

Dua hal di layar ini sering terlewat. Pertama, kalimat "tidak dipercaya oleh sistem operasi" sebenarnya kurang tepat untuk Chrome modern, karena Chrome desktop sudah memakai daftar penerbitnya sendiri (dibahas di section berikutnya). Kedua, kode error itu bisa diklik. Klik sekali, dan Chrome menampilkan kolom Subject (pemilik sertifikat), Issuer (penerbitnya), Expires on, Current date, dan seluruh rantai sertifikat dalam format teks. Kolom Issuer itulah alat diagnosis tercepat yang Anda punya.

Kalau situsnya memakai HSTS (HTTP Strict Transport Security, aturan yang mewajibkan browser selalu memakai HTTPS untuk domain itu), tautan "Lanjutkan" tidak ada sama sekali. Chrome hanya menulis bahwa Anda tidak dapat mengunjungi situs itu sekarang karena situs menggunakan HSTS. Aturan ini dijelaskan di artikel HTTPS.

Di Chrome berbahasa Inggris, judul yang sama berbunyi "Your connection is not private", dengan kode di bawahnya yang tidak berubah. Penerbit yang tidak dikenal juga ditolak Safari dan Firefox, masing-masing dengan judulnya sendiri. Safari menulis "This Connection Is Not Private", sedangkan Firefox berbahasa Inggris menampilkan "Warning: Potential Security Risk Ahead".

Daftar Penerbit yang Dipakai Chrome, Edge, dan Firefox

Sejak Chrome 108 di Windows dan macOS, Chrome tidak lagi meminjam daftar sertifikat akar dari sistem operasi. Chrome membawa daftarnya sendiri bernama Chrome Root Store. Di Linux dan ChromeOS daftar ini aktif sejak Chrome 114, dan di Android sejak Chrome 115. Chrome di iOS menjadi pengecualian, karena kebijakan Apple mewajibkan semua browser di iPhone memakai verifikasi milik sistem.

Perubahan ini punya dua akibat praktis. Chrome di Windows lama yang sudah jarang diperbarui tetap mengenal CA baru, selama versi Chrome-nya masih mendapat pembaruan. Sebaliknya, keputusan Google mencabut kepercayaan pada sebuah CA langsung berlaku di Chrome, tanpa menunggu Microsoft atau Apple.

Chrome tetap menghormati sertifikat akar yang ditambahkan secara lokal. Di Windows, sertifikat di store "Trusted Root Certification Authorities" ikut dipercaya, dan di macOS sertifikat yang ditandai "Always Trust" di Keychain. Inilah jalur yang dipakai antivirus dan kantor untuk memeriksa lalu lintas HTTPS. Satu catatan teknis: untuk koneksi QUIC (dasar HTTP/3), Chrome hanya memakai keputusan lokal untuk mencabut kepercayaan, bukan menambahkannya.

Microsoft Edge memakai mesin verifikasi yang sama, tetapi sejak Edge 109 daftarnya berasal dari program sertifikat akar Microsoft. Firefox berjalan dengan daftar sendiri lagi, yang dikelola Mozilla. Karena itu situs yang sama bisa gagal di Chrome tetapi terbuka di Firefox, atau sebaliknya. Firefox juga tidak memakai kode Chrome; padanannya adalah SEC_ERROR_UNKNOWN_ISSUER, atau MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT untuk sertifikat yang ditandatangani sendiri.

Kenapa ERR_CERT_AUTHORITY_INVALID Muncul Walau Sertifikat Kedaluwarsa

Satu sertifikat bisa punya beberapa cacat sekaligus: penerbitnya asing, masa berlakunya habis, dan namanya tidak cocok. Chrome mencatat semua cacat itu, tetapi layar peringatan hanya menampilkan satu kode. Fungsi MapCertStatusToNetError() di kode sumber Chromium memilih kode dengan urutan tetap, dan komentarnya menyebut aturannya terang-terangan: laporkan error yang paling serius.

Di urutan itu, penerbit yang tidak dikenal berada di atas nama yang tidak cocok dan masa berlaku yang habis. Kami mengujinya pada 23 September 2026 dengan Chrome 153 dan pencatatan jaringan (--log-net-log) terhadap empat subdomain server uji publik badssl.com:

Baris ketiga menarik. Sertifikat expired.badssl.com berakhir April 2015, dan rantainya berujung di sertifikat akar AddTrust yang sudah kedaluwarsa sejak Mei 2020. Log Chrome mencatat dua cacat sekaligus (nilai cert_status 6, gabungan tanggal dan penerbit), tetapi yang tampil tetap −202.

Urutan ini membawa dua akibat yang perlu Anda ketahui. Sertifikat yang hanya kedaluwarsa, atau jam komputer yang salah, menghasilkan kode lain: NET::ERR_CERT_DATE_INVALID. Untuk jam yang salah, Chrome bahkan memakai layar khusus berjudul "Kesalahan jam". Selain itu, setelah masalah penerbit beres, cacat berikutnya bisa muncul sebagai kode baru. Itu tanda perbaikan Anda berhasil satu lapis, bukan gagal.

Membaca Penyebab ERR_CERT_AUTHORITY_INVALID dari Nama Penerbit

Nama di kolom Issuer hampir selalu cukup untuk menebak penyebab ERR_CERT_AUTHORITY_INVALID sekaligus pihak yang harus bertindak. Klik kode error di layar peringatan seperti dijelaskan sebelumnya, lalu cocokkan nilainya dengan pola berikut:

Kalau Issuer berisi nama CA publik yang wajar, seperti Let's Encrypt, Sectigo, atau DigiCert, curigai perangkat atau jaringan Anda lebih dulu. Situs dengan penerbit normal jarang memunculkan kode ini di semua perangkat sekaligus.

Penyebab ERR_CERT_AUTHORITY_INVALID di Perangkat Pengunjung

Situs yang terbuka normal di perangkat lain menandakan penerbit pengganti muncul di perangkat atau jaringan Anda. Penerbit pengganti itu hampir selalu datang dari salah satu sumber berikut:

1. Antivirus yang memeriksa HTTPS: ESET, Kaspersky, Avast, dan sejenisnya menjadi penerbit pengganti untuk setiap situs yang Anda buka, memakai sertifikat akar yang mereka pasang sendiri. Akar itu bisa rusak, tidak ikut terpasang di browser yang Anda pakai, atau tertinggal setelah antivirusnya dicopot. Akibatnya semua situs HTTPS tampak diterbitkan pihak yang tidak dikenal.
2. Proxy kantor atau sekolah: jaringan yang memeriksa HTTPS mewajibkan sertifikat akarnya terpasang di setiap perangkat. Laptop pribadi yang dibawa ke jaringan itu tidak memilikinya. Konsep proxy ini sama dengan yang dipakai banyak perusahaan untuk menyaring akses.
3. Wi-Fi publik yang belum login: hotel, kafe, dan bandara mencegat permintaan pertama Anda dan mengarahkannya ke halaman login. Untuk alamat HTTPS, pencegatan ini tampil sebagai sertifikat yang salah. Chrome kadang mengenalinya dan menampilkan layar yang meminta Anda masuk ke jaringan itu lebih dulu, tetapi tidak selalu.
4. Aplikasi VPN dengan fitur pelindung web: sebagian aplikasi VPN ikut membuka HTTPS untuk memblokir iklan atau situs berbahaya, dengan mekanisme yang sama seperti antivirus.
5. HP Android lama: sertifikat akar ISRG Root X1 milik Let's Encrypt baru dikenal Android 7.1.1. Perangkat yang lebih lama bergantung pada tanda tangan silang yang berakhir 30 September 2024. HP yang tertahan di Chrome versi sebelum 115 masih memakai daftar sistem, sehingga menolak situs yang memakai Let's Encrypt. Chrome 119 sendiri adalah versi terakhir untuk Android 7.

Pola pertama dan kedua punya ciri khas: error muncul di banyak situs sekaligus, termasuk situs besar yang pasti sertifikatnya benar. Kalau hanya satu situs yang bermasalah, kemungkinan besar penyebabnya ada di situs itu.

Cara Mengatasi ERR_CERT_AUTHORITY_INVALID sebagai Pengunjung

Urutan langkah di bawah dimulai dari yang tidak mengubah setelan apa pun. Berhentilah begitu penyebabnya jelas.

Langkah #1: Uji silang perangkat dan jaringan

Buka situs yang sama dari dua jalur berbeda: perangkat lain di jaringan yang sama, lalu perangkat Anda sendiri lewat paket data HP. Empat kemungkinan hasilnya langsung mempersempit masalah:

• Gagal di semua kombinasi: masalah ada di server situs. Anda cukup memberi tahu pengelolanya.
• Gagal hanya di jaringan tertentu: penyebabnya proxy kantor atau Wi-Fi yang mencegat.
• Gagal hanya di perangkat Anda: penyebabnya antivirus, VPN, atau usia perangkat.
• Berhasil di semua kombinasi sekarang: kemungkinan besar Wi-Fi sebelumnya belum login.

Langkah #2: Baca kolom Issuer

Klik kode NET::ERR_CERT_AUTHORITY_INVALID di layar peringatan dan catat isi Issuer. Cocokkan dengan tabel pola penerbit di atas. Nama antivirus atau perangkat keamanan kantor di kolom itu sudah menjawab siapa yang menyisip di tengah jalan.

Langkah #3: Selesaikan login Wi-Fi publik

Buka alamat yang dipastikan tanpa HTTPS, misalnya http://neverssl.com, supaya halaman login jaringan bisa tampil. Setelah login, muat ulang situs tujuan. Kalau jaringan itu sudah Anda percaya tetapi masih menukar sertifikat semua situs setelah login, sebaiknya jangan dipakai untuk membuka akun penting.

Langkah #4: Atur pemeriksaan HTTPS antivirus atau VPN

Buka setelan antivirus, cari fitur bernama semacam SSL/TLS filtering, HTTPS scanning, atau Web Shield, lalu matikan sementara dan muat ulang halaman. Kalau error hilang, jangan biarkan fitur itu mati permanen. Perbarui antivirusnya, atau pasang ulang supaya sertifikat akarnya ikut terpasang kembali dengan benar. Untuk VPN, matikan fitur pelindung web atau pemblokir iklannya, bukan seluruh VPN.

Langkah #5: Perbarui sistem, atau pakai browser dengan daftar sendiri

Di komputer, perbarui Chrome atau Edge ke versi terbaru supaya daftar penerbitnya ikut mutakhir. Untuk HP Android 7.0 ke bawah yang tidak bisa diperbarui lagi, Let's Encrypt sendiri menyarankan Firefox. Firefox membawa daftar penerbit sendiri yang sudah mengenal ISRG Root X1.

Saran Perbaikan yang Tidak Menyentuh Penerbit

Beberapa saran populer untuk error ini tidak ada hubungannya dengan verifikasi penerbit. Mengenali batasnya menghemat waktu Anda:

1. Menghapus cache dan cookie: Chrome memverifikasi sertifikat ulang pada setiap koneksi baru, dan hasil verifikasi tidak disimpan di cache halaman. Menghapus cache tidak mengubah penerbit yang disodorkan server.
2. "Clear SSL state" di Internet Options Windows: tombol ini mengosongkan cache sesi milik komponen jaringan Windows. Chrome dan Edge memakai tumpukan jaringan dan cache TLS sendiri, jadi tombol itu tidak menyentuh keduanya.
3. Mengganti DNS atau flush DNS: DNS hanya menentukan ke server mana browser tersambung. Selama servernya sama, sertifikat yang dikirim juga sama. Pengecualiannya satu: DNS yang sebelumnya diarahkan ke server pencegat. Menggantinya memang bisa menghilangkan error, tetapi itu tanda ada masalah lain yang lebih serius di jaringan Anda.
4. Mengatur jam komputer: jam yang salah menghasilkan ERR_CERT_DATE_INVALID dengan layar "Kesalahan jam", bukan kode ini.

Mematikan ekstensi browser juga jarang berpengaruh. Ekstensi Chrome tidak bisa mengganti sertifikat server; yang bisa melakukannya adalah program yang berjalan di luar browser, seperti antivirus dan VPN.

ERR_CERT_AUTHORITY_INVALID di Website Anda Sendiri

Laporan dari berbagai perangkat dan jaringan sekaligus menunjuk ke sertifikat yang dipasang di server Anda. Sertifikat itu hampir selalu jatuh ke salah satu kelompok berikut:

1. Sertifikat bawaan belum diganti: panel seperti cPanel memasang sertifikat self-signed sementara sampai AutoSSL berhasil menerbitkan sertifikat sungguhan. AutoSSL gagal kalau domain belum mengarah ke server, misalnya karena DNS baru saja dipindah.
2. Sertifikat staging Let's Encrypt: certbot dengan opsi --staging atau --test-cert menerbitkan sertifikat dari akar uji seperti "(STAGING) Pretend Pear X1". Let's Encrypt menegaskan akar ini tidak ada di daftar kepercayaan browser mana pun. Opsi ini sering terbawa dari sesi percobaan ke server produksi.
3. Cloudflare Origin CA yang terbuka: sertifikat Origin CA hanya mengenkripsi jalur antara Cloudflare dan server Anda. Dokumentasi Cloudflare memperingatkan bahwa pengunjung akan melihat error sertifikat kalau Cloudflare di-pause atau proxy subdomain dimatikan (awan abu-abu).
4. CA yang dicabut kepercayaannya: Chrome 131 berhenti memercayai sertifikat Entrust yang terbit setelah 11 November 2024. Chrome 139 melakukan hal yang sama untuk sertifikat Chunghwa Telecom dan Netlock yang terbit setelah 31 Juli 2025. Sertifikat lama dari CA tersebut tetap dipercaya sampai habis masanya.
5. CA internal: aplikasi internal yang ditandatangani CA perusahaan akan selalu memunculkan error ini di perangkat yang tidak dikelola perusahaan.

Satu kasus yang sering dikira penyebab tetapi jarang memicu kode ini di Chrome adalah rantai yang tidak lengkap. Chrome mengunduh sendiri sertifikat perantara yang hilang, dan server uji incomplete-chain.badssl.com terbuka tanpa error pada pengujian kami. Masalah itu justru mematahkan aplikasi Android dan skrip server, seperti dibahas di artikel chain SSL.

Cara Mengatasi ERR_CERT_AUTHORITY_INVALID di Server

Langkah #1: Periksa penerbit dari luar browser

Perintah openssl s_client menampilkan sertifikat persis seperti yang dikirim server, tanpa campur tangan antivirus di perangkat Anda. Ganti namasitus.com dengan domain Anda:

openssl s_client -showcerts \
  -connect namasitus.com:443 \
  -servername namasitus.com \
  < /dev/null 2>&1 \
  | grep -E '^ +([0-9] s|i):|Verify'

Baris s: adalah pemilik sertifikat, i: penerbitnya. Pada server uji self-signed, keduanya identik dan OpenSSL menutup dengan kode 18:

 0 s:... O=BadSSL, CN=*.badssl.com
   i:... O=BadSSL, CN=*.badssl.com
Verify return code: 18
  (self-signed certificate)

Hasil Verify return code: 19 (self-signed certificate in certificate chain) berarti rantainya lengkap, tetapi berujung di akar yang tidak dikenal. Contohnya CA internal atau akar staging. Keluaran di atas sudah diringkas supaya muat di layar ponsel.

Langkah #2: Terbitkan sertifikat dari CA publik

Di hosting berbasis cPanel, buka menu SSL/TLS Status lalu jalankan Run AutoSSL, setelah memastikan domain sudah mengarah ke server. Langkah demi langkah untuk hosting Indowebsite ada di panduan cara install SSL gratis. Untuk situs bisnis yang membutuhkan validasi organisasi atau garansi, gunakan sertifikat SSL dari CA komersial.

Di VPS dengan certbot, terbitkan ulang tanpa opsi staging:

sudo certbot certonly --force-renewal \
  -d namasitus.com -d www.namasitus.com

Tanpa --force-renewal, certbot melihat sertifikat staging yang belum mendekati habis masa berlakunya dan hanya menawarkan untuk mempertahankannya. Tambahkan opsi --webroot atau --nginx sesuai cara Anda memvalidasi domain sebelumnya.

Langkah #3: Kembalikan proxy Cloudflare, atau ganti sertifikatnya

Kalau server memakai Origin CA, pilih salah satu. Nyalakan kembali proxy (awan oranye) untuk setiap record yang mengarah ke server itu. Atau, kalau subdomain itu memang harus diakses langsung, pasang sertifikat dari CA publik di server sebagai pengganti Origin CA.

Langkah #4: Pasang berkas rantai lengkap, lalu muat ulang layanan

Arahkan konfigurasi web server ke berkas yang berisi sertifikat beserta perantaranya (fullchain.pem untuk certbot), bukan cert.pem saja. Setelah itu muat ulang layanannya, misalnya sudo systemctl reload nginx. Sertifikat baru tidak dipakai sampai layanan dimuat ulang.

Langkah #5: Verifikasi dari luar jaringan Anda

Jalankan lagi perintah di Langkah #1 dan pastikan hasilnya Verify return code: 0 (ok). Buka juga situsnya di jendela incognito lewat paket data HP. Jendela incognito tidak membawa keputusan "Lanjutkan" yang mungkin pernah Anda klik sebelumnya.

ERR_CERT_AUTHORITY_INVALID di Localhost dan Jaringan Internal

Pengembang sering bertemu ERR_CERT_AUTHORITY_INVALID di localhost, karena CA publik tidak menerbitkan sertifikat untuk nama tersebut. Solusi yang rapi adalah membuat CA lokal milik Anda sendiri, lalu memasangnya ke daftar kepercayaan komputer itu saja. Alat mkcert melakukannya dengan dua perintah:

mkcert -install
mkcert localhost 127.0.0.1 ::1

Perintah pertama membuat CA lokal dan memasangnya ke daftar sistem, Firefox, dan Java bila ada. Perintah kedua menerbitkan sertifikat untuk tiga alamat localhost. Untuk menguji di HP, sertifikat akarnya harus dipasang manual di perangkat tersebut.

Perhatikan berkas rootCA-key.pem yang dibuat mkcert. Dokumentasinya sendiri memperingatkan bahwa berkas itu memberi kuasa penuh untuk menyadap koneksi aman di komputer yang memercayai CA tersebut. Jangan pernah membagikannya atau menyimpannya di repositori.

Halaman admin router, NAS, dan server virtualisasi di jaringan rumah juga memakai sertifikat self-signed. Chromium sudah menyiapkan kode khusus untuk kasus ini (ERR_CERT_SELF_SIGNED_LOCAL_NETWORK, −219), tetapi fiturnya belum aktif secara bawaan. Jadi perangkat semacam itu masih tampil sebagai −202. Untuk perangkat yang Anda kelola sendiri dan akses setiap hari, mengganti sertifikatnya dengan terbitan CA lokal lebih aman daripada membiasakan diri mengeklik "Lanjutkan".

Melewati ERR_CERT_AUTHORITY_INVALID: Kapan Boleh dan Kapan Tidak

Tautan "Lanjutkan ke [nama situs] (tidak aman)" memang melewati (bypass) peringatan. Chrome juga menyimpan frasa tersembunyi, thisisunsafe, yang bila diketik di layar peringatan akan melewati halaman itu, termasuk layar HSTS yang tidak punya tautan. Komentar di kode sumber Chromium tepat di atas fitur itu menegaskan bahwa error HTTPS itu serius dan tidak seharusnya diabaikan. Untuk keperluan pengujian, menurut komentar yang sama, ada cara lain yang lebih aman.

Melewati peringatan masih wajar pada tiga keadaan. Pertama, perangkat milik Anda sendiri di jaringan rumah. Kedua, server pengembangan yang sertifikatnya Anda buat sendiri. Ketiga, pengujian singkat yang tidak melibatkan data rahasia.

Jangan pernah melewatinya untuk halaman login, perbankan, pembayaran, email, atau situs mana pun yang meminta data pribadi. Pada situs publik, error ini adalah satu-satunya tanda yang Anda dapat saat seseorang menyisip di tengah koneksi. Setelah Anda mengeklik "Lanjutkan", Chrome mengingat keputusan itu selama satu minggu dan tidak lagi memperingatkan untuk situs tersebut. Kesalahan satu kali bisa berulang tanpa terasa.

Pertimbangan Sebelum Memperbaiki ERR_CERT_AUTHORITY_INVALID

Setiap perbaikan di atas membawa konsekuensi yang sebaiknya Anda timbang lebih dulu:

1. Mematikan pemeriksaan HTTPS antivirus mengurangi perlindungan: antivirus kehilangan kemampuan memindai unduhan dan halaman berbahaya yang lewat HTTPS. Memperbaiki sertifikat akarnya lebih baik daripada mematikan fiturnya.
2. Memasang sertifikat akar berarti memberi kuasa menyadap: CA yang Anda tambahkan ke daftar kepercayaan dapat menerbitkan sertifikat untuk situs apa saja di perangkat itu. Pasang hanya dari pihak yang Anda kenal, seperti admin TI kantor atau CA lokal buatan sendiri.
3. Origin CA mengikat Anda ke proxy Cloudflare: sertifikat ini praktis karena gratis dan sekali pasang. Namun setiap kali proxy dimatikan untuk keperluan diagnosis, pengunjung langsung melihat error.
4. Sertifikat gratis butuh perpanjangan otomatis: sertifikat Let's Encrypt berlaku 90 hari. Pastikan tugas perpanjangan certbot atau AutoSSL berjalan, karena perpanjangan yang gagal akan menghasilkan ERR_CERT_DATE_INVALID beberapa bulan kemudian.

Pertanyaan Seputar ERR_CERT_AUTHORITY_INVALID

Bagaimana cara menghilangkan "Your connection is not private"?

Lihat dulu kode di bawah judulnya, karena judul yang sama dipakai Chrome untuk beberapa masalah berbeda. Kode ERR_CERT_AUTHORITY_INVALID diselesaikan dengan langkah di artikel ini. Kode ERR_CERT_DATE_INVALID menunjuk jam perangkat atau sertifikat yang habis masa berlakunya, sedangkan ERR_CERT_COMMON_NAME_INVALID berarti nama di sertifikat tidak cocok dengan alamat yang dibuka. Mengeklik "Lanjutkan" hanya menyembunyikan layarnya selama seminggu, bukan menghilangkan penyebabnya.

Bagaimana cara mengatasi sertifikat SSL yang tidak valid?

Dari sisi pemilik situs, "tidak valid" hampir selalu berarti salah satu dari tiga hal. Penerbitnya tidak dipercaya, masa berlakunya habis, atau namanya tidak mencakup alamat yang dibuka. Perintah openssl s_client di section perbaikan server bisa membedakannya. Baris i: menunjukkan penerbit, dan Verify return code: 10 berarti kedaluwarsa. Tambahkan opsi -verify_hostname namasitus.com untuk memeriksa nama; kode 62 berarti namanya tidak cocok. Setelah penyebabnya jelas, perbaikannya hampir selalu sama: terbitkan ulang sertifikat dari CA publik untuk semua nama yang dipakai, lalu pasang berkas rantai lengkapnya.

Apakah error ini berarti situsnya diretas?

Umumnya tidak. Kasus terbanyak adalah sertifikat yang salah pasang di server, atau program di perangkat Anda yang memeriksa HTTPS. Namun Anda tidak bisa membedakan keduanya dari layar peringatan saja, sehingga sikap yang aman tetap sama: jangan memasukkan data apa pun sebelum penyebabnya jelas.

Kenapa error ini hanya muncul saat memakai Wi-Fi kantor?

Jaringan kantor itu kemungkinan besar memeriksa lalu lintas HTTPS dan menerbitkan ulang sertifikat setiap situs. Perangkat milik kantor sudah dipasangi sertifikat akarnya, sementara perangkat pribadi tidak. Tanyakan kepada admin jaringan apakah perangkat pribadi boleh dipasangi sertifikat tersebut, atau gunakan paket data untuk keperluan pribadi.

Apakah Microsoft Edge menampilkan kode yang sama?

Kodenya sama, karena Edge dibangun di atas Chromium. Bedanya ada di daftar penerbit: sejak Edge 109, Edge memakai daftar dari program sertifikat akar Microsoft, bukan Chrome Root Store. Hasilnya bisa berbeda pada CA yang baru dicabut kepercayaannya oleh salah satu pihak saja.

Apakah sertifikat gratis lebih sering memicu error ini?

Tidak. ISRG Root X1 milik Let's Encrypt ada di daftar Chrome, Edge, Firefox, dan Safari, sama seperti akar CA berbayar. Error pada sertifikat gratis hampir selalu berasal dari cara pemasangannya — sertifikat staging, AutoSSL yang belum berhasil, atau perpanjangan yang gagal — bukan dari penerbitnya. Yang membedakan sertifikat berbayar adalah jenis validasi dan garansinya.

Kenapa error muncul lagi seminggu setelah saya mengeklik "Lanjutkan"?

Chrome menyimpan keputusan melewati error sertifikat selama tepat satu minggu (604.800 detik di kode sumbernya). Sesudah itu peringatan tampil kembali, karena Chrome menganggap keadaan bisa saja sudah berubah. Kalau errornya selalu kembali, berarti sertifikat situs itu memang belum diperbaiki.

Kesimpulan

ERR_CERT_AUTHORITY_INVALID artinya Chrome tidak mengenal penerbit sertifikat situs, dan kode ini mengalahkan cacat lain seperti masa berlaku habis atau nama yang tidak cocok. Karena hanya ada satu pertanyaan yang dijawabnya, cara tercepat menemukan penyebabnya adalah mengeklik kode error lalu membaca kolom Issuer.

Nama antivirus, proxy kantor, atau Wi-Fi publik di kolom itu berarti masalahnya ada di sisi pengunjung. Sertifikat self-signed, staging, Origin CA, atau CA yang dicabut kepercayaannya berarti pemilik server yang harus bertindak. Melewati peringatan hanya pantas untuk perangkat dan server milik Anda sendiri, tidak pernah untuk situs yang meminta data pribadi.

Semoga artikel ini membantu.