نحو أتمتة SSL

في كثير من الأحيان علينا أن نعمل مع شهادات SSL. دعنا نتذكر عملية إنشاء وتثبيت شهادة (في الحالة العامة لمعظم).


  • ابحث عن مزود (موقع يمكننا شراء طبقة المقابس الآمنة).
  • توليد المسؤولية الاجتماعية للشركات.
  • إرسالها إلى مزود الخاص بك.
  • تحقق من ملكية المجال.
  • الحصول على شهادة.
  • تحويل الشهادة إلى النموذج المطلوب (اختياري). على سبيل المثال ، من pem إلى PKCS # 12.
  • تثبيت الشهادة على خادم الويب.

سريع نسبيا ، ليست معقدة ومفهومة. هذا الخيار مناسب تمامًا إذا كان لدينا أكثر من عشرة مشاريع. وإذا كان هناك أكثر من ذلك ، ولديهم ثلاث بيئات على الأقل؟ كلاسيك - التدريج - الإنتاج. في هذه الحالة ، يجب أن تفكر في أتمتة هذه العملية. أقترح أن تستكشف المشكلة بشكل أعمق وأن تجد حلاً يقلل من الوقت اللازم لإنشاء الشهادات والحفاظ عليها في المستقبل. سوف يقدم المقال تحليلًا للمشكلة ودليلًا صغيرًا للتكرار.


سوف أبدي تحفظًا مقدمًا: التخصص الرئيسي لشركتنا هو .net ، وبناءً على ذلك ، ينشأ IIS و Windows الآخر. لذلك ، سيتم وصف عميل ACME وكافة الإجراءات الخاصة به من حيث استخدام windows.


لمن هذه البيانات ذات الصلة وبعض المصدر


شركة K يمثلها المؤلف. عنوان URL (على سبيل المثال): company.tld


المشروع X هو أحد مشاريعنا ، التي توصلت إلى استنتاج مفاده أنه على الرغم من ذلك ، نحتاج إلى المضي قدمًا نحو توفير الحد الأقصى من الوقت عند العمل مع الشهادات. يحتوي هذا المشروع على أربع بيئات هي: dev ، والاختبار ، والتدريج ، والإنتاج. ديف واختبار على جانبنا ، التدريج والإنتاج على جانب العميل.


تتمثل ميزة المشروع في أنه يحتوي على عدد كبير من الوحدات النمطية المتاحة كنطاقات فرعية.


وهذا هو ، لدينا الصورة التالية:


ديفاختبارانطلاقإنتاج
projectX.dev.company.tldprojectX.test.company.tldstaging.projectX.tldprojectX.tld
module1.projectX.dev.company.tldmodule1.projectX.test.company.tldmodule1.staging.projectX.tldmodule1.projectX.tld
module2.projectX.dev.company.tldmodule2.projectX.test.company.tldmodule2.staging.projectX.tldmodule2.projectX.tld
............
moduleN.projectX.dev.company.tldmoduleN.projectX.test.company.tldmoduleN.staging.projectX.tldmoduleN.projectX.tld

للإنتاج ، يتم استخدام شهادة البدل المشتراة ، لا توجد أسئلة. لكنه لا يغطي سوى المستوى الأول من النطاق الفرعي. وفقًا لذلك ، إذا كانت هناك شهادة لـ * .projectX.tld - فسوف تعمل من أجل staging.projectX.tld ، لكن بالنسبة module1.staging.projectX.tld ، فإنها لا تعمل بالفعل. لكنني لا أشعر بشراء واحدة منفصلة.


وهذا ليس سوى مثال على مشروع واحد لشركة واحدة. والمشروع ، بالطبع ، ليس واحداً.


