👩🏻‍💻 🧛🏿 📏 مقدمة ل TLS لباتريك باتريك (الجزء 1) 🔟 🥧 🧑🏼‍🤝‍🧑🏻

كما تعلمون بالفعل ، هذا باتريك. إنه نجم البحر ، مما يعني أنه من الممكن ، دون إهانته ، أن نقول أن يديه تنمو من مكان واحد. باتريك هو أيضًا عملي للغاية وينسى على الفور كل ما لا يحتاجه - ولكن إذا كان يحتاج إلى شيء ، فهو يريد أن يعرفه (لأنه يحتاج إليه!). المفسد: هنا يحاول باتريك إجراء مصافحة TLS.

كتب هذا المقال لباتريك وأمثاله. ولدت من عرض تقديمي تم عرضه لأول مرة في برنامجنا التعليمي الداخلي Plesk TechTalk ، حيث يشارك الموظفون في نموذج يمكن الوصول إليه المعلومات مع بعضهم البعض حول التقنيات والعمليات والحلول المثيرة للاهتمام. لذلك ، ستبدو الصور في هذه المقالة مثل الشرائح :) مؤلف النص الأصلي للتقرير هو مدير البرنامج Plesk Ruslan Kosolapov .

عادة ، تغطي جميع مواد TLS بعض الجوانب الصغيرة ، ولكن ليس الصورة الكبيرة. هذا ليس عمليًا للغاية ولدى باتريك صداع من هذا. كل شيء سيكون مختلفًا هنا: باختصار ، قابل للتطبيق "في الحياة اليومية" وبشكل شامل قدر الإمكان.

ما هو TLS ولماذا باتريك

TLS (أمان طبقة النقل) هو بروتوكول حماية طبقة النقل. هناك حاجة حتى لا يتمكن أحد من "الاستماع" إليك ومعرفة بعض المعلومات المهمة (غالبًا كلمات المرور ، إذا تحدثنا عن العمل على الشبكة). وأيضا من أجل حماية أنفسهم من التزييف وتعديل حركة المرور أثناء الإرسال. يكمن الغرض من TLS في هذين الأمرين.

للتوضيح ، دعنا ننظر إلى مصافحة TLS كمكالمة لـ Patrick SpongeBob. أثناء المكالمة ، يمكن لأي شخص التنصت على المحادثة (يقف بجوار باتريك أو تشغيل في منتصف الخط) ، وعموما قد لا يكون سبونج بوب على الطرف الآخر - كل هذه المشاكل ذات صلة. ولحلها ، يريد باتريك استخدام TLS.

باختصار ، تبدو المصافحة عالية المستوى كما يلي:

باتريك: أريد استخدام TLS ، إصدارات التشفير هي كذا وكذا.
سبونجبوب: حسنًا ، دعنا نستخدم إصدارات التشفير كذا وكذا.

بعد ذلك ، يرسل SpongeBob الشهادة ، يتحقق باتريك منها ، ويقول أن كل شيء على ما يرام ، ويتم مفتاح الجلسة (يوجد بالفعل اثنان منهم ، ولكن لا يهم). لماذا تستخدم مفتاح الجلسة بدلاً من التشفير غير المتماثل - لأنه أسرع. بعد ذلك ، يبدأون في التحدث بلغة غير مفهومة لفك التشفير. وبالتالي ، كل شيء محمي.

يبدو أن كل شيء بسيط. كيف تعمل على الأجهزة ليست مهمة للغاية بالنسبة لنا. ولكن إذا بدأت في التفكير - وبدأ باتريك في التفكير! - يطرح السؤال حول كيفية الموافقة بشكل عام على أننا سنستخدم TLS؟ بعد كل شيء ، بمجرد عدم وجود TLS ، ولكن لم يكن هناك سوى بروتوكولات عادية - SMTP ، HTTP. كيف تقول ما هو مطلوب على TLS؟ وهنا في صناعتنا كل شيء على النحو المعتاد - هناك طرق عديدة!

