Server Solusi – Ketika proses penerbitan atau perpanjangan sertifikat SSL gagal, salah satu pesan yang mungkin muncul adalah challenge failed, unauthorized, atau connection timed out. Masalah ini biasanya berkaitan dengan proses validasi domain oleh Let’s Encrypt, bukan semata-mata karena sertifikat SSL yang lama sudah kedaluwarsa.

Pemeriksaan sebaiknya dimulai dari metode validasi yang digunakan, konfigurasi DNS, akses dari internet ke server, dan konfigurasi web server. Tanpa memeriksa detail error, kita belum bisa memastikan penyebabnya karena pesan yang terlihat sama dapat berasal dari kondisi yang berbeda.

Dalam panduan ini, saya menggunakan pendekatan troubleshooting bertahap agar kamu bisa menemukan bagian yang gagal sebelum mengubah konfigurasi server.

Apa penyebab Let’s Encrypt challenge failed?

Let’s Encrypt challenge failed terjadi ketika otoritas sertifikat tidak dapat memverifikasi bahwa kamu mengendalikan domain yang diminta. Penyebabnya bisa berupa DNS yang belum mengarah ke server yang benar, port validasi yang tidak dapat diakses, konfigurasi HTTP yang salah, atau record DNS untuk validasi yang tidak sesuai.

Jika menggunakan Certbot pada Ubuntu Server dengan Nginx atau Apache, pemeriksaan awal yang paling berguna adalah membaca pesan error lengkap, memastikan domain mengarah ke alamat IP yang benar, lalu memeriksa apakah metode validasi HTTP-01 atau DNS-01 dapat diselesaikan.

Jangan langsung menghapus sertifikat lama atau memasang ulang Certbot. Tindakan tersebut belum tentu menyelesaikan masalah validasi.

Kenali pesan error yang muncul

Sebelum mengubah konfigurasi, periksa pesan yang ditampilkan Certbot atau panel hosting. Bagian terpenting biasanya menjelaskan alasan otoritas sertifikat menolak validasi.

Pesan tersebut merupakan petunjuk awal, bukan bukti final penyebab masalah. Misalnya, unauthorized bisa terjadi ketika file challenge tidak dapat diakses dengan benar, tetapi bisa juga muncul karena domain diarahkan ke server lain.

Baca JugaCara Mengatasi Domain Tidak Bisa Diakses Setelah Ganti Nameserver

Jika kamu menggunakan panel seperti CyberPanel, Plesk, atau panel hosting lainnya, periksa log penerbitan sertifikat di panel tersebut. Nama menu dan lokasi log dapat berbeda bergantung pada panel dan versinya.

Periksa DNS domain sebelum menjalankan Certbot lagi

Let’s Encrypt harus dapat menemukan domain yang sedang divalidasi. Jika kamu baru memindahkan website ke VPS, mengganti nameserver, atau mengubah alamat IP, DNS menjadi salah satu hal pertama yang perlu diperiksa.

Jalankan perintah berikut dari server atau komputer yang memiliki dig:

dig +short A example.comdig +short AAAA example.comdig +short A www.example.com

Ganti example.com dengan domain milikmu.

Perintah tersebut memeriksa record IPv4 (A) dan IPv6 (AAAA) untuk domain utama serta IPv4 untuk subdomain www. Bandingkan hasilnya dengan alamat IP server yang seharusnya menerima permintaan validasi.

Hal yang perlu diperhatikan:

• Jika record A mengarah ke IP lama, perbaiki record DNS di penyedia DNS yang menjadi otoritatif untuk domain tersebut.

• Jika record AAAA tersedia, pastikan alamat IPv6 itu benar-benar dapat melayani domain. Konfigurasi IPv6 yang keliru dapat menyebabkan permintaan validasi menuju alamat yang salah.

• Jika kamu meminta sertifikat untuk example.com dan www.example.com, pastikan keduanya mengarah ke layanan yang dapat memberikan respons validasi yang benar.

• Jika hasil dig kosong, periksa apakah record memang belum dibuat atau nama domain yang diperiksa keliru.

