Kesalahan SSL: Apa Itu dan Cara Memperbaikinya

Kesalahan SSL adalah yang ditampilkan oleh browser ketika browser tidak dapat membuka koneksi terenkripsi tepercaya ke sebuah situs web. Alih-alih halaman yang Anda minta, Anda akan mendapatkan layar peringatan dan kode singkat dalam huruf kapital kecil, seperti NET::ERR_CERT_AUTHORITY_INVALID atau SSL_ERROR_NO_CYPHER_OVERLAP.

Kode itulah bagian yang berguna, dan sebagian besar panduan justru melewatkannya. “Kesalahan SSL” bukan istilah teknis, dan tidak ada standar yang mendefinisikannya. Itu adalah nama sehari-hari untuk seluruh keluarga kegagalan yang berbeda-beda, itulah sebabnya saran umum seperti membersihkan cache memperbaiki sebagian di antaranya dan sama sekali tidak berpengaruh pada sisanya.

Apa Sebenarnya Arti Kesalahan SSL

Saat Anda memuat alamat yang dimulai dengan https://, browser dan server Anda menjalankan negosiasi singkat yang disebut jabat tangan TLS sebelum konten halaman apa pun dipindahkan. Jabat tangan tersebut menyepakati versi protokol dan sekumpulan algoritma enkripsi, dan server membuktikan identitasnya dengan sertifikat. Jika ada bagian mana pun dari proses itu yang gagal, browser menolak untuk melanjutkan dan menampilkan kesalahan, bukan halamannya.

SSL dan TLS perlu dipisahkan di sini, karena penamaannya menyebabkan kebingungan nyata. SSL adalah protokol asli, dan setiap versinya telah usang selama bertahun-tahun. Yang sebenarnya digunakan browser Anda adalah TLS. Kata “SSL” tetap bertahan dalam nama produk, dalam direktif konfigurasi, dan dalam kode kesalahan, itulah sebabnya Anda masih melihatnya di mana-mana. Ketika sebuah halaman atau browser menyebut SSL, itu hampir selalu berarti TLS.

Hal ini penting untuk pemecahan masalah karena definisi populer tentang kesalahan SSL terlalu sempit. Anda sering akan membaca bahwa kesalahan SSL berarti browser tidak dapat memverifikasi sertifikat situs. Itu benar untuk satu kelompok kesalahan ini dan salah untuk sisanya. Server yang merespons di port HTTPS dengan teks biasa yang tidak terenkripsi menghasilkan kesalahan SSL dan sama sekali tidak pernah mengirimkan sertifikat apa pun. Dua mesin yang tidak dapat menyepakati rangkaian cipher menghasilkan kesalahan sebelum sertifikat bahkan diperiksa. Memulai dari sertifikat padahal sertifikat bukanlah masalahnya adalah alasan paling umum orang menghabiskan berjam-jam untuk perbaikan yang seharusnya hanya lima menit.

Tahap Koneksi Mana yang Gagal

Setiap koneksi HTTPS berjalan melalui urutan yang sama, dan kesalahan SSL hanyalah titik di mana urutan tersebut berhenti. Menentukan tahapnya langsung mempersempit penyebabnya, karena setiap tahap memiliki sekumpulan penjelasan yang sama sekali berbeda.

1. Koneksi tidak pernah menjadi TLS. Browser Anda membuka koneksi dan yang kembali bukanlah TLS, atau pihak lain menutup koneksi sebelum jabat tangan selesai. Tidak ada sertifikat yang terlibat, dan tidak ada sertifikat yang perlu diganti.
2. Jabat tangan gagal saat bernegosiasi. Kedua belah pihak berbicara TLS tetapi tidak dapat menyepakati versi protokol, rangkaian cipher, atau situs mana yang diminta. Jabat tangan berhenti sebelum sertifikat divalidasi, dan sering kali bahkan sebelum sertifikat dikirim.
3. Sertifikat diterima dan ditolak. Inilah kelompok yang dimaksud orang saat mereka mengatakan “kesalahan SSL”. Kedaluwarsa, cakupan nama host, rantai kepercayaan, pencabutan, dan kekuatan tanda tangan semuanya ada di sini.
4. Jabat tangan berhasil dan sesuatu setelah itu gagal. Koneksi terenkripsi berhasil dibangun dengan benar, kemudian lapisan berikutnya mengalami masalah. Sertifikat pada titik ini sudah dikonfirmasi baik, jadi menggantinya tidak mengubah apa pun.

