Cara Tambah Sijil CA Sendiri ke Ubuntu Trust Store

Menambah CA anda sendiri ke dalam stor kepercayaan Ubuntu

Untuk menambah CA anda sendiri ke dalam stor kepercayaan Ubuntu, salin sijil root ke dalam /usr/local/share/ca-certificates/ dengan nama yang berakhir dengan .crt, kemudian jalankan sudo update-ca-certificates. CA (pihak berkuasa sijil) ialah pasangan kunci yang sijilnya dibenarkan untuk menandatangani sijil lain. Apabila mesin mempercayai root anda, setiap sijil yang ditandatangani oleh root tersebut akan diterima, jadi pengesahan HTTPS antara servis anda sendiri tidak lagi gagal.

Panduan ini membina keseluruhan rantaian secara luar talian dengan openssl. Anda mencipta kunci root dan sijil root, mengeluarkan satu sijil leaf untuk pelayan, kemudian memasang root tersebut dan melihat arahan pengesahan yang sama mengubah jawapannya. Urutan itu adalah intipatinya: melakukan pengesahan sebelum dan selepas pemasangan adalah cara anda melihat bahawa pemasangan itulah yang mengubah hasilnya.

Ubuntu 24.04 membekalkan OpenSSL 3 dan pakej ca-certificates pada imej lalai, jadi tiada apa yang perlu dipasang terlebih dahulu (disemak pada Ogos 2026).

Bilakah anda perlu menjalankan CA anda sendiri?

CA awam seperti Let's Encrypt memerlukan nama dalam DNS awam dan pelayan yang boleh dihubungi. Nama dalaman tidak layak. Pangkalan data pada rangkaian peribadi atau panel pentadbir yang terikat pada tunnel tidak boleh mendapatkan sijil awam, dan kedua-duanya tidak sepatutnya didedahkan kepada internet semata-mata untuk mendapatkannya.

Sijil self-signed pada Ubuntu menyelesaikan masalah untuk satu hos sahaja. Setiap klien perlu mempercayai sijil tersebut, dan hos seterusnya perlu mengulangi kerja yang sama. CA peribadi menaikkan tahap keputusan tersebut. Klien mempercayai root sekali sahaja, dan setiap sijil yang ditandatangani oleh root selepas itu akan dipercayai, termasuk sijil untuk hos yang belum wujud lagi.

Kosnya adalah nyata. Kunci root boleh menandatangani apa sahaja yang dibenarkan oleh kekangan, jadi sesiapa yang membaca ca.key boleh mengeluarkan sijil yang akan diterima oleh mesin anda. Lindungi kunci tersebut seperti anda melindungi kunci peribadi dalam pengurusan kunci SSH. Jika sesuatu servis mempunyai nama DNS awam, abaikan semua ini dan gunakan CA awam: Certbot dengan nginx dan Let's Encrypt memerlukan usaha yang kurang dan tidak perlu memasang apa-apa pada bahagian klien.

Cipta kunci CA dan sijil root

Bekerja di dalam direktori yang hanya boleh dibuka oleh pengguna anda. Kunci root tidak boleh dikeluarkan dari direktori tersebut.

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

-aes256 menyulitkan kunci dengan frasa laluan pilihan anda, dan setiap arahan seterusnya yang menandatangani dengan kunci ini akan memintanya. Jika anda tidak menggunakan -aes256, kunci tersebut akan disimpan dalam cakera tanpa penyulitan. Ini bermakna sandaran atau akaun pentadbir kedua sudah memadai untuk membolehkan sesiapa sahaja mengeluarkan sijil yang dipercayai oleh mesin anda.

Sekarang, cipta sijil 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

Gantikan internal.example dengan akhiran nama yang anda gunakan, dan baca bahagian seterusnya sebelum anda mengekalkan sambungan (extension) terakhir itu.

Setiap sambungan menjalankan satu tugas.

