Cara Memperbaiki Error NET::ERR_CERT_AUTHORITY_INVALID

NET::ERR_CERT_AUTHORITY_INVALID adalah kegagalan TLS handshake di tingkat browser yang terjadi ketika sertifikat yang disajikan oleh server web tidak dapat ditelusuri kembali ke Certificate Authority (CA) root yang dipercaya oleh trust store bawaan browser. Browser menghentikan koneksi sebelum data apa pun dipertukarkan, menampilkan error ini untuk mencegah paparan terhadap serangan man-in-the-middle (MITM), intersepsi data, atau lalu lintas dari server palsu.

Ini bukan sekadar peringatan kosmetik. Ini adalah kegagalan verifikasi kriptografi yang serius. Browser telah memeriksa rantai sertifikat, mencoba memvalidasi setiap tautan hingga ke root yang dipercaya, dan menemukan rantai tersebut rusak, tidak ada, atau tidak valid secara kriptografi. Memahami dengan tepat di mana rantai tersebut putus adalah perbedaan antara perbaikan lima menit dan berjam-jam kesalahan diagnosis.

Apa yang Sebenarnya Memicu Error Ini

Sebagian besar dokumentasi mencantumkan penyebab di tingkat permukaan. Gambaran sebenarnya lebih bernuansa, dan setiap akar penyebab memerlukan jalur remediasi yang berbeda.

Sertifikat Self-Signed

Sertifikat self-signed adalah sertifikat di mana penerbit dan subjeknya identik — server menandatangani sertifikatnya sendiri alih-alih meminta CA tepercaya untuk menandatanganinya. Ini adalah standar di lingkungan pengembangan lokal, server staging internal, dan infrastruktur privat. Tidak ada trust store browser publik yang mengenalinya, sehingga validasi rantai langsung gagal.

Nuansa penting: Bahkan jika Anda menambahkan sertifikat self-signed ke trust store OS Anda, beberapa browser (terutama Chrome di platform tertentu) menggunakan penyimpanan sertifikat mereka sendiri dan tetap akan menolaknya kecuali dikonfigurasi secara eksplisit.

Sertifikat SSL/TLS Kedaluwarsa

Setiap sertifikat memiliki kolom `notBefore` dan `notAfter` yang dikodekan dalam struktur X.509-nya. Setelah jam sistem melewati timestamp `notAfter`, sertifikat tersebut tidak valid secara kriptografi terlepas dari bagaimana sertifikat itu diterbitkan. Browser menerapkan ini secara ketat.

Kasus tepi: Jika jam server Anda maju secara signifikan, sertifikat yang secara teknis masih valid mungkin tampak kedaluwarsa bagi server itu sendiri selama negosiasi TLS handshake, menyebabkan error ini dari sisi server daripada sisi klien.

Rantai Sertifikat Tidak Lengkap (Intermediate CA Hilang)

Ini adalah penyebab yang paling sering salah didiagnosis di lingkungan produksi. CA root tepercaya tidak langsung menandatangani sertifikat end-entity. CA root menandatangani CA intermediate, yang kemudian menandatangani sertifikat Anda. Saat Anda menginstal sertifikat SSL di server, Anda harus menginstal rantai penuh: sertifikat end-entity Anda ditambah semua sertifikat intermediate yang digabungkan secara berurutan.

Jika intermediate tidak ada dalam respons TLS server, sebagian besar browser tidak dapat menyelesaikan penelusuran rantai ke root tepercaya. Firefox agak lebih toleran di sini karena menyimpan cache intermediate dari sesi sebelumnya (pengambilan AIA), tetapi Chrome dan Edge akan gagal total.

Cara memverifikasi: Jalankan `openssl s_client -connect yourdomain.com:443 -showcerts` dan periksa apakah rantai penuh dikembalikan.

Ketidakcocokan Common Name atau SAN Sertifikat

Jika sertifikat diterbitkan untuk `www.example.com` tetapi pengguna mengakses `example.com` (atau subdomain yang tidak dicakup oleh wildcard), browser akan memunculkan error yang terkait tetapi berbeda. Namun, dalam beberapa konfigurasi ini termanifestasi sebagai error authority invalid daripada error name mismatch, terutama dengan format sertifikat lama yang tidak memiliki Subject Alternative Names (SAN).

