Tutorial Ubuntu 26.04 / Menerbitkan sertifikat HTTPS serta memeriksa pembaruan dan kedaluwarsa

Siapkan HTTPS untuk domain yang Anda kelola setelah jalur validasi domain siap, lalu terapkan sertifikat pada server web. Keberhasilan penerbitan, sertifikat yang benar-benar diterima pengguna, penjadwalan pembaruan, dan pemantauan kedaluwarsa harus diperiksa secara terpisah.

Periksa domain dan prasyarat HTTP publik

HTTPS adalah HTTP melalui koneksi TLS (Transport Layer Security) yang terenkripsi dan memverifikasi identitas server melalui sertifikat. Situs .test pada 127.0.0.1:8080 dari latihan Nginx tidak dapat dipakai begitu saja untuk penerbitan sertifikat publik. Siapkan domain nyata, DNS yang menunjuk server, server_name, document root, dan respons port 80 yang benar.

Masukkan nama domain sebenarnya tanpa skema http, jalur, atau nomor port. Siapkan dnsutils jika dig belum tersedia. Jalankan pemeriksaan dari server dan klien pada jaringan internet lain; periksa aturan host, router, dan penyedia cloud. curl -I hanya memeriksa respons HEAD, sehingga tetap perlu memeriksa isi melalui GET pada tahap berikutnya.

read -r -p "Domain yang Anda kelola: " domain
dig +short A "$domain"
dig +short AAAA "$domain"
curl -I "http://$domain/"

Jika ada rekaman AAAA, jalur IPv6 juga harus benar. Dokumentasi IPv6 Let’s Encrypt menjelaskan bahwa alamat IPv6 diprioritaskan saat validasi dan fallback ke IPv4 tidak berlaku untuk semua jenis kegagalan. Respons salah dari server IPv6 tidak selesai hanya karena server IPv4 sudah benar. Perbaiki rekaman dan jalur sesuai layanan yang benar-benar disediakan.

Siapkan situs HTTP dengan domain sebenarnya

Bagian ini untuk server Ubuntu terpisah yang dapat dicapai publik melalui domain Anda. VM host-only pada latihan IP statis tidak langsung dapat dicapai dari internet. Jika belum memiliki hosting publik atau kendali DNS, tunda penerbitan atau rancang DNS-01 memakai plugin resmi yang sesuai beserta penyimpanan kredensialnya.

Siapkan Nginx yang aktif, curl, Bash, alat shell, dan akses sudo. Atur A ke IPv4 publik yang benar serta AAAA hanya bila jalur IPv6 siap. Tinjau konfigurasi Nginx yang sudah dimuat agar nama domain ini belum ditangani oleh server block lain. Pemeriksaan jalur pada skrip berikut tidak memeriksa benturan server_name di semua konfigurasi.

Simpan seluruh blok sebagai ~/prepare-public-http.sh, lalu jalankan bash ~/prepare-public-http.sh DOMAIN_ANDA setelah mengganti argumennya dengan domain sebenarnya. Contoh memakai nama host ASCII biasa; gunakan punycode yang sudah diverifikasi untuk domain internasional. Filter sintaks ini bukan bukti kepemilikan, keberadaan DNS, atau kesiapan validasi. Nama dokumentasi seperti domain contoh IANA tidak boleh dipakai sebagai domain milik sendiri.

set -euo pipefail
if [ "$#" -ne 1 ]; then
    printf 'Pemakaian: bash prepare-public-http.sh DOMAIN_ANDA\n' >&2; exit 2
fi
domain=$(printf '%s' "$1" | tr '[:upper:]' '[:lower:]')
if [[ ! "$domain" =~ ^([a-z0-9]([a-z0-9-]*[a-z0-9])?\.)+[a-z]([a-z0-9-]*[a-z0-9])?$ ]]; then
    printf 'Gunakan nama host ASCII yang Anda kelola.\n' >&2; exit 2
fi
case "$domain" in
    *.test|*.invalid|*.localhost|*.example|example.com|*.example.com|example.org|*.example.org|example.net|*.example.net|*.local)
        printf 'Gunakan domain milik Anda yang sebenarnya, bukan nama contoh.\n' >&2; exit 2 ;;
