SSD Nodes Learn 🎉 VPS mulai $5.50/bln
Panduan Matt ConnorOleh Matt Connor

Cara Menambahkan CA Sendiri ke Trust Store Ubuntu

Buat CA privat dengan openssl, terbitkan sertifikat leaf, lalu pasang root di /usr/local/share/ca-certificates agar Ubuntu mempercayai HTTPS internal.

Tambahkan CA Anda sendiri ke trust store Ubuntu

Untuk menambahkan CA Anda sendiri ke trust store Ubuntu, salin sertifikat root ke /usr/local/share/ca-certificates/ dengan nama yang diakhiri .crt, lalu jalankan sudo update-ca-certificates. CA (certificate authority) adalah pasangan kunci yang sertifikatnya diizinkan untuk menandatangani sertifikat lain. Setelah mesin mempercayai root Anda, setiap sertifikat yang ditandatangani root tersebut akan diterima. Dengan demikian, verifikasi HTTPS antarservice Anda tidak lagi gagal.

Panduan ini membuat seluruh rantai secara offline menggunakan openssl. Anda membuat kunci root dan sertifikat root, menerbitkan satu sertifikat leaf untuk server, lalu memasang root dan memantau perubahan hasil dari perintah verifikasi yang sama. Urutan ini penting. Verifikasi sebelum dan sesudah pemasangan menunjukkan bahwa pemasangan tersebut yang mengubah hasilnya.

Ubuntu 24.04 menyediakan OpenSSL 3 dan paket ca-certificates pada image default, sehingga tidak ada yang perlu dipasang terlebih dahulu (diperiksa pada August 2026).

Kapan Anda perlu menjalankan CA sendiri?

CA publik seperti Let's Encrypt memerlukan nama di DNS publik dan server yang dapat dijangkaunya. Nama internal tidak memenuhi syarat. Database pada jaringan privat atau panel admin yang terikat pada tunnel tidak dapat memperoleh sertifikat publik. Keduanya juga tidak boleh diekspos ke Internet hanya untuk mendapatkan sertifikat.

Sertifikat yang ditandatangani sendiri di Ubuntu hanya menyelesaikan masalah pada satu host. Setiap klien harus memercayai sertifikat tersebut. Saat host berikutnya ditambahkan, pekerjaan yang sama harus diulangi. CA privat memindahkan keputusan tersebut satu tingkat ke atas. Klien cukup memercayai root satu kali. Setelah itu, setiap sertifikat yang ditandatangani oleh root akan dipercaya, termasuk sertifikat untuk host yang belum ada.

Biayanya nyata. Kunci root dapat menandatangani apa pun yang diizinkan oleh batasan yang berlaku. Karena itu, siapa pun yang dapat membaca ca.key dapat menerbitkan sertifikat yang akan diterima oleh mesin Anda. Lindungi kunci tersebut seperti Anda melindungi kunci privat dalam manajemen kunci SSH. Jika sebuah service memiliki nama DNS publik, lewati semua langkah ini dan gunakan CA publik: Certbot dengan nginx dan Let's Encrypt memerlukan lebih sedikit pekerjaan dan tidak memerlukan instalasi apa pun di sisi klien.

Buat kunci CA dan sertifikat root

Gunakan direktori yang hanya dapat dibuka oleh user Anda. Kunci root tidak boleh keluar dari direktori tersebut.

install -d -m 700 ~/ca
cd ~/ca
openssl genrsa -aes256 -out ca.key 4096
chmod 600 ca.key

-aes256 mengenkripsi kunci dengan passphrase yang Anda pilih. Setiap perintah berikutnya yang menandatangani dengan kunci ini akan memintanya. Jika -aes256 tidak digunakan, kunci tersimpan dalam bentuk teks biasa di disk. Dengan demikian, backup atau akun admin kedua sudah cukup untuk memberi seseorang kemampuan menerbitkan sertifikat yang dipercaya oleh mesin Anda.

Selanjutnya, buat sertifikat root yang ditandatangani oleh kunci CA itu sendiri.

openssl req -x509 -new -key ca.key -sha256 -days 3650 \
  -subj "/O=Example Internal/CN=Example Internal Root CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -addext "subjectKeyIdentifier=hash" \
  -addext "nameConstraints=critical,permitted;DNS:internal.example" \
  -out ca.crt