• basicConstraints dengan CA:TRUE adalah perkara yang menjadikan ini sebagai sijil CA. Tanpanya, klien akan menolak sebarang sijil yang ditandatangani oleh kunci ini, walaupun tandatangannya adalah betul.
• pathlen:0 menyatakan bahawa CA boleh menandatangani sijil daun (leaf certificates) dan tiada CA lain di bawahnya.
• keyUsage mengehadkan kunci tersebut hanya untuk menandatangani sijil dan senarai pembatalan (revocation lists), supaya kunci yang sama tidak digunakan secara tidak sengaja sebagai kunci pelayan TLS.
• subjectKeyIdentifier memberikan root satu pengecam yang dirujuk oleh sijil daun. Ini adalah cara klien mencari pengeluar yang betul di dalam stor yang menyimpan ratusan sijil.
• nameConstraints mengehadkan nama yang dibenarkan untuk dijamin oleh CA ini.

Semak semula apa yang telah anda buat dan jangan sekadar menganggap arahan tersebut telah melakukan apa yang anda mahukan.

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

Subjek dan pengeluar akan memaparkan rentetan yang sama kerana sijil root menandatangani dirinya sendiri. Nombor siri dan dua tarikh tersebut datang daripada fail yang baru anda cipta, jadi ambil maklumat tersebut daripada output itu dan bukannya daripada panduan sesiapa pun.

Hadkan perkara yang boleh ditandatangani oleh CA anda

Root dalam stor sistem dipercayai untuk setiap nama di internet melainkan anda menetapkan sebaliknya. Itu adalah jumlah kuasa yang besar untuk dipegang dalam satu fail pada satu pelayan. nameConstraints mengurangkannya. Dengan permitted;DNS:internal.example dalam root, rantaian daripada CA ini untuk nama di luar internal.example akan ditolak walaupun tandatangannya sah.

Uji perkara itu daripada 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 $?

Sijil tersebut dikeluarkan kerana CA anda menandatangani apa sahaja yang anda minta untuk ditandatangani. Pengesahan adalah tempat ia gagal: status keluar adalah bukan sifar dan OpenSSL menamakan kekangan yang dilanggarnya. Itulah nilai sambungan tersebut. Kunci CA yang dicuri masih tidak dapat menghasilkan sijil yang berfungsi untuk nama di luar subpokok. Padamkan baki fail dengan rm /tmp/outside.* apabila anda selesai.

Empat perkara yang perlu diketahui sebelum anda menetapkan kekangan. Ia ditandakan sebagai critical, jadi klien yang tidak memahami sambungan tersebut mesti menolak rantaian itu daripada mengabaikannya; ini adalah langkah yang selamat tetapi boleh mengejutkan pustaka TLS lama. Subpokok yang dibenarkan untuk nama DNS tidak menyekat SAN alamat IP, kerana jenis nama tanpa subpokok yang disenaraikan kekal tidak disekat, jadi tambahkan permitted;IP:10.0.0.0/255.255.0.0 dalam sambungan yang sama jika sijil anda membawa alamat IP. Subpokok mesti meliputi setiap nama yang akan anda keluarkan, termasuk nama hos pendek, jadi sijil untuk nama kosong app akan gagal berbanding contoh di atas. Kekangan ini dibina ke dalam root, jadi mengubah fikiran bermakna sijil root baharu dan pemasangan semula pada setiap klien.

Terbitkan sijil daun yang ditandatangani oleh CA anda

Sijil daun ialah sijil yang dipersembahkan oleh pelayan kepada klien. Mulakan dengan kunci miliknya sendiri dan CSR (certificate signing request), yang membawa kunci awam serta nama yang diminta, ditandatangani oleh kunci daun untuk membuktikan pemohon memegang bahagian kunci peribadi.

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 diletakkan dalam fail sambungan, bukan dalam CSR. Klien memadankan nama hos terhadap subjectAltName (SAN) dan mengabaikan common name sepenuhnya, jadi sijil dengan CN tanpa SAN akan gagal dalam pengesahan nama hos pada setiap klien semasa, tidak kira apa yang dinyatakan oleh CN.

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

