Ubuntu ట్రస్ట్ స్టోర్‌కు మీ స్వంత CA సర్టిఫికేట్‌ను

Ubuntu ట్రస్ట్ స్టోర్‌కు మీ స్వంత CAని జోడించడం

Ubuntu ట్రస్ట్ స్టోర్‌కు మీ స్వంత CAని జోడించడానికి, రూట్ సర్టిఫికేట్‌ను /usr/local/share/ca-certificates/ లోకి .crt తో ముగిసే పేరుతో కాపీ చేయండి, ఆపై sudo update-ca-certificates ని రన్ చేయండి. CA (సర్టిఫికేట్ అథారిటీ) అనేది ఒక కీ జత, దీని సర్టిఫికేట్ ఇతర సర్టిఫికేట్‌లను సంతకం చేయడానికి అనుమతించబడుతుంది. మీ రూట్ సర్టిఫికేట్‌ను మెషిన్ నమ్మిన తర్వాత, ఆ రూట్ సంతకం చేసిన ప్రతి సర్టిఫికేట్ ఆమోదించబడుతుంది, తద్వారా మీ స్వంత సేవల మధ్య HTTPS వెరిఫికేషన్ విఫలం కావడం ఆగిపోతుంది.

ఈ గైడ్ openssl ఉపయోగించి మొత్తం చైన్‌ను ఆఫ్‌లైన్‌లో నిర్మిస్తుంది. మీరు ఒక రూట్ కీ మరియు రూట్ సర్టిఫికేట్‌ను సృష్టించి, సర్వర్ కోసం ఒక లీఫ్ సర్టిఫికేట్‌ను జారీ చేసి, ఆపై రూట్‌ను ఇన్‌స్టాల్ చేసి, అదే వెరిఫికేషన్ కమాండ్ దాని సమాధానాన్ని ఎలా మారుస్తుందో గమనించండి. ఈ క్రమం చాలా ముఖ్యం: ఇన్‌స్టాలేషన్‌కు ముందు మరియు తర్వాత వెరిఫై చేయడం ద్వారా, ఫలితాన్ని మార్చింది ఈ ఇన్‌స్టాలేషన్ అని మీరు అర్థం చేసుకోగలరు.

Ubuntu 24.04 డిఫాల్ట్ ఇమేజ్‌లో OpenSSL 3 మరియు ca-certificates ప్యాకేజీని కలిగి ఉంటుంది, కాబట్టి ముందుగా ఏదీ ఇన్‌స్టాల్ చేయాల్సిన అవసరం లేదు (ఆగస్టు 2026 నాటికి ధృవీకరించబడింది).

మీరు సొంతంగా CAను ఎప్పుడు నిర్వహించాలి?

Let's Encrypt వంటి పబ్లిక్ CAకు పబ్లిక్ DNSలో పేరు మరియు అది చేరుకోగల సర్వర్ అవసరం. అంతర్గత (internal) పేర్లు దీనికి సరిపోవు. ప్రైవేట్ నెట్‌వర్క్‌లోని డేటాబేస్ లేదా టన్నెల్‌కు కట్టుబడి ఉన్న అడ్మిన్ ప్యానెల్ పబ్లిక్ సర్టిఫికేట్‌ను పొందలేవు, అలాగే సర్టిఫికేట్ పొందడం కోసం వాటిని ఇంటర్నెట్‌కు బహిర్గతం చేయకూడదు.

Ubuntuపై self-signed certificate ఒకే హోస్ట్‌కు మాత్రమే పరిష్కారం చూపుతుంది. ప్రతి క్లయింట్ ఆ ఒక్క సర్టిఫికేట్‌ను నమ్మాలి, మరియు తదుపరి హోస్ట్ కోసం మళ్ళీ అదే పని చేయాలి. ప్రైవేట్ CA ఈ నిర్ణయాన్ని ఒక స్థాయి పైకి తీసుకెళ్తుంది. క్లయింట్లు రూట్ సర్టిఫికేట్‌ను ఒక్కసారి నమ్మితే చాలు, ఆ తర్వాత రూట్ సంతకం చేసిన ప్రతి సర్టిఫికేట్‌ను అవి నమ్ముతాయి; ఇంకా ఉనికిలో లేని హోస్ట్‌ల సర్టిఫికేట్‌లు కూడా ఇందులో ఉంటాయి.

దీని వల్ల కలిగే నష్టాలు కూడా ఉన్నాయి. రూట్ కీ నిబంధనలు అనుమతించిన దేనినైనా సంతకం చేయగలదు, కాబట్టి ca.keyని ఎవరైతే చదవగలరో వారు మీ మెషీన్లు అంగీకరించే సర్టిఫికేట్‌లను జారీ చేయగలరు. SSH key managementలో ప్రైవేట్ కీని ఎలా కాపాడుకుంటారో, దీన్ని కూడా అలాగే కాపాడండి. ఒక సేవకు పబ్లిక్ DNS పేరు ఉంటే, ఇదంతా వదిలేసి పబ్లిక్ CAను ఉపయోగించండి: Certbot with nginx and Let's Encrypt వాడటం సులభం మరియు క్లయింట్ వైపు ఏమీ ఇన్‌స్టాల్ చేయాల్సిన అవసరం ఉండదు.

CA కీ మరియు రూట్ సర్టిఫికేట్‌ను సృష్టించడం

