Auto SSL
إصدار وتجديد الشهادات لأسماء مضيفيك تلقائيًا.
افتح الموضوعمساعدة CDN.com.tr
سياسة TLS عند الحافة
تقبل حافة CDN.com.tr إصداري TLS 1.2 وTLS 1.3 فقط، وتختار الشفرة من قائمتها المرتّبة الخاصة. في مقدّمة القائمة تأتي مجموعات التشفير التي تجمع تبادل مفاتيح ECDHE مع شفرات AEAD (مجموعات TLS 1.3 ومجموعات TLS 1.2 الحديثة)، وتليها مجموعات TLS 1.2 أقدم تُبقى من أجل العملاء القدامى: ECDHE مع CBC، وتبادل مفاتيح RSA دون ECDHE (GCM وCBC). تُرفَض TLS 1.0 وTLS 1.1 وRC4 و3DES وMD5 وشفرات التصدير.
شهادات SSL
سياسة TLS عند الحافة
تقبل حافة CDN.com.tr إصداري TLS 1.2 وTLS 1.3 فقط، وتختار الشفرة من قائمتها المرتّبة الخاصة. في مقدّمة القائمة تأتي مجموعات التشفير التي تجمع تبادل مفاتيح ECDHE مع شفرات AEAD (مجموعات TLS 1.3 ومجموعات TLS 1.2 الحديثة)، وتليها مجموعات TLS 1.2 أقدم تُبقى من أجل العملاء القدامى: ECDHE مع CBC، وتبادل مفاتيح RSA دون ECDHE (GCM وCBC). تُرفَض TLS 1.0 وTLS 1.1 وRC4 و3DES وMD5 وشفرات التصدير.
مسار اللوحة
- Not a panel setting
- Edge configuration, applied to every account
المتطلبات المسبقة
- اسم مضيف خاص بك يقدّمه CDN بالفعل.
- openssl على جهازك إن أردت إعادة إنتاج الدليل.
التحقق
- openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1 — تُرفَض المصافحة، وتُبلّغ بعدم توفر بروتوكولات.
- openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_3 — تنجح المصافحة وتُبلّغ عن TLS_AES_256_GCM_SHA384.
- عميل يعرض شفرة CBC أولًا ينتهي به الأمر مع ذلك على شفرة AEAD، لأن الاختيار مفضَّل من جهة الخادم.
حالات الاستخدام
يسألك استبيان أمني أو مناقصة أو الماسح الخاص بك عن إصدارات TLS والشفرات التي يقبلها موقعك. الإجابة نفسها لكل حساب: هي مضبوطة عند الحافة وليست إعدادًا خاصًا بكل حساب.
سير العمل
- أجب عن السؤال من السياسة أدناه — تنطبق على كل اسم مضيف يقدّمه CDN.
- إن احتجت دليلًا بدل تصريح، شغّل فحوصات openssl في قائمة verification مقابل اسم المضيف الخاص بك.
- إن تعذّر على أحد عملائك الاتصال، حدّد إصدار TLS الخاص به قبل افتراض مشكلة شهادة.
الفحوصات
- مقبول: TLS 1.2 وTLS 1.3.
- مرفوض: TLS 1.0 وTLS 1.1. محاولة المصافحة على تلك الإصدارات تُغلَق، لا تُخفَّض.
- اختيار الشفرة مفضَّل من جهة الخادم: تختار الحافة من قائمتها المرتّبة الخاصة بدلًا من احترام ترتيب العميل.
- تُقدِّم القائمة تبادل مفاتيح ECDHE مع شفرات AEAD: تأتي أولًا مجموعات تشفير TLS 1.3 ومجموعات TLS 1.2 الحديثة. وتليها مجموعات TLS 1.2 أقدم تُبقى من أجل التوافق مع العملاء القدامى: ECDHE مع CBC، وتبادل مفاتيح RSA دون ECDHE (GCM وCBC). ولأن الخادم يختار وفق ترتيبه الخاص، ينتهي أي عميل حديث دائمًا إلى شفرة AEAD. لا تُعرَض RC4 و3DES وMD5 وNULL وشفرات درجة التصدير.
- لا يوجد مفتاح خاص بكل حساب لهذا. ليس في Delivery Rules ولا في SSL Management، لأن خيارًا أضعف لعميل واحد سيُضعف الحافة المشتركة.
- عميل قديم جدًا يتحدث TLS 1.0 فقط لا يستطيع الاتصال. هذه هي النتيجة المقصودة من السياسة.
الأسئلة الشائعة
هل يمكنكم تفعيل TLS 1.0 لعميل قديم واحد لدينا؟
لا. قائمة البروتوكول مشتركة بين كل موقع على الحافة، فاستثناء لحساب واحد سيُضعف الجميع. TLS 1.0 و1.1 مهجوران ويفشلان في كل خط أساس امتثال حالي — عادة الخط الأساس نفسه الذي دفعك للسؤال.
ماسحنا يبلّغ عن شفرة CBC. هل هذا اكتشاف؟
تُبقي القائمة المعروضة ذيلًا من CBC بعد شفرات AEAD للعملاء الأقدم. ولأن الاختيار مفضَّل من جهة الخادم، فإن أي عميل حديث يتفاوض على شفرة AEAD — يسرد الماسح ما هو معروض، لا ما يُستخدَم فعليًا. تحقّق من الشفرة المتفاوَض عليها في اتصال حقيقي قبل اعتبارها اكتشافًا.
هل يعتمد هذا على شهادتي؟
لا. إصدارات البروتوكول والشفرات سياسة حافة؛ شهادتك تحدّد الهوية، لا معاملات المصافحة. تحصل شهادة Auto SSL وشهادة تجارية مرفوعة على سياسة TLS نفسها تمامًا.
كيف أثبت هذا لمدقّق؟
شغّل أمري openssl في قائمة verification مقابل اسم المضيف الخاص بك وأرفق المخرجات. تفشل محاولة TLS 1.1 وتبلّغ محاولة TLS 1.3 عن شفرة AEAD متفاوَض عليها؛ معًا يُظهران نصفَي السياسة.