Simpan fail tersebut sebagai app.ext, kemudian 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 bersebelahan dengan CA, yang menyimpan nombor siri seterusnya supaya tiada dua sijil daripada CA ini berkongsi nombor yang sama. Simpan fail tersebut dalam direktori CA. -days 397 ialah pilihan, bukan had alat tersebut. Jangka hayat yang singkat lebih penting di sini berbanding dengan CA awam, kerana CA peribadi tidak mempunyai infrastruktur pembatalan: tiada CRL dan tiada OCSP responder melainkan anda membinanya sendiri, jadi kunci daun yang bocor akan kekal boleh digunakan sehingga sijil tamat tempoh.

Semak hasil tersebut sebelum anda mendekati trust store.

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

Baris issuer kini menamakan CA dan bukannya daun itu sendiri. Baris SAN menyenaraikan nama yang sah untuk sijil ini, dan klien akan memadankan terhadap senarai tersebut dan tiada yang lain.

Sahkan dengan -CAfile yang eksplisit, sebelum memasang apa-apa

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

Ini hanya bertanyakan satu soalan khusus: adakah app.crt berangkai kepada sijil dalam ca.crt? Ia tidak menyatakan apa-apa tentang perkara yang dipercayai oleh mesin ini, kerana anda telah memberikan root kepada OpenSSL melalui baris perintah. Kegagalan di sini bermakna terdapat masalah pada sijil itu sendiri, jadi selesaikan masalah tersebut sebelum meneruskan.

Sekarang, tanya mesin tersebut.

openssl verify app.crt
echo $?

Tanpa -CAfile, OpenSSL akan kembali menggunakan direktori sijil binaan dalamannya. openssl version -d mencetak direktori asas yang digunakan oleh binaan anda, dan pada Ubuntu, direktori certs di bawahnya diselesaikan kepada /etc/ssl/certs. Root anda belum ada di sana, jadi pengesahan gagal: rangkaian tersebut sampai kepada pengeluar yang tidak disimpan dalam stor, dan tiada tempat lain untuk diperiksa. Perhatikan status keluar (exit status). Ia adalah perkara yang akan berubah dalam dua langkah lagi.

Pelanggan sebenar merupakan ujian yang lebih baik daripada openssl verify, kerana ia memeriksa nama hos selain daripada rangkaian sijil. Hidangkan sijil tersebut dan ambilnya.

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 menghantar sambungan ke 127.0.0.1 sambil tetap meminta app.internal.example, jadi SAN sepadan dan satu-satunya persoalan yang tinggal ialah kepercayaan. curl gagal dan mencetak sebab ia tidak dapat mengesahkan rangkaian tersebut. Tambahkan -v untuk butiran lanjut. Biarkan pelayan ujian terus berjalan.

Pasang root ke dalam /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

Butiran yang menentukan sama ada langkah ini berjaya:

• Nama fail mesti berakhir dengan .crt. Halaman manual update-ca-certificates menyatakan bahawa sijil dengan sambungan .crt yang ditemui di bawah /usr/local/share/ca-certificates akan disertakan dan dipercayai secara tersirat. Fail yang dinamakan root.pem atau root.cer akan dilangkau tanpa sebarang notis.
• Kandungan mestilah dalam format PEM, iaitu blok base64 yang dibalut dengan baris BEGIN CERTIFICATE dan END CERTIFICATE. Fail DER yang dinamakan semula kepada .crt masih dalam bentuk binari dan tidak akan dibaca. Tukarkannya menggunakan openssl x509 -inform DER -in ca.der -out ca.crt.
• Hanya sijil root yang perlu diletakkan di sini. Kunci peribadi CA dan sijil leaf tidak sepatutnya berada dalam stor kepercayaan (trust store).

update-ca-certificates akan memaparkan bilangan sijil yang ditambah dan dibuang. Jika tiada sijil ditambah, puncanya adalah disebabkan oleh sambungan fail atau format fail yang salah.