في البداية أرادوا استخدام منفذ معين ، مما يعني ضمنيًا استخدام TLS عليه. ما هي عيوب هذا؟ ولماذا ظهرت بعد ذلك الطريقة الصريحة (الصريحة) لبدء جلسة TLS؟ هناك عدة أسباب:

أنت بحاجة إلى الكثير من المنافذ - والمنافذ شيء لا ترغب في إنفاقه. لأنه كلما زاد العدد ، زادت صعوبة تكوين جدار الحماية.
يمكن أن يتجاهل الخادم هذا - فقد اتصل بالمنفذ 443 ، ولا يوجد TLS هناك ، فقط HTTP بدون أي HTTPS.
قبل إنشاء الاتصال ، لا يمكنك معرفة ما إذا كان خادم TLS مدعومًا أم لا.

كل هذا أدى إلى ظهور طريقة صريحة - عندما نتصل بمنفذ عادي ، ثم نقوم بترقية جلستنا إلى TLS. بالنسبة للخدمات المختلفة ، يحتوي البروتوكول على أوامر مختلفة ، على سبيل المثال ، بالنسبة لـ SMTP ، هناك أمر منفصل على مستوى بروتوكول SMTP - STARTTLS . HTTP لديه أيضا مثل هذه النكتة ، ويطلق عليه الترقية: TLS / 1.0 . على مستوى البروتوكول ، من الأسهل فهم ما إذا كان خادم TLS مدعومًا أم لا.

دعونا نتحدث قليلاً عن الأنواع المختلفة من الاتصالات وكيف تسير الأمور مع TLS بالنسبة لهم.

الاتصال: HTTP

سيكون كل شيء سهلاً إذا لم تكن هناك ، كما هو الحال دائمًا ، فروق دقيقة. في حالة HTTP ، توفر متطلبات الأمان المتزايدة تطورًا مستمرًا للعمل مع TLS. في البداية كان هناك إعادة توجيه إلى HTTPS ، وقد تم ذلك ببساطة في العنوان. وقد ترك هذا ثغرة في نقاط الضعف ، لذا توصل زميل Google إلى HSTS (HTTP Transport Strict Transport Security). هذا عنوان في استجابة HTTP يخبر المتصفح: "يرجى تذكر أنه عندما تصل إلى هذا النطاق ، انتقل مباشرة إلى HTTPS ، حتى إذا أخبرك الشخص بالذهاب إلى HTTP". وبالتالي ، ليس هناك إعادة توجيه وكل شيء يحدث أكثر أمانًا. بالإضافة إلى ذلك ، لدى Google مبادرة أخرى - يمكنك ترك طلب حتى تتم إضافة موقعك إلى القائمة الخاصة بـ Google Chrome "استخدم دومًا HTTPS" ، بغض النظر عن أي عناوين.

موجز: يحل HSTS إعادة التوجيه من HTTP إلى نقاط الضعف HTTPS ، لذلك تدعم جميع المتصفحات تقريبًا HSTS ، وهو أمر جيد.

الاتصال: غريب (إصدارات جديدة من HTTP وليس فقط)

في HTTP / 2 ، تكون الأشياء جيدة مع TLS: يتم استخدامها دائمًا (حيث يتم إنشاء المتصفحات الآن). بالإضافة إلى ذلك ، يجب أن يكون TLS في HTTP / 2 حديثًا - أي أن يكون لديك الإصدار 1.2+.

على الأرجح ، ستبيع Google قريبًا الاستخدام واسع النطاق لـ HTTP / 3 ، والآن يتم اعتماده من خلال معيار IANA. قصة مظهرها وتطورها مربكة إلى حد ما ؛ الشيء الرئيسي الذي يجب تذكره باتريك:

HTTP / 3 هو دائمًا TLS 1.3+.
يعتمد HTTP / 3 على QUIC - إنه بروتوكول عبر UDP ، وهو ، وفقًا لـ Google ، أفضل من TCP. في الواقع ، قبل الموافقة النهائية على اسم HTTP / 3 ، كان البروتوكول يسمى HTTP-over-QUIC.

