SSD Nodes Learn Hosting plans →
Panduan Matt ConnorOleh Matt Connor · Dikemas kini 2026-08-07

Cara Jana Sijil TLS Self-Signed di Ubuntu 24.04

Jana sijil TLS yang diterima Chrome pada Ubuntu 24.04 dengan arahan openssl SAN yang betul. Elakkan ralat NET::ERR_CERT_AUTHORITY_INVALID tanpa perlu menggunakan flag curl -k.

Apa yang anda sedang bina

Sijil TLS yang ditandatangani sendiri (self-signed) yang diterima oleh pelayar dan klien moden, subjectAltName yang betul, keizinan kunci yang wajar, disambungkan ke dalam nginx atau Apache, serta bahagian yang hampir semua panduan terlepas: menjadikan klien anda mempercayai sijil tersebut dengan betul, bukannya menekan amaran dan mengekod curl -k secara keras ke dalam skrip selama-lamanya. Pada akhirnya, satu CA peribadi lima arahan untuk kegunaan apabila satu servis dalaman menjadi enam.

Pertama, keputusan perlu dibuat, kerana sijil yang ditandatangani sendiri jarang sekali menjadi alat yang tepat berbanding kekerapan ia digunakan. Jika servis boleh dicapai daripada internet awam di bawah nama DNS sebenar, berhenti membaca dan dapatkan sijil Let's Encrypt percuma dengan certbot pada nginx atau setara untuk Apache sebaliknya. Ia percuma, diperbaharui secara automatik, dan setiap pelayar di dunia sudah mempercayainya. Sijil yang ditandatangani sendiri pada tapak awam melatih pengguna anda untuk mengabaikan amaran keselamatan, yang merupakan tabiat lebih buruk daripada HTTP biasa.

Sijil yang ditandatangani sendiri adalah alat yang tepat apabila tiada internet awam terlibat: panel pentadbir yang terikat pada alamat terowong WireGuard pada VPS anda, kotak staging pada rangkaian peribadi, trafik antara servis (service-to-service) di antara backend, perkakas makmal rumah (home-lab), atau menggantikan sijil pemegang tempat yang dijana oleh Webmin untuk dirinya sendiri pada port 10000. Let's Encrypt tidak boleh mengeluarkan sijil untuk 10.8.0.1 atau git.internal.lan walau bagaimanapun, tiada CA awam yang akan meletakkan IP peribadi atau TLD rekaan dalam sijil. Untuk nama-nama tersebut, anda adalah CA-nya.

Segala yang di bawah ini dijalankan pada kotak Ubuntu 24.04 yang baharu, yang membekalkan OpenSSL 3.0.x (openssl version untuk mengesahkan). Tiada apa-apa di sini yang memerlukan akses internet; semuanya berfungsi dalam keadaan air-gapped.

Mengapa arahan sebaris lama menghasilkan sijil yang ditolak oleh Chrome

Arahan yang diberikan oleh setiap tutorial sebelum tahun 2017 kelihatan 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

Arahan ini meminta satu siri soalan interaktif, meletakkan nama hos anda dalam medan Common Name, dan menghasilkan sijil tanpa sambungan subjectAltName. Sijil tersebut tidak sah sejak awal lagi. Chrome berhenti membaca Common Name dalam versi 58, pada bulan April 2017, RFC 2818 telah pun menamatkan penggunaan padanan CN pada tahun 2000, dan Firefox, Safari, curl, serta Python berkelakuan dengan cara yang sama. Sijil mengenal pasti pelayannya melalui sambungan SAN atau tidak sama sekali, dan pelayar memberitahu anda perkara tersebut dengan kata-kata tepat ini:

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.

Tiada jumlah pengubahsuaian trust-store yang boleh membetulkan ralat tersebut, kerana sijil itu benar-benar tidak menamakan apa-apa. Jika anda sedang melihat NET::ERR_CERT_COMMON_NAME_INVALID sekarang, sijil anda tidak mempunyai SAN (atau mempunyai SAN yang salah) dan anda perlu menjana sijil baharu. Nasib baik, penyelesaiannya hanya memerlukan satu arahan.

Menjana sijil yang diterima pelayar: satu arahan

