Jinsi ya kutengeneza TLS certificate Ubuntu

Unachojenga

Sertifikeeti ya TLS inayojisaini (self-signed) ambayo vivinjari na wateja wa kisasa hukubali — subjectAltName sahihi, ruhusa sahihi za funguo (key permissions), iliyounganishwa kwenye nginx au Apache — pamoja na sehemu ambayo mwongozo karibu kila mmoja hupuuza: kuifanya sertifikeeti yako iaminike na wateja wako ipasavyo, badala ya kubonyeza maonyo na kuweka curl -k ndani ya skripti milele. Mwishoni, utajifunza kutengeneza CA ya ndani kwa amri tano wakati huduma moja ya ndani itakapokuwa sita.

Kwanza, fanya uamuzi, kwa sababu sertifikeeti inayojisaini ni kifaa sahihi mara chache kuliko inavyotumika. Ikiwa huduma inaweza kufikiwa kutoka mtandao wa umma kupitia jina halisi la DNS, acha kusoma na chukua sertifikeeti ya bure ya Let's Encrypt kwa kutumia certbot kwenye nginx au sertifikeeti sawa ya Apache badala yake. Haigharimu chochote, hujihusisha upya wenyewe, na kila kivinjari duniani tayari inaiamini. Sertifikeeti inayojisaini kwenye tovuti ya umma huwafundisha watumiaji wako kubonyeza maonyo ya usalama, jambo ambalo ni tabia mbaya zaidi kuliko kutumia HTTP ya kawaida.

Sertifikeeti inayojisaini ni kifaa sahihi wakati hakuna mtandao wa umma: jopo la admin lililounganishwa na anwani ya WireGuard tunnel kwenye VPS yako, seva ya majaribio (staging) kwenye mtandao binafsi, trafiki kati ya huduma (service-to-service) kati ya mifumo ya nyuma (backends), kifaa cha maabara ya nyumbani (home-lab), au kubadilisha sertifikeeti ya awali ambayo Webmin hutengeneza kwa ajili yake kwenye port 10000. Let's Encrypt haiwezi kutoa sertifikeeti kwa 10.8.0.1 au git.internal.lan — hakuna CA ya umma itakayoweka IP ya ndani au TLD ya kutengenezwa kwenye sertifikeeti. Kwa majina hayo, wewe ndiye CA.

Kila kitu hapa chini kinafanya kazi kwenye seva mpya ya Ubuntu 24.04, ambayo inakuja na OpenSSL 3.0.x (tumia openssl version kuthibitisha). Hakuna kinachohitaji ufikiaji wa mtandao hapa; kila kitu kinafanya kazi bila mtandao (air-gapped).

Kwa nini amri ya zamani ya mstari mmoja inazalisha vyeti ambavyo Chrome hukataa

Amri ambayo kila mwongozo wa kabla ya 2017 hukupa inaonekana hivi:

# 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

Inakuuliza mfululizo wa maswali ya moja kwa moja, huweka hostname yako kwenye uga wa Common Name, na huzalisha cheti kisicho na kiambishi mwishio cha subjectAltName. Cheti hicho hakitakubalika. Chrome ilisitisha kusoma Common Name katika toleo la 58, mnamo Aprili 2017 — RFC 2818 ilikuwa tayari imefuta utambuzi wa CN mwaka 2000 — na Firefox, Safari, curl, na Python hufanya kazi kwa njia hiyo hiyo. Cheti hutambua seva yake kupitia kiambishi cha SAN au hufanya hivyo kabisa; kivinjari hukujulisha hili kwa maneno haya:

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.

Marekebisho yoyote ya trust-store hayataondoa hitilafu hiyo, kwa sababu cheti hakitaji jina lolote. Ikiwa unakutana na NET::ERR_CERT_COMMON_NAME_INVALID sasa hivi, cheti chako hakina SAN (au kina SAN isiyo sahihi) na unahitaji kutengeneza cheti kipya. Kwa bahati nzuri, suluhisho ni amri moja.

Tengeneza cheti kinachokubaliwa na kivinjari: amri moja

OpenSSL iliongeza flag ya -addext katika toleo la 1.1.1, kumaanisha kuwa hauhitaji tena mbinu tata za faili za usanidi (config-file) zinazotumiwa kwenye miongozo ya zamani kuingiza SAN. Kwenye 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"

Kazi ya kila flag:

• -x509 hutoa cheti cha kujisaini (self-signed) moja kwa moja badala ya ombi la kusaini (signing request).
• -newkey rsa:4096 hutengeneza funguo (key) mpya katika hatua hiyo hiyo. RSA 4096 inafaa kwa mifumo ya zamani; ikiwa kila kitu kinachojiunga ni cha kisasa, -newkey ec -pkeyopt ec_paramgen_curve:P-256 ni ndogo na ina kasi zaidi.
• -noenc ni tahajia ya OpenSSL 3.x kwa -nodes ya zamani: hakuna neno la siri (passphrase) kwenye funguo. Tahajia zote mbili zinafanya kazi. Funguo yenye neno la siri inamaanisha nginx itasimama ikisubiri maelezo wakati wa kila kuwaka, hivyo kwa funguo ya seva unahitaji hii.
• -days 730 — miaka miwili; maelezo zaidi kuhusu namba hiyo yapo kwenye sehemu ya muda wa kumalizika.
• -subj hujibu maswali ya mwingiliano (interactive) moja kwa moja. CN ni kwa ajili ya urembo tu sasa, lakini iweke kama jina kuu; baadhi ya zana huonyesha jina hilo.
• -addext "subjectAltName=..." ndiyo flag muhimu zaidi. Orodhesha kila jina na kila IP ambayo watumiaji wataandika: entries za DNS: kwa majina ya host (wildcards kama DNS:*.internal.lan ni sawa), entries za IP: kwa anwani. Ikiwa mtu atafungua https://10.8.0.1, entry ya IP:10.8.0.1 lazima iwepo — SAN inayotumia DNS pekee itawapa NET::ERR_CERT_COMMON_NAME_INVALID tena.

Hakikisha SAN imewekwa vizuri kabla ya kuunganisha kitu chochote:

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

Matokeo sahihi:

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

Ikiwa badala yake inatoa No extensions in certificate, cheti haina SAN na vivinjari vitakikataa — tengeneza upya badala ya kuendelea.

Funga ufunguo wako

Ufunguo wa siri (private key) unaoweza kusomwa na mtumiaji yeyote kwenye mfumo si ufunguo wa siri. Kwenye Ubuntu, /etc/ssl/private tayari ni 710 root:ssl-cert, jambo linalozuia watu wasiohusika, lakini weka mipangilio ya faili hiyo waziwazi:

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

Nginx na Apache zote husoma vyeti (certificates) kama root kabla ya kushusha mamlaka, hivyo root:root mode 600 hufanya kazi kwa ajili yao. Ikiwa ufunguo huo ni kwa ajili ya huduma inayojiendesha kama mtumiaji wake mwenyewe na inayopakia ufunguo huo — kama vile Node app, Gitea, au Python daemon — mbadilishie chown kwa mtumiaji wa huduma hiyo, huku ukibaki na mode 600. Usifanye kamwe: mode 644, kuweka nakala kwenye git repository, au kuweka nakala kwenye /tmp.

Iunganishe kwenye 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 lazima itoe syntax is ok na test is successful kabla ya reload kufanya kazi yoyote. Ikiwa itatoa SSL_CTX_use_PrivateKey_file() failed ... key values mismatch, cheti na funguo (key) vinatoka kwenye matokeo tofauti ya uundaji — angalia sehemu ya failure-modes.

Iunganishe kwenye Apache

sudo a2enmod ssl proxy proxy_http

ssl pekee haitoshi hapa: vhost iliyo chini inatumia ProxyPass, na bila mod_proxy na mod_proxy_http ukaguzi wa konfigirishoni utafeli na Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration. Hifadhi vhost kama /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 inapaswa kujibu Syntax OK. Sasa jaribu kutoka kwenye mashine ya mteja:

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

na utapata kosa:

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

Hili siyo hitilafu. Ni TLS inayofanya kazi: curl haijawahi kuiona sertifeketi yako na inakataa kuwasiliana na seva ambayo haiwezi kuithibitisha. Sehemu inayofuata ndiyo suluhisho halisi — na siyo kile ambacho nusu ya mtandao hufanya wakati huu huu.

Jinsi ya kuifanya iaminike na mifumo isiyo sahihi ya kuepuka