Untuk melihat server DNS otoritatif yang digunakan, jalankan:

dig NS example.com

Perubahan DNS tidak selalu langsung terlihat di semua resolver karena adanya caching dan TTL. Setelah mengubah record, periksa kembali hasilnya sebelum mencoba menerbitkan sertifikat.

Jangan mengubah DNS secara acak hanya karena proses validasi gagal. Jika record sudah benar, lanjutkan ke pemeriksaan konektivitas dan konfigurasi web server.

Periksa akses HTTP-01 melalui port 80

HTTP-01 adalah metode validasi yang umum digunakan saat menerbitkan sertifikat melalui Certbot dengan Nginx, Apache, atau webroot. Dalam metode ini, Let’s Encrypt mencoba mengambil file khusus melalui URL berikut:

Baca JugaCara Mengatasi Error SSL Certificate Expired di Website

http://example.com/.well-known/acme-challenge/TOKEN

TOKEN di atas merupakan contoh penanda, bukan nama file yang harus kamu buat secara sembarangan.

Untuk HTTP-01, server harus dapat menyajikan respons validasi yang sesuai melalui port 80. Redirect ke HTTPS tidak selalu menjadi masalah, tetapi redirect yang mengarah ke host, alamat, atau jalur yang salah dapat menggagalkan validasi. Dokumentasi Let’s Encrypt tentang port 80 menjelaskan alasan akses HTTP tetap diperlukan untuk metode ini.

Periksa apakah layanan web berjalan

Jika menggunakan Nginx:

sudo systemctl status nginx

Jika menggunakan Apache pada Ubuntu:

sudo systemctl status apache2

Perintah tersebut menunjukkan status service. Jika layanan tidak aktif, periksa log dan konfigurasi terlebih dahulu sebelum menjalankannya kembali.

Untuk melihat apakah ada proses yang mendengarkan port 80 atau 443:

sudo ss -ltnp | grep -E ':(80|443)\b'

Jika tidak ada hasil untuk port 80, belum tentu penyebabnya langsung diketahui. Bisa jadi web server memang tidak berjalan, memakai port lain, atau layanan berada di belakang proxy. Periksa arsitektur server sebelum melakukan perubahan.

Periksa firewall dan jaringan

Pada Ubuntu yang menggunakan UFW, periksa aturan aktif dengan:

sudo ufw status verbose

Jika HTTP-01 digunakan dan port 80 memang belum diizinkan, kamu dapat mempertimbangkan aturan berikut setelah memastikan kebijakan firewall server:

sudo ufw allow 80/tcp

Perintah ini mengubah aturan firewall. Pastikan kamu memahami kebijakan keamanan yang berlaku, terutama jika server dikelola melalui firewall provider atau jaringan eksternal. Membuka port pada UFW saja tidak akan membantu jika firewall provider masih memblokir koneksi.

Jangan menonaktifkan seluruh firewall hanya untuk menguji penerbitan sertifikat. Lebih aman memeriksa aturan spesifik yang berkaitan dengan koneksi validasi.

Periksa apakah file challenge dapat diakses

Jika DNS sudah benar dan port 80 dapat dijangkau, periksa konfigurasi web server yang menangani domain tersebut. Masalah sering muncul ketika domain mengarah ke virtual host yang berbeda, document root salah, atau aturan rewrite mengubah permintaan ke jalur lain.

Jika kamu menggunakan Certbot dengan metode webroot, file validasi biasanya ditempatkan di bawah direktori:

Baca JugaCloudflare Error 521 Setelah Pindah Hosting: Penyebab dan Cara Mengatasinya

<WEBROOT>/.well-known/acme-challenge/

<WEBROOT> harus diganti dengan document root yang benar untuk domain yang sedang divalidasi.

Sebagai contoh, jika document root website adalah /var/www/example.com/public, lokasi file challenge menjadi:

/var/www/example.com/public/.well-known/acme-challenge/

Path tersebut hanya contoh. Jangan menganggap semua website menggunakan direktori yang sama.