మీ వినియోగదారు మాత్రమే తెరవగలిగే డైరెక్టరీలో పని చేయండి. రూట్ కీ ఎప్పటికీ ఆ డైరెక్టరీని దాటి బయటకు వెళ్లకూడదు.

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

-aes256 మీరు ఎంచుకున్న పాస్‌ఫ్రేజ్‌తో కీని ఎన్‌క్రిప్ట్ చేస్తుంది. ఆ తర్వాత ఈ కీతో సంతకం చేసే ప్రతి కమాండ్ ఆ పాస్‌ఫ్రేజ్‌ను అడుగుతుంది. -aes256 ని ఉపయోగించకపోతే, కీ డిస్క్‌పై ఎన్‌క్రిప్షన్ లేకుండా ఉంటుంది. అప్పుడు బ్యాకప్ ఫైల్ లేదా మరొక అడ్మిన్ ఖాతా ద్వారా ఎవరైనా మీ మెషీన్లు నమ్మే సర్టిఫికేట్‌లను జారీ చేసే అధికారాన్ని పొందే ప్రమాదం ఉంది.

ఇప్పుడు రూట్ సర్టిఫికేట్‌ను సృష్టించండి, దీనిపై CA కీ తనంతట తానుగా సంతకం చేసుకుంటుంది.

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

internal.example స్థానంలో మీరు వాడే పేరును (suffix) ఉంచండి. చివరి ఎక్స్‌టెన్షన్‌ను ఉంచే ముందు తదుపరి విభాగాన్ని చదవండి.

ప్రతి ఎక్స్‌టెన్షన్ ఒక నిర్దిష్ట పనిని చేస్తుంది.

• basicConstraints తో పాటు CA:TRUE ఉండటం వల్లే ఇది CA సర్టిఫికేట్‌గా మారుతుంది. ఇది లేకపోతే, సంతకం సరిగ్గా ఉన్నప్పటికీ, ఈ కీ సంతకం చేసిన ఏ సర్టిఫికేట్‌ను క్లయింట్ అంగీకరించదు.
• pathlen:0 అనేది ఈ CA కేవలం లీఫ్ సర్టిఫికేట్‌లపై మాత్రమే సంతకం చేయగలదని, దీని కింద మరిన్ని CAలను సృష్టించకూడదని నిర్దేశిస్తుంది.
• keyUsage ఈ కీని కేవలం సర్టిఫికేట్‌లు మరియు రివోకేషన్ లిస్ట్‌లపై సంతకం చేయడానికి మాత్రమే పరిమితం చేస్తుంది. దీనివల్ల పొరపాటున ఈ కీని TLS సర్వర్ కీగా వాడకుండా నిరోధించవచ్చు.
• subjectKeyIdentifier రూట్ సర్టిఫికేట్‌కు ఒక గుర్తింపును ఇస్తుంది. లీఫ్ సర్టిఫికేట్‌లు దీనిని సూచిస్తాయి, తద్వారా వందలాది సర్టిఫికేట్‌లు ఉన్న స్టోర్‌లో క్లయింట్ సరైన జారీదారుని (issuer) గుర్తించగలదు.
• nameConstraints ఈ CA ఏ పేర్లకు హామీ ఇవ్వవచ్చో వాటిని పరిమితం చేస్తుంది.

కమాండ్ మీరు ఆశించినట్లుగా పనిచేసిందో లేదో తెలుసుకోవడానికి, సృష్టించిన ఫైల్‌ను మళ్ళీ చదవండి.

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

రూట్ సర్టిఫికేట్ తనపై తాను సంతకం చేసుకుంటుంది కాబట్టి, Subject మరియు Issuer రెండూ ఒకే స్ట్రింగ్‌ను చూపిస్తాయి. సీరియల్ నంబర్ మరియు రెండు తేదీలు మీరు ఇప్పుడే సృష్టించిన ఫైల్ నుండి వస్తాయి, కాబట్టి వాటిని ఎవరి గైడ్ నుండో కాకుండా, ఈ అవుట్‌పుట్ నుండే తీసుకోండి.

మీ CA దేనిని సంతకం చేయవచ్చో పరిమితం చేయండి

మీరు వేరేలా పేర్కొనకపోతే, సిస్టమ్ స్టోర్‌లోని ఒక root సర్టిఫికేట్ ఇంటర్నెట్‌లోని ప్రతి పేరుకు విశ్వసనీయంగా ఉంటుంది. ఒక సర్వర్‌లోని ఒకే ఫైల్‌కు ఇంత పెద్ద మొత్తంలో అధికారం ఉండటం ప్రమాదకరం. nameConstraints దీనిని తగ్గిస్తుంది. root లో permitted;DNS:internal.example ఉన్నప్పుడు, సంతకం సరిగ్గా ఉన్నప్పటికీ, internal.example వెలుపల ఉన్న పేరు కోసం ఈ CA నుండి వచ్చే చైన్ తిరస్కరించబడుతుంది.

దీనిని నమ్మే బదులు పరీక్షించండి.

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 $?