Suluhisho zisizo sahihi kwanza, zikionyeshwa kwa majina yake halisi. curl -k (au --insecure) ndani ya script, verify=False kwenye Python requests, NODE_TLS_REJECT_UNAUTHORIZED=0 kwenye Node — hakuna kati ya hizi inayofanya cheti chako kiaminike. Zinaondoa uhakiki wa cheti (off), ikimaanisha kuwa client itawasiliana na server yoyote inayowasilisha cheti chochote, ikiwemo kile ambacho mshambuliaji amekiweka kwenye njia yake. Unabaki na mzigo wa TLS lakini unapoteza uthibitisho ambao ndio lengo lake kuu. Mbaya zaidi, alama hizi huenea: zinabandikwa kwenye cron job moja, kisha kwenye script ya deploy, kisha kwenye kodi ya uzalishaji (production), hadi hakuna anayekumbuka ni mawasiliano gani yaliyokusudiwa kuwa ya muda mfupi. Ikiwa verify=False itabaki baada ya kikao cha debugging, muundo huo ni mbaya.

Suluhisho sahihi ni kuifundisha kila OS ya client kuwa cheti hiki ni mzizi unaoaminika (trusted root). Kwenye client za Ubuntu na Debian:

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

Mstari muhimu kwenye matokeo (kufuatiwa na block ya Running hooks in /etc/ca-certificates/update.d...):

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

Mambo mawili ya kuzingatia yapo kwenye mistari hiyo. Faili lazima iishe na .crt — extension ya .pem itapuuzwa kimya kimya na utapata 0 added bila ujumbe wa kosa. Na maudhui lazima yawe PEM — faili lianze na -----BEGIN CERTIFICATE-----; badilisha binary ya DER kwanza kwa kutumia openssl x509 -inform der -in file.der -out file.crt. Kuongeza cheti chenye kujisaini (self-signed) kama mzizi hufanya kazi kwa sababu cheti chenye kujisaini ndicho mzizi chake.

Baada ya hapo, curl, wget, git, apt, na kitu kingine chochote kinachotumia OpenSSL dhidi ya bundle ya mfumo kitaiamini server bila kutumia alama zozote. Baadhi ya client zina hifadhi zao za uaminifu (trust stores) na zinahitaji matibabu ya kipekee:

• Chrome/Chromium kwenye Linux husoma database ya NSS, siyo hifadhi ya mfumo: sudo apt install libnss3-tools, kisha certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt kwa kila mtumiaji.
• Firefox ina hifadhi yake: Settings → Privacy & Security → Certificates → Import, au badilisha security.enterprise_roots.enabled kuwa true kwenye about:config ili isome hifadhi ya mfumo.
• Python requests inakuja na bundle yake ya CA (certifi) na hupuuzia hifadhi ya mfumo: tumia verify="/usr/local/share/ca-certificates/git.internal.crt" au usafishe (export) REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt.
• Node.js: usafishe (export) NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt.

Kwenye client za Windows, bonyeza mara mbili .crt na uweke kwenye Trusted Root Certification Authorities; kwenye macOS, iweke kwenye System keychain ndani ya Keychain Access na uweke alama ya Always Trust.

Chanzo kimoja kwa huduma nyingi: CA ndogo ya kibinafsi

Uaminifu wa kila cheti pekee huzuia ufanisi wa upanuzi: huduma sita mara mashine nne za mteja ni jumla ya usakinishaji 24 wa uaminifu, na kila huduma mpya inaongeza mzigo zaidi. Suluhisho ni CA ya kibinafsi — wateja wanaamini chanzo kimoja, na unatia saini cheti cha kila huduma kwa kutumia chanzo hicho.

Chaguo rahisi ni mkcert, ambacho kipo kwenye repos za Ubuntu 24.04 na hushughulikia NSS stores (Chrome, Firefox) ambazo update-ca-certificates haziwezi:

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

mkcert -install hutengeneza chanzo na kukisajili katika kila trust store kwenye mashine hiyo; amri ya tatu hutoa git.internal.lan+2.pem na git.internal.lan+2-key.pem, ambazo ziko tayari kuwekwa kwenye vipande vya nginx au Apache hapo juu. Mtindo wake unafikiria mashine ya maendeleo — funguo ya chanzo huishi kwenye mashine yoyote iliyorun -install — hivyo ni bora kwa laptop ya dev lakini si bora kwa kundi la seva.

Kwa seva, OpenSSL ya kawaida inafanya kazi nzima ya CA kwa amri tano:

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