تبدو الأسباب الشائعة لكل شخص لمعالجة هذه المشكلة مثل هذا:


  • في الآونة الأخيرة ، اقترحت Google تخفيض فترة الصلاحية القصوى لشهادات SSL . مع كل العواقب.
  • تسهيل عملية إصدار وصيانة طبقة المقابس الآمنة لتلبية الاحتياجات الداخلية للمشاريع والشركة ككل.
  • التخزين المركزي لسجلات الشهادات ، والذي يحل جزئيًا مشكلة التحقق من النطاق باستخدام DNS والتحديثات التلقائية اللاحقة ، وكذلك يحل مشكلة ثقة العميل. ومع ذلك ، تسبب CNAME المزيد من الثقة على خادم الشركة الشريكة / المقاول أكثر من مورد جهة خارجية.
  • حسنًا ، أخيرًا ، في هذه الحالة ، عبارة "من الأفضل أن يكون لديك أكثر من عدم" مناسبة تمامًا.

اختيار موفر SSL والخطوات التحضيرية


من بين الخيارات المتاحة لشهادات SSL المجانية ، تم النظر في cloudflare و allowencrypt. تتم استضافة DNS لهذا (وبعض المشاريع الأخرى) على cloudflare ، لكنني لست معجبًا باستخدام شهاداتهم. لذلك ، تقرر استخدام letsencrypt.
لإنشاء شهادة SSL بدل ، يجب تأكيد ملكية المجال. يتضمن هذا الإجراء إنشاء سجل DNS (TXT أو CNAME) ، مع التحقق لاحقًا عند إصدار شهادة. يحتوي Linux على أداة مساعدة تسمى certbot ، والتي تتيح لك أتمتة هذه العملية جزئيًا (أو كليًا لبعض موفري DNS). بالنسبة لنظام Windows ، من بين خيارات عميل ACME التي تم العثور عليها واختبارها ، استقرت على WinACME .


ويتم إنشاء سجل المجال ، ننتقل إلى إنشاء الشهادة:


صورة


نحن مهتمون بالنتيجة الأخيرة ، وهي الخيارات المتاحة للتحقق من ملكية المجال لإصدار شهادة البدل:


  1. إنشاء سجلات DNS يدويًا (التحديث التلقائي غير معتمد)
  2. إنشاء سجلات DNS باستخدام خادم acme-dns (يمكن العثور على مزيد من التفاصيل هنا .
  3. إنشاء سجلات DNS باستخدام البرنامج النصي الخاص بك (التناظرية من البرنامج المساعد cloudflare ل certbot).

للوهلة الأولى ، النقطة الثالثة مناسبة تمامًا ، ولكن إذا كان موفر DNS لا يدعم هذه الوظيفة؟ ونحن بحاجة إلى حالة عامة. والحالة العامة هي سجلات CNAME ، كلها تدعمها. لذلك ، نتوقف عند النقطة 2 ، وننتقل إلى تهيئة خادم ACME-DNS الخاص بنا.


تكوين خادم ACME-DNS وعملية إصدار الشهادات


على سبيل المثال ، قمت بإنشاء المجال 2nd.pp.ua ، وفي المستقبل سوف أستخدمه.


من المتطلبات الأساسية للتشغيل الصحيح للخادم إنشاء سجلات NS و A لمجالها. وأول لحظة غير سارة صادفتُها - لا تسمح لك cloudflare (على الأقل في وضع الاستخدام المجاني) بإنشاء سجل NS و A للمضيف نفسه في نفس الوقت. ليس ذلك كان مشكلة ، ولكن في الربط كان ذلك ممكنا. أجاب الدعم أن لوحاتهم لا تسمح بذلك. لا يهم ، قم بإنشاء إدخالين:


acmens.2nd.pp.ua. IN A 35.237.128.147 acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua. 

في هذه المرحلة ، يجب حل مضيف acmens.2nd.pp.ua .


 $ ping acmens.2nd.pp.ua PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data 

لكن acme.2nd.pp.ua لن يتم حلها ، لأن خادم DNS الذي يخدمها لا يعمل بعد.


يتم إنشاء السجلات ، انتقل إلى تكوين وتشغيل خادم ACME-DNS. سأحصل عليه مباشرة على خادم أوبونتو في حاوية عامل الميناء ، ولكن يمكنك تشغيله أينما كان هناك golang. نظام التشغيل Windows جيد للغاية ، لكن ما زلت أفضل خادم Linux.


إنشاء الدلائل والملفات اللازمة:


 $ mkdir config $ mkdir data $ touch config/config.cfg 

استفد همة محرر النصوص المفضل لديك وإدراج تكوين عينة في config.cfg.


لتحقيق النجاح ، قم فقط بتعديل الأقسام العامة وقسم واجهة برمجة التطبيقات:


 [general] listen = "0.0.0.0:53" protocol = "both" domain = "acme.2nd.pp.ua" nsname = "acmens.2nd.pp.ua" nsadmin = "admin.2nd.pp.ua" records = "acme.2nd.pp.ua. A 35.237.128.147", "acme.2nd.pp.ua. NS acmens.2nd.pp.ua.", ] ... [api] ... tls = "letsencrypt" … 