మీ CA మీరు అడిగిన దేనినైనా సంతకం చేస్తుంది కాబట్టి, సర్టిఫికేట్ జారీ చేయబడుతుంది. ధృవీకరణ (verification) దశలోనే ఇది విఫలమవుతుంది: exit status సున్నా కాదు మరియు OpenSSL అది ఎదుర్కొన్న constraint ను పేర్కొంటుంది. ఎక్స్‌టెన్షన్ యొక్క విలువ ఇదే. ఒకవేళ CA కీ దొంగిలించబడినా, అది సబ్‌ట్రీ వెలుపల ఉన్న పేరు కోసం పనిచేసే సర్టిఫికేట్‌ను సృష్టించలేదు. మీరు పూర్తి చేసిన తర్వాత rm /tmp/outside.* తో మిగిలిన ఫైళ్లను తొలగించండి.

constraint ను అమలు చేసే ముందు తెలుసుకోవలసిన నాలుగు విషయాలు. ఇది critical గా మార్క్ చేయబడింది, కాబట్టి ఈ ఎక్స్‌టెన్షన్ అర్థం కాని క్లయింట్ దానిని విస్మరించడానికి బదులుగా చైన్‌ను తిరస్కరించాలి. ఇది సురక్షితమైన పద్ధతి, కానీ పాత TLS లైబ్రరీలకు ఇది ఆశ్చర్యం కలిగించవచ్చు. DNS పేర్ల కోసం అనుమతించబడిన సబ్‌ట్రీ IP అడ్రస్ SANలను నియంత్రించదు, ఎందుకంటే సబ్‌ట్రీ జాబితాలో లేని పేరు రకంపై ఎటువంటి నియంత్రణ ఉండదు. కాబట్టి మీ సర్టిఫికేట్‌లలో IP అడ్రస్‌లు ఉంటే, అదే ఎక్స్‌టెన్షన్‌లో permitted;IP:10.0.0.0/255.255.0.0 ని కూడా జోడించండి. సబ్‌ట్రీ మీరు జారీ చేసే ప్రతి పేరును కవర్ చేయాలి, ఇందులో చిన్న హోస్ట్‌నేమ్‌లు కూడా ఉంటాయి. కాబట్టి app వంటి బేర్ నేమ్ (bare name) కోసం సర్టిఫికేట్ పైన పేర్కొన్న ఉదాహరణకు వ్యతిరేకంగా విఫలమవుతుంది. ఈ constraint root లోనే ఉంటుంది, కాబట్టి మీరు నిర్ణయం మార్చుకుంటే, కొత్త root సర్టిఫికేట్ అవసరమవుతుంది మరియు ప్రతి క్లయింట్‌లో కొత్తగా ఇన్‌స్టాల్ చేయాల్సి ఉంటుంది.

మీ CA ద్వారా సంతకం చేయబడిన leaf certificate ను జారీ చేయండి

Leaf certificate అనేది సర్వర్ క్లయింట్‌లకు అందించే ధృవీకరణ పత్రం. దీని కోసం ముందుగా ఒక ప్రత్యేక key మరియు CSR (certificate signing request) ను సిద్ధం చేసుకోవాలి. ఈ CSR లో public key మరియు అభ్యర్థించిన పేరు ఉంటాయి; అభ్యర్థన చేసే వ్యక్తి వద్ద private key ఉందని నిరూపించడానికి ఇది leaf key తో సంతకం చేయబడుతుంది.

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

ముఖ్యమైన పేర్లను CSR లో కాకుండా, extension ఫైల్‌లో చేర్చాలి. క్లయింట్లు hostname ను subjectAltName (SAN) తో సరిపోల్చుకుంటాయి మరియు common name ను పూర్తిగా విస్మరిస్తాయి. కాబట్టి, CN ఉండి SAN లేని certificate, ప్రస్తుత క్లయింట్ల వద్ద hostname verification లో విఫలమవుతుంది, CN లో ఏమున్నా సరే.

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

దీనిని app.ext గా సేవ్ చేసి, ఆపై CA తో అభ్యర్థనపై సంతకం చేయండి.

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

-CAcreateserial, CA పక్కన ca.srl ను సృష్టిస్తుంది. ఇది తదుపరి serial number ను కలిగి ఉంటుంది, తద్వారా ఈ CA నుండి జారీ చేయబడిన ఏ రెండు certificates ఒకే serial number ను కలిగి ఉండవు. ఈ ఫైల్‌ను CA డైరెక్టరీలోనే ఉంచండి. -days 397 అనేది ఒక ఎంపిక మాత్రమే, సాధనం యొక్క పరిమితి కాదు. పబ్లిక్ CA తో పోలిస్తే ఇక్కడ తక్కువ కాలపరిమితి (short lifetime) చాలా ముఖ్యం, ఎందుకంటే ప్రైవేట్ CA కి revocation మౌలిక సదుపాయాలు ఉండవు: మీరు సొంతంగా నిర్మించుకోకపోతే CRL లేదా OCSP responder ఉండవు. కాబట్టి, ఒకవేళ leaf key లీక్ అయితే, certificate గడువు ముగిసే వరకు అది ఉపయోగించదగినదిగానే ఉంటుంది.

Trust store లోకి వెళ్లే ముందు ఫలితాన్ని సరిచూసుకోండి.

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

ఇప్పుడు issuer లైన్ leaf పేరుకు బదులుగా CA పేరును చూపుతుంది. SAN లైన్ ఈ certificate చెల్లుబాటు అయ్యే పేర్లను జాబితా చేస్తుంది, క్లయింట్ ఆ జాబితాతో మాత్రమే సరిపోల్చుకుంటుంది, వేరే దేనితోనూ కాదు.

