SSD Nodes Learn Hosting plans →
Panduan Matt ConnorOleh Matt Connor

Cara Membuat Sertifikat Self-Signed di Ubuntu 24.04

Buat sertifikat TLS self-signed yang diterima Chrome di Ubuntu 24.04 dengan SAN, satu perintah openssl, konfigurasi nginx atau Apache, dan trust tanpa curl -k.

Yang Anda bangun

Sertifikat TLS yang ditandatangani sendiri dan benar-benar diterima browser serta klien modern, subjectAltName yang benar, izin kunci yang sesuai, terhubung ke nginx atau Apache, serta bagian yang hampir selalu dilewatkan panduan: membuat klien memercayainya dengan benar, bukan melewati peringatan dan menanamkan curl -k secara permanen dalam skrip. Pada akhirnya, tersedia CA privat dengan lima perintah untuk digunakan ketika satu layanan internal berkembang menjadi enam.

Pertama, tentukan kebutuhannya, karena sertifikat yang ditandatangani sendiri jauh lebih jarang menjadi pilihan yang tepat daripada frekuensi penggunaannya. Jika layanan dapat dijangkau dari Internet publik melalui nama DNS yang sebenarnya, berhentilah membaca dan gunakan sertifikat Let's Encrypt gratis dengan certbot pada nginx atau padanan untuk Apache. Sertifikat tersebut tidak berbayar, diperbarui secara otomatis, dan sudah dipercaya oleh browser serta sistem operasi utama. Sertifikat yang ditandatangani sendiri pada situs publik membiasakan pengguna mengeklik untuk melewati peringatan keamanan. Kebiasaan ini lebih buruk daripada menggunakan HTTP biasa.

Sertifikat yang ditandatangani sendiri tepat digunakan jika Internet publik tidak terlibat: panel admin yang terikat pada alamat tunnel WireGuard di VPS Anda, server staging pada jaringan privat, trafik antar-layanan antarbackend, perangkat home lab, atau penggantian sertifikat placeholder yang dibuat Webmin untuk dirinya sendiri pada port 10000. Let's Encrypt juga tidak dapat menerbitkan sertifikat untuk 10.8.0.1 atau git.internal.lan. Tidak ada CA publik yang akan memasukkan alamat IP privat atau TLD buatan ke dalam sertifikat. Untuk nama-nama tersebut, Anda berperan sebagai CA.

Semua langkah di bawah ini dijalankan pada mesin Ubuntu 24.04 yang masih baru. Sistem ini menyertakan OpenSSL 3.0.x (openssl version untuk konfirmasi). Tidak ada langkah yang memerlukan akses Internet. Semuanya dapat dijalankan dalam lingkungan air-gapped.

Mengapa one-liner lama menghasilkan sertifikat yang ditolak Chrome

Perintah yang diberikan oleh setiap tutorial sebelum 2017 biasanya terlihat seperti ini:

# Do not run this: shown so you recognise it in old guides
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout selfsigned.key -out selfsigned.crt

Perintah tersebut mengajukan serangkaian pertanyaan interaktif, memasukkan hostname Anda ke kolom Common Name, dan menghasilkan sertifikat tanpa ekstensi subjectAltName. Sertifikat itu langsung tidak dapat digunakan. Chrome berhenti membaca Common Name pada versi 58, pada April 2017. RFC 2818 bahkan telah menyatakan pencocokan CN usang sejak tahun 2000. Firefox dan Safari berperilaku sama. curl dan modul ssl milik Python masih menggunakan Common Name sebagai fallback jika sertifikat sama sekali tidak memiliki SAN. Karena itu, sertifikat tanpa SAN dapat lolos dalam pengujian singkat dengan curl, tetapi tetap gagal di semua browser. Bagi browser, sertifikat mengidentifikasi server melalui ekstensi SAN atau tidak sama sekali. Browser akan memberi tahu Anda dengan kata-kata berikut:

NET::ERR_CERT_COMMON_NAME_INVALID

This server could not prove that it is git.internal.lan; its security
certificate does not specify Subject Alternative Names.

Mengubah trust store tidak akan memperbaiki error tersebut, karena sertifikat itu memang tidak mencantumkan nama apa pun. Jika Anda sedang melihat NET::ERR_CERT_COMMON_NAME_INVALID, sertifikat Anda tidak memiliki SAN (atau SAN-nya salah), dan Anda perlu menerbitkan sertifikat baru. Untungnya, perbaikannya hanya memerlukan satu perintah.

