Gembok HTTPS Tidak Muncul Padahal SSL Sudah Terpasang? Cek Mixed Content

Sertifikat SSL sudah terpasang, statusnya valid, tapi browser tetap tidak menampilkan gembok. Kadang malah muncul tulisan Not secure atau ikon peringatan di address bar. Di kasus seperti ini, sertifikatnya sering kali tidak bermasalah sama sekali. Yang bermasalah adalah isi halamannya: masih ada gambar, script, atau CSS yang dimuat lewat http://. Kondisi ini disebut mixed content, yaitu halaman HTTPS yang ikut memuat resource lewat koneksi HTTP biasa. Di meja support, ini termasuk keluhan yang paling sering datang setelah pemasangan SSL atau migrasi ke HTTPS. Langkah pertama yang biasanya dicek adalah memastikan sertifikatnya memang beres, supaya kita tidak memperbaiki hal yang salah.

Pastikan sertifikat dan redirect memang sudah beres

Sebelum menyalahkan mixed content, buktikan dulu dari terminal bahwa server mengirim sertifikat yang benar untuk domain itu dan bahwa akses http:// sudah diarahkan ke https://. Dua perintah ini read-only dan aman dijalankan dari mana saja:

BASH

# Cek sertifikat yang dikirim server (-servername mengirim SNI, penting di shared hosting)
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

# Cek apakah request HTTP sudah di-redirect ke HTTPS
curl -sI http://example.com/ | grep -iE '^(HTTP|location)'

Dari perintah pertama, perhatikan tiga hal. Bagian subject (atau SAN di sertifikat) harus mencakup domain kamu. Bagian issuer harus CA yang dikenal, bukan sertifikat self-signed. Tanggal notAfter juga belum boleh lewat. Kalau salah satu tidak cocok, masalahnya memang di sertifikat dan artikel ini bukan jawabannya. Dari perintah kedua, idealnya kamu melihat status 301 atau 302 dengan header Location yang mengarah ke https://. Kalau tidak ada redirect, pengunjung yang mengetik domain tanpa https:// akan tetap mendarat di versi HTTP. Itu masalah terpisah, tapi sering muncul bersamaan. Kalau sertifikat valid dan redirect jalan, tapi gembok tetap hilang, hampir pasti penyebabnya ada di resource yang dimuat halaman.

Kenapa satu gambar http:// bisa menghilangkan gembok

Gembok di browser bukan sekadar tanda bahwa sertifikat valid. Gembok berarti seluruh halaman, termasuk semua resource di dalamnya, dikirim lewat koneksi terenkripsi. Kalau satu file saja dimuat lewat HTTP, file itu bisa dibaca atau diubah di tengah jalan, jadi browser tidak bisa lagi menjamin halaman itu utuh. Browser biasanya membedakan dua jenis mixed content. Yang pertama sering disebut passive atau displayed content: gambar, audio, dan video. Browser modern umumnya mencoba meng-upgrade request ini otomatis ke https://, dan kalau versi HTTPS-nya tidak ada, file itu diblokir atau ditampilkan dengan peringatan. Yang kedua adalah active content: script, stylesheet, iframe, dan request XHR atau fetch. Ini hampir selalu langsung diblokir, karena script yang dimodifikasi bisa mengambil alih halaman sepenuhnya. Dampaknya ke pengunjung jadi berbeda. Mixed content pasif biasanya hanya membuat gembok hilang. Mixed content aktif bisa membuat tampilan berantakan karena CSS tidak termuat, slider tidak jalan, atau form tidak bisa dikirim. Jadi kalau ada pelanggan yang bilang situsnya rusak setelah pindah ke HTTPS, mixed content aktif layak dicurigai lebih dulu. Perlu dicatat, link biasa seperti <a href='http://...'> tidak termasuk mixed content. Itu hanya navigasi ke halaman lain, bukan resource yang dimuat di halaman saat ini.

Menemukan resource penyebabnya lewat DevTools

Cara tercepat adalah buka halaman yang bermasalah, tekan F12 untuk membuka DevTools, lalu lihat tab Console. Browser berbasis Chromium biasanya menampilkan pesan yang diawali Mixed Content: dan menyebutkan URL persis yang dimuat lewat HTTP, beserta apakah request itu diblokir atau hanya diberi peringatan. Firefox menampilkan pesan serupa dengan kata-kata yang sedikit berbeda. Kalau pesannya banyak, tab Network lebih rapi. Di Chrome, kolom filter mendukung kata kunci mixed-content:all untuk menampilkan semua request mixed content, atau mixed-content:blocked untuk yang diblokir saja. Dari situ klik request-nya, lalu lihat kolom Initiator untuk tahu file mana yang memanggilnya. Informasi ini penting, karena URL http:// sering bukan ditulis di HTML halaman, melainkan di file CSS tema atau disisipkan oleh script plugin. Satu catatan: lakukan pengecekan ini dalam jendela incognito atau setelah hard refresh, supaya hasilnya tidak tercampur dengan cache browser.

Memindai halaman dan CSS dari terminal dengan curl

DevTools bagus untuk satu halaman, tapi untuk audit beberapa URL atau verifikasi sebelum dan sesudah perbaikan, terminal lebih praktis karena hasilnya bisa diulang persis sama. Idenya sederhana: ambil HTML mentah, lalu cari semua string http://.

BASH

# Daftar semua URL http:// di HTML halaman (abaikan namespace w3.org)
curl -s https://example.com/ | grep -oE 'http://[a-zA-Z0-9./?=_%:~#&+-]+' | grep -v 'w3.org' | sort -u