ఏదైనా ఇన్‌స్టాల్ చేసే ముందు, స్పష్టమైన -CAfile తో ధృవీకరించండి

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

ఇది ఒక చిన్న ప్రశ్నను అడుగుతుంది: app.crt లోని సర్టిఫికేట్, ca.crt లోని సర్టిఫికేట్‌కు అనుసంధానించబడి ఉందా? మీరు OpenSSL కి కమాండ్ లైన్ ద్వారా రూట్ సర్టిఫికేట్‌ను అందించారు కాబట్టి, ఈ యంత్రం దేనిని నమ్ముతుందనే దానితో దీనికి సంబంధం లేదు. ఇక్కడ ధృవీకరణ విఫలమైతే, అది సర్టిఫికేట్‌లలోనే ఉన్న సమస్య అని అర్థం, కాబట్టి ముందుకు వెళ్లే ముందు దానిని సరిచేయండి.

ఇప్పుడు యంత్రాన్ని అడగండి.

openssl verify app.crt
echo $?

-CAfile లేనప్పుడు, OpenSSL తన అంతర్నిర్మిత సర్టిఫికేట్ డైరెక్టరీని ఉపయోగిస్తుంది. openssl version -d మీ బిల్డ్ ఉపయోగించే బేస్ డైరెక్టరీని ప్రింట్ చేస్తుంది, మరియు Ubuntu లో దాని కింద ఉన్న certs డైరెక్టరీ /etc/ssl/certs కి మారుతుంది. మీ రూట్ సర్టిఫికేట్ ఇంకా అక్కడ లేదు, కాబట్టి ధృవీకరణ విఫలమవుతుంది: చైన్ ఒక ఇష్యూయర్ వద్దకు చేరుకుంటుంది, కానీ ఆ స్టోర్‌లో అది ఉండదు, వెతకడానికి వేరే చోటు ఉండదు. ఎగ్జిట్ స్టేటస్ (exit status) గమనించండి. రెండు దశల తర్వాత మారేది ఇదే.

openssl verify కంటే ఒక నిజమైన క్లయింట్ మెరుగైన పరీక్షను అందిస్తుంది, ఎందుకంటే ఇది చైన్‌తో పాటు హోస్ట్‌నేమ్‌ను కూడా తనిఖీ చేస్తుంది. సర్టిఫికేట్‌ను సర్వ్ చేసి, దానిని ఫెచ్ (fetch) చేయండి.

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 కనెక్షన్‌ను 127.0.0.1 కి పంపుతుంది, అదే సమయంలో app.internal.example ని అభ్యర్థిస్తుంది, కాబట్టి SAN సరిపోలుతుంది మరియు ఇప్పుడు మిగిలి ఉన్న ఏకైక ప్రశ్న నమ్మకం (trust) మాత్రమే. curl విఫలమవుతుంది మరియు చైన్‌ను ఎందుకు ధృవీకరించలేకపోయిందో కారణాన్ని ప్రింట్ చేస్తుంది. మరిన్ని వివరాల కోసం -v ని జోడించండి. టెస్ట్ సర్వర్‌ను రన్ అవుతూనే ఉంచండి.

root ను /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

ఇది పనిచేస్తుందో లేదో నిర్ణయించే వివరాలు ఇక్కడ ఉన్నాయి:

• ఫైల్ పేరు తప్పనిసరిగా .crt తో ముగియాలి. update-ca-certificates మాన్యువల్ పేజీ ప్రకారం, /usr/local/share/ca-certificates లోపల ఉన్న .crt పొడిగింపు కలిగిన సర్టిఫికెట్లు మాత్రమే పరిగణించబడతాయి మరియు విశ్వసించబడతాయి. root.pem లేదా root.cer అని పేరున్న ఫైల్ ఎటువంటి హెచ్చరిక లేకుండా విస్మరించబడుతుంది.
• కంటెంట్ తప్పనిసరిగా PEM ఫార్మాట్‌లో ఉండాలి, అంటే ఇది BEGIN CERTIFICATE మరియు END CERTIFICATE లైన్ల మధ్య ఉన్న base64 బ్లాక్ అయి ఉండాలి. .crt గా పేరు మార్చిన DER ఫైల్ బైనరీగానే ఉంటుంది కాబట్టి అది చదవబడదు. దానిని openssl x509 -inform DER -in ca.der -out ca.crt తో మార్చండి.
• ఇక్కడ కేవలం root మాత్రమే ఉండాలి. CA ప్రైవేట్ కీ మరియు లీఫ్ సర్టిఫికెట్‌లకు ట్రస్ట్ స్టోర్‌లో చోటు లేదు.

update-ca-certificates ఎన్ని సర్టిఫికెట్లు జోడించబడ్డాయో మరియు ఎన్ని తొలగించబడ్డాయో చూపిస్తుంది. ఒకవేళ ఏవీ జోడించబడకపోతే, దానికి కారణం ఫైల్ పొడిగింపు లేదా ఫైల్ ఫార్మాట్ సరిగ్గా లేకపోవడమే.

ఆ సందేశంపై ఆధారపడకుండా, సిస్టమ్ వైపు నుండి మార్పును నిర్ధారించుకోండి.

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