Penyimpangan Jam di Sisi Klien

Sertifikat TLS dibatasi waktu. Jika jam mesin klien diatur ke tanggal sebelum kolom `notBefore` sertifikat atau setelah kolom `notAfter`-nya, browser akan menolaknya. Ini sangat umum terjadi pada mesin virtual, server yang baru disediakan, atau mesin yang telah dimatikan untuk waktu lama tanpa sinkronisasi NTP.

Inspeksi SSL oleh Perangkat Lunak Keamanan

Firewall perusahaan, suite keamanan endpoint, dan beberapa produk antivirus melakukan inspeksi SSL/TLS (juga disebut intersepsi HTTPS). Mereka mengakhiri koneksi TLS di appliance keamanan, memeriksa teks biasa, lalu mengenkripsinya kembali menggunakan sertifikat yang dibuat secara dinamis yang ditandatangani oleh CA appliance itu sendiri. Jika CA appliance tersebut tidak ada di trust store browser, setiap situs HTTPS akan memicu error ini.

Root Certificate Store yang Kedaluwarsa

Pada sistem operasi yang lebih lama (Windows 7 tanpa pembaruan, distribusi Linux lama), bundel CA root sistem mungkin tidak menyertakan sertifikat root yang lebih baru. ISRG Root X1 milik Let’s Encrypt, misalnya, menyebabkan error yang meluas di Android 7 ke bawah dan pada sistem Windows yang tidak ditambal ketika cross-signature DST Root CA X3 kedaluwarsa pada September 2021.

Perbandingan Akar Penyebab

Perbaikan Langkah demi Langkah

Langkah 1: Sinkronkan Tanggal dan Waktu Sistem

Ini adalah perbaikan tercepat ketika error muncul tiba-tiba pada mesin yang sebelumnya berfungsi.

Windows:

1. Buka Settings > Time & Language > Date & time.
2. Aktifkan Set time automatically dan Set time zone automatically.
3. Klik Sync now di bawah “Synchronize your clock.”
4. Jika sinkronisasi otomatis gagal, buka Command Prompt sebagai Administrator dan jalankan: `w32tm /resync /force`

macOS:

1. Buka System Settings > General > Date & Time.
2. Aktifkan Set time and date automatically dan pilih server NTP terdekat (misalnya, `time.apple.com`).
3. Jika masalah berlanjut, jalankan di Terminal: `sudo sntp -sS time.apple.com`

Linux (server atau desktop):

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

Setelah menyinkronkan, mulai ulang browser dan coba lagi.

Langkah 2: Hapus Cache Browser, Cookie, dan Sertifikat yang Di-cache

Browser menyimpan cache kebijakan HSTS (HTTP Strict Transport Security) dan data sertifikat. Entri cache yang usang dapat mempertahankan error bahkan setelah masalah yang mendasarinya diselesaikan.

Google Chrome:

1. Navigasi ke `chrome://settings/clearBrowserData`.
2. Atur rentang waktu ke All time.
3. Centang Cookies and other site data dan Cached images and files.
4. Klik Clear data.

Untuk menghapus cache khusus HSTS di Chrome, navigasi ke `chrome://net-internals/#hsts`, masukkan domain di bawah “Delete domain security policies,” dan klik Delete.

Mozilla Firefox:

1. Buka Settings > Privacy & Security.
2. Di bawah Cookies and Site Data, klik Clear Data.
3. Hapus juga Cached Web Content.

Microsoft Edge:

1. Navigasi ke `edge://settings/clearBrowserData`.
2. Pilih All time dan hapus data cache dan cookie.

Langkah 3: Identifikasi dan Nonaktifkan Inspeksi SSL

Jika Anda berada di jaringan perusahaan atau menggunakan produk keamanan endpoint, inspeksi SSL adalah tersangka utama.

1. Klik ikon gembok (atau ikon peringatan) di bilah alamat browser.
2. Periksa detail sertifikat. Jika penerbitnya adalah vendor antivirus Anda (misalnya, “Avast Root,” “Kaspersky Anti-Virus,” “ESET SSL Filter CA”) daripada CA publik seperti DigiCert, Let’s Encrypt, atau Sectigo, inspeksi SSL sedang aktif.
3. Di pengaturan antivirus atau firewall Anda, temukan HTTPS scanning, SSL filtering, atau Web Shield dan nonaktifkan.
4. Atau, tambahkan sertifikat CA root appliance ke trust store browser Anda.