لا يزال هناك بروتوكول SCTP مثير للاهتمام ، والذي يستخدم بشكل رئيسي في الاتصالات. أعلاه ، يتم استخدام كل من TLS و DTLS (هذا هو TLS لـ UDP).

باختصار: في غضون عامين ، سيتم استخدام QUIC (أي HTTP / 3) في كل مكان ، ولكن الآن يجب أن يكون هناك HTTP / 2 في كل مكان ، ولكن في الواقع ليس في كل مكان.

الاتصال: البريد

يعتقد العديد من العملاء أنه يجب أن يكون هناك TLS على المنفذ 587 ، ولكن هناك أيضًا فروق دقيقة هنا: يتوقع شخص ما TLS بشكل افتراضي ، ويتوقع شخص ما طلب STARTTLS صريحًا من العميل. ولهذا السبب ، تتسبب مجموعات مختلفة من خادم البريد وعميل البريد في بعض الأحيان في حدوث تأثيرات غير مرغوب فيها. على سبيل المثال ، يدخل العميل المنفذ 587 ، متوقعًا أنه سيكون هناك TLS ، بينما ينتظر الخادم أن يطلب العميل بشكل صريح STARTTLS . بعد عدم تلقي أي شيء ، يعود العميل إلى المنفذ 25. والنتيجة هي التبديل الصامت إلى اتصال SMTP غير آمن. عند الاختبار والتطوير ، من الجدير التذكر حول هذه التأثيرات لمجموعات خادم العميل. يحتوي Autodiscaver على خيارات مختلفة لتحديد TLS: كيف يجب أن يكون ، وما هو متوقع ، وماذا يفعل. يفهم العديد من عملاء البريد هذه الأشياء.

موجز: مع دعم TLS في خوادم البريد وعملاء البريد ، كل شيء على ما يرام بشكل عام ، ولكن في حالات معينة قد تكون هناك مشاكل ولا يتم دعم امتدادات TLS بشكل جيد.

ربط: FTP

يمكن قول القليل هنا. المشكلة الرئيسية هي SNI (هذا هو عندما تكون المجالات المختلفة على نفس IP). على مستوى FTP ، لا يتم نقل اسم المجال. في إصدار صريح ، لا يمكن أن يعمل ، لأنه لا يوجد مكان لكتابته. هناك العديد من خيارات الحلول - بعضها يقدم ذلك ، والبعض الآخر لذلك ، لم يتم اعتماد حل عام حتى الآن ، ولا يوجد معيار.

باختصار: هناك نوع من دعم TLS لبروتوكول نقل الملفات (FTPS ، SFTP - وهو نظير لبروتوكول FTP يتم تنفيذه من خلال SSH) ، ولكن بعض الجوانب لا يتم تغطيتها بسبب القيود التقنية لبروتوكول نقل الملفات نفسه.

مصافحة TLS

لذا ، نعرف الآن كيفية بدء الاتصال باستخدام TLS في اتصالات مختلفة ، وتمكن باتريك من التعبير عن رغبته في SpongeBob. بمجرد الموافقة على استخدام TLS ، يتم إنتاج تأكيد اتصال TLS. يجب أن تكون النتيجة اتفاقية بين العميل والخادم حول كيفية تشفيرها كلها. بالإضافة إلى ذلك ، يجب على العميل التأكد من أن الخادم هو المطلوب. في بعض الأحيان يقوم الخادم أيضًا بفحص العميل (ولكن بشكل أقل تكرارًا).

الأصفار والإصدارات

كما ذكرنا سابقًا ، فإن الخطوة الأولى هي اختيار إصدار TLS وأي شفرات سيتم استخدامها للتشفير. بشكل عام ، يبدو التشفير كما يلي:

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

DHE
ECDhe
AES128
AES 256
RSA
Ecdsa
Cbc
Gcm
SHA256
SHA383
الحلقة 20
بولي 1308

صورة لتذكر الأصفار الجيدة:

إذا كان من الصعب التذكر ، فهناك خدمات جيدة يمكن أن تخبرك عنها ، على سبيل المثال ، خدمة من Mozilla ssl-config.mozilla.org .

يمكنك أن ترى على الفور أين وكيف يتم دعمه - هذا ما يحاول رجال موزيلا اتباعه.

