الخدمة بلغة Dart: اسم المجال ، SSL

جدول المحتويات
  1. 1.
  2. 2. Backend
  3. 2.1. .
  4. 2.2. . SSL ( )
  5. 2.3. .
  6. ...
  7. 3. Web
  8. 3.1. “Under construction”
  9. ...
  10. 4. Mobile
  11. ...




إخلاء المسؤولية (حسب التعليقات على المقال السابق)
  • . .
  • , : .
  • , , , K8s, AWS, GKE . , . , , «», .
  • , : , .
  • . . , .
    • Dependency injection ( boilerplate)
    • ORM. .
    • oAuth2 + JWT . .
    • Deeplinks (Universal links/ App links). web/app
    • (websockets)
    • flutter






اسم النطاق



في المرة الأخيرة أن الأمر انتهى على ذلك في حاوية عامل ميناء أطلق خادم الويب إنجن إكس، وتوزيع ملف index.html وثابت. هذه المرة سنقوم بتوسيع وظائف خادم الويب عن طريق إضافة تشفير البيانات وإعادة التوجيه القسري من http إلى https.







للقيام بذلك ، تحتاج إلى حل مشكلة تنظيمية: الحقيقة هي أنه لا يمكن الحصول على شهادة التشفير إلا لاسم مجال أو مجموعة من الأسماء. لهذا السبب ، نذهب إلى أي من مسجلي أسماء النطاقات ونختار اسمًا يطابق العلامة التجارية (الغرض ، الشعار ، وما إلى ذلك) دون أن ننسى الغرض من أسماء النطاقات عالية المستوى. في حالتي ، فإن dartservice.ru مثالي . أثناء عملية التسجيل ، يجب عليك ملء نموذج معلومات المالك بما في ذلك الاسم والعنوان البريدي والبريد الإلكتروني. ثم تحتاج إلى الانتقال إلى إدارة سجلات DNS في لوحة تحكم المسجل وإنشاء ثلاثة سجلات:



  • اثنان على الأقل من سجلات NS. هذه هي أسماء خوادم اسم المجال للمسجل ويتم توفير اسمها من قبل المسجل عند شراء اسم المجال.
  • سجل. هذا هو سجل للعلاقة بين اسم المجال وعنوان IP الخاص بالخادم.


في حالتي ، تبدو سجلات DNS كما يلي:







بعد القيام بذلك ، يجب ألا تتوقع نتائج فورية. عادةً ما يستغرق تبادل المعلومات بين خوادم DNS من 1 إلى 12 ساعة لمنطقة RU. ثم ... أضف اختبارًا آخر إلى المشروع /test/http/client.http







SSL



بشكل عام ، بالطبع ، يعد SSL اسمًا قديمًا. تسمى الإصدارات الجديدة من البروتوكول TLS 1.0 ... 1.3 ، لكن الآلية تظل كما هي - تشفير البيانات أثناء الانتقال بين بروتوكول طبقة التطبيق (في حالتنا HTTP) وبروتوكول طبقة النقل (TCP / IP). في الحقيقة أنت بحاجة إلى:



  • احصل على شهادة تشفير من مرجع مصدق خاص ، لتأكيد ملكية المجال المقابل.
  • NGINX.
  • .
  • , http https.


من المقبول عمومًا في الوقت الحالي استخدام الشهادات المجانية الصادرة تلقائيًا عن خدمة Let's encrypt . أحد قيود هذه الشهادات هو فترة الصلاحية. 90 يومًا فقط. بعد ذلك ، يجب الحصول على الشهادة مرة أخرى. للحصول على الشهادات تلقائيًا (بدون تدخل بشري) ، تم تطوير بروتوكول وتطبيقات ACME التي تؤدي بشكل دوري إجراءات لتأكيد ملكية المجال. دعنا نوصي بتشفير استخدام تطبيق certbot . إنه مكتوب بلغة python ويتطلب تثبيت المستودع الخاص به و python3. لذلك ، سوف نستخدم حاوية عامل إرساء مع certbot مثبت من سجل DockerHub . لنحدد أحدث إصدار ثابت من certbot / certbot: v1.5.0...



لنكتشف الآن آلية الحصول على شهادة باستخدام بروتوكول ACME:



  • عند التشغيل الأول ، ينشئ Certbot مفتاحًا خاصًا وعامًا ، ثم ينشئ حساب مسؤول المجال في خدمة Let's encrypt ، ونقل المفتاح العام ومعلومات المجال.
  • بعد ذلك ، يرسل برنامج Let's encrypt رسالة ، والتي يجب على certbot التوقيع عليها باستخدام مفتاح خاص وإعادته مرة أخرى.
  • يجب أن يضع ertbot على الخادم ملفًا خاصًا متاحًا للقراءة على dartservice.ru/.well-known/acme-challenge لتأكيد ملكية هذا المجال.
  • يؤلف Certbot طلب شهادة ، ويرسله إلى Let's encrypt ونستلم شهادة للمجال في المقابل.


دعنا نضيف حاوية التطبيق إلى البرنامج النصي docker-compose.yaml :







معلمة جديدة هنا comand : هنا هو الأمر الذي سيتم تنفيذه بعد بدء الحاوية. في هذه الحالة ، بالتأكيد (احصل على شهادة). يتم الحصول على شهادة عبر الإنترنت ، أي أنه من الضروري الإجابة باستمرار على العديد من الأسئلة. يتيح لك تمرير العلامات بعد الأمر القيام بذلك دون تدخل بشري: --webroot (طريقة التأكيد) --webroot-path = / usr / share / nginx / html / Letsencrypt (المسار حيث سيتم وضع ملفات تأكيد ملكية المجال) - مشرف البريد الإلكتروني @ email.com (بريد مسؤول المجال) --agree-tos(قبول شروط اتفاقية الترخيص) - no-eff-email (لا تبلغ عن البريد الإلكتروني لمطوري certbot) -d dartservice.ru (قائمة المجالات).