Jangan nonaktifkan perangkat lunak keamanan Anda secara permanen. Aktifkan kembali setelah pengujian, atau konfigurasikan untuk mengecualikan domain tepercaya tertentu.

Langkah 4: Verifikasi dan Perbaiki Rantai Sertifikat Sisi Server (Administrator Server)

Ini adalah perbaikan yang tepat untuk situs web produksi di mana pengunjung melihat error tersebut.

Diagnosis rantai:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Issuer:|Subject:"

“`

Atau gunakan inspeksi rantai penuh:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts

“`

Hitung sertifikat yang dikembalikan. Anda seharusnya melihat setidaknya dua (end-entity + intermediate). Jika hanya satu yang muncul, intermediate tidak ada.

Perbaikan di Apache (`httpd.conf` atau file virtual host):

“`apache

SSLCertificateFile /etc/ssl/certs/yourdomain.crt

SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

“`

Perbaikan di Nginx (`nginx.conf` atau blok server):

Nginx mengharuskan rantai penuh digabungkan ke dalam satu file:

“`bash

cat yourdomain.crt intermediate.crt > fullchain.pem

“`

Kemudian referensikan:

“`nginx

ssl_certificate /etc/ssl/certs/fullchain.pem;

ssl_certificate_key /etc/ssl/private/yourdomain.key;

“`

Setelah mengedit, selalu uji konfigurasi sebelum memulai ulang:

“`bash

Apache

apachectl configtest

Nginx

nginx -t

“`

Kemudian muat ulang layanan:

“`bash

sudo systemctl reload apache2

or

sudo systemctl reload nginx

“`

Jika Anda menjalankan lingkungan terkelola, VPS dengan cPanel menyediakan antarmuka GUI di bawah SSL/TLS Manager di mana Anda dapat menempelkan sertifikat, kunci privat, dan bundel CA langsung tanpa menyentuh file konfigurasi secara manual.

Langkah 5: Perbarui atau Ganti Sertifikat yang Kedaluwarsa

Jika sertifikat telah kedaluwarsa, tidak ada solusi sisi klien. Server harus menyajikan sertifikat yang valid.

Untuk Let’s Encrypt (Certbot):

“`bash

sudo certbot renew –dry-run

sudo certbot renew

sudo systemctl reload nginx # or apache2

“`

Untuk sertifikat yang dikelola secara manual: Dapatkan sertifikat baru dari CA Anda, unggah melalui panel kontrol Anda, dan pastikan rantai sertifikat baru lengkap. Jika Anda memerlukan sertifikat tepercaya untuk domain produksi, SSL Certificates dari CA yang diakui menghilangkan masalah sertifikat self-signed sepenuhnya.

Otomatiskan pembaruan: Sertifikat Let’s Encrypt kedaluwarsa setiap 90 hari. Tambahkan cron job atau gunakan systemd timer untuk mengotomatiskan pembaruan:

“`bash

0 3 * * * /usr/bin/certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Langkah 6: Percayai Sertifikat Self-Signed untuk Penggunaan Internal

Jika Anda menjalankan alat internal, server pengembangan, atau layanan jaringan privat di mana penggantian sertifikat tidak memungkinkan, Anda dapat menambahkan sertifikat self-signed ke trust store OS.

Windows:

1. Ekspor sertifikat dari browser (klik peringatan > Certificate > Details > Copy to File).
2. Buka `certmgr.msc`.
3. Navigasi ke Trusted Root Certification Authorities > Certificates.
4. Klik kanan > All Tasks > Import dan impor sertifikat.

macOS:

“`bash

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.crt

“`

Linux (Debian/Ubuntu):

“`bash

sudo cp cert.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

“`

Penting: Chrome di Linux dan Windows menggunakan trust store OS untuk sebagian besar keperluan, tetapi juga mempertahankan database NSS-nya sendiri. Jika Chrome masih menolak sertifikat setelah memperbarui penyimpanan OS, impor langsung melalui `chrome://settings/certificates`.

Langkah 7: Perbarui Browser dan Sistem Operasi