Anda tidak perlu menebak berada di tahap mana. Kode kesalahannya memberi tahu Anda, dan bagian berikutnya memetakan setiap kode ke tahapnya.

Temukan Kesalahan Anda

Baca kode yang tercetak di bawah pesan peringatan. Di Chrome dan Edge, kode ini berada dalam huruf kapital kecil di bawah “Koneksi Anda tidak pribadi”. Di Firefox, Anda mungkin perlu membuka detail lanjutan pada halaman peringatan. Kemudian temukan kodenya di bawah ini.

Tahap 1: koneksi tidak pernah menjadi TLS

• SSL_ERROR_RX_RECORD_TOO_LONG di Firefox berarti server merespons permintaan HTTPS dengan sesuatu yang bukan TLS, hampir selalu HTTP biasa yang disajikan di port 443. Ini adalah masalah konfigurasi server.
• PR_END_OF_FILE_ERROR di Firefox berarti pihak lain menutup koneksi sebelum jabat tangan selesai. Penyebabnya sering kali berada di antara Anda dan server, bukan pada salah satu ujungnya.

Tahap 2: jabat tangan gagal saat bernegosiasi

• ERR_SSL_PROTOCOL_ERROR adalah kode generik Chrome untuk jabat tangan yang gagal karena alasan yang tidak dapat diidentifikasi secara tepat. Mulailah di sini jika kode Anda adalah ini, karena tugas pertama adalah mempersempitnya.
• SSL_ERROR_NO_CYPHER_OVERLAP adalah padanan di Firefox, dan sama luasnya: kode ini muncul untuk setiap kegagalan jabat tangan fatal yang dilaporkan server, apa pun alasan sebenarnya dari server tersebut.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH adalah kode Chrome untuk kelas kegagalan yang sama, yang muncul untuk daftar kondisi negosiasi yang singkat dan spesifik.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT berarti server mengakhiri jabat tangan dengan sengaja karena nama host yang diminta tidak cocok dengan situs mana pun yang dikonfigurasi di dalamnya. Tidak ada sertifikat yang dikirim, jadi sertifikat bukanlah penyebabnya.
• ERR_BAD_SSL_CLIENT_AUTH_CERT berjalan berlawanan arah dengan setiap kesalahan lain di sini: situs meminta browser Anda menyediakan sertifikat dan menolak yang diterimanya, atau tidak menerima sertifikat sama sekali. Kesalahan ini benar-benar diperbaiki di komputer Anda.
• Kesalahan Cloudflare 525 adalah kegagalan jabat tangan pada bagian perjalanan yang berbeda: antara Cloudflare dan server asal di baliknya, bukan antara browser Anda dan Cloudflare. Pengunjung tidak dapat berbuat apa-apa terhadapnya.

Tahap 3: sertifikat diterima dan ditolak

Koneksi Anda tidak pribadi adalah layar peringatan Chrome untuk seluruh kelompok ini, bukan penyebab tersendiri, jadi jika hanya itu yang Anda miliki, baca dulu kode di bawahnya.

Rantai kepercayaan tidak dapat dibangun. Browser tidak dapat menghubungkan sertifikat situs kembali ke root yang dipercayainya, biasanya karena server mengirim sertifikatnya sendiri dan melewatkan sertifikat perantara di atasnya.

• NET::ERR_CERT_AUTHORITY_INVALID di Chrome dan Edge.
• SEC_ERROR_UNKNOWN_ISSUER di Firefox, kondisi yang sama dengan nama berbeda.
• Sertifikat perantara yang kedaluwarsa, di mana rantainya ada tetapi salah satu mata rantai di atas Anda telah habis masa berlakunya.
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, di mana tidak ada rantai karena sertifikat menandatangani dirinya sendiri.

Tanggal atau namanya tidak cocok. Sertifikat dipercaya tetapi tidak berlaku untuk waktu ini atau nama host ini.

• NET::ERR_CERT_DATE_INVALID, di mana sertifikat telah kedaluwarsa atau belum berlaku. Perlu diketahui bahwa jam yang salah pada perangkat Anda sendiri juga menghasilkan hal ini.
• NET::ERR_CERT_COMMON_NAME_INVALID, di mana nama host tidak tercantum dalam sertifikat.
• DLG_FLAGS_SEC_CERT_CN_INVALID, masalah nama host yang sama yang dilaporkan oleh perangkat lunak yang dibangun di atas tumpukan web Windows yang lebih lama, terutama mode Internet Explorer di Edge dan aplikasi bisnis internal.