Untuk menguji pemetaan direktori secara manual, kamu dapat membuat file sementara di direktori challenge yang benar:

sudo mkdir -p /var/www/example.com/public/.well-known/acme-challengeprintf 'acme-test\n' | sudo tee /var/www/example.com/public/.well-known/acme-challenge/test-file

Kemudian, akses URL berikut dari luar server atau gunakan curl:

curl -i http://example.com/.well-known/acme-challenge/test-file

Sesuaikan path dengan document root sebenarnya. File ini hanya untuk pengujian akses dan bukan token validasi resmi dari Let’s Encrypt.

Respons yang diharapkan adalah HTTP 200 dengan isi acme-test. Jika mendapatkan 403, 404, atau diarahkan ke halaman lain, periksa konfigurasi virtual host, izin akses direktori, aturan rewrite, dan proxy yang digunakan.

Setelah selesai, hapus file pengujian yang dibuat tadi:

sudo rm /var/www/example.com/public/.well-known/acme-challenge/test-file

Pastikan path yang dihapus benar-benar file sementara tersebut. Jangan menjalankan penghapusan terhadap seluruh direktori challenge karena bisa mengganggu proses validasi yang sedang berlangsung.

Jika menggunakan Nginx

Periksa sintaks konfigurasi terlebih dahulu:

sudo nginx -t

Jika ada kesalahan, perbaiki file konfigurasi yang disebutkan dalam output. Jangan langsung melakukan restart sebelum validasi sintaks berhasil.

Periksa pula server block yang menangani domain:

sudo nginx -T

Perintah ini menampilkan konfigurasi Nginx yang aktif beserta konfigurasi yang disertakan. Output dapat berisi informasi sensitif dari konfigurasi, jadi jangan membagikannya secara utuh tanpa meninjau isinya.

Pastikan domain yang diminta tercantum pada server_name, port HTTP ditangani dengan benar, dan konfigurasi root sesuai dengan metode webroot yang digunakan.

Jika perlu mengubah konfigurasi, simpan salinan file terlebih dahulu. Setelah perubahan lolos nginx -t, terapkan dengan reload:

Baca JugaCara Mengatasi Connection Timed Out ke Server: Diagnosis dan Solusi

sudo systemctl reload nginx

Reload hanya dilakukan setelah konfigurasi valid. Jika Nginx tidak berjalan atau reload gagal, lanjutkan dengan pemeriksaan status dan log, bukan mengulang perintah yang sama tanpa diagnosis.

Jika menggunakan Apache

Pada Ubuntu, periksa konfigurasi Apache:

sudo apache2ctl configtest

Periksa virtual host yang dikenali Apache:

sudo apache2ctl -S

Pastikan domain diarahkan ke virtual host dan document root yang benar. Jika menggunakan rewrite atau redirect HTTPS, pastikan jalur /.well-known/acme-challenge/ tidak dialihkan ke lokasi yang menghalangi proses validasi.

Setelah memperbaiki konfigurasi, lakukan reload hanya jika pengujian konfigurasi berhasil:

sudo systemctl reload apache2

Perintah dan lokasi konfigurasi di atas ditujukan untuk instalasi Apache pada Ubuntu. Distribusi lain atau instalasi khusus dapat menggunakan nama service dan path berbeda.

Jika memakai DNS-01, periksa record TXT

Tidak semua validasi menggunakan port 80. Metode DNS-01 membuktikan kendali domain melalui record TXT pada nama khusus:

_acme-challenge.example.com

Metode ini sering digunakan untuk wildcard certificate seperti *.example.com, atau ketika akses HTTP langsung ke server tidak memungkinkan.

Periksa record TXT dengan:

dig +short TXT _acme-challenge.example.com

Ganti nama domain sesuai sertifikat yang sedang diminta.

Jika nilai TXT tidak sesuai dengan token yang diminta oleh proses ACME, validasi dapat gagal. Periksa hal-hal berikut:

1. Nama record harus tepat, termasuk label _acme-challenge.

2. Nilai TXT harus sama dengan token yang diminta proses validasi saat ini.

