ProHoster > بلوق > إدارة > نحو أتمتة إصدار SSL

نحو أتمتة إصدار SSL

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

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

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

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

لمن تكون ذات صلة وبعض بيانات الخلفية

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

يعد المشروع X أحد مشاريعنا ، حيث توصلت إلى استنتاج مفاده أننا ما زلنا بحاجة إلى التحرك نحو توفير أقصى قدر من الوقت عند العمل باستخدام الشهادات. يحتوي هذا المشروع على أربع بيئات: التطوير والاختبار والتدريج والإنتاج. إن التطوير والاختبار من جانبنا ، والتخطيط والإنتاج في جانب العميل.

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

أي لدينا الصورة التالية:

ديف
اختبار
التدريج
الإنتــاج

projectX.dev.company.tld
projectX.test.company.tld
التدريج.projectX.tld
مشروع X.tld

Module1.projectX.dev.company.tld
Module1.projectX.test.company.tld
Module1.staging.projectX.tld
Module1.projectX.tld

Module2.projectX.dev.company.tld
Module2.projectX.test.company.tld
Module2.staging.projectX.tld
Module2.projectX.tld

...
...
...
...

ModuleN.projectX.dev.company.tld
ModuleN.projectX.test.company.tld
ModuleN.staging.projectX.tld
وحدة

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

وهذا فقط في مثال مشروع واحد لشركة واحدة. والمشروع بالطبع ليس وحده.

تبدو الأسباب العامة لمعالجة هذه المشكلة كما يلي:

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

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

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

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

نحو أتمتة إصدار SSL

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

  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. سأعيشها على خادم ubuntu في عامل ميناء حاوية ، ولكن يمكنك تشغيلها في أي مكان يوجد golang. Windows جيد أيضًا ، لكنني ما زلت أفضل خادم Linux.

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

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

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

للعمل الناجح يكفي تصحيح الأقسام العامة و api:

[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"
…

أيضًا ، اختياريًا ، أنشئ ملف docker-compose في الدليل الرئيسي للخدمة:

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. نحن مهتمون بالانتخابات:

  • م: إنشاء شهادة جديدة (خيارات كاملة)
  • 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.

نحو أتمتة إصدار SSL

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

نحو أتمتة إصدار SSL

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

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

نحو أتمتة إصدار SSL

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

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

المصدر: www.habr.com

إضافة تعليق