esac
site=/etc/nginx/sites-available/ubuntu-course-public
enabled=/etc/nginx/sites-enabled/ubuntu-course-public
root_dir=/srv/ubuntu-course-public
for path in "$site" "$enabled" "$root_dir"; do
    if sudo test -e "$path" || sudo test -L "$path"; then
        printf 'Jalur latihan sudah ada: %s; hentikan dan periksa.\n' "$path" >&2; exit 1
    fi
done
backup_dir=$(sudo mktemp -d /root/nginx-before-public.XXXXXX)
sudo cp -a /etc/nginx "$backup_dir/"
sudo install -d -m 0755 "$root_dir"
printf 'public-http-lab\n' | sudo sh -c 'set -C; cat > "$1/index.html"' sh "$root_dir"
sudo chmod 0644 "$root_dir/index.html"
sudo sh -c 'set -C; cat > "$1"' sh "$site" <<EOF
server {
    listen 80;
    listen [::]:80;
    server_name $domain;
    root /srv/ubuntu-course-public;
    index index.html;
    location / {
        try_files \$uri \$uri/ =404;
    }
}
EOF
sudo ln -s "$site" "$enabled"
sudo nginx -t
sudo systemctl reload nginx
printf 'Situs HTTP siap; cadangan: %s\n' "$backup_dir"

Menurut dokumentasi server_name Nginx, nama menentukan pemilihan server block. Bila listener IPv6 tidak tersedia, sesuaikan baris listen dengan kebijakan server dan jangan mengiklankan AAAA yang tidak berfungsi. Lanjutkan hanya setelah pembuatan berkas, tautan, nginx -t, dan reload semuanya berhasil. Periksa respons baru; hasil pemeriksaan sintaks saja belum membuktikan halaman benar.

Jika skrip berhenti, periksa berkas dan tautan latihan yang sudah dibuat terhadap cadangan. Jangan menjalankannya berulang-ulang dengan memaksa penimpaan. Pertahankan situs lain; untuk membatalkan situs baru, tinjau dan lepaskan hanya tautan atau konfigurasi latihan yang dibuat, lalu uji konfigurasi sebelum reload.

Pada server publik baru dengan kebijakan yang memang mengizinkan HTTP/HTTPS dan UFW yang sudah dikelola, tambahkan aturan berikut. Pertahankan aturan SSH dan siapkan jalur 80/443 pada firewall penyedia serta router. Perintah ini tidak mengaktifkan UFW. Aturan yang hanya mengizinkan klien latihan .10 tidak cukup untuk validasi HTTP-01 dari luar.

sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw status verbose

Variabel domain dari skrip terpisah tidak tersisa pada shell pemanggil. Masukkan lagi nama yang benar dalam sesi Bash sekarang. Dari klien internet lain, pastikan GET mengembalikan penanda public-http-lab untuk nama dan jalur A/AAAA yang diharapkan sebelum beralih ke Certbot.

read -r -p "Domain yang Anda kelola: " domain
dig +short A "$domain"
dig +short AAAA "$domain"
curl --fail --show-error "http://$domain/"

HTTP-01 Let’s Encrypt memerlukan akses ke jalur challenge pada port 80; situs loopback atau sekadar port 8080 tidak menggantikannya. Jika memakai beberapa server atau proxy, pastikan jalur challenge diarahkan dengan benar. DNS-01 membuktikan kendali melalui rekaman DNS dan dapat dipakai untuk wildcard, tetapi otomatisasinya perlu dukungan DNS yang tepat.

Pilih satu jalur pemasangan Certbot

Jika Certbot sudah terpasang, periksa asal instalasi, lokasi perintah, sertifikat yang dikelola, dan pekerjaan pembaruannya terlebih dahulu. Jangan mencampur instalasi APT, Snap, dan pip. Contoh ini memakai jalur Snap resmi pada server latihan baru yang sudah mempunyai snapd dan dukungan classic. Tinjau izin classic sebelum memasang.

sudo snap install --classic certbot
/snap/bin/certbot --version

Petunjuk resmi Certbot untuk Nginx dan Snap mencakup pemasangan, penerbitan, dan pengujian pembaruan. Contoh menggunakan jalur penuh /snap/bin/certbot sehingga tidak memerlukan tautan perintah tambahan yang dapat berbenturan dengan instalasi lain.