Buat sertifikat yang diterima browser: satu perintah

OpenSSL menambahkan flag -addext pada versi 1.1.1. Artinya, Anda tidak lagi memerlukan konfigurasi file yang rumit seperti pada panduan lama untuk menyisipkan SAN. Pada Ubuntu 24.04:

sudo openssl req -x509 -newkey rsa:4096 -sha256 -days 730 -noenc \
  -keyout /etc/ssl/private/git.internal.key \
  -out /etc/ssl/certs/git.internal.crt \
  -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"

Fungsi setiap flag:

  • -x509 membuat sertifikat yang ditandatangani sendiri secara langsung, bukan permintaan penandatanganan.
  • -newkey rsa:4096 membuat key baru dalam langkah yang sama. RSA 4096 kompatibel dengan client lama. Jika semua koneksi menggunakan client modern, -newkey ec -pkeyopt ec_paramgen_curve:P-256 berukuran lebih kecil dan lebih cepat.
  • -noenc adalah penulisan OpenSSL 3.x untuk -nodes versi lama: key tidak menggunakan passphrase. Kedua penulisan tersebut dapat digunakan. Jika key menggunakan passphrase, nginx akan berhenti dan menunggu input setiap kali boot. Karena itu, gunakan opsi ini untuk key server.
  • -days 730 menetapkan masa berlaku selama dua tahun. Angka tersebut dijelaskan lebih lanjut pada bagian masa berlaku.
  • -subj memberikan jawaban atas pertanyaan interaktif secara langsung. CN kini hanya bersifat kosmetik, tetapi tetap tetapkan ke nama utama. Beberapa tool masih menampilkannya.
  • -addext "subjectAltName=..." adalah flag utama. Cantumkan setiap nama dan setiap IP yang akan diketik client: entri DNS: untuk hostname (wildcard seperti DNS:*.internal.lan dapat digunakan), serta entri IP: untuk alamat IP. Jika ada yang akan mengakses https://10.8.0.1, entri IP:10.8.0.1 harus dicantumkan. SAN yang hanya berisi DNS akan menimbulkan NET::ERR_CERT_COMMON_NAME_INVALID lagi.

Pastikan SAN benar-benar tercantum sebelum menghubungkan konfigurasi apa pun:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -ext subjectAltName

Output yang benar:

X509v3 Subject Alternative Name:
    DNS:git.internal.lan, IP Address:10.8.0.1

Jika perintah tersebut justru menampilkan No extensions in certificate, berarti sertifikat tidak memiliki SAN dan akan ditolak oleh browser. Buat ulang sertifikat tersebut, jangan lanjutkan ke langkah berikutnya.

Amankan kunci

Private key yang dapat dibaca oleh setiap user pada server bukan lagi private key. Pada instalasi standar Ubuntu 24.04, /etc/ssl/private sudah memiliki izin 700 root:root, sehingga hanya root yang bahkan dapat mencantumkannya; izin tersebut menjadi 710 root:ssl-cert hanya jika sesuatu memasang paket ssl-cert (apache2 merekomendasikannya). Apa pun kondisinya, tetapkan izin file secara eksplisit:

sudo chown root:root /etc/ssl/private/git.internal.key
sudo chmod 600 /etc/ssl/private/git.internal.key

nginx dan Apache sama-sama membaca sertifikat sebagai root sebelum menurunkan hak akses, sehingga mode root:root 600 dapat digunakan. Jika kunci digunakan oleh service yang berjalan sebagai usernya sendiri dan memuat kunci tersebut secara langsung, misalnya aplikasi Node, Gitea, atau daemon Python, chown kunci tersebut kepada user service itu, tetap dengan mode 600. Jangan pernah menggunakan mode 644, menyimpan salinannya di repositori git, atau menyimpan salinannya di /tmp.

Hubungkan ke nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name git.internal.lan;

    ssl_certificate     /etc/ssl/certs/git.internal.crt;
    ssl_certificate_key /etc/ssl/private/git.internal.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}
sudo nginx -t && sudo systemctl reload nginx

nginx -t harus menampilkan syntax is ok dan test is successful sebelum reload melakukan apa pun. Jika yang ditampilkan adalah SSL_CTX_use_PrivateKey_file() failed ... key values mismatch, sertifikat dan kunci berasal dari dua proses pembuatan yang berbeda. Lihat bagian mode kegagalan.

