सवाल उबंटू पर एसएसएल प्रमाणपत्र और निजी कुंजी के लिए सबसे अच्छा स्थान


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

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


53
2018-04-13 15:56


मूल


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


जवाब:


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

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


44
2018-04-13 16:06



मुझे आश्चर्य है कि क्यों निर्देशिका डिफ़ॉल्ट रूप से g + s नहीं है। - Collin Anderson
यह होने की जरूरत नहीं है; निर्देशिका 0750 है, इसलिए फ़ाइलों को पढ़ने के लिए निर्देशिका में किसी भी उपयोगकर्ता के लिए निर्देशिका में जाने के लिए कोई रास्ता नहीं है। - womble♦
मेरे द्वारा उपयोग किए जाने वाले अधिकांश अनुप्रयोगों के लिए, मैं लिंक किए गए उत्तर में वर्णित व्यवहार को देखता हूं: वे उपयोगकर्ता का उपयोग करते हैं root प्रमाण पत्र लोड करने के लिए। लेकिन यहां अनुमतियां अच्छी तरह से समझाई गई हैं। - SimonSimCity
ऐसा लगता है कि एसएसएल-प्रमाणपत्र उबंटू पर एक अवैध समूह का नाम है। शायद यह जड़ रूट होना चाहिए: इसके बजाय रूट - Atifm


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

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

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

उदाहरण सेटअप

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

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

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 ठीक काम करेगा। 

मालिक सेट करें:

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

ध्यान दें:
अगर आपके पास नहीं है एसएसएल-प्रमाणपत्र समूह, ऊपर पंक्ति पर 'root: root' का उपयोग करें या दूसरी पंक्ति छोड़ें।

एसएसएल फाइलें रखें:

डाल जनता इंटरमीडिएट सर्टिफिकेट के साथ www एसएसएल प्रमाणपत्र (एस)     /etc/apache2/ssl
  डाल निजी एसएसएल कुंजी (ओं) में /etc/apache2/ssl/private

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

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

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

निजी कुंजी

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

ध्यान दें:
उबंटू एसएसएल-प्रमाण समूह के कारण समूह अनुमति को पढ़ने के लिए सेट किया गया है (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

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

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

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


32
2017-10-21 17:17



सुनिश्चित नहीं है कि आप / etc / apache2 / ssl / priv के लिए अनुमतियों के लिए सेटिंग 710 क्यों सुझाएंगे। निर्देशिका (समूह के लिए) के लिए पाठ बिट को सेट किए बिना निर्देशिका (समूह के लिए) निष्पादित बिट सेट करना मुझे बहुत समझ में नहीं आता है। क्या आप इसे 750 के रूप में सेट करना चाहते थे? - chriv
@chriv मैं केवल उबंटू डिफ़ॉल्ट SSL क्षेत्र के तहत इसे सेटअप करने के तरीके के आधार पर अनुमतियां सेट करता हूं। / Etc / ssl / certs और / etc / ssl / private & 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 - George Dimitriadis
बीटीडब्ल्यू - एक अपाचे ".conf" फ़ाइल में केवल 80: और 443 कॉन्फ़िगरेशन को गठबंधन करना भी संभव है। मैं किसी भी पोर्ट को मारने पर रीडायरेक्ट करता हूं: 80: 443 / एसएसएल वैसे भी। मूलभूत SSL सेटिंग्स को .conf फ़ाइल में रखना और अतिरिक्त 'विस्तृत' SSL सेटिंग्स फ़ाइल बनाना (उदाहरण के लिए इस्तेमाल किए गए सिफर सेट करने के लिए) और बस शामिल यह वर्चुअल क्षेत्रों के बाहर आपकी सभी .conf फ़ाइलों में। मैं इन सेटिंग्स का उपयोग एसएसएल को 'कठोर' करने के लिए करता हूं और मैं इसे प्रत्येक आभासी साइट .conf में शामिल करता हूं। मैं ए + पर प्राप्त कर सकते हैं एसएसएल लैब्स इस तरह से । - bshea


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

फिर बाद में सड़क के नीचे यदि आपके certs की समय सीमा समाप्त हो गई है और आप उन्हें हटा दें, और फिर से चलाने के लिए नहीं जानते हैं 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 मेरे certs और चेन पकड़ने के लिए, तो वे सीए certs की गड़बड़ी में खो नहीं गए थे जो आप पाएंगे /etc/ssl/certs


8
2018-03-23 14:58





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

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


2
2018-04-13 16:08



अक्सर, निजी कुंजी तक पहुंचने वाले एप्लिकेशन गैर रूट उपयोगकर्ताओं के रूप में चल रहे हैं। मैं एसएसएल-प्रमाण समूह के लिए पहुंच बनाए रखने का सुझाव देना चाहता हूं। - Shane Madden♦
समझा लेकिन अपाचे जैसे वेब सर्वर एक रूट 'पैरेंट' प्रक्रिया को स्पॉन करते हैं और nginx भी मानते हैं यह भी प्रासंगिक है। - Jonathan Ross