Browser yang kedaluwarsa mungkin tidak memiliki sertifikat CA root yang lebih baru atau mungkin tidak mendukung versi protokol TLS saat ini (minimum TLS 1.2 kini diperlukan; TLS 1.3 lebih disukai).

Chrome: Navigasi ke `chrome://settings/help`. Chrome diperbarui secara otomatis; jika ada pembaruan yang tertunda, pembaruan akan diinstal di sini.

Firefox: Navigasi ke Help > About Firefox. Firefox akan memeriksa dan menerapkan pembaruan.

Sistem Operasi: Di Windows, pastikan Windows Update sudah terkini. Di server Linux, jalankan:

“`bash

sudo apt update && sudo apt upgrade ca-certificates openssl

“`

Ini sangat penting untuk server yang menjalankan distribusi lama di mana bundel CA (paket `ca-certificates`) belum diperbarui untuk menyertakan CA root yang lebih baru.

Langkah 8: Reset Network Stack dan Flush DNS

Miskonfigurasi tingkat jaringan, cache DNS yang rusak, atau entri Winsock yang usang terkadang dapat berkontribusi pada kegagalan negosiasi TLS.

Windows (jalankan Command Prompt sebagai Administrator):

“`cmd

netsh int ip reset

netsh winsock reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

“`

Mulai ulang mesin setelah menjalankan perintah-perintah ini.

macOS:

“`bash

sudo dscacheutil -flushcache

sudo killall -HUP mDNSResponder

“`

Linux:

“`bash

sudo systemd-resolve –flush-caches

or for systems using nscd:

sudo service nscd restart

“`

Langkah 9: Lewati Peringatan (Hanya untuk Pengujian)

Ini semata-mata alat diagnostik, bukan solusi. Gunakan hanya untuk mengonfirmasi bahwa error terkait sertifikat dan bukan masalah jaringan atau aplikasi, atau saat mengakses server internal yang diketahui aman selama pengembangan.

Chrome: Klik Advanced di halaman error, lalu Proceed to [domain] (unsafe).

Firefox: Klik Advanced, lalu Accept the Risk and Continue.

Jangan pernah melewati peringatan ini di situs yang menangani autentikasi, pembayaran, atau data pribadi. Peringatan ada karena koneksi benar-benar tidak terverifikasi.

Memverifikasi Perbaikan

Setelah menerapkan perubahan sisi server apa pun, validasi hasilnya menggunakan alat-alat ini sebelum menyatakan masalah terselesaikan:

• SSL Labs SSL Test (`ssllabs.com/ssltest/`): Memberikan analisis rantai penuh, nilai dukungan protokol, dan mengidentifikasi kelemahan konfigurasi tertentu.
• `openssl s_client`: Verifikasi baris perintah yang menunjukkan dengan tepat apa yang disajikan server selama TLS handshake.
• `curl -vI https://yourdomain.com`: Pemeriksaan cepat yang menampilkan detail TLS handshake dan hasil validasi sertifikat.
• `whatsmychaincert.com`: Secara khusus mendiagnosis sertifikat intermediate yang hilang.

Memilih Infrastruktur Hosting yang Tepat untuk Mencegah Terulangnya Masalah

Banyak error sertifikat berasal dari keterbatasan infrastruktur daripada kesalahan administrator. Lingkungan shared hosting terkadang membatasi cara rantai sertifikat dikonfigurasi atau membatasi akses ke file konfigurasi web server. Jika Anda berulang kali mengalami masalah rantai atau pembaruan, migrasi ke lingkungan VPS Hosting memberi Anda kendali penuh atas stack TLS Anda — termasuk kemampuan untuk mengonfigurasi Nginx atau Apache secara langsung, mengotomatiskan pembaruan Certbot, dan menginstal bundel CA kustom.

Untuk beban kerja lalu lintas tinggi atau yang sensitif terhadap kepatuhan di mana manajemen sertifikat sangat penting, Dedicated Servers menghilangkan variabel multi-tenant yang dapat mempersulit konfigurasi SSL. Jika Anda mengelola beberapa domain atau subdomain, VPS Control Panel menyederhanakan penerapan sertifikat di semua domain tersebut dari satu antarmuka.

Matriks Keputusan: Perbaikan Mana yang Berlaku untuk Situasi Anda

Daftar Periksa Poin Penting Praktis