Ganti internal.example dengan akhiran nama yang benar-benar Anda gunakan. Baca bagian berikutnya sebelum mempertahankan ekstensi terakhir tersebut.

Setiap ekstensi memiliki satu fungsi.

  • basicConstraints dengan CA:TRUE menjadikan ini sertifikat CA. Tanpa ekstensi tersebut, klien menolak sertifikat apa pun yang ditandatangani oleh kunci ini, meskipun tanda tangannya benar.
  • pathlen:0 menyatakan bahwa CA boleh menandatangani sertifikat leaf, tetapi tidak boleh ada CA lain di bawahnya.
  • keyUsage membatasi kunci agar hanya digunakan untuk menandatangani sertifikat dan daftar pencabutan. Dengan demikian, kunci yang sama tidak dapat keliru digunakan sebagai kunci server TLS.
  • subjectKeyIdentifier memberikan identifier kepada root yang menjadi rujukan sertifikat leaf. Dengan identifier ini, klien dapat menemukan penerbit yang tepat di dalam penyimpanan yang berisi beberapa ratus sertifikat.
  • nameConstraints membatasi nama yang boleh dijamin oleh CA ini.

Tinjau kembali hasil yang Anda buat. Jangan menganggap perintah tersebut sudah melakukan hal yang Anda maksud.

openssl x509 -noout -subject -issuer -serial -dates -in ca.crt
openssl x509 -noout -text -in ca.crt

Subject dan issuer menampilkan string yang sama karena sertifikat root menandatangani dirinya sendiri. Nomor seri dan kedua tanggal berasal dari file yang baru saja Anda buat. Karena itu, ambil nilai tersebut dari output tersebut, bukan dari panduan mana pun.

Batasi nama yang boleh ditandatangani CA Anda

Root dalam penyimpanan sistem dipercaya untuk setiap nama di Internet, kecuali Anda menetapkan sebaliknya. Itu merupakan kewenangan yang besar untuk disimpan dalam satu file pada satu server. nameConstraints menguranginya. Dengan permitted;DNS:internal.example pada root, rantai dari CA ini untuk nama di luar internal.example akan ditolak meskipun tanda tangannya valid.

Uji hal itu, bukan dengan mempercayainya.

openssl req -new -newkey rsa:2048 -nodes -keyout /tmp/outside.key -out /tmp/outside.csr \
  -subj "/CN=www.example.com"
openssl x509 -req -in /tmp/outside.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 30 -sha256 \
  -extfile <(printf 'subjectAltName=DNS:www.example.com\n') -out /tmp/outside.crt
openssl verify -CAfile ca.crt /tmp/outside.crt
echo $?

Sertifikat berhasil diterbitkan karena CA Anda menandatangani apa pun yang Anda minta. Kegagalan terjadi saat verifikasi: status keluar bernilai non-zero dan OpenSSL menyebutkan batasan yang dilanggar. Di situlah ekstensi ini berguna. Kunci CA yang dicuri tetap tidak dapat menghasilkan sertifikat yang berfungsi untuk nama di luar subtree tersebut. Setelah selesai, hapus file sisa dengan rm /tmp/outside.*.

Ada empat hal yang perlu diketahui sebelum Anda menetapkan batasan. Batasan ini ditandai critical, sehingga client yang tidak memahami ekstensi tersebut harus menolak rantai, bukan mengabaikannya. Ini merupakan perilaku yang aman, tetapi dapat menimbulkan masalah pada library TLS lama. Subtree yang diizinkan untuk nama DNS tidak membatasi SAN alamat IP karena jenis nama yang tidak memiliki subtree tetap tidak dibatasi. Karena itu, tambahkan permitted;IP:10.0.0.0/255.255.0.0 dalam ekstensi yang sama jika sertifikat Anda memuat alamat IP. Subtree harus mencakup setiap nama yang akan Anda terbitkan, termasuk hostname pendek. Dengan demikian, sertifikat untuk nama dasar app akan gagal terhadap contoh di atas. Batasan ini tertanam dalam root. Jika Anda mengubah keputusan, Anda memerlukan sertifikat root baru dan instalasi ulang pada setiap client.

Terbitkan sertifikat leaf yang ditandatangani oleh CA Anda