تفاصيل مثيرة للاهتمام: ينقل العميل الشفرات بترتيب الأولوية وفقًا لتفضيلاتهم ، لكن القرار متروك للخادم - فهو يختار التشفير الذي يبدو أنه الأفضل من قائمة المدعومة من قبل العميل.

يشير كلا الجانبين أيضًا إلى الحد الأقصى للإصدار المدعوم من البروتوكول - في هذه الحالة ، باتريك أكثر تقدمًا من SpongeBob.

شهادة فعلا

إلى جانب الإجابة "لنفعلها بهذه الطريقة" ، يرسل الخادم شهادته أو شهاداته - يمكن أن يكون هناك الكثير منها.

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

وبالتالي ، فإن الشهادة هي بنية "الموضوع: المفتاح العام" بالإضافة إلى توقيع ishyuer (يبدو المصدر في الترجمة الصوتية إلى اللغة الروسية فظيعًا ، ولكن أقرب مرادف هنا ليس قريبًا جدًا في سياق "المصدر") الذي تم إصدار هذه الشهادة. لدى Ishüyer أيضًا شهادة وارتباط شخص ما بشيء ما. يمكنك التحقق من الشهادة للتأكد من صحتها من خلال أخذ المفتاح العمومي لجهاز ishyuere والتحقق من التوقيع. ونتيجة لذلك ، لا يمكن تزوير أي شيء هنا.

دعنا نراجع الشهادة ونرى ما هي المشاكل التي قد تواجهها.

أولاً ، يشير الرقم التسلسلي إلى التفرد فقط داخل حدود ishyuere ، على الرغم من أن بعض البرامج تعتبر أنه فريد في الكون كله. لحسن الحظ ، في كثير من الأحيان ، إنه فريد تمامًا حقًا.

تشير الشهادة أيضًا إلى الخوارزميات التي يتم استخدامها للتشفير والتوقيع: RSA أو ECDSA - أي ، أي التشفير لاستخدامه للعمل مع هذا المفتاح العام. الفرق الرئيسي بين RSA و ECDSA هو أن المبدأ الرياضي لـ ECDSA يقوم على منحنيات بيضاوية ، و RSA يعتمد فقط على الأرقام الطبيعية ، لذلك فهو أبطأ وتستخدم بتات المفاتيح الضخمة (3-4 آلاف) لمنع تكسيرها . وبالنسبة لـ ECDSA ، يكفي مفتاح 300 بت ويعمل بشكل أسرع. لذلك ، يتحول الكثير إلى ECDSA - المصافحة نفسها ثقيلة وأريد تقليلها. يمكن طلب ECDSA عند إصدار الشهادة ، وإذا كان المنقب يدعمها ، فسوف يقوم بذلك نيابة عنك. لكن توقيع الشهادة يعتمد على ما هو المفتاح الخاص لدى ishuiur حاليًا ، وليس على ما إذا كنت قد طلبت ECDSA أو RSA.لذلك ، يمكن للمتصفحات إظهار أن أحدهما موجود في التوقيع والآخر في المفتاح العام ، ولا داعي للخوف إذا لم يكن التوقيع ECDSA.

كيف تحصل على شهادة؟

باختصار - مثل هذا:

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

هذا أيضًا هيكل ، يصعب العمل به تمامًا ، نظرًا لوجود عدد قليل من الخدمات التي تسمح لك بتعيين كل شيء وتحديده والتحقق منه ورؤية كل شيء.

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

CAA RR