# Cari url(http://...) di file CSS tema (ganti path sesuai temuan di DevTools)
curl -s https://example.com/wp-content/themes/nama-tema/style.css | grep -n 'http://'

# Cek apakah server sudah mengirim header CSP yang relevan
curl -sI https://example.com/ | grep -i 'content-security-policy'

Hasil perintah pertama perlu dibaca dengan kepala dingin. Tidak semua baris yang muncul adalah mixed content. Link navigasi biasa, canonical lama di meta tag, atau URL di dalam teks artikel juga akan ikut tertangkap. Yang perlu diperhatikan adalah URL yang berada di atribut src, srcset, atau href pada tag <link rel='stylesheet'>, karena itulah yang benar-benar dimuat browser. Ada juga batasannya. curl hanya melihat HTML yang dikirim server. Resource yang disisipkan JavaScript setelah halaman dimuat tidak akan terlihat di sini, jadi untuk kasus seperti itu DevTools tetap jadi alat utama. Kombinasi keduanya biasanya sudah cukup. Perintah ketiga berguna untuk tahu apakah sudah ada header Content-Security-Policy dengan upgrade-insecure-requests. Header ini menyuruh browser meng-upgrade semua request HTTP ke HTTPS secara otomatis. Itu bisa jadi tambalan cepat, tapi tidak memperbaiki sumbernya. Pertimbangan kapan cukup pakai header dan kapan wajib memperbaiki database sudah dibahas di artikel Fix Mixed Content in the Database or Rely on upgrade-insecure-requests?.

Memperbaiki URL di database dan file tema WordPress

Di WordPress, URL http:// biasanya tersimpan di tiga tempat: opsi home dan siteurl, isi post dan meta di database, serta file tema atau child theme yang menulis URL secara hardcode. Kalau server punya WP-CLI, semuanya bisa dicek dari folder instalasi WordPress. Perhatian: wp search-replace tanpa --dry-run langsung mengubah isi database dan tidak bisa di-undo tanpa backup. Selalu ekspor database dulu, jalankan simulasi, baca hasilnya, baru eksekusi.

BASH

# Lihat URL utama yang tersimpan
wp option get home
wp option get siteurl

# Backup database sebelum mengubah apa pun
wp db export sebelum-search-replace.sql

# Simulasi: tampilkan jumlah penggantian per tabel tanpa menulis ke database
wp search-replace 'http://example.com' 'https://example.com' --dry-run --skip-columns=guid

# Cari URL http:// yang ditulis langsung di file tema
grep -rn 'http://example.com' wp-content/themes/

Kenapa pakai WP-CLI dan bukan query SQL REPLACE() biasa? Banyak data WordPress disimpan dalam format PHP serialized, yang menyimpan panjang string. Kalau http:// diganti https:// lewat SQL langsung, panjang string berubah satu karakter dan data itu bisa jadi tidak terbaca, misalnya pengaturan widget atau opsi tema yang tiba-tiba kembali ke default. wp search-replace menangani format ini dengan benar. Kolom guid dilewati karena isinya berfungsi sebagai ID unik post, bukan URL yang dimuat di halaman. Secara default perintah ini hanya memproses tabel dengan prefix WordPress yang terdaftar; kalau ada plugin yang memakai tabel tanpa prefix, cek opsi --all-tables lewat wp help search-replace. Setelah hasil dry-run masuk akal, jalankan ulang perintah yang sama tanpa --dry-run. Untuk hasil grep di folder tema, perbaiki di child theme kalau ada, karena perubahan di tema induk akan tertimpa saat update. Kalau URL-nya mengarah ke domain pihak ketiga, cek dulu apakah versi https:// dari file itu memang tersedia dengan membukanya langsung atau lewat curl -sI. Kalau tidak tersedia, pilihannya mengganti sumbernya atau menyimpan file itu di server sendiri. Beberapa page builder menyimpan CSS hasil generate di file terpisah. Setelah database diperbaiki, file itu mungkin masih berisi URL lama sampai di-regenerate dari pengaturan plugin-nya. Caranya tergantung plugin yang dipakai.

Verifikasi ulang setelah purge cache

Langkah ini sering terlewat. Halaman yang sudah diperbaiki di database bisa saja masih tersaji versi lama dari page cache, cache di web server, atau CDN. Purge semua lapisan cache yang ada di stack kamu, lalu jalankan lagi perintah curl yang sama seperti sebelum perbaikan. Daftar URL http:// yang relevan seharusnya sudah kosong, atau tinggal link navigasi biasa. Setelah itu buka halaman di jendela incognito dan cek Console sekali lagi. Ulangi untuk beberapa jenis halaman, bukan hanya beranda: halaman artikel, halaman produk, halaman kontak dengan form, karena resource tiap template bisa berbeda. Kalau ingin langkah yang lebih berurutan dalam bahasa Inggris untuk dibagikan ke tim, ada juga panduan How to Find Mixed Content Resources Blocking the Browser Padlock. Intinya, gembok yang hilang setelah SSL terpasang hampir selalu soal isi halaman, bukan sertifikatnya. Buktikan dulu sertifikat dan redirect dengan openssl dan curl, temukan resource http:// lewat DevTools dan grep, perbaiki di sumbernya dengan backup dan dry-run, lalu jalankan perintah yang sama setelah purge cache. Simpan perintah pemindaian itu, karena berguna lagi setiap kali ada tema baru, plugin baru, atau migrasi domain.