Sertifikat leaf adalah sertifikat yang diberikan server kepada klien. Mulailah dengan key dan CSR (certificate signing request) miliknya sendiri. CSR memuat public key dan nama yang diminta, serta ditandatangani oleh leaf key untuk membuktikan bahwa pemohon memegang private key.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout app.key -out app.csr \
  -subj "/CN=app.internal.example"
chmod 600 app.key

Nama yang penting harus dimasukkan ke dalam file ekstensi, bukan ke dalam CSR. Klien mencocokkan hostname dengan subjectAltName (SAN) dan sepenuhnya mengabaikan common name. Karena itu, sertifikat yang memiliki CN tanpa SAN gagal dalam verifikasi hostname pada semua klien saat ini, apa pun isi CN tersebut.

basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:app.internal.example, DNS:api.internal.example
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always

Simpan sebagai app.ext, lalu tandatangani permintaan tersebut dengan CA.

openssl x509 -req -in app.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 397 -sha256 -extfile app.ext -out app.crt

-CAcreateserial menulis ca.srl di samping CA. File ini menyimpan nomor serial berikutnya agar tidak ada dua sertifikat dari CA ini yang memiliki nomor serial sama. Simpan file tersebut di direktori CA. -days 397 adalah pilihan, bukan batasan tool. Masa berlaku yang singkat lebih penting dalam konteks ini dibandingkan dengan CA publik, karena private CA tidak memiliki infrastruktur pencabutan: tidak ada CRL dan tidak ada responder OCSP kecuali Anda membangunnya. Karena itu, private key leaf yang bocor tetap dapat digunakan hingga sertifikatnya kedaluwarsa.

Periksa hasilnya sebelum menyentuh trust store.

openssl x509 -noout -subject -issuer -serial -dates -in app.crt
openssl x509 -noout -ext subjectAltName -in app.crt

Baris issuer sekarang mencantumkan CA, bukan leaf itu sendiri. Baris SAN mencantumkan nama yang valid untuk sertifikat ini, dan klien hanya mencocokkan nama dengan daftar tersebut.

Verifikasi dengan -CAfile eksplisit sebelum memasang apa pun

openssl verify -CAfile ca.crt app.crt
echo $?

Perintah ini mengajukan satu pertanyaan khusus: apakah app.crt membentuk rantai hingga sertifikat di ca.crt? Perintah ini tidak menunjukkan apa yang dipercaya mesin ini, karena Anda memberikan root kepada OpenSSL melalui baris perintah. Kegagalan pada tahap ini menunjukkan masalah pada sertifikat itu sendiri. Perbaiki sebelum melanjutkan.

Sekarang, minta mesin melakukan verifikasi.

openssl verify app.crt
echo $?

Tanpa -CAfile, OpenSSL menggunakan direktori sertifikat bawaan. openssl version -d menampilkan direktori dasar yang digunakan oleh build Anda. Di Ubuntu, direktori certs di dalamnya mengarah ke /etc/ssl/certs. Root Anda belum ada di sana, sehingga verifikasi gagal: rantai mencapai penerbit yang tidak ada di dalam trust store, dan tidak ada lokasi lain yang dapat diperiksa. Perhatikan status keluar. Nilai inilah yang akan berubah dua langkah lagi.

Klien sungguhan merupakan pengujian yang lebih baik daripada openssl verify karena klien juga memeriksa hostname selain rantai sertifikat. Sajikan sertifikat tersebut dan ambil hasilnya.

openssl s_server -accept 8443 -cert app.crt -key app.key -www &
curl --resolve app.internal.example:8443:127.0.0.1 https://app.internal.example:8443/

--resolve mengarahkan koneksi ke 127.0.0.1 sambil tetap meminta app.internal.example, sehingga SAN cocok dan satu-satunya hal yang belum diketahui adalah kepercayaan. curl gagal dan menampilkan alasan rantai tidak dapat diverifikasi. Tambahkan -v untuk melihat detail lebih lanjut. Biarkan server pengujian tetap berjalan.

Instal root ke /usr/local/share/ca-certificates

sudo cp ca.crt /usr/local/share/ca-certificates/example-internal-root.crt
sudo chmod 644 /usr/local/share/ca-certificates/example-internal-root.crt
sudo update-ca-certificates