Cadangkan dan validasi sebelum menerbitkan sertifikat

Pastikan variabel domain dalam sesi Bash yang sama berisi nama sebenarnya yang telah diperiksa. Jalankan seluruh blok berikut. set -eu menghentikannya jika cadangan atau pengujian Nginx gagal sebelum Certbot dijalankan.

(
set -eu
backup=$(sudo mktemp -d /root/nginx-before-tls.XXXXXX)
sudo cp -a /etc/nginx "$backup/"
sudo nginx -t
sudo /snap/bin/certbot --nginx -d "$domain"
)

Baca pilihan alamat email, persetujuan ketentuan, dan pengalihan HTTP ke HTTPS sebelum memutuskan. Mode --nginx dapat mengubah konfigurasi server; bandingkan perubahan dengan cadangan dan periksa lagi situs terkait. Jangan menganggap file sertifikat terbit berarti semua endpoint sudah menyajikannya.

Jika HTTP-01 tidak dapat dijangkau, pilih alternatif yang didokumentasikan untuk lingkungan itu. Kredensial API DNS harus dibatasi ke lingkup yang diperlukan dan disimpan dengan izin yang tepat; jangan menaruh rahasianya dalam perintah atau catatan publik. Selidiki DNS, port, dan log validasi sebelum mengulang permintaan yang gagal. Panduan pengguna Certbot menjelaskan plugin, pengelolaan sertifikat, dan pembaruan.

Periksa HTTPS eksternal dan sertifikat yang disajikan

Jalankan dua pemeriksaan berikut dari klien yang mewakili jalur pengguna, dengan domain yang sama. Periksa masing-masing status keluar dan responsnya.

curl --fail --show-error "https://$domain/"
openssl s_client -connect "$domain:443" -servername "$domain" -verify_return_error -verify_hostname "$domain" </dev/null

Pastikan isi halaman sesuai dan pemeriksaan nama host serta rantai kepercayaan berhasil. Pada OpenSSL s_client, -servername mengirim nama SNI, -verify_hostname memeriksa nama sertifikat, dan -verify_return_error menghentikan verifikasi yang gagal. SNI (Server Name Indication) membantu server memilih sertifikat untuk nama yang diminta. Jangan mengabaikan kesalahan sertifikat atau memakai curl -k untuk menghasilkan keberhasilan semu.

Sertifikat lokal yang baru dapat berbeda dari sertifikat pada proxy, load balancer, cache TLS, atau server IPv6 lain. Periksa jalur publik yang benar-benar dipakai, termasuk endpoint IPv4/IPv6 yang tersedia. Bila alat pemeriksa gagal karena penyimpanan CA klien tidak siap, perbaiki kepercayaan klien yang sah; jangan mematikan verifikasi.

Uji pembaruan dan pantau kedaluwarsa

sudo /snap/bin/certbot certificates
sudo /snap/bin/certbot renew --dry-run
systemctl list-timers --all | grep certbot

Perintah certificates menampilkan sertifikat yang dikelola dan tanggal kedaluwarsanya. Cocokkan juga sertifikat yang disajikan ke pengguna, misalnya melalui penampil sertifikat browser, karena daftar lokal tidak membuktikan sertifikat eksternal sama. Baca notAfter aktual dan siapkan peringatan sebelum kedaluwarsa; jangan mengasumsikan masa berlaku selalu sejumlah hari tertentu.

renew --dry-run menguji jalur pembaruan saat ini dan bukan bukti bahwa eksekusi terjadwal di masa depan pasti berhasil. Periksa timer yang benar-benar dipasang beserta layanan dan log eksekusinya, lalu pastikan ada pemantauan kegagalan. Jika grep tidak menemukan certbot, periksa mekanisme pemasangan dan penjadwalan sebenarnya sebelum menyimpulkan tidak ada pembaruan atau membuat pekerjaan duplikat.

Setelah pembaruan, pastikan endpoint publik menyajikan sertifikat baru dan respons aplikasi tetap benar. Saat memulihkan, tinjau hanya perubahan Certbot/Nginx untuk latihan ini; pertahankan sertifikat serta pengaturan pembaruan domain lain. Jangan mengembalikan seluruh cadangan di atas perubahan yang lebih baru tanpa perbandingan.