Sertifikat dipercaya dan masih berlaku tetapi tidak diizinkan karena alasan lain.

• NET::ERR_CERT_REVOKED, di mana Certificate Authority membatalkannya sebelum tanggal kedaluwarsanya.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, di mana sertifikat tidak tiba dengan bukti publik penerbitan yang cukup.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, di mana sesuatu dalam rantai ditandatangani dengan SHA-1. Chrome versi terkini mungkin melaporkan sertifikat yang sama dengan kode berbeda, tetapi kondisi dan perbaikannya tidak berubah.
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, sebuah tabrakan dalam penyimpanan sertifikat Firefox sendiri, bukan kesalahan pada koneksi.
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, yang berlaku untuk sekumpulan kecil domain yang tertanam di dalam browser, sehingga situs web biasa tidak dapat menghasilkannya.

File sertifikat itu sendiri salah. Kedua hal ini ditemukan di server, bukan di browser, dan biasanya menghentikan sebuah situs untuk menyajikan HTTPS sama sekali.

• ERR_SSL_SERVER_CERT_BAD_FORMAT, di mana browser tidak dapat mendekode sertifikat yang dikirim server.
• Ketidakcocokan modulus, di mana sertifikat yang terpasang bukan milik kunci privat yang terpasang.

Tahap 4: jabat tangan berhasil dan sesuatu setelahnya gagal

Kesalahan-kesalahan ini digolongkan sebagai kesalahan SSL karena kebiasaan. Dalam setiap kasus, koneksi terenkripsi sudah berfungsi, jadi sertifikat telah divalidasi dengan berhasil dan menerbitkannya kembali tidak akan membantu.

• ERR_SSL_BAD_RECORD_MAC_ALERT berarti server menerima data terenkripsi yang tidak dapat diverifikasinya, yang terjadi setelah jabat tangan di bawah kunci sesi. Ada sesuatu di jalur yang merusak atau menulis ulang lalu lintas data.
• ERR_QUIC_PROTOCOL_ERROR adalah kegagalan QUIC, transportasi di bawah HTTP/3. Ini bukan masalah sertifikat, dan penyebab umumnya adalah firewall atau VPN yang memfilter UDP.
• ERR_SPDY_PROTOCOL_ERROR adalah kegagalan pada lapisan HTTP/2, yang berada di atas jabat tangan TLS yang sudah selesai.
• Konten campuran adalah kasus yang aneh: halaman dimuat melalui HTTPS dengan sempurna, kemudian meminta sumber daya melalui HTTP biasa. Ini tidak menghasilkan halaman kesalahan sama sekali, hanya gembok yang diturunkan derajatnya dan skrip atau gambar yang hilang.

Kesalahan yang diberi nama berdasarkan perangkat, bukan tahap

Dua platform menghasilkan cukup banyak keunikannya sendiri sehingga layak dibahas secara terpisah, karena kondisi dasar yang sama berperilaku berbeda pada keduanya.

• Kesalahan SSL di iPhone dan iPad, termasuk pesan “Terjadi kesalahan SSL dan koneksi aman ke server tidak dapat dibuat”. Pengaturan tanggal dan waktu adalah hal pertama yang perlu diperiksa.
• Kesalahan koneksi SSL di Android, di mana Chrome dan aplikasi lainnya merujuk pada penyimpanan kepercayaan (trust store) yang berbeda, dan sertifikat perantara yang hilang menyebabkan lebih banyak masalah dibandingkan pada desktop.

Kode yang sudah tidak muncul lagi

Tiga kode masih banyak dibahas tetapi telah dihapus dari browser yang menghasilkannya, jadi jika Anda membaca saran tentang salah satunya, periksa tanggalnya. Kondisi di balik dua di antaranya masih ada dengan nama lain.

• NET::ERR_CERT_SYMANTEC_LEGACY dihapus di Chrome 136, yang dirilis pada April 2025.
• ERR_SSL_VERSION_INTERFERENCE dihapus di Chrome 76 pada tahun 2019, meskipun gangguan yang dijelaskannya masih terjadi dan sekarang muncul dengan cara yang berbeda.
• ERR_SPDY_PROTOCOL_ERROR diganti namanya menjadi ERR_HTTP2_PROTOCOL_ERROR di Chrome 77, juga pada tahun 2019. Kegagalan yang dijelaskannya masih berlaku saat ini, itulah sebabnya kode ini tercantum di bawah tahap empat di atas.

