Cara Menginstal Sertifikat SSL di NGINX

Panduan ini menunjukkan kepada Anda cara menginstal sertifikat SSL/TLS di NGINX. Panduan ini membahas bagian yang paling sering membuat orang bingung: membangun rantai sertifikat yang benar (“fullchain”) yang dibutuhkan NGINX, mengarahkan direktif yang tepat ke file yang tepat, menguji konfigurasi sebelum melakukan reload, dan menambahkan pengalihan HTTP ke HTTPS yang bersih agar setiap pengunjung mendarat di versi aman situs Anda.

Membuat kode CSR untuk NGINX

Jika Anda sudah membuat CSR dan memiliki file sertifikat yang telah diterbitkan, lompat ke bagian Menginstal sertifikat SSL di NGINX.

Sebelum Certificate Authority dapat menerbitkan sertifikat Anda, Anda perlu mengirimkan CSR (Certificate Signing Request): blok teks kecil yang berisi detail domain Anda dan kunci publik, dipasangkan dengan kunci privat yang disimpan di server. Anda memiliki dua opsi:

• Buat CSR secara otomatis dengan CSR Generator kami. Alat ini menghasilkan CSR dan kunci privat yang sesuai, yang kemudian Anda unggah ke server.
• Buat CSR langsung di server menggunakan OpenSSL dengan mengikuti tutorial kami tentang cara membuat CSR di NGINX. Kunci privat tetap berada di server.

Buka file .csr yang dihasilkan di editor teks apa pun; blok teks di dalamnya (termasuk baris —–BEGIN CERTIFICATE REQUEST—– dan —–END CERTIFICATE REQUEST—–) adalah yang Anda tempelkan ke formulir permohonan SSL saat checkout. Jika Anda ingin mengonfirmasi isi CSR sebelum mengirimkannya, tempelkan ke CSR decoder kami.

Menginstal sertifikat SSL di NGINX

Setelah CA menerbitkan sertifikat, Anda biasanya akan menerima:

• Sertifikat utama (server) Anda, biasanya berupa file .crt yang dinamai sesuai domain Anda.
• Sertifikat intermediate (dan terkadang root), baik sebagai file .crt terpisah atau digabungkan menjadi satu file .ca-bundle.
• Kunci privat (file .key) yang dibuat bersamaan dengan CSR Anda.

NGINX memerlukan sertifikat server dan rantai intermediate digabungkan menjadi satu file (“fullchain”) yang dirujuk oleh ssl_certificate; kunci privat dirujuk secara terpisah oleh ssl_certificate_key. Melewatkan rantai adalah kesalahan instalasi paling umum: sertifikat terlihat baik-baik saja di browser desktop tetapi gagal di Android, di klien API, dan di alat seperti SSL Checker kami.

Langkah 1: Gabungkan sertifikat menjadi satu file

Urutan sertifikat dalam file gabungan itu penting. Sertifikat server Anda ditempatkan pertama, lalu setiap intermediate dari CA penerbit leaf ke atas, dengan root di posisi terakhir (atau dihilangkan, karena browser sudah mempercayai root dari penyimpanan bawaannya):

• Sertifikat utama Anda untuk nama domain.
• Sertifikat intermediate.
• Sertifikat root (opsional).

Anda dapat membangun file fullchain secara manual di editor teks (tempelkan setiap blok PEM secara berurutan), atau dengan satu perintah cat. Jika Anda menerima file intermediate dan root secara terpisah, jalankan:

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

Jika intermediate dan root sudah berada dalam satu file .ca-bundle, jalankan:

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

Ganti nama file dengan milik Anda sendiri. Pindahkan file gabungan (dan kunci privat, jika belum ada di sana) ke direktori SSL di server Anda, misalnya /etc/ssl/ atau /etc/nginx/ssl/. Pastikan file kunci hanya dapat dibaca oleh root:

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

Langkah 2: Edit file konfigurasi NGINX

