SSD Nodes Learn 🎉 VPS $5.50/महिन्यापासून
मार्गदर्शक Matt Connorद्वारे Matt Connor

Ubuntu मध्ये स्वतःचे CA प्रमाणपत्र कसे जोडावे?

Ubuntu च्या ट्रस्ट स्टोअरमध्ये स्वतःचे CA प्रमाणपत्र जोडण्यासाठी /usr/local/share/ca-certificates मध्ये फाइल कॉपी करून update-ca-certificates कमांड कशी वापरावी ते शिका.

Ubuntu च्या ट्रस्ट स्टोअरमध्ये स्वतःचे CA जोडा

Ubuntu च्या ट्रस्ट स्टोअरमध्ये स्वतःचे CA जोडण्यासाठी, रूट प्रमाणपत्र /usr/local/share/ca-certificates/ मध्ये .crt ने संपणाऱ्या नावाने कॉपी करा आणि त्यानंतर sudo update-ca-certificates चालवा. CA (certificate authority) ही एक की-पेअर (key pair) असते, ज्याच्या प्रमाणपत्राला इतर प्रमाणपत्रांवर स्वाक्षरी करण्याचा अधिकार असतो. एकदा का मशीन तुमच्या रूटवर विश्वास ठेवू लागले की, त्या रूटने स्वाक्षरी केलेले प्रत्येक प्रमाणपत्र स्वीकारले जाते, ज्यामुळे तुमच्या स्वतःच्या सेवांमधील HTTPS पडताळणी अयशस्वी होणे थांबते.

हे मार्गदर्शक openssl वापरून संपूर्ण साखळी ऑफलाइन तयार करते. तुम्ही एक रूट की आणि रूट प्रमाणपत्र तयार करता, सर्व्हरसाठी एक लीफ प्रमाणपत्र जारी करता, त्यानंतर रूट इंस्टॉल करता आणि पडताळणी कमांडचे उत्तर कसे बदलते ते पाहता. हा क्रम महत्त्वाचा आहे: इंस्टॉल करण्यापूर्वी आणि नंतर पडताळणी केल्यामुळेच इंस्टॉलमुळे काय बदल झाला हे तुम्हाला समजते.

Ubuntu 24.04 मध्ये डिफॉल्ट इमेजवर OpenSSL 3 आणि ca-certificates पॅकेज आधीच उपलब्ध असते, त्यामुळे सुरुवातीला काहीही इंस्टॉल करण्याची आवश्यकता नाही (ऑगस्ट 2026 मध्ये तपासल्यानुसार).

तुम्ही स्वतःची CA कधी चालवावी?

Let's Encrypt सारख्या सार्वजनिक CA ला सार्वजनिक DNS मध्ये नाव आणि पोहोचता येईल असा सर्व्हर आवश्यक असतो. अंतर्गत (internal) नावे यासाठी पात्र नसतात. खाजगी नेटवर्कवरील डेटाबेस किंवा टनेलशी जोडलेले ॲडमिन पॅनेल सार्वजनिक प्रमाणपत्र मिळवू शकत नाहीत आणि केवळ प्रमाणपत्र मिळवण्यासाठी त्यांना इंटरनेटवर उघडे करणे योग्य नाही.

Ubuntu वरील self-signed certificate केवळ एका होस्टसाठी काम करते. प्रत्येक क्लायंटला त्या एका प्रमाणपत्रावर विश्वास ठेवावा लागतो आणि दुसऱ्या होस्टसाठी पुन्हा तीच प्रक्रिया करावी लागते. खाजगी CA मुळे हा निर्णय एका स्तरावर वर जातो. क्लायंट एकदा रूटवर विश्वास ठेवतात आणि त्यानंतर रूटने स्वाक्षरी केलेले प्रत्येक प्रमाणपत्र, ज्यामध्ये अद्याप अस्तित्वात नसलेल्या होस्टची प्रमाणपत्रेही समाविष्ट आहेत, ते आपोआप विश्वसनीय ठरतात.