మొదటి కమాండ్ మీ సర్టిఫికెట్ యొక్క సబ్జెక్ట్ హ్యాష్‌తో ఫైల్ పేరును తయారు చేసి జాబితా చేస్తుంది. update-ca-certificates ఆ సిమ్‌లింక్‌ను సృష్టించింది, అది మీరు ఇన్‌స్టాల్ చేసిన ఫైల్‌ను సూచిస్తుంది. రెండవ కమాండ్ సింగిల్-ఫైల్ బండిల్‌లో ఉన్న సర్టిఫికెట్ల సంఖ్యను లెక్కిస్తుంది. ఇన్‌స్టాల్ చేయడానికి ముందే దీనిని రన్ చేస్తే, సంఖ్య ఒకటి పెరగడాన్ని మీరు గమనించవచ్చు.

ఈ root ను ఇతర మెషీన్‌లకు కాపీ చేసేటప్పుడు, ఇన్‌స్టాల్ చేయడానికి ముందే కాపీ సరిగ్గా జరిగిందో లేదో తనిఖీ చేయండి. ఒక root సర్టిఫికెట్ తప్పుగా ఉంటే సిస్టమ్‌కు చాలా ప్రమాదకరం, కాబట్టి ఏదైనా ఇతర డౌన్‌లోడ్‌ను ఎలాగైతే checksum తో ధృవీకరిస్తారో, దీనిని కూడా అలాగే పరిగణించండి.

సిస్టమ్ స్టోర్‌కు వ్యతిరేకంగా మళ్ళీ ధృవీకరించండి

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

అవే కమాండ్లు, అవే సర్టిఫికేట్ ఫైళ్లు, కానీ భిన్నమైన సమాధానం. app.crt గురించి ఏదీ మారలేదు, మరియు మీరు ఇంతకుముందు ప్రారంభించిన సర్వరే ఇది. ఏకైక వ్యత్యాసం ఏమిటంటే, క్లయింట్లు చదివే స్టోర్‌లో ఇప్పుడు root ఉంది, కాబట్టి చైన్ పూర్తవుతుంది. గుర్తుంచుకోవలసిన విధానం ఇది: ధృవీకరణ అనేది క్లయింట్ ఇప్పటికే నమ్మే జారీదారు (issuer) కోసం చేసే అన్వేషణ, మరియు CAని ఇన్‌స్టాల్ చేయడం ద్వారానే ఆ జారీదారు క్లయింట్ వెతికే చోటుకు చేరుకుంటాడు.

kill %1 ఉపయోగించి టెస్ట్ సర్వర్‌ను ఆపివేయండి.

/etc/ssl/certs లో మీ ఫైల్‌ను ఎందుకు ఉంచకూడదు

/etc/ssl/certs అనేది జనరేట్ చేయబడిన అవుట్‌పుట్. update-ca-certificates దీనిని అసలైన సర్టిఫికేట్ ఫైళ్లకు సంబంధించిన సిమ్‌లింక్‌లతో (symlinks) నింపుతుంది మరియు వాటి పక్కనే /etc/ssl/certs/ca-certificates.crt అనే కన్కాటెనేటెడ్ బండిల్‌ను రాస్తుంది.

మీరు మాన్యువల్‌గా ఆ డైరెక్టరీలోకి కాపీ చేసిన సర్టిఫికేట్‌ను ఏదీ గుర్తించలేదు. OpenSSL యొక్క డైరెక్టరీ లుకప్, సర్టిఫికేట్ యొక్క సబ్జెక్ట్ హ్యాష్ పేరుతో ఉన్న ఫైళ్లను మాత్రమే తెరుస్తుంది, కాబట్టి myca.crt అని పేరున్న ఫైల్ దానికి కనిపించదు. Ubuntu లోని curl బండిల్ ఫైల్‌ను చదువుతుంది, మరియు ఈ బండిల్ రిజిస్టర్డ్ సోర్సెస్ నుండి తిరిగి నిర్మించబడుతుంది, కాబట్టి మీరు కాపీ చేసిన ఫైల్ ఆ పాత్‌లో ఉండదు. మీరు update-ca-certificates --fresh రన్ చేసినప్పుడు, ఆ డైరెక్టరీలోని సిమ్‌లింక్‌లు తొలగించబడి తిరిగి నిర్మించబడతాయి, దీనివల్ల మీరు మాన్యువల్‌గా చేసిన లింక్‌లు కూడా తొలగిపోతాయి.

ఈ విభజనలో మరొక భాగం /usr/share/ca-certificates, ఇది ca-certificates ప్యాకేజీకి చెందినది మరియు /etc/ca-certificates.conf లో జాబితా చేయబడింది. ప్యాకేజీ అప్‌డేట్‌లు దీనిని తిరిగి రాస్తాయి (rewrite). /usr/local/share/ca-certificates అనేది స్థానిక అడ్మినిస్ట్రేటర్ కోసం కేటాయించబడిన డైరెక్టరీ, కాబట్టి మిగిలిన వాటిని నిర్వహించే ప్యాకేజీ అప్‌గ్రేడ్ అయిన ప్రతిసారీ మీ CA సురక్షితంగా ఉంటుంది.

ఏ ప్రోగ్రామ్‌లు సిస్టమ్ ట్రస్ట్ స్టోర్‌ను విస్మరిస్తాయి

