Membaca Log AutoSSL cPanel untuk Tahu Kenapa Domain Dilewati Saat Renewal

Domain utama sudah dapat sertifikat baru dari AutoSSL, tapi www, mail, atau satu subdomain tertentu masih memakai sertifikat lama, atau malah jatuh ke self-signed. Di dashboard tidak ada error merah yang jelas, paling hanya status yang kelihatan setengah beres. Pertanyaan yang biasanya muncul: kenapa AutoSSL melewati domain itu? Jawabannya hampir selalu sudah tercatat, hanya letaknya di log AutoSSL, di bagian DCV, bukan di halaman ringkasan. Catatan ini aku tulis sebagai bahan belajar: apa yang sebenarnya terjadi saat renewal, cara membaca log-nya, apa yang sering disalahpahami, dan cara latihan dengan aman di VPS uji.

Apa yang dilakukan AutoSSL saat renewal

AutoSSL bukan sekadar memperpanjang sertifikat yang sudah ada. Setiap kali jalan, dia menyusun ulang daftar domain yang ingin dicakup untuk satu akun cPanel: domain utama, addon domain, subdomain, alias, plus subdomain layanan seperti www, mail, webmail, atau cpanel tergantung konfigurasi server. Setiap nama di daftar itu harus lolos DCV dulu. DCV (Domain Control Validation) adalah pembuktian bahwa server ini memang mengendalikan domain tersebut. Cara yang paling umum adalah HTTP DCV: AutoSSL menaruh file kecil di bawah folder .well-known di document root, lalu memeriksa apakah file itu bisa diakses lewat domain tersebut dari internet. Kalau server ini juga authoritative untuk zona DNS domain-nya, biasanya ada opsi DNS DCV, yaitu validasi lewat record DNS. Detail kapan DNS DCV dipakai tergantung versi cPanel dan provider AutoSSL yang aktif. Yang penting dipahami: cPanel biasanya melakukan pengecekan lokal dulu sebelum meminta sertifikat ke provider. Domain yang gagal di tahap ini tidak ikut diajukan. Hasilnya, sertifikat baru tetap terbit, tapi hanya untuk domain yang lolos. Dari sisi pengguna, ini terlihat seperti "sebagian domain dilewati tanpa alasan", padahal alasannya ada, hanya ditulis per domain di log.

Di mana log-nya dan cara membacanya

Ada tiga tempat yang biasa dipakai, tergantung akses kamu. Dari sisi pemilik akun, halaman SSL/TLS Status di cPanel menampilkan status per domain. Domain yang gagal biasanya punya keterangan singkat, dan dari halaman itu juga kamu bisa menjalankan AutoSSL ulang untuk akun sendiri. Dari sisi admin server, WHM punya halaman Manage AutoSSL dengan tab Logs. Di sana setiap run tercatat terpisah, dan kamu bisa memilih log run tertentu lalu membaca hasilnya per akun dan per domain. Kalau punya akses root, log yang sama tersimpan sebagai file di disk. Ini paling enak kalau kamu mau mencari satu domain di banyak run sekaligus. Perintah di bawah semuanya read-only:

BASH

# Daftar folder log per run AutoSSL
ls -1 /var/cpanel/logs/autossl/

# Cari semua baris yang menyebut subdomain bermasalah
grep -ri 'sub.contohdomain.com' /var/cpanel/logs/autossl/ | tail -n 20

# Bandingkan IP hasil resolve publik dengan IP server
dig +short A sub.contohdomain.com @1.1.1.1
hostname -I

Struktur folder dan nama file di dalam /var/cpanel/logs/autossl/ bisa berbeda antar versi, jadi lihat dulu isinya sebelum membuat script apa pun di atasnya. Untuk hostname -I, ingat bahwa di server di balik NAT, IP yang muncul bisa IP privat, bukan IP publik yang dipakai di record DNS. Saat membaca log, cari baris per domain yang menyebut DCV. Bentuknya kurang lebih seperti ini:

TEXT

# contoh format output, bukan dari insiden nyata; teks persis berbeda per versi
Analyzing "contohuser"'s domains ...
  contohdomain.com: Local HTTP DCV OK
  www.contohdomain.com: Local HTTP DCV OK
  sub.contohdomain.com: Local HTTP DCV error: the domain resolves to 203.0.113.10, which is not this server's IP
  mail.contohdomain.com: Local HTTP DCV error: no IPv4 or IPv6 address

Pola bacanya sederhana: domain mana yang OK, domain mana yang error, dan apa alasan di belakang error itu. Alasannya hampir selalu menunjuk ke DNS atau ke jalur HTTP menuju file validasi.

Penyebab yang paling sering muncul

