2011-10-25 18 views
5

का उपयोग करने का एक बुरा अभ्यास है हम जावा मानक कीस्टोर ($JAVA_HOME/jre/lib/security/cacerts) का उपयोग टोमकैट के लिए विश्वसनीय स्टोर के रूप में कर रहे थे। और वह tomcat सर्वर किसी अन्य सर्वर के साथ संवाद करेगा। एक हालिया ओएस (एईक्स) अपग्रेड ने फ़ाइल को $JAVA_HOME/jre/lib/security/cacerts पर स्पष्ट रूप से लिखा है और इसके परिणामस्वरूप खोए गए प्रमाण पत्र और टोमकैट में होस्ट किए गए एप्लिकेशन के साथ कई समस्याएं हुईं।क्या यह जावा मानक कीस्टोर

यह देखकर यह $ JAVA_HOME/jre/lib/security/cacerts पर रिले करने का एक बुरा अभ्यास है? इस परिदृश्य से निपटने के लिए वैकल्पिक (बेहतर | मानक) तरीके क्या हैं?

+0

java_home मंच के आधार पर भिन्न हो सकता है, आप इसके लिए देखना चाहेंगे। मैं व्यक्तिगत रूप से एक अलग हाइव फ़ोल्डर की खोज करता हूं। – Tim

उत्तर

1

cacerts फ़ाइल में जो कुछ भी है, उसके संदर्भ में, यह आपके ओएस या आपके ब्राउज़र में स्थापित डिफ़ॉल्ट सीए प्रमाणपत्रों पर निर्भर होने की तुलना में आवश्यक रूप से खराब अभ्यास नहीं है, लेकिन इसका मतलब यह नहीं है कि यह बहुत अच्छा है।

सूर्य/Oracle JSSE Reference Guide about this के बीच में कहीं एक छोटे से "महत्वपूर्ण नोट" है:

महत्वपूर्ण नोट:/lib/सुरक्षा में विश्वसनीय रूट प्रमाण पत्र की एक सीमित संख्या के साथ JDK जहाजों/cacerts फ़ाइल। कीटोल में प्रलेखित के रूप में, यदि आप इस फ़ाइल को ट्रस्टस्टोर के रूप में उपयोग करते हैं, तो इस फ़ाइल में निहित प्रमाणपत्रों को बनाए रखने की आपकी ज़िम्मेदारी है (यानी जोड़ें/हटाएं)।

आपके द्वारा संपर्क किए जाने वाले सर्वर की प्रमाणपत्र कॉन्फ़िगरेशन के आधार पर, आपको अतिरिक्त रूट प्रमाणपत्र जोड़ने की आवश्यकता हो सकती है। उचित विक्रेता से आवश्यक विशिष्ट रूट प्रमाण पत्र प्राप्त करें।

विन्यास के संदर्भ में, विशिष्ट अनुप्रयोगों जहाँ मैं "स्थानीय" CA प्रमाणपत्र स्थापित करने के लिए किया है के लिए, मैं इसे और अधिक स्थिर एक स्थानीय विश्वास की दुकान का उपयोग करने (उदाहरण के लिए, javax.net.ssl.trustStore के साथ निर्दिष्ट) पाते हैं।

2

सुनिश्चित नहीं है, लेकिन आपकी धारणाएं सही हैं, सावधानी बरतें जहां आपने अपना कीस्टोर रखा है। मैं दृढ़ता से सुझाव दूंगा कि यह अपाचे फ़ोल्डर के अंदर रखा गया है।

Websphere में डिफ़ॉल्ट रूप से कुंजीस्टोर इस तरह से काम करता है, के बाद से यह अपने आप JVM :)

+2

ग्लासफ़िश के पास इसके स्वयं के कीस्टोर और कैकर्ट भी हैं। – Hiro2k

5

यह एक बुरा व्यवहार आप एक निर्माण प्रक्रिया है कि आयात दोहराया जाएगा अगर नहीं है लाता है।

0

हां यह करने के लिए यह एक बुरा अभ्यास है।

सबसे अच्छा अभ्यास अपने विश्वसनीय प्रमाणपत्रों को जितना आवश्यक हो उतना सीमित करना है।
तो आपको अपने कुंजीपटल का उपयोग केवल अपने आवेदन द्वारा विश्वसनीय प्रमाणपत्रों के साथ करना चाहिए था।

+0

जो पीकेआई के पूरे उद्देश्य का उल्लंघन करता है। विचार यह है कि भरोसेमंद जड़ों की उपस्थिति ट्रस्ट की एक श्रृंखला बनने की अनुमति देती है ताकि आप किसी विश्वसनीय सीए द्वारा हस्ताक्षरित किसी भी प्रमाण पत्र पर भरोसा कर सकें। आप प्रमाणीकरण को भंग कर रहे हैं, जो पीकेआई और प्रमाणपत्र हैं, प्राधिकरण के साथ, जो एक अनुप्रयोग-डोमेन समस्या है।इन दो अलग-अलग कार्यों को गठबंधन करने के लिए मूल रूप से टूटा हुआ है। – EJP

+0

@EJP: जब आपके पास एक एंडपॉइंट होता है जो केवल नेटवर्क में विशिष्ट इकाइयों के साथ संचार करता है, तो मैं अपने सिस्टम में कॉन्फ़िगर किए गए * किसी * सीए द्वारा भरोसा क्यों करता हूं (चाहे वह लिनक्स, जावा का सीएर्ट, विंडोज प्रमाणपत्र है आदि)? – Cratylus

0

एईक्स अपग्रेड एक पैच है। किसी भी पैच को उपयोगकर्ता डेटा को हटा/ओवरराइट नहीं करना चाहिए। मैं सुझाव दूंगा कि इस प्रकार के डेटा हानि से प्रभावित उपयोगकर्ता आईबीएम को पैच प्रक्रिया को ठीक करने के लिए कहते हैं। इसकी तुलना में, httpd सर्वर का एक पैच कॉन्फ़िगरेशन को ओवरराइट/हटा नहीं देता है, भले ही यह प्रोग्राम निर्देशिका में है।