Sahkan perubahan tersebut daripada pihak sistem dan bukannya sekadar bergantung pada mesej 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 membina nama fail berdasarkan hash subjek sijil anda dan menyenaraikannya. update-ca-certificates mencipta symlink tersebut, dan ia menghala kembali ke fail yang anda pasang. Perintah kedua mengira jumlah sijil dalam bundle fail tunggal. Jalankan perintah ini sebelum pemasangan supaya anda boleh melihat peningkatan jumlah sijil sebanyak satu.

Apabila anda menyalin root ini ke mesin lain, pastikan salinan tersebut sampai dalam keadaan sempurna sebelum memasangnya. Sijil root adalah fail paling kritikal dalam sistem jika berlaku kesilapan, jadi kendalikannya seperti mana-mana muat turun lain yang anda akan sahkan dengan checksum sebelum digunakan.

Sahkan semula terhadap stor sistem

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

Perintah yang sama, fail sijil yang sama, namun jawapan yang berbeza. Tiada apa-apa tentang app.crt yang berubah, dan pelayan tersebut adalah pelayan yang anda mulakan tadi. Satu-satunya perbezaan ialah root kini berada di dalam stor yang dibaca oleh klien tersebut, maka rantaian itu menjadi lengkap. Itulah mekanisme yang perlu diingati: pengesahan ialah carian untuk pengeluar yang sudah dipercayai oleh klien, dan memasang CA adalah cara pengeluar tersebut diletakkan di tempat yang dicari oleh klien.

Hentikan pelayan ujian dengan kill %1.

Mengapa /etc/ssl/certs bukan tempat untuk meletakkan fail anda

/etc/ssl/certs ialah output yang dijana. update-ca-certificates mengisinya dengan symlink yang merujuk kembali kepada fail sijil sebenar dan menulis bundle yang digabungkan /etc/ssl/certs/ca-certificates.crt di sebelahnya.

Sijil yang anda salin ke dalam direktori tersebut secara manual tidak akan dikesan oleh mana-mana proses. Carian direktori OpenSSL hanya membuka fail yang dinamakan mengikut hash subjek sijil, jadi fail bernama myca.crt tidak dapat dilihat olehnya. curl pada Ubuntu membaca fail bundle, dan bundle tersebut dibina semula daripada sumber berdaftar, jadi salinan anda juga tidak terdapat dalam laluan tersebut. Jalankan update-ca-certificates --fresh dan symlink dalam direktori itu akan dibuang dan dibina semula, yang turut memadamkan sebarang pautan yang dibuat secara manual.

Bahagian lain bagi pembahagian ini ialah /usr/share/ca-certificates, yang dimiliki oleh pakej ca-certificates dan disenaraikan dalam /etc/ca-certificates.conf. Kemas kini pakej akan menulis semula fail tersebut. /usr/local/share/ca-certificates ialah direktori yang dikhaskan untuk pentadbir tempatan, jadi CA anda akan kekal selamat setiap kali pakej yang menguruskan bahagian lain dikemas kini.

Program yang mengabaikan stor kepercayaan sistem

Memasang root certificate membetulkan setiap program yang meminta OpenSSL atau membaca /etc/ssl/certs. Ini merangkumi curl, wget, git, modul ssl standard Python, dan program Go, yang membaca fail sistem pada Linux. Runtime yang menyertakan senarai sijil sendiri tidak terjejas, dan di sinilah punca kebanyakan kekeliruan selepas pemasangan berjaya.