याची किंमत मोठी आहे. रूट की (root key) मर्यादांच्या अधीन राहून कशावरही स्वाक्षरी करू शकते, त्यामुळे ज्याच्याकडे ca.key वाचण्याची क्षमता आहे, तो अशी प्रमाणपत्रे जारी करू शकतो जी तुमची यंत्रे स्वीकारतील. तिचे रक्षण त्याच प्रकारे करा ज्या प्रकारे तुम्ही SSH key management मधील खाजगी की चे करता. जर एखाद्या सेवेला सार्वजनिक DNS नाव असेल, तर हे सर्व टाळा आणि सार्वजनिक CA वापरा: Certbot with nginx and Let's Encrypt वापरणे अधिक सोपे आहे आणि त्यासाठी क्लायंटच्या बाजूला काहीही इन्स्टॉल करण्याची गरज पडत नाही.

CA की (key) आणि रूट प्रमाणपत्र तयार करणे

केवळ तुमच्या वापरकर्त्याला प्रवेश असेल अशा डिरेक्टरीमध्ये काम करा. रूट की (root key) कधीही या डिरेक्टरीच्या बाहेर जाऊ देऊ नका.

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

-aes256 तुम्ही निवडलेल्या पासफ्रेजने की (key) एनक्रिप्ट करते आणि त्यानंतर या की (key) द्वारे स्वाक्षरी करणाऱ्या प्रत्येक कमांडसाठी तो पासफ्रेज विचारला जातो. जर तुम्ही -aes256 वापरले नाही, तर की (key) डिस्कवर उघड्या स्वरूपात (clear text) साठवली जाते. अशा वेळी, बॅकअप किंवा दुसरा ॲडमिन खाते असणारी व्यक्ती तुमच्या मशीनवर विश्वासार्ह प्रमाणपत्रे जारी करण्याची क्षमता मिळवू शकते.

आता रूट प्रमाणपत्र तयार करा, ज्यावर CA की (key) स्वतः स्वाक्षरी करते.

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 च्या जागी तुम्ही वापरत असलेला नेम सफिक्स (name suffix) लिहा आणि शेवटचे एक्स्टेंशन ठेवण्यापूर्वी पुढील विभाग वाचा.