Buka file konfigurasi NGINX untuk situs Anda. Di Debian dan Ubuntu file ini berada di /etc/nginx/sites-available/ (dengan symlink di sites-enabled/); di RHEL, CentOS, AlmaLinux, dan Rocky Linux file ini berada di /etc/nginx/conf.d/. Tambahkan atau edit blok server yang mendengarkan pada port 443 agar mengarah ke file fullchain dan kunci privat:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

    ssl_session_timeout 1d;
    ssl_session_cache shared:NginxSSL:10m;
    ssl_session_tickets off;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Beberapa catatan mengenai direktif di atas:

• listen 443 ssl; mengaktifkan TLS pada port 443. Direktif lama ssl on; telah dihapus di NGINX 1.25 dan tidak boleh muncul dalam konfigurasi modern.
• http2 on; mengaktifkan HTTP/2 sebagai direktif tersendiri (NGINX 1.25.1 dan yang lebih baru). Konfigurasi lama menggunakan listen 443 ssl http2;, yang masih berfungsi tetapi sudah usang.
• ssl_protocols TLSv1.2 TLSv1.3; menonaktifkan TLS 1.0 dan 1.1 yang sudah usang. Mulai dari NGINX 1.27.3, ini juga menjadi default jika Anda menghilangkan direktif tersebut, tetapi menetapkannya secara eksplisit adalah pilihan yang jelas dan memudahkan audit.
• Daftar cipher ini sesuai dengan profil “intermediate” Mozilla dan berfungsi pada hampir semua klien terbaru. Jika Anda hanya membutuhkan klien TLS 1.3, Anda dapat menghilangkan ssl_ciphers sepenuhnya.

Langkah 3: Mengalihkan HTTP ke HTTPS

Tambahkan blok server terpisah di port 80 yang mengalihkan secara permanen setiap permintaan ke HTTPS, sehingga pengunjung yang datang melalui HTTP biasa mendarat di URL yang aman:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Menggunakan return 301 lebih cepat dan lebih aman daripada aturan rewrite berbasis regex dan merupakan pola yang direkomendasikan langsung oleh NGINX.

Langkah 4: Uji konfigurasi dan reload NGINX

Selalu validasi konfigurasi sebelum melakukan reload, agar kesalahan ketik tidak sampai membuat layanan menjadi tidak aktif:

sudo nginx -t

Anda akan melihat pesan syntax is ok dan test is successful. Jika muncul kesalahan, pesan tersebut akan menyertakan nama file dan nomor baris; perbaiki dan jalankan tes lagi. Setelah tes berhasil, lakukan reload NGINX agar konfigurasi baru diterapkan tanpa memutus koneksi yang sedang berlangsung:

sudo systemctl reload nginx

Pada sistem tanpa systemd, gunakan sinyal reload milik NGINX sendiri:

sudo nginx -s reload

Utamakan reload daripada restart: reload membaca ulang konfigurasi tanpa menutup koneksi yang aktif, sedangkan restart akan memutuskannya.

Langkah 5 (opsional): Mengaktifkan OCSP stapling

OCSP stapling memungkinkan NGINX untuk menyertakan status pencabutan yang segar dan ditandatangani bersama sertifikat, sehingga klien tidak perlu menghubungi CA di setiap jabat tangan (handshake). Tambahkan yang berikut ini di dalam blok server HTTPS Anda:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

Lakukan reload NGINX lagi dengan sudo systemctl reload nginx. Stapling adalah langkah pengamanan kecil tetapi berharga, dan sebagian besar sertifikat modern mendukungnya secara langsung.

Memverifikasi instalasi

Buka situs Anda melalui https:// di browser dan periksa apakah gembok tertutup dan sertifikat sesuai dengan domain Anda. Kemudian jalankan pemindaian yang lebih mendalam dengan SSL Checker kami untuk mendapatkan laporan instan mengenai sertifikat, rantai, serta protokol dan cipher yang ditawarkan server Anda. Hasil hijau di sana berarti klien di setiap platform utama akan mempercayai sertifikat tersebut, termasuk klien mobile dan API.

Pertanyaan yang Sering Diajukan