Jika Anda Mengunjungi Situs

Sebagian besar kesalahan SSL adalah tanggung jawab situs web untuk diperbaiki, dan sebanyak apa pun upaya yang Anda lakukan di perangkat Anda sendiri tidak akan mengubahnya. Ada daftar singkat pengecualian sejati, dan ada baiknya Anda memeriksanya sebelum menyimpulkan bahwa situs tersebut rusak.

• Periksa jam Anda. Validasi sertifikat membandingkan tanggal sertifikat dengan waktu perangkat Anda sendiri. Jam yang salah hingga berbulan-bulan atau bertahun-tahun membuat setiap sertifikat terlihat tidak valid, dan ini adalah penyebab tunggal paling umum dari sisi pengunjung.
• Coba jaringan kedua. Beralih dari Wi-Fi ke data seluler, atau sebaliknya, memberi tahu Anda dalam hitungan detik apakah ada sesuatu di jaringan yang mencegat lalu lintas data. Wi-Fi publik dan hotel sering kali menjadi biang keladinya.
• Matikan pemindaian HTTPS untuk sementara. Produk antivirus dan proksi perusahaan memeriksa lalu lintas terenkripsi dengan mengganti sertifikat mereka sendiri. Ketika mereka melakukannya dengan buruk, Anda mendapatkan kesalahan SSL pada situs yang bekerja dengan baik di tempat lain.
• Coba jendela pribadi dan browser lain. Jika kesalahan muncul di satu browser tetapi tidak di browser lain, penyebabnya biasanya bersifat lokal, pada ekstensi atau data yang tersimpan. Jika muncul di semuanya, itu adalah situsnya.

Jika tidak ada satu pun dari langkah tersebut yang membantu, masalahnya ada di server dan jawaban yang jujur adalah bahwa Anda tidak dapat memperbaikinya. Hal ini sepenuhnya berlaku untuk kesalahan Cloudflare 525, di mana kegagalan terjadi pada koneksi yang tidak melibatkan browser Anda.

Browser memang menawarkan cara untuk melanjutkan meskipun ada sebagian besar peringatan sertifikat, dan ada baiknya jelas mengenai apa risikonya. Melanjutkan berarti memberi tahu browser untuk menerima koneksi yang identitasnya tidak dapat diverifikasi, yang berarti Anda tidak memiliki jaminan bahwa Anda berbicara dengan situs yang Anda ketik, bukan dengan sesuatu di tengahnya. Itu adalah trade-off yang dapat diterima pada server uji coba yang Anda kendalikan sendiri. Itu tidak dapat diterima pada apa pun di mana Anda akan memasukkan kata sandi atau detail pembayaran. Beberapa kesalahan sama sekali tidak menawarkan cara untuk melanjutkan, dan itu memang disengaja, bukan sebuah cacat.

Jika Anda Mengelola Situs Web

Diagnosis dulu sebelum Anda mengubah apa pun. Menginstal ulang sertifikat yang sebenarnya bukan masalah adalah cara biasa yang membuat satu jam berubah menjadi satu sore penuh.

Mulai dengan pemeriksaan eksternal

Jalankan domain melalui SSL Checker kami. Alat ini melaporkan apa yang sebenarnya dikirim server ke dunia luar, yang sering kali berbeda dari apa yang ada dalam file konfigurasi. Rantai yang terlihat lengkap di disk tetapi tiba tidak lengkap di browser adalah temuan paling umum, dan itulah penyebab di balik baik NET::ERR_CERT_AUTHORITY_INVALID maupun SEC_ERROR_UNKNOWN_ISSUER.

Anda dapat melihat hal yang sama dari command line. Ini mencetak setiap sertifikat yang ditawarkan server, dalam urutan yang ditawarkannya:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Baca daftar sertifikat pada keluaran tersebut, bukan baris Verify return code di bagian bawah. Baris tersebut jauh lebih kurang informatif dari yang terlihat: baris itu hanya melaporkan putusan OpenSSL mengenai rantai tersebut, ia mengabaikan nama host kecuali Anda secara eksplisit meminta pemeriksaan tersebut, dan ia mencetak 0 (ok) bahkan ketika server sama sekali tidak mengirim sertifikat karena jabat tangan dibatalkan. Jika keluarannya menyatakan no peer certificate available alih-alih menampilkan baris subject=, tidak ada yang diverifikasi dan kegagalannya terjadi lebih awal.