OpenSSL telah memperkenalkan flag -addext dalam versi 1.1.1, yang bermaksud anda tidak lagi memerlukan gimnastik fail konfigurasi yang digunakan oleh panduan lama untuk menyuntik 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 mengeluarkan sijil yang ditandatangani sendiri secara terus dan bukannya permintaan tandatangan.
  • -newkey rsa:4096 menjana kunci baharu dalam langkah yang sama. RSA 4096 tidak menjejaskan mana-mana klien legasi; jika semua sambungan adalah moden, -newkey ec -pkeyopt ec_paramgen_curve:P-256 adalah lebih kecil dan lebih pantas.
  • -noenc ialah ejaan OpenSSL 3.x bagi -nodes yang lama: tiada frasa laluan pada kunci. Kedua-dua ejaan berfungsi. Kunci dengan frasa laluan bermakna nginx akan tergantung menunggu input pada setiap but, jadi untuk kunci pelayan anda mahukan tetapan ini.
  • -days 730, dua tahun; maklumat lanjut mengenai nombor tersebut dalam bahagian tamat tempoh.
  • -subj menjawab soalan interaktif secara terus. CN kini hanya bersifat kosmetik, tetapi tetap tetapkan ia kepada nama utama; sesetengah alatan memaparkannya.
  • -addext "subjectAltName=..." ialah flag yang paling penting. Senaraikan setiap nama dan setiap IP yang akan ditaip oleh klien: DNS: entri untuk nama hos (wildcard seperti DNS:*.internal.lan boleh digunakan), IP: entri untuk alamat. Jika sesiapa akan melayari ke https://10.8.0.1, entri IP:10.8.0.1 mesti ada di sana, SAN yang hanya mengandungi DNS akan memberikan mereka NET::ERR_CERT_COMMON_NAME_INVALID sekali lagi.

Sahkan bahawa SAN benar-benar wujud sebelum menyambungkan apa-apa:

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

Output yang betul:

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

Jika output sebaliknya memaparkan No extensions in certificate, sijil tersebut tidak mempunyai SAN dan pelayar akan menolaknya, jana semula sijil tersebut dan jangan teruskan.

Kunci fail kunci peribadi

Kunci peribadi yang boleh dibaca oleh setiap pengguna pada pelayan bukanlah kunci peribadi. Pada Ubuntu, /etc/ssl/private sudah ditetapkan kepada 710 root:ssl-cert, yang menghalang akses daripada pengguna biasa, namun tetapkan kebenaran fail tersebut secara eksplisit:

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

nginx dan Apache kedua-duanya membaca sijil sebagai root sebelum menurunkan keistimewaan, jadi mod root:root 600 berfungsi untuk kedua-duanya. Jika kunci tersebut adalah untuk servis yang berjalan sebagai pengguna sendiri dan memuatkan kunci itu secara kendiri, seperti aplikasi Node, Gitea, atau daemon Python, chown kunci tersebut kepada pengguna servis itu, dengan mengekalkan mod 600. Perkara yang tidak boleh dilakukan: menggunakan mod 644, menyimpan salinan dalam repositori git, atau menyimpan salinan dalam /tmp.

Sambungkan 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 mesti mencetak syntax is ok dan test is successful sebelum reload dilakukan. Jika ia sebaliknya mencetak SSL_CTX_use_PrivateKey_file() failed ... key values mismatch, sijil dan kunci tersebut adalah daripada dua proses penjanaan yang berbeza, sila rujuk bahagian failure-modes.

Sambungkan ke Apache

sudo a2enmod ssl proxy proxy_http

ssl sahaja tidak mencukupi di sini: vhost di bawah menggunakan ProxyPass, dan tanpa mod_proxy serta mod_proxy_http, ujian konfigurasi akan gagal dengan Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration. Simpan vhost tersebut 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 sepatutnya menjawab Syntax OK. Sekarang, buat ujian daripada mesin klien:

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

dan anda akan menerima ralat:

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

Itu bukan pepijat. Itu adalah fungsi TLS: curl tidak mengenali sijil anda dan enggan berhubung dengan pelayan yang tidak dapat disahkan. Bahagian seterusnya ialah penyelesaian sebenar, dan ia bukanlah kaedah yang digunakan oleh kebanyakan orang di internet pada masa ini.

Menjadikan klien mempercayainya, dan anti-corak yang perlu ditolak

