🌍 🕞 👊🏼 एसएसएल प्रमाणपत्र प्रबंधन: एक केंद्रीकृत समाधान के लिए सैकड़ों सर्वरों पर अराजकता से 🔸 🕺🏾 👊🏽

"यूरोप का सबसे बड़ा ऑनलाइन स्कूल" शब्दों के पीछे क्या हो सकता है? एक ओर, यह प्रति घंटे 1 हजार पाठ, 10 हजार शिक्षक, 100 हजार छात्र हैं। और मेरे लिए, एक इंफ्रास्ट्रक्चर इंजीनियर, इसमें 200+ सर्वर, सैकड़ों सेवाएं (माइक्रो और बहुत नहीं), 2 से 6 वें स्तर तक डोमेन नाम शामिल हैं। हर जगह आपको एसएसएल की आवश्यकता होती है और, तदनुसार, इसके लिए एक प्रमाण पत्र।

अधिकांश भाग के लिए, हम Let’s Encrypt प्रमाणपत्र का उपयोग करते हैं। उनके फायदे हैं कि वे स्वतंत्र हैं, और रसीद पूरी तरह से स्वचालित है। दूसरी ओर, उनके पास एक विशेषता है: लघु - केवल तीन महीने - वैधता। तदनुसार, उन्हें अक्सर अपडेट किया जाना चाहिए। हमने इसे किसी तरह से स्वचालित करने की कोशिश की, लेकिन फिर भी बहुत सारे मैनुअल काम थे, और कुछ लगातार टूट रहा था। एक साल पहले, हम प्रमाण पत्र के इस ढेर को अद्यतन करने के लिए एक सरल और विश्वसनीय विधि के साथ आए और तब से हम इस समस्या के बारे में भूल गए।

एक सर्टिफिकेट पर एक सर्वर से लेकर कई डेटा सेंटरों में सैकड़ों

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

लेट्स एनक्रिप्ट प्रमाण पत्र प्राप्त करने के लिए, आपको प्रमाणपत्र में निर्दिष्ट डोमेन नाम के स्वामित्व की पुष्टि करनी होगी। यह आमतौर पर एक रिवर्स HTTP अनुरोध के साथ किया जाता है।

यहाँ कुछ मानक कठिनाइयाँ आईं जिनका हमने सामना किया:

: . .
HTTP. , . . - LDAP. - . .

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

परेशानी यह है कि BrowserStack में, जो परीक्षक उपयोग करते हैं, कम से कम iPad, Mac, iPhone के लिए विश्वसनीय सूची में प्रमाणपत्र जोड़ना असंभव है। इसलिए परीक्षकों को खतरनाक साइटों के बारे में लगातार पॉप-अप चेतावनियों के साथ रखना पड़ा।

समाधान के लिए खोजें

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

बिग ईयर एक पुराना बॉट है जो एक प्रमाण पत्र को बर्बाद नहीं करेगा।

और वाइल्डकार्ड प्रमाणपत्र का उपयोग करते हैं? चलो! चलिए पहले से ही उन्हें एन्क्रिप्ट करते हैं। सही है, आपको DNS के माध्यम से डोमेन स्वामित्व की पुष्टि को कॉन्फ़िगर करना होगा। और हमारा DNS AWS Route53 में रहता है। और आपको सभी सर्वरों में AWS में पहुंच विवरण को विघटित करना होगा। और नए सर्वरों के आगमन के साथ, इस सभी अर्थव्यवस्था को भी कॉपी करें।

खैर, 3 स्तर के नाम वाइल्डकार्ड द्वारा कवर किए गए हैं। और 4 के स्तर और उच्चतर के नामों के साथ क्या करना है? हमारे पास कई टीमें हैं जो विभिन्न सेवाओं के विकास में लगी हुई हैं। अब यह सीमा और बैकएंड को विभाजित करने के लिए प्रथागत है। और यदि फ्रंटएंड को service.skyeng.ru जैसा 3-स्तरीय नाम मिलता है , तो बैकएंड api.service.skyeng.ru नाम देने की कोशिश करता है । हम्म, शायद उन्होंने उन्हें ऐसा करने से मना किया? महान विचार! और दर्जनों मौजूदा लोगों के साथ क्या करना है? यह उन सभी को एक डोमेन नाम में चलाने के लिए लोहे के हाथ के साथ हो सकता है? अलग-अलग स्तरों के इन सभी नामों को URLs जैसे skyeng.ru/service से बदलें। तकनीकी रूप से, यह एक विकल्प है, लेकिन इसमें कितना समय लगता है? और व्यवसाय ऐसे कार्यों की आवश्यकता को कैसे उचित ठहरा सकता है? हमारे पास 30+ विकास दल हैं, सभी को मनाते हैं - इसमें कम से कम छह महीने लगेंगे। और हम विफलता का एक बिंदु बना रहे हैं। यह पसंद है या नहीं, यह एक विवादास्पद निर्णय है।