3. Record harus dibuat di penyedia DNS yang benar-benar mengelola zona domain.

4. Jika ada beberapa token validasi yang masih aktif, jangan menghapus record lain secara sembarangan.

5. Tunggu propagasi DNS dan periksa kembali dari resolver yang berbeda jika diperlukan.

Untuk membandingkan hasil dari resolver publik, kamu bisa menggunakan:

dig @1.1.1.1 +short TXT _acme-challenge.example.comdig @8.8.8.8 +short TXT _acme-challenge.example.com

Jika hasilnya berbeda, perubahan record mungkin belum terlihat secara konsisten akibat caching atau propagasi DNS. Jika hasilnya sama tetapi token tetap salah, periksa kembali nilai dan nama record pada panel DNS.

Catatan: jangan memasukkan sembarang nilai TXT untuk mencoba memperbaiki error. Nilai yang diperlukan harus berasal dari proses validasi yang sedang berjalan.

Baca log Certbot untuk menemukan penyebab yang lebih spesifik

Jika pemeriksaan DNS, firewall, dan web server belum menemukan masalah, lanjutkan dengan log Certbot. Pesan error terperinci biasanya lebih berguna daripada hanya melihat status akhir challenge failed.

Jalankan:

sudo tail -n 100 /var/log/letsencrypt/letsencrypt.log

Perintah tersebut menampilkan sekitar 100 baris terakhir dari log Certbot. Perhatikan nama domain, jenis challenge, alamat yang diakses, kode respons HTTP, serta alasan penolakan dari server validasi.

Kamu juga dapat memeriksa informasi sertifikat yang dikelola Certbot:

sudo certbot certificates

Perintah ini membantu mengidentifikasi nama sertifikat, domain yang tercakup, dan masa berlakunya. Ini berguna untuk memastikan kamu sedang memeriksa sertifikat yang benar, terutama jika satu server mengelola beberapa website.

Jika Certbot mencatat unauthorized, cocokkan URL challenge dan respons yang diterima dengan konfigurasi server. Jika error mengarah pada timeout, prioritaskan pemeriksaan konektivitas. Jika error menyebut record DNS, kembali ke pemeriksaan DNS-01 atau resolusi domain sesuai jenis challenge yang digunakan.

Dokumentasi resmi Certbot menyediakan penjelasan mengenai perintah, metode authenticator, dan proses renewal.

Pilih perbaikan sesuai metode validasi

Jangan langsung mengganti metode validasi sebelum memahami penyebab error. Gunakan hasil diagnosis untuk menentukan tindakan yang relevan.

Jika menggunakan HTTP-01 dengan Nginx atau Apache

Urutan perbaikan yang dapat kamu ikuti:

1. Pastikan domain mengarah ke IP server yang benar.

2. Pastikan port 80 dapat diakses dari internet, termasuk melalui firewall provider.

3. Periksa virtual host, document root, dan aturan redirect.

4. Pastikan jalur /.well-known/acme-challenge/ dapat memberikan respons yang sesuai.

5. Perbaiki konfigurasi dan validasi sintaks sebelum reload.

6. Ulangi proses penerbitan atau perpanjangan sertifikat setelah masalah ditemukan dan diperbaiki.

Jika kamu menggunakan Certbot dengan plugin Nginx, contoh perintah untuk meminta sertifikat adalah:

sudo certbot --nginx -d example.com -d www.example.com

Gunakan perintah tersebut hanya jika plugin Nginx tersedia, domain yang dicantumkan memang ingin dimasukkan ke sertifikat, dan konfigurasi web server sesuai. Jika sertifikat hanya untuk domain utama, jangan menambahkan www tanpa memastikan subdomain tersebut sudah dikonfigurasi.

Jika kamu memakai Apache, metode yang sesuai dapat berupa:

sudo certbot --apache -d example.com -d www.example.com

Kedua perintah di atas adalah contoh permintaan sertifikat, bukan jaminan bahwa proses akan berhasil. Periksa kembali error jika validasi masih gagal.