Pembaikan yang salah didahulukan, dinamakan mengikut fungsinya. curl -k (atau --insecure) yang dibenamkan ke dalam skrip, verify=False dalam Python requests, NODE_TLS_REJECT_UNAUTHORIZED=0 dalam Node, tiada satu pun daripada ini menjadikan sijil anda dipercayai. Ia mematikan pengesahan sijil, yang bermaksud klien akan berhubung dengan mana-mana pelayan yang memberikan mana-mana sijil, termasuk sijil yang diletakkan oleh penyerang di dalam laluan rangkaian. Anda mengekalkan beban TLS tetapi kehilangan pengesahan yang merupakan tujuan utamanya. Lebih buruk lagi, flag ini merebak: ditampal ke dalam satu cron job, kemudian skrip deploy, seterusnya kod pengeluaran, sehingga tiada siapa yang ingat sambungan mana yang sepatutnya bersifat sementara. Jika verify=False bertahan selepas sesi penyahpepijatan yang menghasilkannya, reka bentuk tersebut adalah salah.

Pembaikan yang betul adalah dengan mengajar setiap OS klien bahawa sijil ini adalah root yang dipercayai. 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 (blok Running hooks in /etc/ca-certificates/update.d... mengikutinya):

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

Terdapat dua perangkap yang tersembunyi dalam baris tersebut. Fail mesti berakhir dengan .crt, sambungan .pem diabaikan secara senyap dan anda mendapat 0 added tanpa mesej ralat. Kandungannya juga mestilah dalam format PEM, fail bermula dengan -----BEGIN CERTIFICATE-----; tukar binari DER terlebih dahulu dengan openssl x509 -inform der -in file.der -out file.crt. Menambah sijil yang ditandatangani sendiri (self-signed) sebagai root berfungsi kerana sijil yang ditandatangani sendiri adalah root bagi dirinya sendiri.

Selepas itu, curl, wget, git, apt, dan apa-apa sahaja yang menggunakan OpenSSL terhadap bundle sistem akan mempercayai pelayan tersebut tanpa sebarang flag. Segelintir klien membawa stor kepercayaan mereka sendiri dan memerlukan pengendalian individu:

  • Chrome/Chromium pada Linux membaca pangkalan data NSS, bukan stor sistem: sudo apt install libnss3-tools, kemudian certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt bagi setiap pengguna.
  • Firefox mempunyai stornya sendiri: Tetapan → Privasi & Keselamatan → Sijil → Import, atau tukar security.enterprise_roots.enabled kepada true dalam about:config supaya ia membaca stor sistem.
  • Python requests membawa bundle CA sendiri (certifi) dan mengabaikan stor sistem: hantar verify="/usr/local/share/ca-certificates/git.internal.crt" atau eksport REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt.
  • Node.js: eksport NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt.

Pada klien Windows, klik dua kali pada .crt dan pasang ke dalam Trusted Root Certification Authorities; pada macOS, tambahkannya ke dalam keychain System dalam Keychain Access dan tandakan Always Trust.

Satu root untuk banyak servis: CA peribadi yang kecil

Kepercayaan bagi setiap sijil (per-certificate trust) tidak lagi praktikal apabila skala meningkat: enam servis didarab dengan empat mesin klien bermakna dua puluh empat pemasangan kepercayaan, dan setiap servis baharu menambah beban tersebut. Penyelesaiannya ialah CA peribadi, di mana klien mempercayai satu root, dan anda menandatangani sijil setiap servis dengannya.

Pilihan yang mesra pengguna ialah mkcert, yang terdapat dalam repositori Ubuntu 24.04 dan mengendalikan stor NSS (Chrome, Firefox) yang terlepas daripada update-ca-certificates:

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

mkcert -install mencipta satu root dan mendaftarkannya dalam setiap stor kepercayaan pada mesin tersebut; arahan ketiga mengeluarkan git.internal.lan+2.pem dan git.internal.lan+2-key.pem, yang sedia untuk dimasukkan ke dalam snippet nginx atau Apache di atas. Reka bentuknya mengandaikan ia digunakan pada mesin pembangunan, kunci root disimpan pada mesin yang menjalankan -install, jadi ia sangat sesuai untuk komputer riba pembangunan tetapi tidak sesuai untuk kumpulan pelayan.

Bagi pelayan, OpenSSL biasa boleh melaksanakan keseluruhan proses CA dalam lima arahan:

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 terletak pada arahan terakhir: openssl x509 -req membuang semua sambungan (extensions) daripada CSR secara lalai, termasuk SAN yang telah anda tambah dengan teliti. -copy_extensions copy (pilihan OpenSSL 3.x, jadi ia berfungsi pada 24.04) mengekalkan sambungan tersebut; jika ditinggalkan, sijil yang ditandatangani tidak mempunyai SAN, dan Chrome akan memaparkan NET::ERR_CERT_COMMON_NAME_INVALID sekali lagi. Sahkan dengan semakan openssl x509 -noout -ext subjectAltName yang sama seperti sebelumnya.