Konfigurasikan pada Apache

sudo a2enmod ssl proxy proxy_http

ssl saja tidak cukup di sini: vhost di bawah menggunakan ProxyPass, dan tanpa mod_proxy serta mod_proxy_http, pengujian konfigurasi gagal dengan Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration. Simpan vhost sebagai /etc/apache2/sites-available/git-internal.conf:

<VirtualHost *:443>
    ServerName git.internal.lan
    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/git.internal.crt
    SSLCertificateKeyFile   /etc/ssl/private/git.internal.key

    ProxyPass        / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>
sudo a2ensite git-internal
sudo apache2ctl configtest && sudo systemctl reload apache2

configtest seharusnya merespons pada Syntax OK. Sekarang lakukan pengujian dari mesin klien:

curl -v https://git.internal.lan/

dan Anda akan mendapatkan error:

curl: (60) SSL certificate problem: self-signed certificate

Itu bukan bug. Itu adalah TLS yang bekerja: curl belum mengenal sertifikat Anda dan menolak berkomunikasi dengan server yang tidak dapat diautentikasi. Bagian berikutnya berisi perbaikan yang sebenarnya, dan bukan cara yang dilakukan banyak orang di Internet saat ini.

Membuat klien mempercayainya dan pola anti yang harus dihindari

Berikut perbaikan yang salah terlebih dahulu, beserta namanya. curl -k (atau --insecure) yang ditanam langsung dalam script, verify=False pada Python requests, dan NODE_TLS_REJECT_UNAUTHORIZED=0 pada Node tidak membuat sertifikat Anda tepercaya. Semua itu menonaktifkan verifikasi sertifikat, sehingga klien akan berkomunikasi dengan server apa pun yang menyajikan sertifikat apa pun, termasuk sertifikat yang ditempatkan penyerang di jalur komunikasi. Anda tetap menanggung overhead TLS, tetapi kehilangan autentikasi yang menjadi tujuan TLS. Yang lebih buruk, flag tersebut mudah menyebar: ditempelkan ke satu cron job, lalu ke deploy script, kemudian ke kode produksi, sampai tidak ada yang ingat koneksi mana yang seharusnya hanya bersifat sementara. Jika sebuah verify=False tetap ada setelah sesi debugging yang memunculkannya selesai, desainnya salah.

Perbaikan yang benar adalah mengajarkan OS setiap klien bahwa sertifikat ini merupakan root tepercaya. Pada klien Ubuntu dan Debian:

sudo cp git.internal.crt /usr/local/share/ca-certificates/git.internal.crt
sudo update-ca-certificates

Baris yang penting dalam output tersebut (diikuti oleh blok Running hooks in /etc/ca-certificates/update.d...):

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Ada dua hal yang sering terlewat dalam baris tersebut. File harus diakhiri dengan .crt. Ekstensi .pem diabaikan secara diam-diam, lalu Anda mendapatkan 0 added tanpa pesan error. Isi file juga harus berformat PEM; file dimulai dengan -----BEGIN CERTIFICATE-----. Konversikan biner DER terlebih dahulu menggunakan openssl x509 -inform der -in file.der -out file.crt. Menambahkan sertifikat self-signed itu sendiri sebagai root berfungsi karena sertifikat self-signed memang merupakan root-nya sendiri.

Setelah itu, curl, wget, git, apt, dan apa pun yang menggunakan OpenSSL terhadap system bundle akan mempercayai server tanpa flag apa pun. Sejumlah kecil klien memiliki trust store sendiri dan memerlukan penanganan khusus:

  • Chrome/Chromium di Linux membaca database NSS, bukan system store: sudo apt install libnss3-tools, lalu certutil -d sql:$HOME/.local/share/pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt untuk setiap pengguna. Path tersebut menjadi default Chrome sejak versi 146. Jika pengguna masih memiliki ~/.pki/nssdb lama dari instalasi sebelumnya, Chrome tetap membacanya. Karena itu, arahkan -d ke sql:$HOME/.pki/nssdb pada mesin tersebut.
  • Firefox memiliki store sendiri: Settings → Privacy & Security → Certificates → Import. Pada Windows dan macOS, Anda juga dapat mengubah security.enterprise_roots.enabled menjadi true di about:config agar Firefox membaca store OS. Mozilla mendokumentasikan preferensi tersebut untuk Windows dan macOS, bukan Linux. Karena itu, pada Ubuntu gunakan import.
  • Python requests menyertakan CA bundle sendiri (certifi) dan mengabaikan system store: teruskan verify="/usr/local/share/ca-certificates/git.internal.crt" atau export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt.
  • Node.js secara default menggunakan root yang disertakan dalam paketnya sendiri: export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt, atau minta Node membaca system store yang baru saja Anda perbarui dengan flag --use-system-ca (Node 23.9 dan versi lebih baru di Linux) atau NODE_USE_SYSTEM_CA=1 (Node 24.6 serta Node 22.19 dan versi lebih baru).