Periksa tanggal dan nama host

Kedua hal ini menyumbang sebagian besar penolakan sertifikat. Untuk membaca jendela validitas sertifikat yang disajikan server:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

Browser mencocokkan nama host dengan ekstensi subjectAltName dan sepenuhnya mengabaikan Common Name, jadi itulah bidang yang perlu diperiksa pada file sertifikat lokal:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

Agar OpenSSL menerapkan pemeriksaan nama host seperti yang diterapkan browser, tambahkan flag tersebut, bukan mengasumsikan hasil yang bersih sudah mencakupnya:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

Di macOS, perintah ini perlu diperhatikan. openssl yang disertakan dengan macOS adalah LibreSSL, dan itu langsung menolak -verify_hostname serta melaporkan hasil yang sehat pada beberapa rantai yang sebenarnya rusak. Instal OpenSSL melalui Homebrew, lalu jalankan openssl version lagi untuk memastikan biner mana yang sebenarnya Anda panggil. Jika masih melaporkan LibreSSL, berarti PATH Anda menemukan salinan sistem terlebih dahulu, jadi panggil /opt/homebrew/bin/openssl menggunakan jalur lengkapnya.

Kemudian perbaiki dan verifikasi

Apa yang harus diubah mengikuti tahapannya, dan panduan-panduan individual yang ditautkan di atas menyertakan langkah-langkah spesifik per platform. Tiga perbaikan mencakup sebagian besar kasus:

• Sajikan rantai lengkap. Gabungkan sertifikat Anda dan sertifikat perantara yang disediakan oleh Certificate Authority Anda ke dalam file yang dirujuk oleh server Anda. Jangan letakkan kunci privat di file tersebut.
• Perbarui sebelum kedaluwarsa, dan otomatiskan prosesnya. Masa berlaku sertifikat semakin diperpendek, jadi apa pun yang diperbarui secara manual pada akhirnya akan diperbarui terlambat. Otomatisasi ACME menghilangkan tenggat waktu ini.
• Cakup setiap nama host yang benar-benar Anda layani. Sertifikat untuk sebuah domain tidak mencakup subdomainnya kecuali sertifikat itu adalah wildcard atau mencantumkannya secara eksplisit.

Selalu uji konfigurasi sebelum memuat ulang layanan, dan jalankan kembali pemeriksa setelahnya dari luar jaringan Anda sendiri. Perbaikan yang hanya dikonfirmasi di browser yang Anda gunakan untuk menguji belum benar-benar terkonfirmasi, karena browser tersebut mungkin menyimpan hasil yang di-cache.

Cara Mencegah Kesalahan SSL

Hampir setiap kesalahan SSL pada situs web yang berfungsi normal berasal dari salah satu dari tiga hal: sertifikat yang kedaluwarsa, rantai yang tidak pernah lengkap, atau konfigurasi yang bergeser. Ketiganya dapat dicegah.

• Otomatiskan pembaruan. Masa berlaku maksimum sertifikat sedang dikurangi secara bertahap dalam beberapa tahun ke depan, dan pembaruan manual berhenti menjadi praktis jauh sebelum akhir periode itu. Otomatiskan sekarang, bukan saat prosesnya rusak.
• Pantau kedaluwarsa secara independen. Pengingat kalender gagal ketika orangnya keluar. Pemeriksaan eksternal yang memperingatkan Anda beberapa minggu ke depan tidak akan gagal.
• Periksa kembali setelah setiap perubahan. Migrasi server, perubahan CDN, dan pembaruan panel kontrol semuanya secara diam-diam menulis ulang konfigurasi sertifikat. Verifikasi dari luar setelahnya.
• Uji di ponsel, bukan hanya di desktop. Platform seluler lebih ketat mengenai rantai yang tidak lengkap, jadi masalah rantai sering kali muncul di ponsel sementara desktop terlihat baik-baik saja.
• Instal dengan benar sejak pertama kali. Tutorial instalasi kami mencakup langkah-langkah rantai dan pengikatan per platform, dan sebagian besar kesalahan rantai berasal dari waktu instalasi.

Pertanyaan yang Sering Diajukan