Detail yang menentukan apakah proses ini berhasil:

  • Nama file harus diakhiri dengan .crt. Halaman manual update-ca-certificates menyatakan bahwa sertifikat dengan ekstensi .crt yang ditemukan di bawah /usr/local/share/ca-certificates akan disertakan dan dipercaya secara implisit. File bernama root.pem atau root.cer akan dilewati tanpa pesan apa pun.
  • Kontennya harus dalam format PEM, yaitu blok base64 yang diapit baris BEGIN CERTIFICATE dan END CERTIFICATE. File DER yang hanya diubah namanya menjadi .crt tetap berupa file biner dan tidak akan dibaca. Konversikan file tersebut dengan openssl x509 -inform DER -in ca.der -out ca.crt.
  • Hanya root yang ditempatkan di sini. CA private key dan leaf certificate tidak boleh berada di trust store.

update-ca-certificates menampilkan jumlah sertifikat yang ditambahkan dan dihapus. Jika tidak ada yang ditambahkan, penyebabnya adalah ekstensi atau format file.

Konfirmasikan perubahan dari sisi sistem, bukan dari pesan tersebut.

ls -l /etc/ssl/certs/$(openssl x509 -noout -subject_hash -in /usr/local/share/ca-certificates/example-internal-root.crt).0
grep -c 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt

Perintah pertama membuat nama file berdasarkan subject hash milik sertifikat Anda, lalu menampilkannya. update-ca-certificates membuat symbolic link tersebut, dan link itu mengarah kembali ke file yang Anda instal. Perintah kedua menghitung jumlah sertifikat dalam bundle satu file. Jalankan perintah tersebut sebelum instalasi agar Anda dapat melihat jumlahnya bertambah satu.

Saat menyalin root ini ke mesin lain, pastikan salinannya tiba tanpa perubahan sebelum menginstalnya. Root certificate adalah file paling penting di sistem untuk dipastikan kebenarannya. Perlakukan file ini seperti unduhan lain yang harus Anda verifikasi dengan checksum sebelum digunakan.

Verifikasi kembali terhadap penyimpanan sertifikat sistem

openssl verify app.crt
echo $?
curl --resolve app.internal.example:8443:127.0.0.1 https://app.internal.example:8443/

Perintah dan file sertifikatnya sama, tetapi hasilnya berbeda. Tidak ada perubahan pada app.crt, dan servernya adalah server yang Anda jalankan sebelumnya. Perbedaannya hanya root kini berada di penyimpanan sertifikat yang dibaca client tersebut, sehingga rantai sertifikat dapat dilengkapi. Mekanisme inilah yang perlu diingat: verifikasi mencari penerbit yang sudah dipercaya client, dan menginstal CA adalah cara memasukkan penerbit tersebut ke lokasi yang dicari.

Hentikan server pengujian dengan kill %1.

Mengapa /etc/ssl/certs bukan tempat untuk menaruh file Anda

/etc/ssl/certs adalah output yang dibuat secara otomatis. update-ca-certificates mengisinya dengan symlink yang mengarah kembali ke file sertifikat sebenarnya dan menulis bundle gabungan /etc/ssl/certs/ca-certificates.crt di direktori yang sama.

Sertifikat yang Anda salin secara manual ke direktori tersebut tidak akan ditemukan oleh apa pun. Pencarian direktori OpenSSL hanya membuka file yang namanya dibuat berdasarkan subject hash sertifikat, sehingga file bernama myca.crt tidak terlihat olehnya. curl di Ubuntu membaca file bundle, dan bundle tersebut dibuat ulang dari sumber yang terdaftar, sehingga salinan Anda juga tidak termasuk dalam path tersebut. Jalankan update-ca-certificates --fresh, lalu symlink di direktori itu akan dihapus dan dibuat ulang. Link yang dibuat secara manual juga akan ikut terhapus.

Bagian lain dari pemisahan ini adalah /usr/share/ca-certificates, yang merupakan bagian dari package ca-certificates dan tercantum dalam /etc/ca-certificates.conf. Pembaruan package akan menulis ulang file tersebut. /usr/local/share/ca-certificates adalah direktori yang disediakan untuk administrator lokal, sehingga CA Anda tetap ada setiap kali package yang mengelola direktori lainnya diperbarui.

Program apa yang mengabaikan trust store sistem