Edarkan lab-ca.crt kepada klien melalui langkah-langkah stor kepercayaan di atas, cukup sekali bagi setiap mesin, untuk selamanya. Kawal lab-ca.key seperti harta yang paling berharga: gunakan mode 600, dan sebaik-baiknya simpan pada mesin yang bukan salah satu daripada pelayan yang ditandatanganinya, kerana sesiapa yang memegangnya boleh mencipta sijil untuk sebarang nama yang akan dipercayai oleh klien anda.

Tempoh tamat dan putaran

Jangka hayat sijil CA awam semakin berkurangan. CA/Browser Forum telah mengehadkan sijil yang dipercayai secara awam kepada 200 hari bermula Mac 2026 (turun daripada 398 hari), kemudian kepada 100 hari pada tahun 2027, dan 47 hari menjelang Mac 2029. Walau bagaimanapun, peraturan tersebut hanya mengikat CA yang dipercayai secara awam. CA peribadi anda tidak tertakluk kepada peraturan ini, dan pelayar web tidak menguatkuasakannya terhadap root yang dipasang secara manual. Terdapat satu sekatan dunia sebenar yang terpakai: platform Apple menolak sebarang sijil pelayan TLS yang sah melebihi 825 hari tanpa mengira pihak yang mengeluarkannya. Oleh itu, jika iPhone atau Mac akan membuat sambungan, pastikan sijil leaf adalah untuk tempoh dua tahun atau kurang. -days 730 melepasi had tersebut di mana-mana sahaja; root sepuluh tahun dengan sijil leaf dua tahun merupakan konfigurasi dalaman yang selesa.

Sijil yang mempunyai tempoh hayat panjang gagal dengan satu cara sahaja: secara senyap, serentak, pada tarikh yang tiada siapa ingat pernah dipilih. Semak sijil yang anda miliki:

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

Masukkan peringatan pembaharuan ke dalam kalendar sebenar, atau gunakan cron untuk memberi peringatan 30 hari sebelum tamat tempoh. openssl x509 -checkend 2592000 -in cert.crt akan keluar dengan kod bukan sifar sebaik sahaja tempoh tamat berada dalam lingkungan saat tersebut. Jika anda sudah menjalankan Uptime Kuma untuk pemantauan status, monitor HTTPS-nya akan menandakan sijil yang hampir tamat tempoh secara percuma.

Putaran sijil dengan CA peribadi adalah proses yang mudah: jalankan semula arahan CSR-dan-tandatangan, tukar fail, dan muat semula pelayan web. Root tidak berubah, jadi tiada klien yang akan menyedari sebarang perubahan.

Mod kegagalan, berserta rentetan yang akan anda lihat

NET::ERR_CERT_AUTHORITY_INVALID, keadaan yang dijangka sebelum anda memasang kepercayaan, bukan kecacatan pada sijil. Jika ia berterusan selepas anda memasang root: pada Linux, Chrome membaca NSS dan bukannya stor sistem (lihat langkah certutil); atau fail yang disalin tidak berakhir dengan .crt dan update-ca-certificates menyatakan 0 added; atau pelayan membentangkan sijil yang berbeza daripada sijil yang anda percayai, bandingkan cap jari dengan openssl s_client -connect git.internal.lan:443 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256.

NET::ERR_CERT_COMMON_NAME_INVALID, sijil tidak mempunyai SAN, atau SAN tidak meliputi nama dalam bar alamat. Kes klasik: SAN menyenaraikan DNS:git.internal.lan tetapi pengguna melayari ke https://10.8.0.1. Perubahan stor kepercayaan tidak dapat membetulkan perkara ini; terbitkan semula dengan entri yang hilang.