هناك مثل هذه المشكلة التي يعتقد الناس أنها ليست جيدة في بعض الأحيان. أحد أسباب تحول Symantec إلى جزء من DigiCert هو أنها (Symantec) أصدرت شهادات دون سؤال أصحاب المجال. لا يمكنك القيام بذلك ، كان الأمر مهينًا للجميع ، ولكن الأهم من ذلك كله لشركة Symantec نفسها ، لأنه كان عليك بيع عملك. لجعل الخادم أقل اعتمادًا على مثل هؤلاء الرفاق عديمي الضمير ، هناك شيء مثل CAA RR - سجل في DNS ، والذي يقول من يسمح المالك بإصدار شهادات لنطاقه. هذه الميزة موجودة أيضًا في Plesk ، يتم استخدامها قليلاً حتى الآن ، تقريبًا مثل DNSSec ، ولكن مع ذلك. وافقت جميع سلطات التصديق على التحقق من هذا الإدخال ، وإذا كانت تقول أنه لا يمكن إصدار سلطة التصديق هذه ، فستقول: "لم تجتز عملية التحقق ، فهذا مكتوب في CAA RR ،لا يمكنني كتابة شهادة لك "- ولن أكتبها. إذا لم يكن هناك دخول ، يمكنك ذلك. تدفع Google الآن زمام المبادرة حتى يتحقق العملاء من الشهادة التي حصلوا عليها للتوافق مع سجلات CAA RR. لا يزال النقاش مستمراً.

أيضًا ، CAA RR منذ اللحظة التي قدمنا فيها دعمهم في Plesk موسعًا بالإشارة إلى طرق التحقق (أي ، يمكنك أيضًا الإشارة هنا إلى الطريقة التي تتحقق من أن هذا النطاق يخصك) و URI للحساب (معرف الموارد الموحد). شائع بين المستخدمين يدعم Plesk Let's Encrypt بالفعل كل هذا (أحسنت!).

كل هذا يعمل مع أي نوع من الشهادات ، وبما أننا سنتحدث عن الاختلافات لاحقًا ، فقد حان الوقت للحديث عن الأنواع بمزيد من التفاصيل.

أنواع الشهادات

هناك ثلاثة منهم:

التحقق من صحة المجال

الموضوع هو مجال ، أي أننا نتحقق منه فقط. في السابق ، عندما لم يكن هناك مدققون آليين ، تم التحقق من الصحة بشكل رئيسي عن طريق البريد الإلكتروني من خلال خدمة Whois. اعتبر هذا سببًا كافيًا للاعتقاد بأنك مالك هذا النطاق. ثم فكروا في التحقق من خلال DNS - كتبوا لك عبر البريد الإلكتروني: "وإضافة مثل هذا السجل إلى DNS". ظهرت الأساليب التلقائية في وقت لاحق (سنتحدث عن ACME قليلاً).

التحقق من صحة المنظمة

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

التحقق الموسع

نفس OV ، فقط أكثر برودة. كل شيء منظم للغاية هنا - يجب أن تكون الوثيقة المكونة من 40 صفحة بروح "في الفقرة 5.6.8 ما يلي: ..." ، إلخ. يتم فحص الكثير من الأشياء - البلد ، القسم (إذا تم الإشارة إليه في التطبيق) ، وأحيانًا يغادر شخص خاص حتى يرى بأم عينيه. ما هو الفرق العملي؟ توقفت جميع المتصفحات تقريبًا عن التمييز بين OV و DV ، وهذا أمر سيئ ، لأنه في هذه الحالة لا يتم عرض اسم المنظمة. ونتيجة لذلك ، لا يزعج أحد إنشاء نطاق aliepxress.ru ، ورسم نفس الصفحة وسرقة بطاقات الائتمان. وسيكون من المشروع تمامًا إنشاء أي نطاق من هذا القبيل والحصول على شهادة DV عليه.

مثال مع EV - اسم المؤسسة مرئي هنا ، لذلك إذا سرق شخص ما شيئًا ما ، فسيعرف المستخدم أنه شركة Valve Corp ، وتسجيل الشركة أصعب إلى حد ما من المجال (المزيد من عمليات التحقق).

ومع ذلك ، كل شيء يذهب إلى النقطة التي سيتوقف فيها EV عن الاختلاف ، على الأجهزة المحمولة لم يعد مرئيًا وتحتاج إلى الضغط على زر منفصل ، وفي Safari أيضًا. لا يزال Google Chrome معلقًا (UPD - لم يعد! كان عليّ إنشاء شاشة من IE). حجة أولئك الذين لا يظهرون: "إذا كنت قلقًا ، فانقر وانظر" ، ولكن لا أحد يضغط بشكل طبيعي.