Pada klien Windows, klik dua kali .crt dan instal ke Trusted Root Certification Authorities. Pada macOS, tambahkan sertifikat tersebut ke System keychain melalui Keychain Access, lalu tandai sebagai Always Trust.

Satu root untuk banyak service: private CA kecil

Kepercayaan per sertifikat segera tidak lagi skalabel: enam service dikalikan empat mesin klien berarti dua puluh empat instalasi kepercayaan, dan setiap service baru menambah jumlah tersebut. Solusinya adalah private CA. Klien mempercayai satu root, lalu Anda menandatangani sertifikat setiap service dengan root tersebut.

Pilihan yang praktis adalah mkcert, yang tersedia di repositori Ubuntu 24.04 dan menangani penyimpanan NSS (Firefox dan Chrome, dengan satu pengecualian di bawah) yang tidak ditangani oleh update-ca-certificates:

sudo apt install -y mkcert libnss3-tools
mkcert -install
mkcert git.internal.lan "*.internal.lan" 10.8.0.1

mkcert -install membuat root dan mendaftarkannya di penyimpanan sistem, penyimpanan NSS browser yang dapat ditemukan, serta penyimpanan Java jika JAVA_HOME ditetapkan. Node tidak membaca penyimpanan sistem kecuali diperintahkan, jadi jalankan aplikasi Node dengan --use-system-ca (atau NODE_USE_SYSTEM_CA=1) seperti di atas, atau lakukan export NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem". Perintah ketiga menghasilkan git.internal.lan+2.pem dan git.internal.lan+2-key.pem, yang siap ditempatkan ke dalam snippet nginx atau Apache di atas. Desainnya mengasumsikan mesin pengembangan. Kunci root disimpan di komputer tempat -install dijalankan, sehingga sangat sesuai untuk laptop pengembangan dan tidak sesuai untuk armada server.

Catatannya, per Oktober 2026: mkcert hanya mencari database NSS Chrome di path lama ~/.pki/nssdb, bukan di ~/.local/share/pki/nssdb, yang digunakan Chrome secara default sejak versi 146. Pada mesin tanpa database lama tersebut, tambahkan root ke Chrome secara manual menggunakan perintah certutil dari bagian sebelumnya, dengan -i "$(mkcert -CAROOT)/rootCA.pem".

Untuk server, OpenSSL biasa dapat membuat seluruh CA dengan lima perintah:

openssl genrsa -out lab-ca.key 4096
openssl req -x509 -new -key lab-ca.key -sha256 -days 3650 \
  -out lab-ca.crt -subj "/CN=Lab Internal CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"
openssl genrsa -out git.key 2048
openssl req -new -key git.key -out git.csr -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"
openssl x509 -req -in git.csr -CA lab-ca.crt -CAkey lab-ca.key \
  -CAcreateserial -days 730 -sha256 -copy_extensions copy -out git.crt

Perangkapnya terdapat pada perintah terakhir: secara default, openssl x509 -req menghapus semua ekstensi dari CSR, termasuk SAN yang telah Anda tambahkan dengan cermat. -copy_extensions copy (opsi OpenSSL 3.x, sehingga berfungsi pada 24.04) meneruskan ekstensi tersebut. Jika opsi ini dihilangkan, sertifikat yang ditandatangani tidak memiliki SAN dan Chrome kembali menampilkan NET::ERR_CERT_COMMON_NAME_INVALID. Lakukan verifikasi dengan pemeriksaan openssl x509 -noout -ext subjectAltName yang sama seperti sebelumnya.

Distribusikan lab-ca.crt ke klien melalui langkah trust-store di atas, satu kali untuk setiap mesin. Lindungi lab-ca.key seperti kredensial yang sangat sensitif: gunakan mode 600, dan idealnya simpan di komputer yang bukan salah satu server yang ditandatanganinya. Siapa pun yang memegangnya dapat membuat sertifikat untuk nama apa pun yang akan dipercaya oleh klien Anda.

