Belajar AlmaLinux - TLS, Certificates & PKI

#Pendahuluan

Di episode 14 sebelumnya kita mengamankan akses jarak jauh dengan SSH. Sekarang kita mengamankan data dalam transit melalui TLS: protokol yang melindungi semua trafik HTTPS di internet. Bagi server modern, sertifikat TLS bukan lagi opsional — tanpa HTTPS, browser menandai situs tidak aman dan banyak API menolak koneksi.

Episode ini membawa kalian dari dasar OpenSSL, membedakan jenis sertifikat, mengelola trust store sistem, mengotomatiskan sertifikat Let's Encrypt, hingga memahami konsep PKI.

#OpenSSL dan Sertifikat

OpenSSL adalah toolkit kriptografi standar Linux. Sertifikat digital bekerja dengan kriptografi asimetris: kunci pribadi (rahasia, disimpan server) dan kunci publik (dibagikan). Sertifikat adalah dokumen yang mengikat kunci publik dengan identitas, dan ditandatangani oleh otoritas yang dipercaya.

#Generate Key dan CSR

Langkah pertama membuat sertifikat: generate kunci pribadi, lalu buat CSR (Certificate Signing Request) — permintaan resmi ke CA:

openssl ecparam -name prime256v1 -genkey -out domain.key
openssl req -new -key domain.key -out domain.csr

Contoh di atas memakai kurva EC prime256v1 — modern dan cepat. Selama openssl req, kalian akan ditanya nama organisasi, nama umum (Common Name = domain), dan detail lainnya. Untuk mengotomatiskan semua jawaban, pakai file konfigurasi:

[req]
distinguished_name = dn
prompt = no
 
[dn]
CN = example.com
 
[req_ext]
subjectAltName = DNS:example.com, DNS:www.example.com

subjectAltName (SAN) adalah field modern yang menentukan domain mana yang dilindungi sertifikat — browser modern mengabaikan Common Name dan hanya membaca SAN.

#Sertifikat Self-Signed

Self-signed berarti sertifikat ditandatangani oleh dirinya sendiri, bukan CA yang dipercaya:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes

Cocok untuk lab dan testing. Browser akan menampilkan peringatan, karena tidak ada CA yang bisa memverifikasinya — jangan pernah memakai self-signed untuk produksi publik.

#Self-Signed vs CA-Signed

Sertifikat CA-signed dihasilkan dari CSR yang dikirim ke CA — Let's Encrypt, atau CA komersial — lalu CA mengembalikan sertifikat yang ditandatangani.

#Trust Store: update-ca-trust

Setiap sistem menyimpan daftar CA yang dipercaya. Di AlmaLinux, daftar ini dikelola lewat bundle CA di /etc/pki/ca-trust/ — dan diubah dengan update-ca-trust.

#Menambah CA Internal

Untuk lab dengan CA sendiri (misalnya CA internal perusahaan), tambahkan sertifikat CA ke trust store:

sudo cp internal-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Setelah itu, semua tool sistem — curl, wget, Python, Java — otomatis mempercayai sertifikat yang ditandatangani CA tersebut.

#Verifikasi Sertifikat

openssl x509 -in cert.pem -text -noout
openssl verify cert.pem

openssl verify memeriksa rantai kepercayaan terhadap trust store sistem. Jika output menampilkan OK, rantai sertifikat valid.

#Let's Encrypt dan Certbot

Let's Encrypt adalah CA gratis yang mengeluarkan sertifikat dengan masa berlaku 90 hari, diotomatiskan lewat certbot.

sudo dnf5 install -y certbot python3-certbot-nginx

Untuk web server Nginx:

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

Certbot mendeteksi konfigurasi Nginx, mengeluarkan sertifikat, dan mengonfigurasi HTTPS secara otomatis. Untuk server tanpa web server terpasang, pakai mode certonly:

sudo certbot certonly --standalone -d example.com

#Auto-Renewal

Karena sertifikat Let's Encrypt hanya 90 hari, pembaruan otomatis adalah keharusan. Certbot menyediakan systemd timer:

sudo systemctl list-timers | grep certbot
sudo certbot renew --dry-run

certbot renew --dry-run menguji proses pembaruan tanpa benar-benar memperbarui — ritual wajib dijadwalkan secara berkala agar kegagalan renewal tidak mengejutkan kalian di hari ke-90.

#Dasar PKI: OCSP dan CRL

PKI (Public Key Infrastructure) adalah ekosistem lengkap CA, sertifikat, dan mekanisme pembatalan. Dua mekanisme pembatalan yang perlu dikenal:

Saat sertifikat bocor kunci pribadinya, ia harus dibatalkan. Verifikasi status OCSP sebuah sertifikat:

openssl ocsp -issuer ca.crt -cert server.crt -url http://ocsp.ca.example

Memahami PKI membuat kalian mampu mengelola CA internal — berguna untuk lab, VPN, dan lingkungan enterprise yang butuh sertifikat untuk banyak service internal.

#Kesalahan Umum (Common Pitfalls)

1. Memakai self-signed di produksi. Gunakan Let's Encrypt atau CA komersial untuk layanan publik.
2. Melupakan SAN. Sertifikat yang hanya mencantumkan Common Name ditolak browser modern — selalu sertakan subjectAltName.
3. Menonaktifkan verifikasi TLS untuk "mempercepat". Jangan pernah menonaktifkan validasi sertifikat di klien production.
4. Mengabaikan renewal. Sertifikat yang kedaluwarsa menyebabkan downtime — pasang timer dan uji --dry-run.
5. Lupa update-ca-trust setelah menambah CA. Menyalin file saja tidak cukup; bundle baru diterapkan hanya setelah perintah itu.

#Penutup

Pada episode 15 ini kalian telah membangun fondasi enkripsi: generate key dan CSR dengan OpenSSL, perbedaan self-signed dan CA-signed, pengelolaan trust store dengan update-ca-trust, otomasi sertifikat Let's Encrypt dengan certbot, serta pengenalan PKI dengan OCSP dan CRL.

Inti yang harus dibawa pulang:

• OpenSSL menghasilkan kunci, CSR, dan sertifikat; sertakan subjectAltName di semua request.
• Self-signed untuk lab, CA-signed untuk produksi — pakai Let's Encrypt untuk gratis.
• Trust store sistem dikelola dengan update-ca-trust setelah menambah CA ke /etc/pki/ca-trust/source/anchors/.
• Certbot mengotomatiskan penerbitan dan renewal — verifikasi timer dan --dry-run.
• OCSP dan CRL adalah mekanisme pembatalan sertifikat dalam PKI.

Dengan enkripsi berjalan, kalian siap membangun pertahanan menyeluruh. Di episode 16 selanjutnya, kita akan membahas Security Compliance & Hardening — OpenSCAP dan profil SCAP, baseline CIS Benchmarks dan STIG, tool audit lynis, pemantauan integritas dengan AIDE, serta antivirus ClamAV. Sampai jumpa!