Menginstal root certificate akan memperbaiki setiap program yang meminta OpenSSL atau membaca /etc/ssl/certs. Ini mencakup curl, wget, git, modul standar ssl milik Python, dan program Go yang membaca file sistem di Linux. Runtime yang membawa daftar sertifikat sendiri tidak terpengaruh. Hal ini paling sering menyebabkan kebingungan setelah instalasi berhasil.

  • Node.js menggunakan daftar yang sudah dikompilasi ke dalam program. Arahkan Node.js ke root certificate dengan NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/example-internal-root.crt. Tetapkan variabel ini di environment sebelum proses dimulai karena Node membaca variabel tersebut satu kali saat startup. Rilis Node saat ini juga memiliki opsi untuk membaca system store. Jalankan node --help | grep -i system-ca untuk memeriksa apakah versi Anda mendukungnya.
  • Library requests milik Python menggunakan bundle certifi. Tetapkan REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt untuk proses tersebut, atau teruskan verify="/etc/ssl/certs/ca-certificates.crt" ke pemanggilan. pip menerima --cert karena alasan yang sama.
  • Java membaca keystore. Di Ubuntu, paket ca-certificates-java memasang hook di bawah /etc/ca-certificates/update.d/. Karena itu, update-ca-certificates juga memperbarui keystore Java jika paket tersebut tersedia. Jika tidak, impor root certificate dengan keytool -importcert.
  • Firefox menyimpan store sendiri dan tidak pernah membaca /etc/ssl/certs. Impor sertifikat melalui pengaturan sertifikatnya. Chromium di Linux membaca database NSS per pengguna. Edit database tersebut dengan certutil dari paket libnss3-tools.
  • Container memiliki filesystem sendiri. Karena itu, store milik host tidak berpengaruh di dalam container. Salin root certificate ke dalam image, lalu jalankan update-ca-certificates selama proses build. Rencanakan langkah ini jika service Anda berjalan menggunakan Docker Compose pada VPS.

Jika program tetap menolak sertifikat setelah instalasi yang benar, cari tahu file apa yang dibuka program tersebut sebelum mengubah hal lain. strace -f -e trace=openat <command> 2>&1 | grep -i cert memang bersifat umum, tetapi perintah ini dapat menjawabnya dalam satu kali eksekusi.

Menjaga CA tetap dapat digunakan dalam jangka panjang

Menerbitkan ulang sertifikat leaf berarti mengulangi langkah CSR dan penandatanganan dengan file app.ext yang sama. Klien tidak perlu melakukan tindakan apa pun karena root yang mereka percayai tidak berubah. Simpan ca.srl dan setiap file .ext di direktori CA agar penerbitan berikutnya dapat dilakukan dengan mengulangi perintah yang sudah berhasil, bukan dengan mengandalkan ingatan.

Cadangkan ca.key dan ca.crt di lokasi lain di luar mesin, dan tetap simpan dalam keadaan terenkripsi. Jika key hilang, Anda tidak dapat menerbitkan apa pun yang baru. Anda harus membuat CA kedua dan memasang root-nya di semua lokasi tempat root pertama dipasang. Simpan daftar tertulis mengenai setiap mesin dan setiap penyimpanan aplikasi yang menerima root tersebut. Daftar ini diperlukan agar rotasi dan penghapusannya dapat dilakukan.

Saat root itu sendiri mulai mendekati masa berlaku berakhir, buat penggantinya lebih awal dan pasang kedua root secara berdampingan. Menyimpan dua root tidak menjadi masalah, dan klien dapat menerima salah satunya. Terbitkan ulang sertifikat leaf menggunakan root baru, lalu hapus root lama setelah tidak ada lagi yang bergantung padanya.

Hapus CA dari penyimpanan kepercayaan

sudo rm /usr/local/share/ca-certificates/example-internal-root.crt
sudo update-ca-certificates --fresh

--fresh menghapus symlink di /etc/ssl/certs dan membuatnya ulang dari sumber yang masih ada. Dengan demikian, root yang dihapus tidak lagi berada di direktori maupun bundle. Buktikan penghapusan dengan cara yang sama seperti saat membuktikan instalasi.

openssl verify app.crt
echo $?
grep -c 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt
ls -l /etc/ssl/certs/$(openssl x509 -noout -subject_hash -in ~/ca/ca.crt).0

Verifikasi kembali gagal, jumlah sertifikat kembali ke jumlah awal, dan symlink hash sudah hilang.