Masa berlaku dan rotasi

Masa berlaku sertifikat CA publik terus dipersingkat. CA/Browser Forum membatasi sertifikat tepercaya publik yang baru diterbitkan hingga 200 hari pada Maret 2026, turun dari 398 hari, lalu menjadi 100 hari pada 2027 dan 47 hari pada Maret 2029. Namun, aturan tersebut hanya berlaku bagi CA tepercaya publik. CA privat Anda tidak diatur oleh aturan tersebut, dan browser tidak memberlakukannya terhadap root yang diinstal secara manual. Ada satu batasan nyata yang berlaku: platform Apple menolak sertifikat server TLS dengan masa berlaku lebih dari 825 hari, siapa pun penerbitnya. Jadi, jika iPhone atau Mac akan terhubung, gunakan sertifikat leaf dengan masa berlaku paling lama dua tahun. -days 730 memenuhi batas tersebut di semua platform. Root dengan masa berlaku sepuluh tahun dan sertifikat leaf dengan masa berlaku dua tahun merupakan konfigurasi internal yang praktis.

Sertifikat dengan masa berlaku panjang hanya gagal dengan satu cara: kedaluwarsa secara diam-diam dan serentak pada tanggal yang tidak diingat siapa pun. Periksa sertifikat yang ada:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -enddate

Masukkan pembaruan ke kalender yang sebenarnya, atau gunakan cron untuk mengingatkan Anda 30 hari sebelumnya. openssl x509 -checkend 2592000 -in cert.crt keluar dengan kode nonzero setelah masa berlaku tersisa dalam jumlah detik tersebut. Jika Anda sudah menjalankan Uptime Kuma untuk pemantauan status, monitor HTTPS-nya akan menandai sertifikat yang masa berlakunya akan segera berakhir tanpa biaya tambahan.

Rotasi dengan CA privat cukup sederhana: jalankan kembali perintah CSR dan penandatanganan, ganti file, lalu reload web server. Root tidak berubah, sehingga tidak ada klien yang menyadarinya.

Mode kegagalan dan string yang akan Anda lihat

NET::ERR_CERT_AUTHORITY_INVALID, ini adalah kondisi yang diharapkan sebelum Anda memasang trust, bukan cacat pada sertifikat. Jika kondisi ini tetap muncul setelah Anda memasang root: di Linux, Chrome membaca NSS, bukan certificate store sistem (lihat langkah certutil), dan sejak Chrome 146, database tersebut berada di ~/.local/share/pki/nssdb, kecuali terdapat ~/.pki/nssdb lama. Karena itu, root yang ditambahkan ke path lain tidak akan pernah terdeteksi; atau file yang disalin tidak berakhiran .crt dan update-ca-certificates menampilkan 0 added; atau server menyajikan sertifikat yang berbeda dari sertifikat yang Anda percayai. Bandingkan fingerprint menggunakan openssl s_client -connect git.internal.lan:443 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256.

NET::ERR_CERT_COMMON_NAME_INVALID, sertifikat tidak memiliki SAN, atau SAN tidak mencakup nama pada address bar. Kasus yang umum: SAN mencantumkan DNS:git.internal.lan, tetapi pengguna membuka https://10.8.0.1. Perubahan pada trust store tidak dapat memperbaiki masalah ini. Terbitkan ulang sertifikat dengan entri yang belum ada.

curl: (60) SSL certificate problem: self-signed certificate, curl tidak mempercayai sertifikat tersebut. Varian self-signed certificate in certificate chain memiliki arti yang sama untuk sertifikat yang ditandatangani oleh CA privat Anda. Perbaikan sementara: curl --cacert lab-ca.crt https://.... Perbaikan permanen: trust store. Jangan gunakan -k.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (atau Expecting: CERTIFICATE REQUEST, atau no start line), terjadi kebingungan format PEM. Anda memberikan jenis file yang salah kepada OpenSSL: key atau CSR ketika OpenSSL mengharapkan sertifikat, atau file biner DER ketika OpenSSL mengharapkan PEM. head -1 filename menunjukkan jenis file yang sebenarnya Anda miliki. Sertifikat diawali dengan -----BEGIN CERTIFICATE-----. Untuk DER, lakukan konversi dengan openssl x509 -inform der -in file.der -out file.crt.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch), sertifikat dan key tidak berpasangan, biasanya karena perintah pembuatan dijalankan dua kali dan file-file tersebut tertukar. Konfirmasikan dengan membandingkan openssl x509 -in git.internal.crt -noout -pubkey | sha256sum dan openssl pkey -in git.internal.key -pubout | sha256sum. Hash yang sama berarti keduanya merupakan pasangan yang sesuai. Jika berbeda, buat ulang keduanya secara bersamaan.