अन्य विचार क्या हैं? .. हो सकता है कि एक प्रमाण पत्र बनाया जाए जहाँ हम सभी को शामिल करें। और हम इसे सभी सर्वरों पर स्थापित करेंगे। यह हमारी समस्याओं का समाधान हो सकता है, लेकिन लेट्स एनक्रिप्ट आपको प्रमाण पत्र में केवल 100 नाम रखने की अनुमति देता है, और हमारे पास पहले से ही एक से अधिक माइक्रोसेवा हैं।

परीक्षकों के साथ क्या करना है? वे कुछ भी लेकर नहीं आए, लेकिन वे लगातार शिकायत करते हैं। मधुमक्खियों को छोड़कर सभी बकवास। मधुमक्खियां भी कचरा हैं, लेकिन उनमें से बहुत सारे हैं। प्रत्येक डेवलपर या परीक्षक को एक परीक्षण सर्वर दिया जाता है - हम उन्हें परीक्षण कहते हैं। परीक्षण मधुमक्खियों नहीं हैं, लेकिन उनमें से पहले से ही सौ से अधिक हैं। और प्रत्येक के लिए सभी परियोजनाओं को तैनात किया जाता है। बस इतना ही। और अगर बिक्री के लिए आपको एन प्रमाण पत्र की आवश्यकता है, तो प्रत्येक परीक्षण के लिए समान राशि है। अब तक, वे स्वयं हस्ताक्षरित हैं। उन्हें असली के साथ बदलना बहुत अच्छा होगा ...

दो प्लेबुक और एक सत्य का स्रोत

हंस, कैंसर और पाइक कहीं भी गाड़ी नहीं लाएगा। हमें एक एकल सर्वर नियंत्रण ~~केंद्र की आवश्यकता है~~ । हमारे मामले में, यह Ansible है। हर सर्वर पर प्रमाण पत्र बुराई है। सभी प्रमाणपत्रों को एक स्थान पर संग्रहीत किया जाए। अगर कहीं किसी को प्रमाणपत्र की आवश्यकता है, तो इस जगह पर आएं और शेल्फ से नवीनतम संस्करण लें। और हम यह सुनिश्चित करेंगे कि इस स्टोर में प्रमाणपत्र हमेशा अद्यतित हों।

AWS पहुंच विवरण केवल एक ही स्थान पर मौजूद हैं। तदनुसार, प्रश्न गायब हो जाते हैं, जैसे कि एक नए सर्वर पर AWS CLI की स्थापना, जिसके पास रूट 53 और इस तरह की पहुंच है।

सभी आवश्यक प्रमाण-पत्र एक फ़ाइल में एक प्रकार से YAML प्रारूप में वर्णित हैं:

    certificates:
      - common_name: skyeng.ru
        alt_names:
          - *.skyeng.ru
      - common_name: olympiad.skyeng.ru
        alt_names:
          - *.olympiad.skyeng.ru
          - api.content.olympiad.skyeng.ru
          - games.skyeng.ru
      - common_name: skyeng.tech
        alt_names:
          - *.skyeng.tech

      .  .  .

एक प्लेबुक को समय-समय पर लॉन्च किया जाता है , जो इस सूची के माध्यम से जाता है और अपनी कड़ी मेहनत करता है - अनिवार्य रूप से वही चीज़ जो सर्बोट करता है:

लेट्स एनक्रिप्ट क्रिएट अथॉरिटी के साथ एक खाता बनाता है
एक निजी कुंजी उत्पन्न करता है
एक (अभी तक हस्ताक्षरित नहीं) प्रमाण पत्र उत्पन्न करता है - तथाकथित प्रमाणपत्र हस्ताक्षर अनुरोध
एक हस्ताक्षर अनुरोध भेजता है
एक DNS चुनौती प्राप्त करता है
DNS में प्राप्त रिकॉर्ड रखता है
दोबारा हस्ताक्षर करने का अनुरोध भेजता है
और, अंत में हस्ताक्षरित प्रमाण पत्र प्राप्त करने के बाद, इसे स्टोर में रखता है।