لنقم بتكوين حاوية NGINX:







التغييرات هنا هي لفتح منفذ https (443) وتركيب المجلدات بشهادة SSL وملفات تأكيد ملكية المجال.



معلمة مهمة هي مجلد مفتاح Diffie-Hellman. باختصار: هذا المفتاح ضروري من أجل التبادل الآمن لمفاتيح التشفير بين الخادم والعميل عند إنشاء اتصال. مزيد من التفاصيل هنا .



لنقم بإنشاء مثل هذا المفتاح ، لكننا سنواجه المشكلة التالية: تم إنشاء المفتاح بواسطة برنامج openssl، إنها أداة مساعدة لوحدة تحكم Linux من غير المرجح أن تظهر على جهاز Windows الخاص بنا. أبسط حل هو تشغيل البرنامج النصي الخاص بنا ، والانتقال إلى وحدة تحكم حاوية الويب وإنشاء مفتاح هناك ، وتمرير المجلد المضيف المثبت في الحاوية في مسار الإخراج للملف: قم



بتشغيل البرنامج النصي:



docker-compose up -d


نطلب قائمة الحاويات قيد التشغيل:



docker-compose ps






افتح وحدة التحكم في الحاوية:



docker exec -it srv_web_1 bash


نبدأ في إنشاء المفتاح في مجلد تكوين NGINX (والذي ، كما نتذكر ، يتم تثبيته من المضيف):



openssl dhparam -out /etc/nginx/conf.d/dhparams.pem 2048






انقل المفتاح إلى ./dhparams/dhparam-2048.pem



اخرج من وحدة تحكم الحاوية Ctrl-D وأوقف البرنامج النصي:



docker-compose down


الآن دعنا نغير تكوين NGINX ./conf.d/defaulf.conf :







أضف موقعًا جديدًا ^ ~ /.well-known/acme-challenge لخدمة الملفات الثابتة من المجلد / usr / share / nginx / html / letencrypt . هذا هو المكان الذي سيتم فيه وضع ملفات تأكيد certbot. لنقم بإعداد إعادة توجيه لجميع الطلبات الأخرى إلى https.



كل شيء جاهز للحصول على أول شهادة SSL.



دعنا ننسخ مشروعنا إلى VPS في مجلد جديد / opt / srv_1 / بالأمر:



scp -r ./* root@91.230.60.120:/opt/srv_1/


دعنا نتصل من VScode عبر SSH إلى VPS.



لننتقل إلى مجلد الخادم قيد التشغيل:



cd /opt/srv_0/


ووقف النص:



docker-compose down


انتقل الآن إلى مجلد الخادم الجديد cd / opt / srv_1 / وقم بتشغيل البرنامج النصي:



docker-compose up






في وحدة التحكم ، نرى أن certbot أنشأ ملف تأكيد zeS4O87S6AfRQ3Kj4MaBlBFZx3AIiWdPn61DwogDMK4 وأبلغ خدمة Let's encrypt بذلك ، والتي طلبت بدورها هذا الملف من أربعة عناوين IP مختلفة ثم أصدرت شهادة. تم حفظ الشهادة في شكل سلسلة كاملة ومفتاح خاص في المجلد المقابل. الشهادة صالحة لمدة 90 يومًا (حتى 05.10.2020).



حان الوقت لإنشاء موقع ثانٍ لاتصال آمن في تكوين NGINX على الخادم ./conf.d/defaulf.conf :







أعد تشغيل البرنامج النصي
docker-compose restart


دعونا نرى كيف يتفاعل المتصفح مع شهادتنا:







Google Chrome سعيد بشهادتنا. أصبحت المهمة الآن أكثر تعقيدًا - سنختبر الأمان والتوافر لمتصفحات مختلفة لاتصال SSL الخاص بنا https://www.ssllabs.com/ssltest/ . أدخل العنوان ، وحصلنا على النتيجة:







كل شيء على ما يرام مع الشهادة وتبادل المفاتيح (بفضل Diffie-Hellman) ، لكن روبوت الاختبار خفض العلامة ("B" هي "4" في رأينا) لدعم بروتوكولات TLS1.0 و TLS1.1 القديمة ... إن تعطيلها في تكوين NGINX ليس بالأمر الصعب ، ومع ذلك ، بالنظر إلى تقرير الاختبار بشكل أكبر ، نرى ، على سبيل المثال ، أن متصفحات بعض الأجهزة المحمولة في هذه الحالة لن تكون قادرة على الاتصال:











لا يزال هناك العديد من مهام الخدمة المتبقية لأداء.



يجب ألا يتجاوز عدد محاولات الحصول على شهادة لنطاق ما 5 محاولات في غضون 7 أيام. بعد ذلك ، يمكن لخدمة Let's encrypt أن تمنعنا. ومع ذلك، تشغيل البرنامج النصي أثناء التطور في كل مرة certbot سوف محاولة للقيام بذلك، وذلك في برنامج نصي من عامل ميناء compose.dev.yaml، تغيير قيادة معلمة من certbot الحاويات :







و --dry المدى العلم هو اختبار تشغيل بدون الحصول على الشهادة.



لنكتب اختبارًا:







شفرة المصدر جيثب .



خاتمة



لذلك ، في هذه الخطوة ، قمنا بتأمين الاتصالات بين تطبيقات الخادم والعميل وقمنا بتعليم المتصفحات "الثقة" في مجالنا.



في المقالة التالية ، سنكتب صفحة ويب رفرفة مع العد التنازلي لإطلاق خدمتنا ، ونجمعها ونضعها على خادمنا.



All Articles