SSL प्रमाणपत्र के लिए सर्वश्रेष्ठ स्थान और उबंटू पर निजी कुंजी

Question

उबंटू पर, यह एक प्रमाण पत्र पर हस्ताक्षर करने के लिए इस्तेमाल की जाने वाली निजी कुंजी के लिए सबसे अच्छी जगह की तरह दिखता है (नगीनेक्स द्वारा उपयोग के लिए) /etc/ssl/private/

यह उत्तर जोड़ता है कि प्रमाण पत्र में जाना चाहिए /etc/ssl/certs/लेकिन यह एक असुरक्षित जगह की तरह लगता है। क्या .crtफ़ाइलों को सुरक्षित रखने की आवश्यकता है या क्या उन्हें सार्वजनिक माना जाता है?

Comments

आप अपनी .crtपसंद के हिसाब से टाइम्स स्क्वायर बिलबोर्ड पर रख सकते हैं।

— सिजयोज़

Answer 1

.Crt फ़ाइल कनेक्ट होने वाली हर चीज़ पर भेजी जाती है; यह सार्वजनिक है। ( chown root:rootऔर chmod 644)

निजी कुंजी स्थान में जोड़ने के लिए; सुनिश्चित करें कि आप इसे ठीक से सुरक्षित करने के साथ-साथ इसमें मौजूद हैं। ( chown root:ssl-certऔर chmod 640)

Comments

मुझे आश्चर्य है कि डिफ़ॉल्ट रूप से वह निर्देशिका g + s क्यों नहीं है।

— कोलिन एंडरसन

यह होने की जरूरत नहीं है; निर्देशिका ० the५० है, इसलिए फ़ाइलों को पढ़ने के लिए निर्देशिका में किसी भी उपयोगकर्ता के पास नहीं है ताकि वह निर्देशिका में आगे न बढ़ सके।

— Womble

ऐसा लगता है कि एसएसएल-सर्टिफिकेट ubuntu पर एक अमान्य समूह का नाम है। हो सकता है कि इसे जड़ से

— उखाड़ फेंका जाए

@Atifm ssl- सर्टिफिकेट सर्टिफिकेट ग्रुप को 16.04 या 18.04 को पेश किया गया था। मुझे याद नहीं आ रहा है।

— डायलनयुंग

@ डायलनयुंग: यह सुनिश्चित करने के लिए उबंटू 12.04 पर मौजूद है, और मुझे विश्वास है कि यह पैकेज द्वारा बनाया गया ssl-certहै, शायद अन्य बातों के अलावा, स्व-हस्ताक्षरित

— सर्पिल

Answer 2

यह वास्तव में कोई फर्क नहीं पड़ता है कि आप उन्हें कहाँ तक डालते हैं जब तक आप अपनी निजी कुंजी फ़ाइल (नों) को ठीक से संरक्षित नहीं करते हैं । सार्वजनिक प्रमाणपत्र सार्वजनिक है, कोई सुरक्षा की जरूरत नहीं है - सर्वर विशेषाधिकार या अन्यथा।

उत्तर पर विस्तार करने के लिए, मैं डिफ़ॉल्ट स्थान का उपयोग नहीं करता हूं /etc/ssl।
मेरे लिए बैकअप + अन्य कारणों से सभी खानों को एक अलग क्षेत्र में रखना आसान है।

अपाचे एसएसएल के लिए, मैं अपना /etc/apache2/ssl/privateया समान "रूट एरिया" में रखता हूं /etc/।

उदाहरण सेटअप

यह पोस्ट उबंटू (डेबियन) + अपाचे की ओर गियर है, लेकिन अधिकांश सिस्टम पर काम करना चाहिए -
बस अनुमतियों को लागू करें और दिए गए कॉन्फ़िगरेशन (अपाचे / nginx / etc) में स्थान / पथ को अपडेट करें।
यदि SSL कुंजी फाइलें सही ढंग से संरक्षित की जाती हैं (निर्देशिका और फाइलें), तो आप ठीक हो जाएंगे। नोट नोट करें!

निर्देशिका बनाएँ:

sudo mkdir /etc/apache2/ssl
sudo mkdir /etc/apache2/ssl/private
sudo chmod 755 /etc/apache2/ssl
sudo chmod 710 /etc/apache2/ssl/private

नोट: उबंटू के तहत समूह
chmod 710का समर्थन करता है ssl-cert। (टिप्पणियां देखें) पर
अनुमति सेट करना भी ठीक काम करेगा।700/etc/apache2/ssl/private

SSL फ़ाइलें रखें:

रखो सार्वजनिक में मध्यवर्ती प्रमाणपत्र (रों) के साथ-साथ www SSL प्रमाणपत्र (रों) /etc/apache2/ssl
रखो निजी ssl कुंजी (रों) में/etc/apache2/ssl/private

स्वामी सेट करें:

sudo chown -R root:root /etc/apache2/ssl/
sudo chown -R root:ssl-cert /etc/apache2/ssl/private/

नोट:
यदि आपके पास ssl- सर्टिफिकेट समूह नहीं है, तो बस उपर्युक्त लाइन पर 'root: root' का प्रयोग करें या 2nd लाइन छोड़ें।

अनुमतियाँ सेट करें:

सार्वजनिक प्रमाण पत्र

sudo chmod 644 /etc/apache2/ssl/*.crt

निजी कुंजी

sudo chmod 640 /etc/apache2/ssl/private/*.key

नोट:
समूह की अनुमति उबंटू एसएसएल-सर्टिफिकेट समूह के कारण READ (640) पर सेट है। '600' भी ठीक है।

अपाचे एसएसएल मॉड्यूल को सक्षम करें

sudo a2enmod ssl

किसी भी अपाचे साइट फ़ाइलों को संपादित करें और सक्षम करें

(अंतिम पैराग्राफ देखें) *

sudo nano /etc/apache/sites-available/mysiteexample-ssl.conf
sudo a2ensite mysiteexample-ssl
#             ^^^^^^^^^^^^^^^^^ <-Substitute your ".conf" filename(s)

Apache2 सेवा को पुनरारंभ करें

sudo service apache2 restart

या

sudo systemctl restart apache2.service

किया हुआ। अपनी नई एसएसएल साइट का परीक्षण करें।

* फिर से यह प्रश्न से परे चला जाता है, लेकिन आप डिफ़ॉल्ट Apache SSL साइट कॉन्फ़िगरेशन फ़ाइल ( sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/mysiteexample-ssl.conf) को एक सामान्य प्रारंभिक बिंदु / उदाहरण के रूप में कॉपी कर सकते हैं, जो कि सामान्य (Ubuntu / Debian) Apache / SSL 'conf' फ़ाइल के तहत सामान्य रूप से उपयोग किए जाने वाले डिफ़ॉल्ट निर्देशों / निर्देशिकाओं का उदाहरण है। । यह आम तौर पर एक स्व-हस्ताक्षरित एसएसएल प्रमाणपत्र + कुंजी (स्नैकोइल), सीए बंडल, साथ ही एक दिए गए एसएसएल साइट के लिए उपयोग किए जाने वाले सामान्य निर्देशों को इंगित करता है ।

कॉपी करने के बाद, बस नई .conf फ़ाइल को संपादित करें और इसे जोड़ने / हटाने / अपडेट करने के लिए आवश्यकतानुसार नई जानकारी / पथ के साथ फिर sudo a2ensite mysiteexample-sslइसे सक्षम करने के लिए निष्पादित करें।

Comments

निश्चित नहीं है कि आप / etc / apache2 / ssl / private के लिए अनुमतियों के लिए 710 सेट करने का सुझाव क्यों देंगे। निर्देशिका (समूह के लिए) के लिए निर्देशिका के लिए निष्पादित बिट को सेट करने के बिना निर्देशिका के लिए रीड बिट को सेट करना मेरे लिए बहुत मायने नहीं रखता है। क्या आपको इसे 750 के रूप में सेट करने का मतलब था?

— chriv

@chriv मैं सिर्फ उबंटू डिफ़ॉल्ट एसएसएल क्षेत्र के तहत सेटअप को देखने के आधार पर अनुमतियाँ सेट करता हूं। देखें / etc / ssl / certs और / etc / ssl / निजी और ssl-certs समूह का उपयोग करें। देखें stackoverflow.com/a/23408897/503621

— bshea

कई संभावित उत्तरों के साथ एक सामान्य प्रश्न के लिए एक बहुत अच्छी तरह से और विस्तृत विवरण। धन्यवाद। बस कुछ चीजों को जोड़ने के लिए, आपके <VirtualHost *:443>अनुभाग में आपके sites-available/mysite.confप्रमाणपत्र शामिल होने चाहिए, जैसे:SSLEngine on SSLCertificateFile /etc/apache2/ssl/mysite.crt SSLCertificateKeyFile /etc/apache2/ssl/private/mysite.key

— जॉर्ज दिमित्रियादिस

BTW - यह सिर्फ आपके: 80 और: 443 को एक अपाचे ".conf" फ़ाइल में संयोजित करने के लिए संभव है। मैं कुछ भी मार बंदरगाह को पुनर्निर्देशित करता हूँ: 80 पर: 443 / SSL वैसे भी। यह भी .conf फ़ाइल में बुनियादी SSL सेटिंग्स रख दिया और एक अतिरिक्त 'विस्तृत' SSL सेटिंग्स फ़ाइल बनाने (प्रयुक्त सिफर / आदि उदाहरण के लिए सेट करने के लिए) और सिर्फ संभव है शामिल आभासी क्षेत्रों के बाहर अपने सभी .conf फाइलों में यह। मैं इन सेटिंग्स का उपयोग एसएसएल को थोड़ा 'कठोर' करने के लिए करता हूं और प्रत्येक वर्चुअल साइट में इसे शामिल करता हूं। मैं इस तरीके से SSL लैब्स में A + प्राप्त कर सकता हूं ।

— 17

Answer 3

यहाँ सभी उत्तर ठीक प्रतीत होते हैं, लेकिन मैं एक बात का उल्लेख करना चाहता हूँ जो मुझे मिली है वह एक समस्या है ... यदि आपको अपने प्रमाण पत्र को इंटरमीडिएट या रूट के साथ एक चैन फाइल के साथ लाना है, तो उसे मत डालें /etc/ssl/certs, क्योंकि जब c_rehashचलाया जाता है, यह आपके सीरियलों में जड़ या मध्यवर्ती होने के कारण हैश सीमलिंक बना सकता है।

फिर बाद में सड़क के नीचे अगर आपके सीरेट्स की समय सीमा समाप्त हो गई है और आप उन्हें हटा देते हैं, और फिर से चलाने के लिए नहीं जानते हैं c_rehash, तो हो सकता है कि आप अपनी /etc/ssl/certsनिर्देशिका में हैश सीमलिंक तोड़ चुके हों , और अजीब चीजें तब होने लगती हैं जब आपकी स्थानीय मशीन खुद से कनेक्ट होने की कोशिश करती है एसएसएल, और यह जड़ों के खिलाफ मान्य करने के लिए नहीं मिल सकता है। उदाहरण के लिए, कर्ल के साथ मुझे अचानक मिलना शुरू हुआ:

curl: (60) SSL certificate problem: unable to get issuer certificate

कुछ पुरानी .crt और concatenated .pem फ़ाइलों की सफाई करने के कुछ समय बाद ही मेरे पास थी /etc/ssl/certs।

कम से कम अपनी जंजीरों को कहीं और जमा करना इस समस्या से बचा जाता है। मैंने /etc/ssl/local_certsअपने अनाज और जंजीरों को धारण करने के लिए समाप्त कर दिया है , इसलिए वे उन सीए समारोहों की गड़बड़ी में नहीं खोए हैं जिन्हें आप खोज लेंगे/etc/ssl/certs

Answer 4

वास्तव में एक असुरक्षित जगह नहीं है यदि व्यक्तिगत फ़ाइलों / निर्देशिका के लिए अनुमति कुछ इस तरह सेट की जाती है chown root :0 private.keyऔर chmod 600 private.keyताकि केवल रूट इसे पढ़ सकें। सीएसआर और सर्टिफिकेट फाइल आपके कहे अनुसार कम संवेदनशील हैं।

उन अनुमतियों के साथ आपके द्वारा उल्लिखित पथ और usr / स्थानीय / ssl ठीक होना चाहिए।

Comments

अक्सर, निजी कुंजी तक पहुंचने वाले एप्लिकेशन गैर-रूट उपयोगकर्ताओं के रूप में चल रहे हैं। मैं ssl- प्रमाणित समूह के लिए पहुँच बनाए रखने का सुझाव देता हूँ।

— शेन झुंझलाना

समझ में आया लेकिन अपाचे जैसे वेब सर्वर एक मूल 'माता-पिता' प्रक्रिया को जन्म देते हैं और यह मानते हुए कि यह भी उचित है।

— जोनाथन रॉस

Answer 5

स्थान सही हैं:

• /etc/ssl/certs/के लिए .crtफ़ाइल
• /etc/ssl/privateके लिए .keyफ़ाइल

मालिकroot:root दोनों के लिए होना चाहिए ( sudo chmod root:root <file>यदि आवश्यक हो तो बदलने के लिए उपयोग करें)।

अनुमतियाँ :

• 644के लिए .crtफ़ाइल
• 600के लिए .keyफ़ाइल

इसके लिए काम करेंगे nginx।