• Node.js menggunakan senarai yang dikompilasi di dalamnya. Halakan ia kepada root anda dengan NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/example-internal-root.crt, yang ditetapkan dalam persekitaran sebelum proses bermula, kerana Node membaca pemboleh ubah tersebut sekali sahaja semasa permulaan. Keluaran Node semasa juga mempunyai pilihan untuk membaca stor sistem; jalankan node --help | grep -i system-ca untuk melihat sama ada versi anda mempunyainya.
• Pustaka requests Python menggunakan bundle certifi. Tetapkan REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt untuk proses tersebut, atau hantarkan verify="/etc/ssl/certs/ca-certificates.crt" kepada panggilan berkenaan. pip mengambil --cert atas sebab yang sama.
• Java membaca keystore. Pada Ubuntu, pakej ca-certificates-java memasang hook di bawah /etc/ca-certificates/update.d/, jadi update-ca-certificates turut menyegarkan keystore Java apabila pakej tersebut ada. Tanpanya, import root dengan keytool -importcert.
• Firefox menyimpan stornya sendiri dan tidak pernah melihat /etc/ssl/certs. Import melalui tetapan sijilnya. Chromium pada Linux membaca pangkalan data NSS bagi setiap pengguna, yang anda sunting dengan certutil daripada pakej libnss3-tools.
• Kontena mempunyai sistem failnya sendiri, jadi stor hos tidak bermakna di dalamnya. Salin root ke dalam imej dan jalankan update-ca-certificates semasa binaan. Rancang untuk perkara itu jika servis anda berjalan di bawah Docker Compose pada VPS.

Apabila sesuatu program masih menolak sijil selepas pemasangan bersih, ketahui fail yang dibuka olehnya sebelum mengubah apa-apa lagi. strace -f -e trace=openat <command> 2>&1 | grep -i cert adalah alat yang terus-terang, dan ia menjawab soalan tersebut dalam satu larian.

Mengekalkan kebolehgunaan CA dari semasa ke semasa

Mengeluarkan semula sijil leaf melibatkan langkah CSR dan langkah penandatanganan sekali lagi, dengan menggunakan fail app.ext yang sama. Pelanggan tidak perlu melakukan sebarang tindakan kerana root yang dipercayai oleh mereka tidak berubah. Simpan ca.srl dan setiap fail .ext di dalam direktori CA supaya pengeluaran seterusnya hanyalah pengulangan arahan yang pernah berjaya, bukannya pembinaan semula berdasarkan ingatan.

Buat sandaran bagi ca.key dan ca.crt di lokasi luar mesin, dan pastikan ia kekal disulitkan. Jika kunci hilang, anda tidak boleh mengeluarkan apa-apa sijil baharu: anda terpaksa membina CA kedua dan memasang root baharu tersebut di setiap tempat yang menggunakan CA pertama. Simpan senarai bertulis bagi setiap mesin dan setiap stor aplikasi yang menerima root tersebut, kerana senarai itulah yang membolehkan proses pertukaran dan penyingkiran dilakukan.

Apabila root itu sendiri hampir tamat tempoh, jana penggantinya lebih awal dan pasang kedua-dua root secara serentak. Mempunyai dua root di dalam stor adalah dibenarkan, dan pelanggan akan menerima mana-mana satu daripadanya. Keluarkan semula sijil leaf menggunakan root baharu, kemudian buang root lama setelah tiada lagi aplikasi yang bergantung kepadanya.

Mengeluarkan CA daripada stor kepercayaan

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

--fresh memadamkan symlink dalam /etc/ssl/certs dan membina semula symlink tersebut daripada sumber yang masih ada, jadi root yang dipadamkan akan keluar daripada direktori dan bundle tersebut secara serentak. Buktikan pengeluaran tersebut dengan cara yang sama anda membuktikan pemasangannya.

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

Pengesahan gagal sekali lagi, kiraan sijil kembali ke tahap asal, dan symlink hash telah tiada.

Perintah tersebut hanya mengubah stor sistem dan tiada tempat lain. Batalkan pemasangan di setiap lokasi lain secara manual: kosongkan NODE_EXTRA_CA_CERTS, padamkan alias daripada mana-mana Java keystore, keluarkan root daripada setiap profil pelayar, dan bina semula mana-mana imej kontena yang menyertakan root tersebut. Mengeluarkan root juga tidak membatalkan sijil yang telah ditandatanganinya. Sijil tersebut kekal sah pada setiap mesin yang masih mempercayainya, yang merupakan sebab praktikal mengapa CA peribadi memerlukan senarai bertulis tentang ke mana root tersebut telah diedarkan. CA yang tidak boleh ditarik balik sepenuhnya merupakan lubang keselamatan kekal, jadi uji proses pengeluaran pada satu mesin pada hari anda menyediakannya, sementara senarai tersebut masih pendek.