أيضًا ، إذا رغبت في ذلك ، قم بإنشاء ملف إنشاء عامل ميناء في الدليل الرئيسي للخدمة:


 version: '3.7' services: acmedns: image: joohoi/acme-dns:latest ports: - "443:443" - "53:53" - "53:53/udp" - "80:80" volumes: - ./config:/etc/acme-dns:ro - ./data:/var/lib/acme-dns 

القيام به. يمكنك الجري.


 $ docker-compose up -d 

في هذه المرحلة ، يجب أن يبدأ مضيف acme.2nd.pp.ua ، ويجب أن يظهر 404 على https://acme.2nd.pp.ua


 $ ping acme.2nd.pp.ua PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes of data. $ curl https://acme.2nd.pp.ua 404 page not found 

إذا لم يظهر هذا - docker logs -f <container_name> للمساعدة ، لحسن الحظ ، فإن السجلات قابلة للقراءة تمامًا.


يمكننا البدء في إنشاء شهادة. فتح بوويرشيل كمسؤول وتشغيل winacme. نحن مهتمون بالانتخابات:


  • M: إنشاء شهادة جديدة (خيارات كاملة)
  • 2: الإدخال اليدوي
  • 2: [dns-01] إنشاء سجلات تحقق باستخدام acme-dns ( https://github.com/joohoi/acme-dns )
  • عندما يُسأل عن الرابط إلى خادم ACME-DNS ، نقوم بإدخال عنوان URL الخاص بالخادم الذي تم إنشاؤه (https) استجابة لذلك. عنوان URL لخادم acme-dns: https://acme.2nd.pp.ua

في الخادم ، يصدر العميل إدخالًا يجب إضافته إلى خادم DNS الموجود (إجراء لمرة واحدة):


 [INFO] Creating new acme-dns registration for domain 1nd.pp.ua Domain: 1nd.pp.ua Record: _acme-challenge.1nd.pp.ua Type: CNAME Content: c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua. Note: Some DNS control panels add the final dot automatically. Only one is required. 

صورة


نقوم بإنشاء السجل اللازم ، وتأكد من إنشاؤه بشكل صحيح:


صورة


 $ dig CNAME _acme-challenge.1nd.pp.ua +short c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua. 

نؤكد أننا أنشأنا الإدخال الضروري في winacme ، ونواصل عملية إنشاء الشهادة:


صورة


كيفية استخدام certbot كعميل موصوفة هنا .


هذا يكمل عملية إنشاء شهادة ، يمكنك تثبيتها على خادم ويب واستخدامها. إذا ، عند إنشاء شهادة ، يتم إنشاء مهمة في المجدول أيضًا ، فستحدث عملية تجديد الشهادة تلقائيًا في المستقبل.

Source: https://habr.com/ru/post/ar483770/


All Articles