Jika menggunakan Certbot dengan webroot

Metode webroot cocok ketika web server tetap berjalan dan Certbot menempatkan file challenge di direktori website. Contohnya:

sudo certbot certonly --webroot \-w /var/www/example.com/public \-d example.com

Sesuaikan -w dengan document root yang benar. Jika sertifikat mencakup beberapa domain yang menggunakan webroot berbeda, konfigurasi setiap domain harus diperiksa agar file challenge tersedia pada lokasi yang dapat diakses untuk domain tersebut.

Jika sebelumnya Certbot memakai metode lain, jangan langsung mengganti perintah renewal. Periksa konfigurasi sertifikat yang sudah tersimpan terlebih dahulu.

Jika HTTP-01 memang tidak dapat digunakan

Pertimbangkan DNS-01 jika kamu tidak bisa menyediakan akses HTTP yang diperlukan atau membutuhkan sertifikat wildcard. Metode ini membutuhkan kemampuan membuat record TXT pada DNS domain.

Jika DNS dikelola melalui API provider, plugin DNS yang sesuai dapat membantu mengotomatiskan proses validasi. Pastikan plugin berasal dari sumber tepercaya, mengikuti dokumentasi provider, dan kredensial API-nya dibatasi pada izin yang diperlukan.

Menggunakan DNS-01 bukan berarti masalah DNS hilang. Justru, kesalahan nama record, token, kredensial API, atau waktu propagasi dapat menyebabkan challenge gagal dengan cara yang berbeda.

Uji ulang dengan aman

Setelah perubahan dilakukan, uji proses renewal sebelum mengandalkannya untuk sertifikat produksi.

Untuk sertifikat yang dikelola Certbot, kamu dapat menjalankan:

sudo certbot renew --dry-run

Perintah ini menguji proses renewal menggunakan lingkungan pengujian yang didukung Certbot. Ini bukan bukti bahwa sertifikat produksi sudah diterbitkan atau diperbarui. Perintah juga hanya mencoba sertifikat yang memenuhi kondisi untuk diproses sesuai mekanisme renewal Certbot.

Jika menggunakan konfigurasi yang baru saja diubah, pastikan pengujian memang memakai opsi authenticator dan konfigurasi yang dimaksud. Dokumentasi Certbot menjelaskan penggunaan --dry-run serta cara mengubah konfigurasi renewal secara lebih terarah.

Jangan menggunakan --force-renewal berulang kali hanya untuk melihat apakah error hilang. Permintaan yang tidak perlu dapat menghabiskan batas penerbitan sertifikat. Perbaiki penyebabnya terlebih dahulu, lalu lakukan pengujian yang sesuai.

Verifikasi sertifikat dan website setelah perbaikan

Setelah proses penerbitan atau renewal selesai tanpa error, periksa sertifikat yang tercatat di Certbot:

sudo certbot certificates

Pastikan nama domain, lokasi sertifikat, dan tanggal kedaluwarsa sesuai dengan yang diharapkan.

Berikutnya, periksa respons HTTPS website:

curl -I https://example.com

Perintah tersebut menampilkan header HTTP dari website. Respons 200, 301, atau 302 dapat sama-sama valid bergantung pada konfigurasi website. Status HTTP saja tidak membuktikan bahwa sertifikat yang disajikan sudah benar.

Untuk melihat informasi sertifikat yang dikirim server, gunakan:

echo | openssl s_client \-connect example.com:443 \-servername example.com 2>/dev/null \| openssl x509 -noout -subject -issuer -dates

Periksa subject, issuer, serta tanggal mulai dan berakhirnya sertifikat. Opsi -servername membantu pengujian SNI, yaitu mekanisme yang memungkinkan server memilih sertifikat berdasarkan nama domain.

Jika sertifikat baru sudah terbit tetapi browser masih menampilkan sertifikat lama, periksa apakah web server telah memuat sertifikat yang benar, apakah ada reverse proxy atau CDN yang menyajikan sertifikat berbeda, dan apakah konfigurasi HTTPS mengarah ke file sertifikat yang tepat.

