54. Menggunakan Self-signed Certificate: Panduan Lengkap untuk Software Engineer

Keamanan adalah aspek fundamental dalam pengembangan perangkat lunak, terutama ketika aplikasi kita berinteraksi melalui jaringan. Mulai dari API internal, komunikasi antar-microservices, hingga proses pengembangan lokal, penggunaan protokol HTTPS (Hypertext Transfer Protocol Secure) sudah menjadi standar, bukan lagi pengecualian. Namun, sering kali kita dihadapkan dengan kendala terkait sertifikat SSL, seperti biaya, manajemen, atau sekadar eksperimen lokal. Di sinilah self-signed certificate (sertifikat yang ditandatangani sendiri) punya peran krusial.

Pada artikel kali ini, saya akan membahas secara komprehensif cara membuat, menggunakan, serta memahami risiko dan keunggulan menggunakan self-signed certificate. Saya juga akan menampilkan kode praktis, simulasi skenario, dan diagram yang membantu kamu sebagai software engineer mengambil keputusan yang tepat ketika mengimplementasikannya.

Apa Itu Self-signed Certificate?

Self-signed certificate adalah sertifikat SSL/TLS yang tidak ditandatangani oleh Certificate Authority (CA) publik, melainkan ditandatangani langsung oleh entitas pembuat (misal, server Anda sendiri).

Di lingkungan produksi, certificate yang sah biasanya dikeluarkan oleh CA resmi seperti Let’s Encrypt, DigiCert, atau Comodo. Namun pada staging atau local environment, engineer sering cukup dengan self-signed certificate untuk menguji fitur berbasis HTTPS.

Kapan Sebaiknya Menggunakan Self-signed Certificate?

Cara Membuat Self-signed Certificate dengan OpenSSL

Alat paling umum untuk menghasilkan self-signed certificate adalah OpenSSL, tersedia secara luas di sistem operasi modern.

Step-by-step Membuat Sertifikat

1. Generate Private Key

openssl genrsa -out key.pem 2048

2. Generate Certificate Signing Request (CSR)

openssl req -new -key key.pem -out csr.pem

Selama proses ini, kamu akan diminta mengisi beberapa informasi, seperti Country Name, State, Common Name (isikan domain/server name yang ingin diamankan, misal localhost).

3. Generate Self-signed Certificate

openssl x509 -req -days 365 -in csr.pem -signkey key.pem -out cert.pem

Kini kamu punya dua file penting:

• cert.pem : publik sertifikat
• key.pem : private key (jaga kerahasiaannya!)

Struktur File

Simulasi Implementasi pada Aplikasi Node.js

Mari simulasikan bagaimana self-signed certificate digunakan pada server Node.js sederhana dengan HTTPS.

Struktur Project

/my-https-app
├── cert.pem
├── key.pem
└── server.js

Kode Server (server.js)

const https = require('https');
const fs = require('fs');
const path = require('path');

const options = {
  key: fs.readFileSync(path.join(__dirname, 'key.pem')),
  cert: fs.readFileSync(path.join(__dirname, 'cert.pem'))
};

https.createServer(options, (req, res) => {
  res.writeHead(200);
  res.end('Hello, HTTPS with Self-signed Certificate!');
}).listen(8443, () => {
  console.log('Server running at https://localhost:8443');
});

Simulasi Pengujian

Coba akses https://localhost:8443 dari browser. Browser umumnya akan memperingatkan bahwa sertifikat “untrusted” — hal ini normal karena sertifikat kamu tidak diakui otoritas publik.

Tips: Untuk bypass di development, lanjutkan dan “accept the risk”.

Bagaimana Browser/Client Memvalidasi Sertifikat?

Mari lihat diagram alur validasi TLS client terhadap self-signed certificate:

flowchart TD
    A[Client Request ke HTTPS Server] --> B[Server mengirimkan Public Certificate]
    B --> C{Trusted CA?}
    C --Tidak--> D[Tampilkan Warning atau Tolak Koneksi]
    C --Ya--> E[Lanjutkan SSL Handshake]
    D --> F[User Bisa Lanjut (Manual)]

Dengan self-signed certificate, proses validasi berhenti di “Tidak”, sehingga browser/client akan menolak atau menampilkan peringatan.

Risiko & Best Practice Penggunaan Self-signed Certificate

Risiko

1. Tidak Dipercaya Secara Default: Klien akan menerima peringatan keamanan setiap kali terkoneksi.
2. Rentan MITM jika digunakan di public network: Karena siapa saja bisa membuat sertifikat serupa.
3. Tidak cocok untuk produksi/publik website: SSL Labs dan search engine akan menganggap koneksi tidak aman.

Best Practice

• Batasi pada environment internal/development.
• Jangan komit file key.pem ke version control.
• Kelola expiry certificate — perhatikan masa berlaku agar tidak terjadi error tiba-tiba.
• Bisa tambahkan self-signed certificate ke trusted store di client bila diperlukan (misal untuk automated testing dengan curl, postman, atau CI/CD pipeline).

Cara Automasi pada Docker Compose

Simulasi: Deploy service berbasis HTTPS dengan Docker Compose dan self-signed certificate.

Contoh docker-compose.yml:

version: "3"
services:
  web:
    image: node:18
    volumes:
      - ./server.js:/app/server.js
      - ./cert.pem:/app/cert.pem
      - ./key.pem:/app/key.pem
    working_dir: /app
    command: ["node", "server.js"]
    ports:
      - "8443:8443"

Cara Menambahkan ke CA Lokal (Testing Automation)

Misal pada mesin Linux, tambahkan self-signed cert ke trusted CA:

sudo cp cert.pem /usr/local/share/ca-certificates/my-app-cert.crt
sudo update-ca-certificates

Catatan: Lakukan ini hanya di mesin pengembangan/testing, jangan di laptop pengguna produksi.

Kesimpulan

Self-signed certificate solusi cepat dan praktis untuk lingkungan development atau kebutuhan internal, tanpa beban biaya dan manajemen CA eksternal, asalkan penggunaannya tepat. Sebagai engineer, pahami alur validasi, risiko keamanan, serta cara mitigasinya.

Untuk production, tetap gunakan CA resmi agar user percaya pada aplikasi yang kamu bangun. Namun, untuk prototyping dan pengujian, self-signed certificate jelas menghemat banyak waktu!

Melalui artikel ini, semoga kamu kini lebih mantap menggunakan self-signed certificate sebagai bagian integral dari workflow pengembangan aplikasi modern. Selamat ber-eksperimen dan tetap prioritaskan keamanan!

Referensi dan Bahan Bacaan Tambahan

• OpenSSL Documentation
• Node.js HTTPS API
• Let’s Encrypt vs Self-signed
• SSL Labs SSL Test