రూట్ సర్టిఫికేట్‌ను ఇన్‌స్టాల్ చేయడం ద్వారా OpenSSLని అడిగే లేదా /etc/ssl/certsని చదివే ప్రతి ప్రోగ్రామ్ సమస్య పరిష్కారమవుతుంది. ఇది curl, wget, git, Python యొక్క ప్రామాణిక ssl మాడ్యూల్ మరియు Linuxలో సిస్టమ్ ఫైళ్లను చదివే Go ప్రోగ్రామ్‌లకు వర్తిస్తుంది. తమ సొంత సర్టిఫికేట్ జాబితాను కలిగి ఉన్న రన్‌టైమ్‌లు దీనివల్ల ప్రభావితం కావు; విజయవంతంగా ఇన్‌స్టాల్ చేసిన తర్వాత తలెత్తే గందరగోళానికి ఇదే ప్రధాన కారణం.

• Node.js కంపైల్ చేయబడిన జాబితాను ఉపయోగిస్తుంది. ప్రాసెస్ ప్రారంభానికి ముందే ఎన్విరాన్‌మెంట్‌లో NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/example-internal-root.crtని సెట్ చేయడం ద్వారా మీ రూట్ సర్టిఫికేట్‌ను దానికి సూచించండి, ఎందుకంటే Node ఈ వేరియబుల్‌ను ప్రారంభంలోనే ఒకసారి చదువుతుంది. ప్రస్తుత Node రిలీజ్‌లలో సిస్టమ్ స్టోర్‌ను చదివే ఆప్షన్ కూడా ఉంది; మీ వెర్షన్‌లో అది ఉందో లేదో చూడటానికి node --help | grep -i system-caని రన్ చేయండి.
• Python యొక్క requests లైబ్రరీ certifi బండిల్‌ను ఉపయోగిస్తుంది. ఆ ప్రాసెస్ కోసం REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crtని సెట్ చేయండి లేదా కాల్‌కు verify="/etc/ssl/certs/ca-certificates.crt"ని పంపండి. అదే కారణంతో pip, --certని తీసుకుంటుంది.
• Java ఒక కీస్టోర్‌ను చదువుతుంది. Ubuntuలో ca-certificates-java ప్యాకేజీ /etc/ca-certificates/update.d/ కింద ఒక హుక్‌ను ఇన్‌స్టాల్ చేస్తుంది, కాబట్టి ఆ ప్యాకేజీ ఉన్నప్పుడు update-ca-certificates, Java కీస్టోర్‌ను కూడా రిఫ్రెష్ చేస్తుంది. అది లేకపోతే, keytool -importcertతో రూట్ సర్టిఫికేట్‌ను ఇంపోర్ట్ చేయండి.
• Firefox తన సొంత స్టోర్‌ను కలిగి ఉంటుంది మరియు ఎప్పుడూ /etc/ssl/certsని చూడదు. దాని సర్టిఫికేట్ సెట్టింగ్‌ల ద్వారా ఇంపోర్ట్ చేయండి. Linuxలో Chromium ప్రతి-యూజర్ NSS డేటాబేస్‌ను చదువుతుంది, దీనిని మీరు libnss3-tools ప్యాకేజీలోని certutilతో ఎడిట్ చేయవచ్చు.
• కంటైనర్‌లకు వాటి స్వంత ఫైల్‌సిస్టమ్ ఉంటుంది, కాబట్టి వాటి లోపల హోస్ట్ యొక్క స్టోర్‌కు ఎటువంటి ప్రాముఖ్యత ఉండదు. రూట్ సర్టిఫికేట్‌ను ఇమేజ్‌లోకి కాపీ చేసి, బిల్డ్ సమయంలో update-ca-certificatesని రన్ చేయండి. మీ సేవలు Docker Compose on a VPS కింద నడుస్తుంటే దీనిని ముందుగానే ప్లాన్ చేసుకోండి.

క్లీన్ ఇన్‌స్టాల్ తర్వాత కూడా ఒక ప్రోగ్రామ్ సర్టిఫికేట్‌ను తిరస్కరిస్తుంటే, వేరే దేనినైనా మార్చే ముందు అది ఏ ఫైళ్లను ఓపెన్ చేస్తుందో కనుగొనండి. strace -f -e trace=openat <command> 2>&1 | grep -i cert అనేది చాలా ప్రభావవంతమైన సాధనం, ఇది ఒకే రన్‌లో మీ ప్రశ్నకు సమాధానాన్ని ఇస్తుంది.

CA ను కాలక్రమేణా ఉపయోగపడేలా ఉంచడం

ఒక leaf certificate ను మళ్ళీ జారీ చేయడం అంటే, అదే app.ext ఫైల్‌ను ఉపయోగించి CSR మరియు signing ప్రక్రియలను మళ్ళీ నిర్వహించడం. క్లయింట్లు ఎటువంటి చర్య తీసుకోవాల్సిన అవసరం లేదు, ఎందుకంటే వారు నమ్మే root మారలేదు. ca.srl మరియు ప్రతి .ext ఫైల్‌ను CA డైరెక్టరీలోనే ఉంచండి; తద్వారా తదుపరి జారీ ప్రక్రియ అనేది జ్ఞాపకశక్తిపై ఆధారపడకుండా, గతంలో పనిచేసిన కమాండ్‌ను మళ్ళీ అమలు చేయడం ద్వారా సులభంగా పూర్తవుతుంది.