Penyebab pertama, record DNS mengarah ke IP lain. Ini sering terjadi setelah migrasi: domain utama sudah dipindah ke server baru, tapi subdomain tertentu masih punya record A sendiri yang menunjuk ke server lama. Bisa juga subdomain itu memang sengaja diarahkan ke layanan lain, misalnya landing page atau aplikasi di VPS terpisah. Dari sudut pandang AutoSSL, server ini tidak mengendalikan subdomain tersebut, jadi wajar kalau dilewati. Kalau masalahnya justru DNS yang belum berpindah rata ke semua resolver, penjelasannya ada di Kenapa Website Masih ke Server Lama Padahal TTL Sudah Diturunkan. Penyebab kedua, domain masih di-proxy. Kalau domain lewat reverse proxy atau CDN, hasil resolve DNS-nya adalah IP milik proxy, bukan IP server. Request HTTP DCV kadang tetap sampai ke origin, kadang tidak. Yang sering menggagalkan adalah aturan WAF, challenge anti-bot, cache yang menyajikan respons lama, atau aturan proxy yang tidak meneruskan path .well-known dengan benar. Hasilnya tergantung konfigurasi proxy masing-masing, jadi cara paling jujur untuk memastikannya adalah membaca alasan di log lalu mencoba mengakses file validasi lewat domain itu dari luar. Penyebab ketiga, subdomain layanan tidak punya record sama sekali. mail, webmail, cpanel, atau autodiscover sering ikut masuk daftar AutoSSL walaupun zona DNS-nya dikelola di luar server dan record untuk nama itu tidak pernah dibuat. Log akan menyebut domain tidak resolve. Kalau subdomain itu memang tidak dipakai, ini bukan masalah serius, tapi tetap menimbulkan kesan "AutoSSL gagal" di setiap run. Penyebab keempat, path validasi diblokir di level aplikasi. Aturan .htaccess, plugin keamanan, atau konfigurasi aplikasi bisa membuat request ke .well-known dibalas 403, 404, atau diarahkan ke halaman lain. Di sini DNS-nya benar, tapi file validasi tetap tidak terbaca. Path persisnya tergantung provider: provider berbasis ACME biasanya memakai /.well-known/acme-challenge/, provider lain bisa memakai /.well-known/pki-validation/. Di meja support, urutan cek yang paling cepat biasanya sama: baca alasan di log dulu, baru cek DNS, baru cek jalur HTTP. Pelanggan sering langsung minta "install ulang SSL", padahal sertifikat baru tidak akan mencakup domain itu selama DCV-nya belum lolos.

Yang gampang disalahpahami

Aku dulu menganggap AutoSSL itu semua-atau-tidak-sama-sekali. Ternyata tidak. Satu domain gagal tidak membatalkan seluruh sertifikat, dan itu justru membuat masalahnya mudah terlewat. Situs utama tetap aman, sementara subdomain jarang diakses diam-diam memakai sertifikat yang sebentar lagi kedaluwarsa. Salah paham kedua, menganggap pengecekan DNS dari laptop sendiri sudah cukup. Resolver lokal bisa menyimpan cache, dan hasil dari jaringan kantor bisa berbeda dari yang dilihat server. Lebih aman memakai dig ke resolver publik, atau langsung ke nameserver authoritative, lalu membandingkannya dengan IP server. Salah paham ketiga, mengira menjalankan AutoSSL berkali-kali akan membantu. Selama penyebabnya belum diperbaiki, hasilnya akan sama. Ada juga risiko kena rate limit di sisi provider kalau dijalankan terlalu sering. Perbaiki dulu DNS atau jalur HTTP-nya, baru jalankan ulang sekali. Salah paham keempat, menganggap domain yang dilewati selalu harus diperbaiki. Kadang keputusan yang benar adalah mengecualikan domain itu dari AutoSSL, misalnya subdomain yang memang dilayani server lain dan sudah punya sertifikat sendiri di sana. Yang penting keputusannya disengaja, bukan kebetulan.

Latihan aman di VPS uji

Cara paling efektif memahami log ini adalah membuat kegagalannya sendiri di lingkungan yang tidak dipakai produksi. Di VPS uji dengan cPanel & WHM, langkahnya kurang lebih begini:

Buat akun uji dengan domain atau subdomain yang DNS-nya kamu kendalikan penuh.
Buat satu subdomain yang record A-nya sengaja diarahkan ke IP lain, dan satu subdomain yang tidak punya record sama sekali.
Jalankan AutoSSL untuk akun itu saja, lewat tombol di halaman SSL/TLS Status atau lewat /usr/local/cpanel/bin/autossl_check --user=namauser sebagai root. Cek opsi persisnya dengan --help di versi server kamu.
Buka log run terbaru di WHM atau di /var/cpanel/logs/autossl/, lalu cocokkan alasan error dengan apa yang kamu ubah.
Perbaiki satu per satu, tunggu DNS-nya berubah, lalu jalankan ulang dan lihat domain itu berpindah ke status OK.

Kalau mau, tambahkan juga variasi aturan .htaccess yang memblokir .well-known supaya kamu kenal bentuk error-nya saat DNS benar tapi HTTP-nya gagal. Setelah beberapa putaran, membaca log AutoSSL jadi jauh lebih cepat karena polanya sudah familiar. Intinya, kalau ada domain yang tidak ikut dapat sertifikat baru, jangan mulai dari tombol install ulang. Buka log run AutoSSL terakhir, cari baris DCV untuk domain itu, dan ikuti alasannya: DNS mengarah ke IP lain, domain lewat proxy, record tidak ada, atau path validasi terblokir. Setelah penyebabnya diperbaiki, cukup jalankan AutoSSL sekali lagi untuk akun itu dan pastikan statusnya sudah berubah.