प्रत्येक एक्स्टेंशन एक विशिष्ट कार्य करते.

  • basicConstraints सह CA:TRUE मुळे हे CA प्रमाणपत्र बनते. याशिवाय, क्लायंट या की (key) द्वारे स्वाक्षरी केलेले कोणतेही प्रमाणपत्र नाकारेल, जरी स्वाक्षरी अचूक असली तरीही.
  • pathlen:0 असे दर्शवते की CA लीफ प्रमाणपत्रे (leaf certificates) स्वाक्षरित करू शकते, परंतु त्याखाली इतर कोणतेही CA तयार करू शकत नाही.
  • keyUsage की (key) ला फक्त प्रमाणपत्रे आणि रिव्होकेशन लिस्ट (revocation lists) स्वाक्षरित करण्यापुरते मर्यादित ठेवते, जेणेकरून चुकूनही हीच की (key) TLS सर्व्हर की (key) म्हणून वापरली जाणार नाही.
  • subjectKeyIdentifier रूटला एक ओळख (identifier) देते, ज्याकडे लीफ प्रमाणपत्रे निर्देश करतात. यामुळे शेकडो प्रमाणपत्रे साठवलेल्या स्टोअरमधून क्लायंट योग्य इश्यूअर (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 हे प्रमाण कमी करते. रूटमध्ये permitted;DNS:internal.example असल्यास, internal.example च्या बाहेरील नावासाठी या CA कडून आलेली साखळी (chain) नाकारली जाते, जरी स्वाक्षरी वैध असली तरीही.

त्यावर विश्वास ठेवण्याऐवजी त्याची चाचणी करा.

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 तुम्ही विचारलेली कोणतीही गोष्ट स्वाक्षरीत करतो. पडताळणीच्या वेळी ही प्रक्रिया थांबते: एक्झिट स्टेटस शून्य नसते आणि OpenSSL ज्या मर्यादेमुळे (constraint) हे घडले तिचे नाव दर्शवते. हेच या एक्स्टेंशनचे मूल्य आहे. चोरीला गेलेली CA की (key) देखील सबट्रीच्या बाहेरील नावासाठी कार्यक्षम प्रमाणपत्र तयार करू शकत नाही. काम पूर्ण झाल्यावर rm /tmp/outside.* वापरून उरलेल्या फाईल्स हटवा.

मर्यादा लागू करण्यापूर्वी चार गोष्टी लक्षात ठेवा. हे critical म्हणून चिन्हांकित असते, त्यामुळे ज्या क्लायंटला हे एक्स्टेंशन समजत नाही, त्याने साखळीकडे दुर्लक्ष करण्याऐवजी ती नाकारली पाहिजे. हा सुरक्षित मार्ग असला तरी, जुन्या TLS लायब्ररीसाठी हे अनपेक्षित ठरू शकते. DNS नावांच्या परवानगी असलेल्या सबट्रीमुळे IP ॲड्रेस SANs मर्यादित होत नाहीत, कारण ज्या नाव प्रकाराची सबट्री सूचीबद्ध नाही तो अनिर्बंध राहतो. त्यामुळे जर तुमच्या प्रमाणपत्रांमध्ये IP ॲड्रेस असतील, तर त्याच एक्स्टेंशनमध्ये permitted;IP:10.0.0.0/255.255.0.0 जोडा. सबट्रीमध्ये तुम्ही भविष्यात जारी करणार असलेल्या प्रत्येक नावाचा समावेश असावा, ज्यात लहान होस्टनेम्सचाही समावेश आहे. त्यामुळे app या नावासाठीचे प्रमाणपत्र वरील उदाहरणाप्रमाणे अपयशी ठरेल. ही मर्यादा रूटमध्येच अंतर्भूत असते, त्यामुळे तुमचा निर्णय बदलल्यास तुम्हाला नवीन रूट प्रमाणपत्र तयार करावे लागेल आणि प्रत्येक क्लायंटवर ते पुन्हा इन्स्टॉल करावे लागेल.

तुमच्या CA द्वारे स्वाक्षरी केलेले लीफ प्रमाणपत्र जारी करा

लीफ प्रमाणपत्र हे असे प्रमाणपत्र असते जे सर्व्हर क्लायंटला सादर करतो. याची सुरुवात स्वतःची की आणि CSR (certificate signing request) ने करा. यामध्ये पब्लिक की आणि विनंती केलेले नाव असते, ज्यावर लीफ कीने स्वाक्षरी केलेली असते, जेणेकरून विनंती करणार्‍याकडे खाजगी की असल्याचे सिद्ध होईल.

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

ज्या नावांची आवश्यकता असते ती CSR मध्ये नसून एका एक्स्टेंशन फाइलमध्ये असावीत. क्लायंट होस्टनेमची पडताळणी subjectAltName (SAN) शी करतात आणि कॉमन नेम (CN) कडे पूर्णपणे दुर्लक्ष करतात. त्यामुळे, ज्या प्रमाणपत्रात CN आहे पण SAN नाही, असे प्रमाणपत्र प्रत्येक आधुनिक क्लायंटवर होस्टनेम पडताळणीमध्ये अपयशी ठरते, मग 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.srl ला CA च्या शेजारी लिहिते, ज्यामध्ये पुढील अनुक्रमांक (serial number) असतो, जेणेकरून या CA द्वारे जारी केलेल्या कोणत्याही दोन प्रमाणपत्रांचा अनुक्रमांक सारखा नसेल. ती फाइल CA डिरेक्टरीमध्ये ठेवा. -days 397 ही एक निवड आहे, साधनाची मर्यादा नाही. सार्वजनिक CA च्या तुलनेत येथे कमी कालावधी (short lifetimes) असणे अधिक महत्त्वाचे आहे, कारण खाजगी CA कडे रिव्होकेशन इन्फ्रास्ट्रक्चर नसते: जोपर्यंत तुम्ही स्वतः तयार करत नाही, तोपर्यंत तिथे CRL किंवा OCSP रिस्पॉन्डर नसतो. त्यामुळे, जर लीफ की लीक झाली, तर प्रमाणपत्र कालबाह्य होईपर्यंत ती वापरण्यायोग्य राहते.

ट्रस्ट स्टोअरमध्ये जाण्यापूर्वी निकालाची पडताळणी करा.

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

आता इश्यूअर ओळीमध्ये लीफच्या ऐवजी CA चे नाव दिसते. SAN ओळीमध्ये ती नावे सूचीबद्ध असतात ज्यांच्यासाठी हे प्रमाणपत्र वैध आहे, आणि क्लायंट फक्त त्या यादीशी पडताळणी करतो, इतर कशाशीही नाही.

काहीही इंस्टॉल करण्यापूर्वी स्पष्ट -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 कडे रिझॉल्व्ह होते. तुमचे रूट प्रमाणपत्र तिथे अजून नसल्यामुळे, पडताळणी अयशस्वी होते: चेन अशा इश्यूअरपर्यंत पोहोचते जो स्टोअरमध्ये नाही आणि शोधण्यासाठी दुसरी जागा उरलेली नाही. एक्झिट स्टेटसची नोंद घ्या. दोन पायऱ्यांनंतर हीच गोष्ट बदलणार आहे.

एक वास्तविक क्लायंट openssl verify पेक्षा चांगली चाचणी करतो, कारण तो चेनसोबतच होस्टनेमचीही तपासणी करतो. प्रमाणपत्र सर्व्ह करा आणि ते फेच करा.

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 जुळते आणि आता फक्त विश्वासाचा प्रश्न उरतो. curl अयशस्वी होते आणि चेनची पडताळणी का होऊ शकली नाही याचे कारण प्रिंट करते. अधिक तपशीलासाठी -v जोडा. टेस्ट सर्व्हर चालू ठेवा.

रूट सर्टिफिकेटला /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 वापरून रूपांतरित करा.
  • येथे फक्त रूट सर्टिफिकेटच असावे. 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 ने तो सिम्बॉलिक लिंक (symlink) तयार केला आहे, जो तुम्ही इंस्टॉल केलेल्या फाईलकडे निर्देश करतो. दुसरी कमांड सिंगल-फाईल बंडलमधील प्रमाणपत्रांची संख्या मोजते. इंस्टॉल करण्यापूर्वी ही कमांड चालवा, म्हणजे तुम्हाला संख्येत एकने झालेली वाढ दिसून येईल.

जेव्हा तुम्ही हे रूट सर्टिफिकेट इतर मशीनवर कॉपी करता, तेव्हा इंस्टॉल करण्यापूर्वी ती कॉपी व्यवस्थित पोहोचली आहे का याची खात्री करा. रूट सर्टिफिकेटमध्ये चूक होणे हे सिस्टमसाठी अत्यंत घातक ठरू शकते, म्हणून इतर कोणत्याही डाउनलोडप्रमाणेच चेकसमसह पडताळणी करूनच त्याचा वापर करा.

सिस्टम स्टोअरच्या आधारे पुन्हा पडताळणी करा

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

त्याच कमांड्स, त्याच सर्टिफिकेट फाइल्स, पण वेगळे उत्तर. app.crt बद्दल काहीही बदललेले नाही आणि सर्व्हर तोच आहे जो तुम्ही आधी सुरू केला होता. एकमेव फरक हा आहे की, आता root सर्टिफिकेट त्या स्टोअरमध्ये आहे जिथून क्लायंट्स माहिती वाचतात, त्यामुळे साखळी (chain) पूर्ण होते. ही यंत्रणा लक्षात ठेवण्यासारखी आहे: पडताळणी म्हणजे अशा जारीकर्त्याचा (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 बंडल फाईल वाचते आणि हे बंडल नोंदणीकृत स्रोतांपासून पुन्हा तयार केले जाते, त्यामुळे तुमची कॉपी त्या मार्गावर (path) नसते. जर तुम्ही update-ca-certificates --fresh चालवले, तर डिरेक्टरीमधील सिम्बॉलिक लिंक्स काढून पुन्हा तयार केल्या जातात, ज्यामध्ये तुम्ही हाताने तयार केलेली लिंक देखील निघून जाते.

या विभाजनाचा दुसरा भाग /usr/share/ca-certificates आहे, जो ca-certificates पॅकेजचा भाग आहे आणि /etc/ca-certificates.conf मध्ये सूचीबद्ध आहे. पॅकेज अपडेट्स ते पुन्हा लिहितात. /usr/local/share/ca-certificates ही डिरेक्टरी स्थानिक प्रशासकासाठी (local administrator) राखीव आहे, त्यामुळे उर्वरित फाईल्स व्यवस्थापित करणाऱ्या पॅकेजच्या प्रत्येक अपग्रेडनंतरही तुमचे CA सुरक्षित राहते.

कोणते प्रोग्राम सिस्टम ट्रस्ट स्टोअरकडे दुर्लक्ष करतात

रूट सर्टिफिकेट इन्स्टॉल केल्यामुळे OpenSSL वापरणारे किंवा /etc/ssl/certs वाचणारे सर्व प्रोग्राम्स सुरक्षित होतात. यामध्ये curl, wget, git, Python चे मानक ssl मॉड्यूल आणि Go प्रोग्राम्सचा समावेश होतो, जे Linux वरील सिस्टम फाइल्स वाचतात. ज्या रनटाइम्समध्ये स्वतःची सर्टिफिकेट लिस्ट असते, त्यांच्यावर याचा परिणाम होत नाही; यशस्वी इन्स्टॉलेशननंतर होणाऱ्या गोंधळाचे हेच मुख्य कारण आहे.

  • 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 की-स्टोअर (keystore) वाचते. Ubuntu वर ca-certificates-java पॅकेज /etc/ca-certificates/update.d/ अंतर्गत एक हुक इन्स्टॉल करते, त्यामुळे हे पॅकेज उपलब्ध असल्यास update-ca-certificates जावा की-स्टोअरला देखील रिफ्रेश करते. हे पॅकेज नसल्यास, keytool -importcert वापरून रूट सर्टिफिकेट इम्पोर्ट करा.
  • Firefox स्वतःचे स्टोअर वापरते आणि कधीही /etc/ssl/certs कडे पाहत नाही. त्याच्या सर्टिफिकेट सेटिंग्जद्वारे सर्टिफिकेट इम्पोर्ट करा. Linux वरील Chromium प्रति-वापरकर्ता (per-user) 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) प्रमाणपत्र पुन्हा जारी करणे म्हणजे CSR प्रक्रिया आणि स्वाक्षरी प्रक्रिया पुन्हा करणे, ज्यासाठी त्याच app.ext फाईलचा वापर होतो. क्लायंटना कोणतीही कृती करण्याची गरज नसते, कारण ज्या रूटवर त्यांचा विश्वास आहे तो बदललेला नसतो. ca.srl आणि प्रत्येक .ext फाईल CA डिरेक्टरीमध्ये ठेवा, जेणेकरून पुढच्या वेळी प्रमाणपत्र जारी करताना स्मृतीवर अवलंबून न राहता आधी यशस्वी झालेली कमांड पुन्हा वापरता येईल.

ca.key आणि ca.crt चा बॅकअप मशीनच्या बाहेर कुठेतरी सुरक्षित ठेवा, जो एनक्रिप्टेड असावा. जर की (key) हरवली, तर तुम्ही नवीन काहीही जारी करू शकणार नाही: तुम्हाला दुसरी CA तयार करावी लागेल आणि जिथे पहिली CA इन्स्टॉल केली होती, तिथे नवीन रूट इन्स्टॉल करावा लागेल. ज्या प्रत्येक मशीनवर आणि ॲप्लिकेशन स्टोअरमध्ये रूट इन्स्टॉल केला आहे, त्यांची लेखी यादी ठेवा; कारण ही यादीच प्रमाणपत्र रोटेशन आणि काढणे शक्य करते.

जेव्हा रूटची मुदत संपत येईल, तेव्हा नवीन रूट लवकर तयार करा आणि दोन्ही रूट एकाच वेळी इन्स्टॉल करा. स्टोअरमध्ये दोन रूट असणे योग्य आहे आणि क्लायंट दोन्हीपैकी कोणत्याही एकाला स्वीकारतो. नवीन रूटच्या आधारे लीफ प्रमाणपत्रे पुन्हा जारी करा आणि एकदा का जुन्या रूटवर कोणतीही सेवा अवलंबून नसेल की तो काढून टाका.

ट्रस्ट स्टोअरमधून 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 मधून अलियास (alias) हटवा, प्रत्येक ब्राउझर प्रोफाइलमधून रूट प्रमाणपत्र काढून टाका आणि ज्या कंटेनर इमेजमध्ये ते समाविष्ट केले होते, ती पुन्हा बिल्ड करा. रूट प्रमाणपत्र काढून टाकल्याने त्याने स्वाक्षरी केलेली प्रमाणपत्रे अवैध ठरत नाहीत. ज्या मशीनवर अजूनही या रूट प्रमाणपत्रावर विश्वास ठेवला जातो, तिथे ती वैध राहतात. म्हणूनच खाजगी CA साठी ते रूट प्रमाणपत्र कुठे कुठे वापरले आहे, याची लेखी यादी असणे आवश्यक आहे. जो CA तुम्ही पूर्णपणे मागे घेऊ शकत नाही, तो एक कायमस्वरूपी सुरक्षा धोका (hole) असतो. त्यामुळे, ज्या दिवशी तुम्ही सेटअप कराल, त्याच दिवशी एका मशीनवर हे काढून पाहण्याची चाचणी करा, जोपर्यंत यादी लहान आहे.

FAQ

Ubuntu वर मी CA प्रमाणपत्र कुठे ठेवू?

/usr/local/share/ca-certificates/ मध्ये, ज्या फाईलचे नाव .crt ने संपते आणि ज्यामध्ये PEM मजकूर आहे, तिथे ठेवा आणि त्यानंतर sudo update-ca-certificates चालवा. ती डिरेक्टरी स्थानिक प्रशासकासाठी राखीव आहे, त्यामुळे पॅकेज अपग्रेड्स दरम्यान त्यातील फाईल्स सुरक्षित राहतात. /usr/share/ca-certificates हे ca-certificates पॅकेजच्या मालकीचे असते आणि /etc/ssl/certs हे दोन्हीवरून तयार केले जाते, त्यामुळे त्यापैकी कोणत्याही ठिकाणी ठेवलेली फाईल ओव्हरराईट केली जाते किंवा दुर्लक्षित केली जाते.

update-ca-certificates नंतरही curl प्रमाणपत्र का नाकारते?

दिलेल्या कारणांची क्रमाने तपासणी करा. फाईल .crt ने संपत नसेल किंवा ती PEM ऐवजी DER स्वरूपात असेल, तर update-ca-certificates तिला वगळते आणि काहीही जोडत नाही. प्रमाणपत्रात होस्टनेमशी जुळणारे 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 मधील सिमलिनक्स (symlinks) साफ करतो आणि त्यांना पुन्हा तयार करतो, त्यामुळे प्रमाणपत्र हॅश सिमलिनक्स आणि ca-certificates.crt बंडलमधून एकाच वेळी निघून जाते. त्या CA ने स्वाक्षरी केलेल्या प्रमाणपत्रावर openssl verify चालवून आणि एक्झिट स्टेटस तपासून खात्री करा. त्यानंतर तुम्ही ज्या इतर स्टोअर्समध्ये ते जोडले होते, तिथूनही ते काढून टाका, कारण तो कमांड इतर स्टोअर्सना स्पर्श करत नाही.

सार्वजनिक साइटसाठी मी Let's Encrypt ऐवजी खाजगी CA वापरू शकतो का?

नाही. अभ्यागताच्या ब्राउझरने तुमचे रूट प्रमाणपत्र कधीही पाहिलेले नसते, त्यामुळे तो पूर्ण-पानावर चेतावणी दाखवतो आणि तुम्ही तुमच्या नियंत्रणात नसलेल्या मशीनवर तुमचे रूट प्रमाणपत्र इन्स्टॉल करू शकत नाही. खाजगी CA फक्त अशा नावांच्या वापरासाठी आहे जी फक्त तुमची स्वतःची मशीन्स रिझॉल्व्ह करतात आणि ज्या क्लायंटचे प्रशासन तुम्ही करता. अनोळखी व्यक्ती भेट देणाऱ्या कोणत्याही गोष्टीसाठी, सार्वजनिक CA कडूनच प्रमाणपत्र मिळवा.

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