Hasil pengujian di atas harus diperiksa langsung pada server milikmu. Tanpa menjalankan pengujian terhadap domain tersebut, kita belum bisa menyimpulkan bahwa masalah telah selesai.

Cara mencegah Let’s Encrypt challenge failed terulang

Beberapa pemeriksaan berikut dapat mengurangi risiko kegagalan saat sertifikat perlu diperpanjang kembali.

• Pantau DNS setelah perubahan server. Ketika memindahkan website ke VPS baru, pastikan record A dan AAAA sesuai dengan layanan yang aktif.

• Jangan memblokir port validasi tanpa alasan. Jika menggunakan HTTP-01, pastikan port 80 tetap dapat diakses sesuai kebutuhan website.

• Pertahankan jalur challenge. Tinjau aturan redirect, rewrite, dan konfigurasi proxy agar tidak menghalangi URL /.well-known/acme-challenge/.

• Uji konfigurasi sebelum reload. Gunakan nginx -t atau apache2ctl configtest sesuai web server yang dipakai.

• Periksa renewal secara berkala. Pastikan timer atau scheduler Certbot berjalan dan pantau log ketika renewal gagal.

• Jaga kredensial DNS API. Jika memakai DNS-01 otomatis, batasi izin token dan hindari menyimpan kredensial dalam file yang dapat diakses publik.

• Hindari percobaan berulang tanpa diagnosis. Perbaiki akar masalah terlebih dahulu agar tidak membuang waktu atau terkena batas penerbitan sertifikat.

FAQ

1. Kenapa Let’s Encrypt challenge failed padahal domain bisa dibuka?

Website yang dapat dibuka belum tentu dapat melewati validasi ACME. Bisa jadi domain diarahkan ke server berbeda, jalur challenge tidak tersedia, atau record AAAA mengarah ke IPv6 yang salah. Periksa URL validasi dan pesan error yang dicatat Certbot.

2. Apakah port 80 harus dibuka untuk Let’s Encrypt?

Untuk metode HTTP-01, port 80 harus dapat dijangkau oleh server validasi. Jika metode tersebut tidak memungkinkan, DNS-01 bisa menjadi alternatif. Kebutuhan port bergantung pada metode challenge yang digunakan.

3. Bagaimana jika error unauthorized muncul saat menggunakan Certbot?

Periksa domain yang divalidasi, URL challenge, dan respons yang diberikan server. Jika menggunakan DNS-01, periksa record TXT. Jika menggunakan HTTP-01, pastikan file challenge dapat diakses dan tidak diarahkan ke konten yang salah.

4. Apakah saya perlu menghapus sertifikat lama sebelum mencoba lagi?

Tidak. Menghapus sertifikat lama bukan langkah diagnosis awal dan tidak otomatis memperbaiki validasi domain. Periksa DNS, akses jaringan, konfigurasi web server, dan log terlebih dahulu.

5. Apakah DNS-01 dapat digunakan untuk sertifikat wildcard?

Ya. DNS-01 mendukung validasi untuk sertifikat wildcard, seperti *.example.com. Kamu perlu membuat record TXT yang sesuai dengan token validasi. Untuk renewal otomatis, gunakan integrasi DNS yang sesuai atau mekanisme hook yang dikonfigurasi dengan benar.

Penutup

Untuk mengatasi Let's Encrypt challenge failed, mulai dengan membaca error lengkap dan memastikan metode validasi yang digunakan. Jika menggunakan HTTP-01, periksa DNS, port 80, virtual host, redirect, serta akses ke file challenge. Jika menggunakan DNS-01, pastikan record TXT dan propagasi DNS sudah benar.

Setelah perbaikan, jalankan pengujian renewal yang sesuai dan periksa sertifikat yang benar-benar disajikan oleh server. Jika masalah masih muncul, catat pesan error lengkap beserta metode validasi, web server, dan konfigurasi jaringan yang relevan. Informasi tersebut akan membantu mempersempit penyebab tanpa melakukan perubahan yang tidak diperlukan.