ca.key మరియు ca.crt ఫైళ్లను సర్వర్ వెలుపల ఎక్కడైనా సురక్షితంగా, ఎన్‌క్రిప్ట్ చేసిన స్థితిలో బ్యాకప్ తీసుకోండి. ఒకవేళ కీని కోల్పోతే, మీరు కొత్తగా ఏదీ జారీ చేయలేరు: అప్పుడు మీరు రెండవ CA ను నిర్మించి, మొదటి CA ఎక్కడెక్కడైతే ఇన్‌స్టాల్ చేయబడిందో, అక్కడంతా కొత్త root ను ఇన్‌స్టాల్ చేయాల్సి ఉంటుంది. రూట్ సర్టిఫికేట్‌ను స్వీకరించిన ప్రతి మెషీన్ మరియు ప్రతి అప్లికేషన్ స్టోర్ యొక్క లిఖితపూర్వక జాబితాను ఉంచండి, ఎందుకంటే ఆ జాబితా వల్లే భవిష్యత్తులో సర్టిఫికేట్ రొటేషన్ మరియు తొలగింపు సాధ్యమవుతాయి.

రూట్ సర్టిఫికేట్ గడువు ముగిసే సమయం దగ్గరపడుతున్నప్పుడు, ముందుగానే కొత్త దానిని రూపొందించి, పాత మరియు కొత్త రూట్లను పక్కపక్కనే ఇన్‌స్టాల్ చేయండి. స్టోర్‌లో రెండు రూట్లు ఉండటం వల్ల ఎటువంటి ఇబ్బంది లేదు, క్లయింట్ రెండింటిలో దేనినైనా అంగీకరిస్తుంది. కొత్త రూట్ ఆధారంగా leaf సర్టిఫికేట్లను మళ్ళీ జారీ చేయండి, ఆపై పాత రూట్‌పై ఏదీ ఆధారపడటం లేదని నిర్ధారించుకున్నాక దానిని తొలగించండి.

ట్రస్ట్ స్టోర్ నుండి CAని తొలగించడం

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

--fresh కమాండ్ /etc/ssl/certs లోని సిమ్‌లింక్‌లను (symlinks) తొలగిస్తుంది మరియు ఇంకా అందుబాటులో ఉన్న సోర్స్‌ల నుండి వాటిని తిరిగి నిర్మిస్తుంది, కాబట్టి తొలగించిన రూట్ సర్టిఫికేట్ డైరెక్టరీ మరియు బండిల్ రెండింటి నుండి తొలగిపోతుంది. మీరు ఇన్‌స్టాలేషన్‌ను ఎలా ధృవీకరించారో, అదే విధంగా తొలగింపును కూడా ధృవీకరించండి.

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

ధృవీకరణ మళ్ళీ విఫలమవుతుంది, సర్టిఫికేట్ సంఖ్య ప్రారంభంలో ఉన్న స్థితికి చేరుకుంటుంది మరియు హ్యాష్ సిమ్‌లింక్ తొలగిపోతుంది.

ఆ కమాండ్ సిస్టమ్ స్టోర్‌ను మాత్రమే ప్రభావితం చేస్తుంది. ఇతర ప్రదేశాలలో చేసిన ఇన్‌స్టాలేషన్‌ను మాన్యువల్‌గా రద్దు చేయండి: NODE_EXTRA_CA_CERTS ని క్లియర్ చేయండి, ఏదైనా Java keystore నుండి అలియాస్‌ను తొలగించండి, ప్రతి బ్రౌజర్ ప్రొఫైల్ నుండి రూట్ సర్టిఫికేట్‌ను తొలగించండి మరియు దానిని కలిగి ఉన్న ఏదైనా కంటైనర్ ఇమేజ్‌ను తిరిగి నిర్మించండి (rebuild). రూట్ సర్టిఫికేట్‌ను తొలగించినంత మాత్రాన అది సంతకం చేసిన సర్టిఫికేట్లు చెల్లనివిగా మారవు. ఆ రూట్‌ను ఇంకా నమ్మే ప్రతి మెషీన్‌లో అవి చెల్లుబాటు అవుతూనే ఉంటాయి, అందుకే ప్రైవేట్ CAని ఎక్కడెక్కడ ఇన్‌స్టాల్ చేశారో ఆ జాబితాను నిర్వహించడం చాలా ముఖ్యం. మీరు పూర్తిగా ఉపసంహరించుకోలేని CA ఒక శాశ్వత భద్రతా లోపం (permanent hole) వంటిది, కాబట్టి మీరు CAని సెటప్ చేసిన రోజే, జాబితా చిన్నదిగా ఉన్నప్పుడే ఒక మెషీన్‌పై తొలగింపు ప్రక్రియను పరీక్షించండి.

FAQ

Ubuntuలో CA certificate ను ఎక్కడ ఉంచాలి?

/usr/local/share/ca-certificates/ లో, .crt తో ముగిసే ఫైల్ పేరుతో మరియు PEM కంటెంట్‌తో ఉంచాలి, ఆపై sudo update-ca-certificates ని రన్ చేయాలి. ఆ డైరెక్టరీ స్థానిక అడ్మినిస్ట్రేటర్ కోసం కేటాయించబడింది, కాబట్టి ప్యాకేజీ అప్‌గ్రేడ్‌లు దానిని ప్రభావితం చేయవు. /usr/share/ca-certificates అనేది ca-certificates ప్యాకేజీకి చెందినది, మరియు /etc/ssl/certs రెండింటి నుండి రూపొందించబడుతుంది, కాబట్టి వాటిలో దేనిలోనైనా ఉంచిన ఫైల్ ఓవర్‌రైట్ చేయబడుతుంది లేదా విస్మరించబడుతుంది.