Perintah tersebut hanya memengaruhi penyimpanan sistem. Batalkan instalasi secara manual di setiap lokasi lain: kosongkan NODE_EXTRA_CA_CERTS, hapus alias dari setiap Java keystore, hapus root dari setiap profil browser, dan buat ulang setiap container image yang menyertakan root tersebut. Penghapusan root juga tidak membatalkan sertifikat yang ditandatanganinya. Sertifikat tersebut tetap valid pada setiap mesin yang masih mempercayai root itu. Inilah alasan praktis CA privat memerlukan daftar tertulis mengenai lokasi root tersebut. CA yang tidak dapat dicabut sepenuhnya merupakan celah permanen. Karena itu, uji penghapusannya pada satu mesin pada hari saat CA disiapkan, ketika daftarnya masih singkat.

FAQ

Di mana saya menempatkan sertifikat CA di Ubuntu?

Di /usr/local/share/ca-certificates/, dengan nama file yang diakhiri .crt dan konten PEM, lalu jalankan sudo update-ca-certificates. Direktori tersebut diperuntukkan bagi administrator lokal, sehingga pemutakhiran paket tidak mengubahnya. /usr/share/ca-certificates adalah milik paket ca-certificates, sedangkan /etc/ssl/certs dibuat dari keduanya. Karena itu, file yang ditempatkan di salah satu direktori tersebut akan ditimpa atau diabaikan.

Mengapa curl masih menolak sertifikat setelah update-ca-certificates?

Periksa penyebabnya secara berurutan. File tersebut mungkin tidak diakhiri .crt, atau mungkin menggunakan format DER, bukan PEM. Dalam kasus itu, update-ca-certificates melewatinya dan tidak menambahkan apa pun. Sertifikat mungkin tidak memiliki subjectAltName yang cocok dengan hostname. Ini merupakan kegagalan hostname, bukan kegagalan kepercayaan. Periksa dengan openssl x509 -noout -ext subjectAltName -in app.crt. Server mungkin hanya mengirim sertifikat leaf, padahal sertifikat intermediate juga diperlukan. curl mungkin diarahkan ke bundle lain melalui CURL_CA_BUNDLE atau --cacert. Service yang berjalan lama juga perlu dimulai ulang, karena sebagian besar program hanya membaca trust store sekali saat dijalankan.

Apakah trust store sistem mencakup Firefox, Chrome, Node, dan Java?

Tidak. curl, wget, git, modul standar ssl milik Python, dan program Go membaca file sistem, sehingga semuanya dapat langsung digunakan setelah update-ca-certificates dijalankan. Firefox memiliki store sendiri. Chromium di Linux menggunakan database NSS per pengguna, yang diedit dengan certutil dari paket libnss3-tools. Node.js memerlukan NODE_EXTRA_CA_CERTS yang menunjuk ke file root CA Anda. Java membaca keystore, yang hanya diperbarui oleh update-ca-certificates saat paket ca-certificates-java diinstal. requests milik Python menggunakan certifi dan memerlukan REQUESTS_CA_BUNDLE.

Bagaimana cara menghapus CA dari trust store Ubuntu?

Hapus file tersebut dari /usr/local/share/ca-certificates/, lalu jalankan sudo update-ca-certificates --fresh. Opsi --fresh menghapus symlink di /etc/ssl/certs dan membuatnya kembali. Dengan demikian, sertifikat tersebut dihapus dari symlink hash dan bundle ca-certificates.crt secara bersamaan. Konfirmasikan dengan menjalankan openssl verify terhadap sertifikat yang ditandatangani oleh CA tersebut, lalu periksa status keluarannya. Setelah itu, ulangi penghapusan di setiap store lain tempat Anda menambahkannya, karena perintah tersebut tidak mengubah store lain.

Dapatkah saya menggunakan CA privat sebagai pengganti Let's Encrypt untuk situs publik?

Tidak. Browser pengunjung belum pernah mengenali root Anda, sehingga browser menampilkan peringatan pada seluruh halaman. Anda juga tidak dapat memasang root tersebut pada mesin yang tidak Anda kendalikan. CA privat digunakan untuk nama yang hanya dapat di-resolve oleh mesin Anda sendiri dan untuk klien yang Anda administrasikan. Untuk situs yang dikunjungi orang lain, dapatkan sertifikat dari CA publik.

#tls#certificates#openssl#ubuntu#security#pki