Changamoto iko kwenye amri ya mwisho: openssl x509 -req huondoa vipengele vyote (extensions) kutoka kwenye CSR kwa kimawazi, ikiwa ni pamoja na SAN uliyoweka kwa uangalifu. -copy_extensions copy (hiari ya OpenSSL 3.x, hivyo inafanya kazi kwenye 24.04) huendelea kuvibeba; ikiachwa, cheti kilichotiwa saini hakitakuwa na SAN, na Chrome itakuambia NET::ERR_CERT_COMMON_NAME_INVALID tena. Hakiki kwa kutumia ukaguzi wa openssl x509 -noout -ext subjectAltName kama ilivyofanyika awali.

Sambaza lab-ca.crt kwa wateja kupitia hatua za trust-store hapo juu — mara moja kwa kila mashine, milele. Linda lab-ca.key kama hazina ya thamani: mode 600, kwa hali bora iwekwe kwenye mashine ambayo si moja ya seva zinazotiwa saini, kwa sababu yeyote anayekimiliki anaweza kutengeneza cheti kwa jina lolote ambalo wateja wako wataamini.

Expiry and rotation

Muda wa matumizi ya cheti cha Public CA unafupishwa — CA/Browser Forum ilipunguza muda wa cheti kipya kinachotolewa kwa watu wote hadi siku 200 mnamo Machi 2026 (kutoka siku 398), ikipungua hadi siku 100 mwaka 2027 na siku 47 ifikapo Machi 2029 — lakini sheria hizo zinawafunga CA zinazotambulika kwa watu wote. CA yako ya ndani haifungwi na sheria hizo, na kivinjari (browser) hakizilazimisha dhidi ya mizizi (roots) iliyowekwa kwa mkono. Kuna kizuizi kimoja cha ulimwengu halisi: mifumo ya Apple inakataa cheti chochote cha TLS server kinachofanya kazi kwa zaidi ya siku 825 bila kujali nani alikitoa, hivyo ikiwa iPhone au Mac zitatumika, weka cheti cha leaf kwa muda wa miaka miwili au chini yake. -days 730 inafikia vigezo hivyo kila mahali; mzizi wa miaka kumi wenye leaf za miaka miwili ni mpangilio mzuri wa ndani.

Cheti chenye muda mrefu hukataliwa kwa njia moja tu: kimya kimya, kwa wakati mmoja, katika tarehe ambayo hakuna mtu anayekumbuka kuichagua. Angalia ulichonacho:

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

Weka muda wa uingizaji upya (renewal) kwenye kalenda, au tumia cron kukujulisha siku 30 kabla — openssl x509 -checkend 2592000 -in cert.crt hutoka na kutoa namba isiyo 0 mara moja muda wa kumalizika unapofika ndani ya sekunde hizo. Ikiwa tayari unatumia Uptime Kuma kwa ajili ya ufuatiliaji wa hali, mifumo yake ya HTTPS itaashiria muda wa kumalizika kwa cheti bila malipo.

Ugeuzaji (Rotation) kwa CA ya ndani ni rahisi: rudi na amri za CSR-and-sign, badilisha faili, na uweke upya (reload) web server. Mzizi haujabadilika, hivyo hakuna mteja (client) atakayegundua chochote.

Njia za kushindili, pamoja na maandishi utakayoyaona

NET::ERR_CERT_AUTHORITY_INVALID — hali inayotarajiwa kabla ya kusakinisha imani, si hitilafu katika cheti. Ikiendelea baada ya kusakinisha root: kwenye Linux, Chrome husoma NSS badala ya hifadhi ya mfumo (tazama hatua ya certutil); au faili iliyonaswa haikuishia na .crt na update-ca-certificates ilisema 0 added; au seva inatoa cheti tofauti na lile uliloliweka kama la kuaminika — linganisha alama za vidole (fingerprints) kwa kutumia openssl s_client -connect git.internal.lan:443 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256.

NET::ERR_CERT_COMMON_NAME_INVALID — cheti hakina SAN, au SAN haijafunika jina lililo kwenye sehemu ya anwani. Kisa cha kawaida: SAN inaorodhesha DNS:git.internal.lan lakini mtumiaji amefungua https://10.8.0.1. Mabadiliko ya hifadhi ya imani (trust-store) hayawezi kurekebisha hili; toa cheti upya ukiwa na ingizo linalokosekana.