प्लेबुक दिन में एक बार किया जाता है। यदि वह किसी भी कारण से किसी भी प्रमाण पत्र को नवीनीकृत नहीं कर सका - यह नेटवर्क समस्याएं या लेट्स एनक्रिप्ट की ओर से कुछ त्रुटियां हैं - यह कोई समस्या नहीं है। अगली बार अपडेट किया जाएगा।

अब, जब SSL कुछ सर्विस होस्ट पर आवश्यक होता है, तो आप इस रिपॉजिटरी में जा सकते हैं और वहां से कुछ फाइलें प्राप्त कर सकते हैं - सबसे सरल ऑपरेशन जो कि दूसरी प्लेबुक करता है ... इस होस्ट के लिए कौन से प्रमाणपत्र आवश्यक हैं, इस होस्ट के पैरामीटर में इन्वेंट्री / host_vars / सर्वर में वर्णित हैं। .yml :

    certificates:
      - common_name: skyeng.ru
        handler: reload nginx
      - common_name: crm.skyeng.ru

      .  .  .

यदि फाइलें बदल गई हैं, तो Ansible एक हुक खींचता है - यह Nginx को फिर से शुरू करने के लिए विशिष्ट है (हमारे मामले में, यह डिफ़ॉल्ट है)। और उसी तरह, आप एसीएमई प्रोटोकॉल का उपयोग करने वाले अन्य सीए से प्रमाण पत्र प्राप्त कर सकते हैं।

संपूर्ण

हमारे पास कई अलग-अलग कॉन्फ़िगरेशन थे। लगातार कुछ टूट गया। अक्सर मुझे सर्वर पर चढ़ना पड़ता था और पता चलता था कि क्या फिर से गिर गया है।
अब हमारे पास दो प्लेबुक हैं और सब कुछ एक ही स्थान पर दर्ज है। सब कुछ घड़ी की तरह काम करता है। जीवन और अधिक उबाऊ हो गया है।

परिक्षण

हां, उनके परीक्षण के साथ परीक्षकों के बारे में क्या? प्रत्येक डेवलपर या परीक्षक को एक व्यक्तिगत परीक्षण सर्वर - परीक्षण दिया जाता है। वर्तमान में उनमें से लगभग 200 हैं। उनके पास फॉर्म टेस्ट-y123.skyeng.link के नाम हैं , जहां 123 परीक्षण संख्या है। परीक्षण बनाना और निकालना स्वचालित है। कार्रवाई के घटकों में से एक उस पर एक एसएसएल प्रमाणपत्र की स्थापना है। एक एसएसएल प्रमाणपत्र अग्रिम में उत्पन्न होता है, टेम्पलेट द्वारा नामों के साथ:

    ssl_cert_pattern:
      - *
      - *.auth
      - *.bill

      .  .  .

केवल 30 नामों के बारे में। इसलिए प्रमाणपत्र नामों के साथ आता है

    test-y123.skyeng.link
    *.test-y123.skyeng.link
    *.auth.test-y123.skyeng.link
    *.bill.test-y123.skyeng.link

आदि।

डेवलपर या परीक्षक की बर्खास्तगी के बाद, उसका परीक्षण हटा दिया जाता है। प्रमाणपत्र उपयोग के लिए तैयार है। यह सब संग्रहीत है। आप स्वयं जानते हैं कि यह कहाँ मेजबान में विघटित है, आप जानते हैं कि कैसे।

पुनश्च

कोड के साथ भंडार ।

यह भी इस विषय पर पढ़ना दिलचस्प हो सकता है कि कैसे स्टैक ओवरफ्लो HTTPS में बदल गया :

विभिन्न स्तरों के सैकड़ों डोमेन
WebSockets
HTTP APIs (प्रॉक्सी समस्याएँ)
सब कुछ करें और प्रदर्शन को न छोड़ें

यदि आपके कोई प्रश्न हैं, तो टिप्पणियों में लिखें, मुझे उत्तर देने में खुशी होगी।