FAQ

Mengapa Chrome masih menampilkan "Not secure" setelah saya membuat sertifikat yang ditandatangani sendiri?

Jika errornya adalah NET::ERR_CERT_AUTHORITY_INVALID, sertifikatnya baik. Chrome hanya belum memiliki alasan untuk mempercayainya. Instal sertifikat tersebut (atau root private CA Anda) ke trust store klien. Ingat, di Linux, Chrome menggunakan database NSS melalui certutil (di ~/.local/share/pki/nssdb sejak Chrome 146, atau ~/.pki/nssdb lama jika tersedia), bukan system store. Jika errornya adalah NET::ERR_CERT_COMMON_NAME_INVALID, sertifikat tidak memiliki Subject Alternative Name yang cocok dengan URL dan harus diterbitkan ulang dengan -addext "subjectAltName=...".

Bagaimana cara membuat curl mempercayai sertifikat yang ditandatangani sendiri tanpa -k?

Salin sertifikat (format PEM, ekstensi .crt) ke /usr/local/share/ca-certificates/, lalu jalankan sudo update-ca-certificates. Output harus menyatakan 1 added. Setelah itu, curl memverifikasinya seperti sertifikat publik lainnya. Untuk satu permintaan tanpa mengubah sistem, curl --cacert /path/to/cert.crt memverifikasi hanya terhadap file tersebut; -k menonaktifkan verifikasi sepenuhnya dan tidak boleh digunakan dalam skrip apa pun.

Berapa lama sertifikat yang ditandatangani sendiri dapat berlaku?

Secara teknis, selama yang Anda inginkan. Batas CA/Browser Forum (200 hari saat ini, 47 pada 2029) berlaku untuk CA yang dipercaya publik, bukan trust privat. Dalam praktiknya, batasi sertifikat server hingga 825 hari karena perangkat Apple menolak sertifikat yang lebih lama, terlepas dari penerbitnya. Root privat yang berlaku selama 10 tahun dengan sertifikat leaf dua tahun (-days 730) merupakan default yang wajar. Jadwalkan pembaruannya karena sertifikat internal yang kedaluwarsa dapat membuat seluruh layanan tidak berfungsi tanpa tanda yang jelas pada tanggal yang tidak diingat siapa pun.

Sebaiknya saya menggunakan sertifikat yang ditandatangani sendiri atau Let's Encrypt?

Jika service memiliki nama DNS publik dan dapat dijangkau dari Internet, selalu gunakan Let's Encrypt karena gratis, otomatis, dan sudah dipercaya oleh sebagian besar browser serta sistem operasi. Periksa daftar kompatibilitas Let's Encrypt jika perangkat yang sangat lama harus terhubung. Sertifikat yang ditandatangani sendiri (atau private CA) digunakan untuk hal-hal yang tidak dapat diterbitkan oleh Let's Encrypt: IP privat, hostname internal seperti .lan, jaringan air-gapped, dan service yang sengaja disembunyikan di balik VPN. Keputusan ini bergantung pada keterjangkauan dan penamaan, bukan kekuatan keamanan. Kriptografinya sama.

Mengapa sertifikat saya ditolak meskipun sudah ditambahkan ke /usr/local/share/ca-certificates?

Periksa 3 hal. File harus diakhiri dengan .crt. Ekstensi .pem akan dilewati secara diam-diam, dan update-ca-certificates melaporkan 0 added. Isinya harus berupa teks PEM yang diawali -----BEGIN CERTIFICATE-----, bukan biner DER. Selain itu, aplikasi harus benar-benar menggunakan system store. Chrome di Linux, Firefox, Python requests, Node.js (kecuali dijalankan dengan --use-system-ca), dan Java masing-masing menggunakan trust store privat dan memerlukan penambahan sertifikat secara terpisah.

#openssl#tls#self-signed#ubuntu#security