update-ca-certificates తర్వాత కూడా curl ఎందుకు certificate ను తిరస్కరిస్తుంది?

కారణాలను వరుసగా పరిశీలించండి. ఫైల్ .crt తో ముగియకపోవచ్చు, లేదా అది PEM కు బదులుగా DER ఫార్మాట్‌లో ఉండవచ్చు, అటువంటప్పుడు update-ca-certificates దానిని విస్మరించి ఏమీ జోడించదు. Certificate లో hostname తో సరిపోలే subjectAltName లేకపోవచ్చు, ఇది ట్రస్ట్ ఫెయిల్యూర్ కాదు, హోస్ట్‌నేమ్ ఫెయిల్యూర్; దీనిని openssl x509 -noout -ext subjectAltName -in app.crt తో తనిఖీ చేయండి. సర్వర్ కేవలం లీఫ్ సర్టిఫికేట్‌ను మాత్రమే పంపుతుండవచ్చు, కానీ ఇంటర్మీడియట్ సర్టిఫికేట్ కూడా అవసరం కావచ్చు. curl ను CURL_CA_BUNDLE లేదా --cacert ద్వారా వేరే బండిల్‌కు మళ్లించి ఉండవచ్చు. అలాగే, ఎక్కువ కాలం నడిచే సేవలను రీస్టార్ట్ చేయాలి, ఎందుకంటే చాలా ప్రోగ్రామ్‌లు ప్రారంభమైనప్పుడు ట్రస్ట్ స్టోర్‌ను ఒక్కసారి మాత్రమే చదువుతాయి.

సిస్టమ్ ట్రస్ట్ స్టోర్ Firefox, Chrome, Node మరియు Java లకు వర్తిస్తుందా?

లేదు. curl, wget, git, Python యొక్క ప్రామాణిక ssl మాడ్యూల్ మరియు Go ప్రోగ్రామ్‌లు సిస్టమ్ ఫైళ్లను చదువుతాయి, కాబట్టి update-ca-certificates రన్ చేసిన వెంటనే అవి పనిచేస్తాయి. Firefox తన సొంత స్టోర్‌ను నిర్వహిస్తుంది. Linux లో Chromium ప్రతి వినియోగదారునికి ఒక NSS డేటాబేస్‌ను ఉపయోగిస్తుంది, దీనిని libnss3-tools ప్యాకేజీలోని certutil తో ఎడిట్ చేయవచ్చు. Node.js కి మీ రూట్ ఫైల్‌ను సూచించే NODE_EXTRA_CA_CERTS అవసరం. Java ఒక కీస్టోర్‌ను చదువుతుంది, దీనిని ca-certificates-java ప్యాకేజీ ఇన్‌స్టాల్ అయినప్పుడు మాత్రమే update-ca-certificates రిఫ్రెష్ చేస్తుంది. Python యొక్క requests, certifi ని ఉపయోగిస్తుంది మరియు దానికి REQUESTS_CA_BUNDLE అవసరం.

Ubuntu ట్రస్ట్ స్టోర్ నుండి CA ను ఎలా తొలగించాలి?

/usr/local/share/ca-certificates/ నుండి ఫైల్‌ను తొలగించి, sudo update-ca-certificates --fresh ని రన్ చేయండి. --fresh ఆప్షన్ /etc/ssl/certs లోని సిమ్‌లింక్‌లను క్లియర్ చేసి వాటిని తిరిగి నిర్మిస్తుంది, కాబట్టి సర్టిఫికేట్ హ్యాష్ సిమ్‌లింక్‌ల నుండి మరియు ca-certificates.crt బండిల్ నుండి ఒకేసారి తొలగించబడుతుంది. ఆ CA సంతకం చేసిన సర్టిఫికేట్‌పై openssl verify రన్ చేసి, ఎగ్జిట్ స్టేటస్‌ను చూడటం ద్వారా నిర్ధారించుకోండి. ఆ తర్వాత మీరు జోడించిన ప్రతి ఇతర స్టోర్‌లో కూడా తొలగింపును పునరావృతం చేయండి, ఎందుకంటే ఆ కమాండ్ వాటిని ఏమీ చేయదు.

పబ్లిక్ సైట్ కోసం Let's Encrypt కు బదులుగా ప్రైవేట్ CA ని ఉపయోగించవచ్చా?

లేదు. సందర్శకుల బ్రౌజర్ మీ రూట్‌ను ఎప్పుడూ చూసి ఉండదు, కాబట్టి అది పూర్తి పేజీ హెచ్చరికను చూపుతుంది, మరియు మీరు నియంత్రించని మెషీన్‌లలో మీ రూట్‌ను ఇన్‌స్టాల్ చేయలేరు. ప్రైవేట్ CA అనేది మీ స్వంత మెషీన్‌లు మాత్రమే రిజాల్వ్ చేసే పేర్ల కోసం మరియు మీరు నిర్వహించే క్లయింట్ల కోసం మాత్రమే. అపరిచితులు సందర్శించే దేనికైనా, పబ్లిక్ CA నుండి సర్టిఫికేట్‌ను పొందండి.