الحصول على شهادة: أتمتة

الآن دعونا نتحدث عن الاستلام الآلي لشهادات DV. من أجل الوضوح ، دعنا نرى كيف يقوم برنامج Let's Encrypt المفضل لدينا بذلك. لديه بشكل عام وثائق جيدة ، إذا كان أي شخص مهتمًا ، وحتى باللغة الروسية.

ذروة

ACME (بيئة إدارة الشهادة التلقائية) هو بروتوكول مصمم لأتمتة عملية الحصول على الشهادة وتوحيدها.

كيف تثبت ACME أنك مالك المجال؟ أنت تقول: أريد شهادة وأشير إلى نوع التحقق التلقائي - على سبيل المثال ، ACME HTTP-01. تطلب منك ميزة Encrypt (تشفير) وضع البيانات في ملف ، وإذا كان بإمكانك وضع الملفات على نطاقك (ويمكن لـ Let's Encrypt التقاطها من هناك عبر HTTP) ، فأنت على الأرجح مالكها. الآن تم انتقاد هذا النهج ، بما في ذلك من جوجل ، لأنه لا يحمي من التصيد. أي ، من خلال التحقق اليدوي ، من المرجح أن يثير مجال aliepxress.ru الشك ، ولكن لنشفر نفسه حتى الآن لا يعرف كيف (أو يمكن ، ولكن بشكل سيئ).

تحدي DNS

بالإضافة إلى ACME ، هناك أيضًا تحدي DNS. على سبيل المثال ، يقولون لك: أدخل سجل txt في منطقة DNS الخاصة بك ، ضع البيانات فيه. هناك طرق أخرى ، ولكنها ليست شائعة ، وتم إلغاء واحدة تمامًا ، لأنها تبين أنها عرضة للخطر. ما لدينا في Plesk: شهادات أحرف البدل (التي لا يمكن كتابتها إلا باستخدام تحدي DNS) لا تعمل للعديد من الأشخاص ، لأنه في كثير من الأحيان لا يدير Plesk مناطق DNS الخاصة بالنطاق وإضافته لا يمكن لـ Enc Encrypt أتمتة إنشاء سجل في منطقة DNS .

كلمتين أخريين عن Let's Encrypt

جانب مهم في العمل مع شهادات Let's Encrypt هو الحدود. في حالة الشك (أو الشك في أنه تم تحقيقها) ، من الأفضل اتباع الرابط: Let'sencrypt.org/docs/rate-limits

في بعض الأحيان يتم تحديثها. هناك حدود غير واضحة ينسىها الناس: في أغلب الأحيان ، إذا حكمنا من خلال طلبات الدعم ، فإنهم يواجهون حد 100 اسم نطاق في الشهادة. تمتلك Encrypt أيضًا خادمًا مرحليًا وهناك المزيد من الحدود ، ولكن مثل هذه الشهادات تعتبر غير موثوقة ومتصفحًا لأنها مشابهة للتوقيع الذاتي. في الواقع ، نادرًا ما تصل إلينا 100 اسم ، (على الرغم من حقيقة أن المواقع على Plesk لديها ما مجموعه 1،300،000 شهادة Let's Encrypt). المتوسط ، وفقًا لإحصاءاتنا ، هو 20 اسمًا لكل شهادة. لذا ، إذا لم ينجح شيء ، انظر - ربما تم الوصول إلى الحد الأقصى. فلدينا تشفير جيد للإبلاغ عن الأخطاء ، ويمكنك عادةً فهم ما حدث.

ماذا بعد؟

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

كل ما تحدثنا عنه ، قبل أن يمر TLS 1.3 عبر قناة مفتوحة ، ويمكن لأي شخص رؤية كل هذه الأشياء. هناك العديد من الهجمات المثيرة للاهتمام التي يمكنك قراءتها عن نفسك.
في ~~السلسلة~~ الثانية من المقالة ، سوف نتعلم كيف يتحقق العميل من الشهادة.

مقدمة ل TLS لباتريك باتريك (الجزء 1)