curl: (60) SSL certificate problem: self-signed certificate, curl tidak mempercayai sijil tersebut. Variasi self-signed certificate in certificate chain bermaksud perkara yang sama untuk sijil yang ditandatangani oleh CA peribadi anda. Pembaikan sekali sahaja: curl --cacert lab-ca.crt https://...; pembaikan kekal: stor kepercayaan. Bukan -k.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (atau Expecting: CERTIFICATE REQUEST, atau no start line), kekeliruan PEM. Anda memberikan OpenSSL jenis fail yang salah: kunci atau CSR di mana ia menjangkakan sijil, atau binari DER di mana ia menjangkakan PEM. head -1 filename memberitahu anda apa yang sebenarnya anda miliki, sijil bermula dengan -----BEGIN CERTIFICATE-----. Untuk DER, tukar dengan openssl x509 -inform der -in file.der -out file.crt.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch), sijil dan kunci tidak sepadan, biasanya kerana arahan penjanaan dijalankan dua kali dan fail tersebut bercampur. Sahkan dengan openssl x509 -in git.internal.crt -noout -pubkey | sha256sum berbanding openssl pkey -in git.internal.key -pubout | sha256sum; hash yang sepadan bermakna pasangan yang sepadan. Jika ia berbeza, jana semula kedua-duanya bersama-sama.

FAQ

Mengapa Chrome masih memaparkan "Not secure" selepas saya mencipta sijil yang ditandatangani sendiri (self-signed)?

Jika ralatnya ialah NET::ERR_CERT_AUTHORITY_INVALID, sijil tersebut adalah sah, namun Chrome belum mempunyai sebab untuk mempercayainya. Pasang sijil tersebut (atau root CA peribadi anda) ke dalam stor kepercayaan (trust store) klien. Perlu diingat bahawa pada Linux, Chrome menggunakan pangkalan data NSS melalui certutil, bukannya stor sistem. Jika ralatnya ialah NET::ERR_CERT_COMMON_NAME_INVALID, sijil tersebut tidak mempunyai Subject Alternative Name yang sepadan dengan URL dan perlu dikeluarkan semula dengan -addext "subjectAltName=...".

Bagaimanakah cara untuk membuat curl mempercayai sijil self-signed tanpa menggunakan -k?

Salin sijil tersebut (format PEM, sambungan .crt) ke dalam /usr/local/share/ca-certificates/ dan jalankan sudo update-ca-certificates. Outputnya mesti menyatakan 1 added. Selepas itu, curl akan mengesahkannya seperti sijil awam yang lain. Untuk permintaan sekali sahaja tanpa mengubah sistem, curl --cacert /path/to/cert.crt akan mengesahkan berdasarkan fail tersebut sahaja; -k melumpuhkan pengesahan sepenuhnya dan tidak sepatutnya digunakan dalam skrip sesiapa pun.

Berapa lamakah sijil self-signed boleh sah?

Secara teknikal, anda boleh menetapkannya selama mana yang anda mahu. Had CA/Browser Forum (kini 200 hari, 47 hari menjelang 2029) hanya mengikat CA yang dipercayai secara awam, bukan kepercayaan peribadi. Secara praktikal, hadkan sijil pelayan kepada 825 hari kerana peranti Apple akan menolak sebarang sijil yang lebih lama tanpa mengira pengeluarnya. Root peribadi sepuluh tahun dengan sijil daun (leaf) dua tahun (-days 730) adalah tetapan lalai yang munasabah. Pastikan anda menjadualkan pembaharuan kerana sijil dalaman yang tamat tempoh akan menyebabkan servis terhenti secara senyap pada tarikh yang tidak diingati sesiapa.

Patutkah saya menggunakan sijil self-signed atau Let's Encrypt?

Jika servis mempunyai nama DNS awam dan boleh dicapai dari internet, sentiasa gunakan Let's Encrypt kerana ia percuma, automatik, dan sudah dipercayai oleh setiap klien. Sijil self-signed (atau CA peribadi) adalah untuk kegunaan yang tidak boleh dikeluarkan oleh Let's Encrypt: IP peribadi, nama hos dalaman sahaja seperti .lan, rangkaian yang terasing (air-gapped), dan servis yang sengaja disembunyikan di sebalik VPN. Keputusan ini adalah mengenai kebolehcapaian dan penamaan, bukan kekuatan keselamatan, kerana kriptografinya adalah sama.

Mengapa sijil saya ditolak walaupun selepas menambahkannya ke /usr/local/share/ca-certificates?

Periksa tiga perkara ini. Fail tersebut mesti berakhir dengan .crt; sambungan .pem akan diabaikan secara senyap dan update-ca-certificates akan melaporkan 0 added. Kandungannya mestilah teks PEM yang bermula dengan -----BEGIN CERTIFICATE-----, bukannya binari DER. Selain itu, aplikasi tersebut mestilah benar-benar menggunakan stor sistem. Chrome pada Linux, Firefox, Python requests, Node.js, dan Java masing-masing menyimpan stor kepercayaan peribadi dan memerlukan sijil ditambah secara berasingan.

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