• Konfirmasi apakah error berasal dari sisi klien (jam, cache, inspeksi SSL) atau sisi server (sertifikat kedaluwarsa, intermediate hilang) sebelum mengambil tindakan apa pun.
• Jalankan `openssl s_client -connect domain:443 -showcerts` sebagai langkah diagnostik pertama untuk investigasi sisi server apa pun.
• Selalu gabungkan rantai sertifikat penuh (end-entity + semua intermediate) dalam konfigurasi web server Anda.
• Otomatiskan pembaruan sertifikat dengan cron job Certbot atau yang setara — pembaruan manual adalah jalan pasti menuju pemadaman di masa depan.
• Setelah perubahan sertifikat apa pun, validasi dengan SSL Labs sebelum menutup insiden.
• Jangan pernah menonaktifkan pemindaian SSL antivirus secara permanen; sebagai gantinya, konfigurasikan pengecualian atau instal sertifikat CA proxy dengan benar.
• Di server Linux, perbarui paket `ca-certificates` dan `openssl` untuk memastikan root store mencerminkan CA tepercaya saat ini.
• Gunakan `chrome://net-internals/#hsts` untuk menghapus entri cache HSTS ketika sertifikat domain telah diubah secara sah dan Chrome masih menolak untuk terhubung.

Pertanyaan yang Sering Diajukan

Apa perbedaan antara NET::ERR_CERT_AUTHORITY_INVALID dan NET::ERR_CERT_COMMON_NAME_INVALID?

`ERR_CERT_AUTHORITY_INVALID` berarti penerbit sertifikat tidak dipercaya — rantai tidak dapat diverifikasi. `ERR_CERT_COMMON_NAME_INVALID` berarti sertifikat berasal dari CA tepercaya tetapi diterbitkan untuk domain yang berbeda dari yang sedang diakses. Keduanya memerlukan perbaikan yang berbeda: yang pertama memerlukan sertifikat baru dari CA tepercaya atau perbaikan rantai; yang kedua memerlukan sertifikat yang diterbitkan ulang dengan Subject Alternative Names yang benar.

Bisakah NET::ERR_CERT_AUTHORITY_INVALID muncul bahkan dengan sertifikat SSL berbayar yang valid?

Ya. Sertifikat berbayar dari CA tepercaya tetap akan memicu error ini jika sertifikat intermediate tidak disertakan dalam respons TLS server. Browser tidak selalu dapat mengambil intermediate yang hilang secara otomatis (pengambilan AIA tidak dapat diandalkan), sehingga rantai harus dikonfigurasi secara eksplisit di server.

Mengapa error ini muncul hanya di Chrome tetapi tidak di Firefox?

Firefox mempertahankan trust store sertifikatnya sendiri dan juga menyimpan cache sertifikat intermediate dari koneksi sukses sebelumnya (mekanisme yang disebut pengambilan AIA dengan caching). Chrome lebih ketat bergantung pada trust store OS dan rantai yang disajikan oleh server. Intermediate yang hilang yang telah di-cache Firefox dari sesi sebelumnya tetap akan menyebabkan Chrome gagal.

Apakah aman mengklik “Proceed anyway” pada peringatan NET::ERR_CERT_AUTHORITY_INVALID?

Hanya dalam skenario terkontrol: mengakses server internal yang diketahui, lingkungan pengembangan lokal, atau server staging yang Anda kelola. Di situs mana pun yang menghadap publik — terutama yang memerlukan kredensial login, informasi pembayaran, atau data pribadi — melanjutkan benar-benar berbahaya. Koneksi tidak terenkripsi dari perspektif kepercayaan, artinya setiap pihak yang mencegat di jalur jaringan dapat membaca atau memodifikasi lalu lintas.

Bagaimana cara mencegah error ini berulang di server produksi saya?

Otomatiskan pembaruan sertifikat (Certbot dengan cron job atau systemd timer), pantau kedaluwarsa sertifikat dengan alat eksternal (UptimeRobot, Zabbix, atau `ssl-cert-check`), selalu terapkan rantai sertifikat penuh, dan jaga sinkronisasi NTP server Anda tetap aktif. Untuk lingkungan di mana manajemen manual rentan terhadap kesalahan, pertimbangkan platform hosting dengan manajemen sertifikat terintegrasi — VPS dengan cPanel menangani pembaruan AutoSSL secara otomatis di semua domain yang dihosting.