Solusi Mengatasi Error Certificate Verification Failed pada Nginx dan Apache Web Server

3 mnt baca

 

Solusi Mengatasi Error Certificate Verification Failed pada Nginx dan Apache Web Server

Peringatan kegagalan verifikasi sertifikat SSL, seperti pesan sistem server certificate verification failed. CAfile: none CRLfile: none, merupakan indikasi teknis bahwa rantai kepercayaan (chain of trust) dari enkripsi keamanan Anda telah terputus. Insiden ini tidak hanya memicu layar peringatan "Koneksi Tidak Aman" pada peramban pengunjung, tetapi juga menggagalkan komunikasi API, integrasi webhook, dan proses transfer data antar-peladen (server-to-server).

Akar masalah dari error ini umumnya berpusat pada dua skenario utama: web server tidak mengirimkan sertifikat perantara (intermediate certificate) kepada klien, atau sistem operasi klien/peladen itu sendiri memiliki daftar otoritas sertifikat (CA Store) yang sudah usang dan tidak dikenali lagi.

Memahami Rantai Kepercayaan SSL

Untuk memperbaiki masalah ini secara permanen, penting untuk memahami struktur sertifikat yang terlibat dalam proses verifikasi.

Komponen SSLFungsi dalam Rantai KepercayaanLetak Kegagalan (Penyebab Error)
Server CertificateSertifikat utama yang diterbitkan secara khusus untuk nama domain Anda.Sering kali dipasang sendirian tanpa sertifikat pendukung.
Intermediate CertificateJembatan yang menghubungkan sertifikat domain Anda dengan Otoritas Tertinggi (Root CA).File ini tidak digabungkan (bundle) pada konfigurasi peladen.
Root CA StoreDaftar otoritas sertifikat global tepercaya yang ditanamkan pada sistem operasi.Paket sistem operasi belum diperbarui, menyebabkan Root CA modern ditolak.

Solusi 1: Konfigurasi Rantai Sertifikat pada Nginx

Nginx mensyaratkan sertifikat utama dan sertifikat perantara digabungkan menjadi satu berkas (file) tunggal agar rantai kepercayaan dapat dikirimkan secara utuh ke peramban.

1.Menggabungkan (Bundle) Sertifikat SSL:Menyatukan sertifikat domain dan intermediate.

Buka terminal peladen Linux Anda. Gunakan perintah cat untuk menggabungkan sertifikat domain Anda (misalnya domain.crt) dan sertifikat dari penyedia SSL (misalnya intermediate.crt atau ca-bundle.crt). Urutan sangat penting: sertifikat domain Anda harus berada di urutan paling atas.

Bash
cat domain.crt intermediate.crt > fullchain.crt
2.Edit Server Block Nginx:Mengarahkan Nginx ke sertifikat yang sudah digabungkan.

Buka berkas konfigurasi Nginx Anda (biasanya di /etc/nginx/sites-available/nama_domain). Ubah direktif ssl_certificate agar mengarah ke berkas fullchain.crt yang baru saja Anda buat.

Nginx
server {
    listen 443 ssl;
    server_name domain.com;

    ssl_certificate /path/ke/ssl/fullchain.crt;
    ssl_certificate_key /path/ke/ssl/private.key;
    
    # Konfigurasi lanjutan lainnya...
}
3.Uji Sintaksis dan Muat Ulang Nginx:Menerapkan perubahan tanpa downtime.

Sebelum menerapkan perubahan, selalu pastikan tidak ada kesalahan ketik dengan menjalankan perintah pengujian.

Bash
sudo nginx -t
sudo systemctl reload nginx

Solusi 2: Konfigurasi Rantai Sertifikat pada Apache

Sistem peladen Apache memiliki cara yang sedikit berbeda dalam menangani sertifikat, sangat bergantung pada versi Apache yang Anda gunakan (khususnya versi 2.4.8 ke atas).

1.Konfigurasi Apache Modern (Versi 2.4.8+):Menggunakan satu direktif untuk seluruh rantai.

Pada versi Apache terbaru, direktif SSLCertificateChainFile sudah dianggap usang (deprecated). Sama seperti Nginx, Anda harus membuat berkas gabungan (fullchain.crt), lalu memanggilnya melalui satu baris konfigurasi SSLCertificateFile di dalam blok Virtual Host Anda.

Apache
<VirtualHost *:443>
    ServerName domain.com
    
    SSLEngine on
    SSLCertificateFile /path/ke/ssl/fullchain.crt
    SSLCertificateKeyFile /path/ke/ssl/private.key
</VirtualHost>
2.Konfigurasi Apache Klasik (Di bawah Versi 2.4.8):Gunakan ini hanya jika Anda menggunakan sistem peladen lama.

Jika peladen Anda masih menggunakan Apache versi lawas, Anda tidak perlu menggabungkan berkas. Cukup arahkan sertifikat utama dan sertifikat perantara secara terpisah menggunakan dua direktif berbeda.

Apache
<VirtualHost *:443>
    ServerName domain.com
    
    SSLEngine on
    SSLCertificateFile /path/ke/ssl/domain.crt
    SSLCertificateKeyFile /path/ke/ssl/private.key
    SSLCertificateChainFile /path/ke/ssl/intermediate.crt
</VirtualHost>
3.Uji Sintaksis dan Muat Ulang Apache:Validasi dan penerapan konfigurasi.

Jalankan pengujian konfigurasi untuk memastikan tidak ada konflik, lalu muat ulang layanan Apache.

Bash
sudo apachectl configtest
sudo systemctl reload apache2

Solusi 3: Memperbarui Root CA pada Tingkat Sistem Operasi

Terkadang, konfigurasi Nginx atau Apache sudah sempurna, tetapi sistem Linux peladen itu sendiri yang menolak membaca sertifikat eksternal saat melakukan proses curl atau pemanggilan API, menghasilkan pesan error spesifik CAfile: none CRLfile: none. Ini terjadi karena gudang sertifikat (CA Store) pada sistem operasi tersebut sudah kedaluwarsa.

1.Perbarui Paket CA-Certificates:Berlaku untuk Ubuntu, Debian, dan turunannya.

Anda harus mengunduh ulang daftar otoritas sertifikat global yang terbaru langsung dari repositori resmi distribusi Linux Anda.

Bash
sudo apt-get update
sudo apt-get install --reinstall ca-certificates
2.Sinkronisasi Ulang Sertifikat:Membangun ulang struktur sertifikat sistem.

Setelah paket terinstal, paksa sistem untuk mengekstrak dan membangun ulang daftar sertifikat tepercaya ke dalam direktori /etc/ssl/certs/.

Bash
sudo update-ca-certificates

Setelah proses ini selesai, cobalah kembali menjalankan perintah curl atau eksekusi API Anda. Koneksi seharusnya sudah berjalan normal tanpa penolakan akses.

Menyelesaikan masalah verifikasi sertifikat SSL menuntut ketelitian dalam mengelola rantai kepercayaan kriptografi. Dengan memastikan bahwa berkas sertifikat perantara selalu disatukan dengan sertifikat domain utama pada arsitektur web server, serta menjaga daftar otoritas sertifikat lokal pada sistem operasi tetap mutakhir, peladen Anda akan kembali melayani jalur enkripsi HTTPS yang sempurna. Konfigurasi yang presisi ini menjamin integritas transmisi data, mengamankan komunikasi API terotomatisasi, dan mengembalikan kredibilitas profesional situs web Anda di mata mesin pencari maupun pengguna akhir.