FAQ

Di manakah saya perlu meletakkan sijil CA pada Ubuntu?

Di dalam /usr/local/share/ca-certificates/, dengan nama fail yang berakhir dengan .crt dan kandungan PEM, kemudian jalankan sudo update-ca-certificates. Direktori tersebut dikhaskan untuk pentadbir tempatan, jadi naik taraf pakej tidak akan mengganggu fail di dalamnya. /usr/share/ca-certificates adalah milik pakej ca-certificates, dan /etc/ssl/certs dijana daripada kedua-duanya, jadi fail yang diletakkan di dalam mana-mana direktori tersebut akan ditimpa atau diabaikan.

Mengapa curl masih menolak sijil selepas update-ca-certificates?

Semak punca mengikut urutan. Fail mungkin tidak berakhir dengan .crt, atau mungkin dalam format DER dan bukannya PEM, yang menyebabkan update-ca-certificates melangkau fail tersebut dan tidak menambah apa-apa. Sijil mungkin tidak mempunyai subjectAltName yang sepadan dengan hostname, yang merupakan kegagalan hostname dan bukannya kegagalan kepercayaan; semak dengan openssl x509 -noout -ext subjectAltName -in app.crt. Pelayan mungkin hanya menghantar sijil leaf sedangkan sijil intermediate juga diperlukan. curl mungkin dihalakan ke bundle yang berbeza oleh CURL_CA_BUNDLE atau --cacert. Selain itu, servis yang sedang berjalan memerlukan restart, kerana kebanyakan program membaca trust store hanya sekali semasa ia bermula.

Adakah system trust store merangkumi Firefox, Chrome, Node dan Java?

Tidak. curl, wget, git, modul ssl standard Python dan program Go membaca fail sistem, jadi ia berfungsi sebaik sahaja update-ca-certificates dijalankan. Firefox menyimpan stornya sendiri. Chromium pada Linux menggunakan pangkalan data NSS bagi setiap pengguna, yang disunting dengan certutil daripada pakej libnss3-tools. Node.js memerlukan NODE_EXTRA_CA_CERTS yang menghala ke fail root anda. Java membaca keystore, yang hanya disegarkan oleh update-ca-certificates apabila pakej ca-certificates-java dipasang. requests dalam Python menggunakan certifi dan memerlukan REQUESTS_CA_BUNDLE.

Bagaimanakah cara membuang CA daripada trust store Ubuntu?

Padam fail tersebut daripada /usr/local/share/ca-certificates/ dan jalankan sudo update-ca-certificates --fresh. Pilihan --fresh akan membersihkan symlink dalam /etc/ssl/certs dan membina semula symlink tersebut, jadi sijil akan dikeluarkan daripada hash symlink dan bundle ca-certificates.crt pada masa yang sama. Sahkan dengan menjalankan openssl verify terhadap sijil yang ditandatangani oleh CA tersebut dan baca status keluar (exit status). Kemudian, ulangi proses pembuangan dalam setiap stor lain yang anda tambahkan sijil tersebut, kerana arahan itu tidak menyentuh stor-stor lain.

Bolehkah saya menggunakan CA peribadi (private CA) dan bukannya Let's Encrypt untuk laman web awam?

Tidak. Pelayar pelawat tidak pernah melihat root anda, jadi ia akan memaparkan amaran skrin penuh, dan anda tidak boleh memasang root anda pada mesin yang tidak anda kawal. CA peribadi adalah untuk nama yang hanya diselesaikan oleh mesin anda sendiri dan untuk klien yang anda tadbir. Bagi mana-mana laman yang dilawati oleh orang asing, dapatkan sijil daripada CA awam.