curl: (60) SSL certificate problem: self-signed certificate — curl haiamini cheti. Toleo la self-signed certificate in certificate chain linamaanisha kitu kilekile kwa cheti kilichosainiwa na CA yako binafsi. Suluhisho la haraka: curl --cacert lab-ca.crt https://...; suluhisho la kudumu: hifadhi ya imani. Si -k.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (au Expecting: CERTIFICATE REQUEST, au no start line) — mkanganyiko wa PEM. Ulitoa OpenSSL aina isiyo sahihi ya faili: key au CSR pale ilipotarajiwa cheti, au binary ya DER pale ilipotarajiwa PEM. head -1 filename inakuambia kile ulichonacho — cheti huanza na -----BEGIN CERTIFICATE-----. Kwa DER, badilisha kwa kutumia openssl x509 -inform der -in file.der -out file.crt.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch) — cheti na key hazioanana, mara nyingi kwa sababu amri ya kutengeneza ilitumika mara mbili na faili zikachanganyika. Thibitisha kwa kutumia openssl x509 -in git.internal.crt -noout -pubkey | sha256sum dhidi ya openssl pkey -in git.internal.key -pubout | sha256sum; alama za hash zinazofanana zinaashiria jozi inayolingana. Ikiwa zinatofautiana, tengeneza upya zote kwa pamoja.

FAQ

Kwa nini Chrome bado inaonyesha "Not secure" baada ya kutengeneza certificate ya self-signed?

Ikiwa kosa ni NET::ERR_CERT_AUTHORITY_INVALID, certificate ni sahihi — Chrome haina sababu ya kuiamini bado. Iweke (au CA root yako ya kibinafsi) kwenye trust store ya client. Kumbuka kuwa kwenye Linux, Chrome hutumia NSS database kupitia certutil, badala ya system store. Ikiwa kosa ni NET::ERR_CERT_COMMON_NAME_INVALID, certificate haina Subject Alternative Name inayolingana na URL na lazima itolewe upya kwa kutumia -addext "subjectAltName=...".

Nitafanyaje curl iamini certificate ya self-signed bila kutumia -k?

Nakili certificate (format ya PEM, extension ya .crt) kwenye /usr/local/share/ca-certificates/ kisha uendeshe sudo update-ca-certificates — matokeo lazima yaonyeshe 1 added. Baada ya hapo, curl itahakiki kama certificate yoyote ya umma. Kwa ombi la mara moja bila kubadilisha mfumo, curl --cacert /path/to/cert.crt hutumia faili hiyo pekee; -k huzima uhakiki kabisa na haitakiwi kutumika kwenye scripts za mtu yeyote.

Certificate ya self-signed inaweza kuwa na muda gani wa utumizi?

Kiteknolojia inaweza kudumu kwa muda wowote unaoitaka — mipaka ya CA/Browser Forum (sasa ni siku 200, na siku 47 ifikapo 2029) inawafunga CA zinazotambulika hadharani, si imani ya kibinafsi. Kiutendaji, weka kikomo cha siku 825 kwa server certificates, kwa sababu vifaa vya Apple hukataa chochote kinachozidi muda huo bila kujali mtoa huduma. Root ya kibinafsi ya miaka kumi yenye leaf certificates za miaka miwili (-days 730) ni chaguo bora; weka kalenda ya uingizaji upya, kwa sababu certificate ya ndani iliyoisha muda wake itasababisha mfumo mzima kuacha kufanya kazi bila taarifa kwenye tarehe ambayo hakuna anayekumbuka.

Nitumie certificate ya self-signed au Let's Encrypt?

Ikiwa huduma ina jina la DNS la umma na inaweza kufikiwa kutoka kwenye internet, tumia Let's Encrypt kila wakati — ni bure, inaingiliana, na tayari inaaminika na kila client. Self-signed (au CA ya kibinafsi) ni kwa ajili ya mambo ambayo Let's Encrypt haiwezi kutoa: IP za kibinafsi, hostnames za ndani pekee kama .lan, mitandao iliyotengwa (air-gapped), na huduma zilizofichwa kwa makusudi nyuma ya VPN. Uamuzi unategemea uwezo wa kufikiwa na majina, si nguvu ya usalama — cryptography ni sawa.

Kwa nini certificate yangu inakataliwa hata baada ya kuiongeza kwenye /usr/local/share/ca-certificates?

Angalia mambo matatu. Faili lazima liishie na .crt — extension ya .pem itapuuzwa na update-ca-certificates itatoa 0 added. Maudhui lazima yawe maandishi ya PEM yanayoanza na -----BEGIN CERTIFICATE-----, si binary ya DER. Pia, programu lazima itumie system store — Chrome kwenye Linux, Firefox, Python requests, Node.js, na Java kila kimoja kina trust store yake ya kibinafsi na zinahitaji certificate iongezwe kando.