شهادات SSL/TLS

TL;DR — شهادة SSL/TLS هي الملف الموجود على خادمك الذي يتيح رمز القفل وhttps://. توجد إصدارات رخيصة وأخرى باهظة، لكنها متساوية في تحسين محركات البحث — لا يتحقق Google إلا من أن URL يبدأ بـhttps://، لا من الشهادة التي اشتريتها. تحصل شهادة مجانية من Let’s Encrypt على الترتيب نفسه تمامًا كشهادة غالية. وما يضرك فعليًا هو الشهادة المعطلة: إذا انتهت صلاحيتها أو أسيء إعدادها، تعرض المتصفحات تحذيرًا مخيفًا ويغادر الزوار.

ما شهادة SSL فعليًا

يستخدم HTTPS الحديث شهادات TLS لمصادقة نطاق وإنشاء اتصالات مشفرة. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 8446: TLS 1.3 يوصي Google باستخدام HTTPS ويستعمله إشارةً من إشارات تحديد العنوان الأساسي، لكن سعر الشهادة أو مستوى التحقق منها ليس تعزيزًا موثقًا للترتيب. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

اضغط للتوسيع

The chart groups observed certificate issuance by duration, from three days or less through more than 200 days. The 47-to-100-day bucket dominates this captured period.

عند تحميل موقع آمن، يجري متصفحك والخادم مصافحة سريعة لإعداد التشفير. الشهادة هي ما يسلّمه الخادم أثناء تلك المصافحة. وتؤدي وظيفتين: تشهد لهوية مالك الموقع (إلى حد ما — مزيد من ذلك أدناه)، وتحمل المفتاح الذي يشفّر الاتصال.

يقول الناس «شهادة SSL»، لكن البروتوكول الحديث هو في الحقيقة TLS. بقي اسم «SSL» شائعًا فحسب. (يتناول محور HTTPS غرابة التسمية والسؤال الكامل «هل يساعد HTTPS في الترتيب؟» — تفترض هذه الصفحة أنك تعرف بالفعل أن HTTPS ليس أكثر من عامل ترجيح ضئيل، وتتعمق في الشهادة نفسها.)

هل تساعد شهادة أغلى في تحسين محركات البحث؟

لا. هذه أكثر الخرافات شيوعًا. لا يوثّق Google أي فرق في الترتيب بين أنواع الشهادات أو جهات إصدارها أو أسعارها — مادام HTTPS صالحًا ويعمل، فلا يستطيع التمييز بين شهادة تكلف 300 دولار سنويًا وأخرى مجانية. صاغ جون مولر من Google الأمر بوضوح حين زعم شخص أن SSL يعزز تحسين محركات البحث: “this does not ‘Boost your website’s SEO’, sorry.” (ترجمة) «هذا لا ‘يعزز تحسين محركات البحث لموقعك’، آسف.»

لذلك تحصل شهادة مجانية من Let’s Encrypt على ترتيب مماثل لأغلى خيار يبيعه مورّد شهادات. يشتري المال الإضافي إشارات ثقة بشرية (المزيد عن مستويات التحقق في تبويب Advanced)، لا أفضلية ترتيب.

الأشكال التي تأتي بها الشهادات

يختلف أمران، ومن المفيد إبقاؤهما منفصلين:

• مقدار ما تتحقق منه. تثبت الشهادة الأساسية فقط أنك تتحكم في النطاق. وتتحقق الشهادات الأغلى من الهوية القانونية لشركتك. لا يحدث هذا فرقًا لدى Google.
• ما تغطيه. يمكن لشهادة واحدة أن تغطي اسم مضيف واحدًا، أو مجموعة كاملة من النطاقات الفرعية (شهادة «بدل شامل»)، أو قائمة محددة من الأسماء (شهادة «SAN»).

الجزء المهم فعليًا لتحسين محركات البحث

الشهادة العاملة غير مرئية. أما المعطلة فمشكلة:

• الشهادات المنتهية الصلاحية تعرض تحذير متصفح بملء الشاشة. يغادر الزوار قبل رؤية صفحتك — وقد يبدو ذلك انهيارًا في الترتيب، لكنه في الحقيقة أشخاص يغادرون عند الباب.
• قد تجعل الشهادة شديدة العطل Google يفضّل نسخة HTTP من الصفحة بدل نسخة HTTPS — يفضّل Google عادةً HTTPS، لكن إرشاداته تقول إن الشهادة السيئة تتغلب على ذلك (حتى HSTS لا يستطيع منعه).
• إذا كثرت الأخطاء بما يكفي، فقد يوقف Google زحف صفحات HTTPS تمامًا، ما يدفعها في النهاية خارج نتائج البحث.

لذلك قاعدة الشهادات بسيطة: اشتر الرخيصة (أو المجانية)، ولا تدعها تنتهي أبدًا. أعدّ التجديد التلقائي وانس الأمر.

أتريد العمق الحقيقي — DV مقابل OV مقابل EV، والبدل الشامل مقابل SAN، وسلاسل الشهادات، والتحول إلى أعمار أقصر، وما يحدث بالضبط لبرامج الزحف عند تعطل شهادة؟ انتقل إلى تبويب Advanced.

TL;DR — لا يوثّق Google فرقًا في الترتيب بين عمق تحقق DV/OV/EV أو الإصدار المجاني والمدفوع — فالشهادة الأغلى تشتري ثقة بشرية ومؤسسية، لا ترتيبًا. عمق التحقق (DV/OV/IV/EV) ونطاق التغطية (مفرد/بدل شامل/SAN) قراران مستقلان؛ ولا يُعد أي منهما عامل ترتيب موثقًا. ليست Let’s Encrypt ولا عملية الإصدار الآلي المجانية (ACME) تنازلًا — التشفير نفسه والمعاملة نفسها. يظهر أثر الشهادات في تحسين محركات البحث عند الإخفاق: فالشهادة المنتهية أو الموقعة ذاتيًا أو غير المطابقة لاسم المضيف أو المكسورة السلسلة تعطل الصفحة للمستخدمين، وقد تقلب تفضيل Google المعتاد لـHTTPS على HTTP نحو نسخة HTTP (ولا يستطيع HSTS تجاوز ذلك)، ووفق وثائق Google قد تؤدي كثرة مشكلات HTTPS إلى أن “can prompt Google to stop crawling your HTTPS pages” (ترجمة) «تدفع Google إلى وقف زحف صفحات HTTPS» تمامًا. ومع خفض CA/Browser Forum الحد الأقصى للصلاحية إلى 47 يومًا بحلول 2029، صار التجديد الآلي إلزاميًا. يوضح محور HTTPS أن شهادة DV المجانية تحصل على الإشارة نفسها التي تحصل عليها OV/EV؛ وهنا تأتي المعالجة الكاملة لذلك.

يوضح محور HTTPS أن HTTPS ليس أكثر من إشارة ترجيح، وأن Google يتحقق من المخطط لا الشهادة، وأن شهادة DV مجانية تكسب الإشارة نفسها كشهادة OV/EV باهظة. تتابع هذه المقالة من حيث توقف ذلك وتتعمق طبقة أخرى — في الشهادة نفسها. لن أعيد مناقشة ما إذا كان HTTPS يساعد الترتيب؛ افترض أنك قرأت المحور. أريد هنا الإجابة عن الأسئلة التي يلمح إليها فقط: ما معنى DV/OV/EV فعليًا، وكيف يعمل نطاق التغطية، ولماذا لا بأس بالشهادات الآلية المجانية، وكيف تنكسر سلاسل الشهادات بطرق تختفي عن اختباراتك، وما يحدث فعلًا للزحف — لا للمستخدمين فقط — حين تفسد الشهادة.

«شهادة SSL» هي في الحقيقة شهادة TLS

SSL مصطلح متقادم لعمليات نشر TLS الحديثة. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 8446: TLS 1.3 تركز إرشادات البحث على HTTPS صالح ومتاح بدل فئة الشهادة التجارية. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

ملاحظة سريعة عن التسمية، ثم أتابع: SSL ‏(Secure Sockets Layer) هو البروتوكول المتقادم؛ وكل ما يصدر اليوم يعمل عبر TLS ‏(Transport Layer Security). بقيت «شهادة SSL» الاسم الدارج — حتى إن نصوص Search Console لدى Google ما زالت تقول «SSL certificate problems». سأستخدم «الشهادة» في بقية المقالة.

عمق التحقق: DV مقابل OV مقابل IV مقابل EV

تصدر الشهادات بمختلف مستويات التحقق، التي تصف مقدار ما فحصته سلطة التصديق (CA) قبل أن تشهد لك. وفق تفصيل SSL.com:

• DV (Domain Validation) هي “the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (ترجمة) «أدنى مستويات التحقق، وتتحقق من أن طالب الشهادة يتحكم في النطاق الذي تحميه.» وهي سريعة ورخيصة أو مجانية، وعادةً مؤتمتة (تثبت تحكمك في النطاق عبر سجل DNS أو ملف تجلبه CA).
• OV (Organization Validation) “verifies the identity of the organization (e.g. a business, nonprofit, or government organization) of the Subject listed in the certificate, along with the location where the organization operates.” (ترجمة) «تتحقق من هوية المؤسسة المدرجة بوصفها Subject في الشهادة وموقع عملها.»
• IV (Individual Validation) “verifies the identity of the individual person listed as the Subject of the certificate.” (ترجمة) «تتحقق من هوية الشخص المدرج بوصفه Subject في الشهادة.»
• EV (Extended Validation)، “like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.” (ترجمة) «تتحقق مثل OV من هوية المؤسسة، لكنها تمثل معيار ثقة أعلى وتتطلب فحوص تحقق أشد.»

هذه هي النقطة المهمة لتحسين محركات البحث: لا يوثّق Google فرقًا في الترتيب بين مستويات التحقق. يثبت المحور أن الإشارة الأساسية تقرأ مخطط URL — وصفها إيليس بأنها تنظر إلى الأحرف الخمسة الأولى قبل URL. مادام HTTPS صالحًا ويعمل، تُعامل شهادات DV وOV وEV بالطريقة نفسها. يعكس فرق السعر جهد التدقيق والمسؤولية لدى CA، لا تفضيل Google — يقول web.dev بوضوح: “different CAs charge different amounts of money for the service of vouching for your public key.” (ترجمة) «تفرض سلطات التصديق المختلفة مبالغ مختلفة مقابل خدمة الشهادة لمفتاحك العام.» المال الإضافي يشتري ثقة موجهة إلى البشر والمؤسسات، لا أكثر.

أما الحجة البشرية المتبقية لـEV فقد تلاشت إلى حد بعيد: اختفت فعليًا المعاملة الخاصة لـEV في شريط عنوان المتصفح. أزال Chrome واجهة اسم الشركة الخضراء بدءًا من Chrome 77 (2019)، ولحقه Firefox 70 في العام نفسه. لذلك لم تعد حجة «يرى العملاء اسم شركتنا في الشريط» التي كانت تبرر سعر EV صالحة في المتصفحات السائدة — تحقق من سلوك المتصفح الحالي إذا كنت تتخذ قرار شراء، لكن هذه الإشارة المرئية غير موجودة حاليًا.

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

عمق التحقق محور واحد. أما نطاق التغطية — أي أسماء المضيفين التي تؤمّنها الشهادة فعليًا — فهو محور منفصل تمامًا. يمكن عادةً إصدار أي نطاق تغطية بدرجة DV أو OV (ولا تُعرض شهادات البدل الشامل عادةً بدرجة EV وفق سياسة CA/B):

• نطاق واحد — يغطي اسم مضيف واحدًا بالضبط، مثل www.example.com.
• بدل شامل — يغطي نمط اسم مضيف بعمق تسمية DNS واحدة. يحدد web.dev الحد بدقة: “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” (ترجمة) «في شهادات البدل الشامل، ينطبق البدل على تسمية DNS واحدة فقط؛ فالشهادة الصالحة لـ*.example.com تعمل مع foo.example.com وbar.example.com، لا مع foo.bar.example.com». وهذه العبارة الأخيرة هي الفخ — لا يغطي البدل الشامل النطاقات الفرعية من المستوى الثاني.
• SAN / متعدد النطاقات (UCC) — قائمة صريحة بأسماء مضيفين محددة ضمن Subject Alternative Names للشهادة. يشير web.dev إلى وجود “options for mapping your key to more than one DNS name, including several distinct names (e.g. all of example.com, www.example.com, example.net, and www.example.net).” (ترجمة) «خيارات لربط مفتاحك بأكثر من اسم DNS، بما فيها أسماء متعددة ومختلفة مثل example.com وwww.example.com وexample.net وwww.example.net». ويمكن لشهادة SAN أن تمتد عبر نطاقات مختلفة تمامًا، ما يفيد عند امتلاك بضعة مواقع مترابطة دون الإفراط في تغطية البدل الشامل.

يختبئ نمط إخفاق تحسين محركات البحث العملي في حد التسمية الواحدة للبدل الشامل. لنفترض أنك تستخدم *.example.com وأنشأ شخص staging.blog.example.com — هذا بعمق تسميتين وخارج البدل، وسيعرض خطأ شهادة أو يعود إلى شهادة غير مطابقة. إذا وصله Google أو مستخدم، فسيواجه شهادة معطلة في صفحة ظننت أنها مغطاة.

فخ آخر: نجاح الاختبار على اسم المضيف الجذري لا يثبت التغطية في كل مكان. يجب أن يطلب العميل اسم المضيف الدقيق ويحصل على شهادة تسميه فعلًا (عبر SNI) — وفي شبكات CDN وموازنات الحمل والاستضافة المشتركة المعتمدة على SNI، قد تقدم الحواف أو المناطق أو الأصول المختلفة خلف النطاق نفسه شهادات مختلفة بصورة مشروعة. اختبر كل اسم مضيف عام مستقلًا بدل افتراض أن نتيجة SSL Labs نظيفة على example.com تشمل www. أو حافة إقليمية أو نطاقًا فرعيًا خلف أصل مختلف.

Let’s Encrypt والإصدار الآلي المجاني

تصدر Let’s Encrypt وغيرها من سلطات التصديق المجانية شهادات DV عبر بروتوكول ACME — حلقة مؤتمتة للطلب والتحدي والإصدار تشغلها عنك برامج مثل Certbot. يخطئ الناس في أمرين هنا:

1. المجاني لا يعني الأضعف. توفر شهادة Let’s Encrypt قوة تشفير TLS نفسها كشهادة مدفوعة، ولأن إشارة Google قائمة على المخطط، تحصل على معاملة الترتيب نفسها تمامًا. المقايضتان الحقيقيتان فقط أنها DV دون تدقيق هوية OV/EV وأن عمرها قصير.
2. العمر القصير ميزة بعد الأتمتة. تعني الشهادات القصيرة نافذة تعرض أصغر إذا اختُرق مفتاح، والأهم أن لا إنسان يحتاج إلى تذكر التجديد. تحول الأتمتة أقصر عمر إلى الأكثر أمانًا.

ستصبح النقطة الثانية مهمة للجميع قريبًا، لا لمستخدمي Let’s Encrypt وحدهم.

التحول في أعمار الشهادات (2026–2029) — أتمت الآن

تقلص الصناعة أعمار الشهادات وفق جدول ثابت. أقر CA/Browser Forum الاقتراع SC-081v3 (أغلق التصويت في 11 أبريل 2025)، مخفضًا الحد الأقصى لصلاحية شهادة TLS على مراحل:

• 398 يومًا اليوم
• 200 يوم من 15 مارس 2026
• 100 يوم من 15 مارس 2027
• 47 يومًا من 15 مارس 2029

تتحرك Let’s Encrypt أيضًا في مسارها الأسرع: وفق تحديث فبراير 2026، تخفض عمر شهادتها الافتراضي على خطوتين خلال العامين التاليين — “from 90 days to 64 days, and then 45 days” (ترجمة) «من 90 يومًا إلى 64 يومًا، ثم 45 يومًا» — مع انتقال توقيت التجديد من قرابة اليوم 60 لشهادة 90 يومًا حاليًا إلى قرابة اليوم 30 عندما تصبح الشهادات 45 يومًا. حل ذلك التحديث محل جدول سابق أكثر تحديدًا؛ فاعتبر مواعيد طرح كل خطوة غير محسومة بعد، وراجع سجل تغييرات Let’s Encrypt قبل الاعتماد على تاريخ محدد.

الخلاصة التشغيلية صريحة: إذا لم يكن تجديدك مؤتمتًا بالفعل، فأصلح ذلك قبل 2027. يتحول إيقاع التجديد اليدوي المقبول عند 398 يومًا إلى انقطاع شبه مضمون عند 47–100 يوم. تلخص تغطية DigiCert للاقتراع الأمر جيدًا — يظل التحقق اليدوي ممكنًا تقنيًا، لكن “doing so would be a recipe for failure and outages.” (ترجمة) «سيكون ذلك وصفة للإخفاق والانقطاعات.» تتوقف الأتمتة عن كونها تحسينًا مرغوبًا وتصبح الخيار العقلاني الوحيد.

إخفاقات سلسلة الشهادات / الشهادة الوسيطة

هذا الجانب قليل الشرح، ولا تغطيه وثائق Google ميكانيكيًا، لذا إليك طريقة عمله الفعلية.

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

الإعداد الخاطئ التقليدي هو خادم يرسل شهادة الطرف فقط ويحذف الوسيطة. وهذا ما يجعله خادعًا: غالبًا ما يظل Chrome المكتبي يعمل لأنه يخزن الشهادات الوسيطة التي صادفها في مواقع أخرى ويملأ الفجوة. فيرى المختبر على حاسوبه قفلًا أخضر ويفترض أن كل شيء سليم. وفي الوقت نفسه تفشل المصافحة تمامًا في متصفحات الجوال وكثير من عملاء API/HTTP والأدوات التي لا تملك الوسيطة المخزنة. إنه خلل «يعمل على جهازي» في طبقة TLS.

لاكتشافه، لا تثق بفحص سريع في Chrome المكتبي. استخدم أداة تبني السلسلة من الصفر:

• يعلّم SSL Labs Server Test صراحةً على مشكلات “extra download” / السلسلة غير المكتملة.
• يعرض openssl s_client -connect example.com:443 -showcerts في سطر الأوامر كل شهادة يرسلها الخادم فعليًا، فتتأكد من وجود الوسيطة.

ما يحدث عندما تكون الشهادة غير صالحة أو منتهية أو موقعة ذاتيًا

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

ما يفعله المستخدمون والمتصفحات. يؤدي إخفاق شهادة قاطع — انتهاء الصلاحية أو التوقيع الذاتي أو عدم تطابق اسم المضيف أو CA غير موثوقة — إلى تحذير حاجز بملء الشاشة، لا عبارة “Not Secure” الهادئة التي يحصل عليها HTTP. يغادر المستخدمون. أفضل حالة موثقة هي دراسة Glenn Gabe بعنوان “A Wolf in Panda’s Clothing” (ترجمة) «ذئب في ثياب Panda» — انهارت زيارات متجر إلكتروني في تاريخ تزامن مع تحديث Google Panda، فافترض المالك وجود عقوبة. كان السبب الحقيقي شهادة منتهية الصلاحية تعرض تحذيرات المتصفح؛ غادر الزوار قبل بلوغ الموقع. قال Gabe: “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.” (ترجمة) «أحيانًا لا تكون مشكلات تحسين محركات البحث مشكلات فيه حقًا. وقد تربك المشكلات التقنية التي تظهر بالتزامن مع تحديثات الخوارزمية.» جُددت الشهادة وتعافت الزيارات خلال نحو ثمانية أيام. تتصرف الشهادات الموقعة ذاتيًا بالطريقة نفسها علنًا — حاجز قاطع؛ لذا تلائم البيئات الداخلية/التطوير/التجريب، ولا تلائم الإنتاج العام أبدًا.

ما يفعله Google. هذه دقة تفوت معظم صفحات المنافسين، وهي أشد أثرًا مما يوحي به القول إن الإشارة قائمة على المخطط. تنص إرشادات Google لتحديد العنوان الأساسي صراحةً على أن الشهادة المعطلة ليست غير مرئية للبحث: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals,” (ترجمة) «يفضل Google صفحات HTTPS على صفحات HTTP المكافئة بوصفها أساسية، إلا عند وجود مشكلات أو إشارات متضاربة»، وتسمي الشهادات السيئة إحدى تلك المشكلات مباشرةً — “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” (ترجمة) «تجنب شهادات TLS/SSL السيئة وعمليات إعادة التوجيه من HTTPS إلى HTTP لأنها تجعل Google يفضل HTTP بشدة. ولا يستطيع تطبيق HSTS تجاوز هذا التفضيل القوي.» أي إن الشهادة المعطلة فعلًا قد تقلب النسخة التي يعاملها Google كأساسية إلى HTTP العادي — أثر حقيقي في ما يظهر في البحث، لا مجرد هامش في ميزانية الزحف.

وبصورة منفصلة، تقول وثائق Search Console إن لإخفاقات الشهادة أثرًا في الزحف أيضًا: فالشهادة غير الصالحة “typically affects an entire site,” (ترجمة) «تؤثر عادةً في موقع كامل»، وتنص على أنه “if a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (ترجمة) «إذا كثرت مشكلات HTTPS في موقع، فقد يدفع ذلك Google إلى وقف زحف صفحات HTTPS». وعندها تحصل عناوين URL المتبقية على وسم “HTTPS not evaluated.” (ترجمة) «لم يُقيَّم HTTPS.» إذن توجد آليتان مختلفتان — انقلاب تفضيل العنوان الأساسي إلى HTTP، وتقييد مستقل لقدرة Google على الزحف — وقد تنتجان العَرَض المرئي نفسه (خروج الصفحات من الفهرس) دون تغيير إشارة ترتيب https:// الأساسية. أصلح الشهادة؛ لا توجد هنا رافعة عامل ترتيب لملاحقتها، ولا إعفاء «الأمر غير ضار لأن المخطط لم يتغير».

تطابق قائمة Google لمحفزات الأخطاء تصنيف الإخفاقات: عدم تطابق اسم المضيف مع أسماء الشهادة — “The host name of your site does not match any of the Subject Names in your SSL certificate” (ترجمة) «لا يطابق اسم مضيف موقعك أيًا من أسماء Subject في شهادة SSL.» — والشهادات التي “not recognized by major web browsers” (ترجمة) «لا تتعرف إليها المتصفحات الرئيسية» (موقعة ذاتيًا، أو CA غير موثوقة، أو تالفة، أو قديمة/لم يبدأ سريانها).

مراقبة انتهاء الصلاحية والتجديد التلقائي

انتهاء الصلاحية هو أكثر إخفاقات الشهادات شيوعًا وأسهلها منعًا، ونطاق أثره غير متماثل — فهو عادةً يعطل الموقع كله دفعة واحدة (Google: “Typically this affects an entire site” (ترجمة) «يؤثر هذا عادةً في موقع كامل») لا صفحةً بعد أخرى. والحل ليس تذكير تقويم أبدًا. أعدّ أتمتة حقيقية:

• ACME / Certbot على خادمك، أو البديل الذي توفره منصتك.
• شهادات يديرها المضيف أو CDN (Cloudflare ومعظم المضيفين المُدارين وكثير من منصات PaaS) تصدر وتجدد عنك تلقائيًا.
• مراقب خارجي للشهادة/وقت التشغيل ينبّه إلى اقتراب انتهاء الصلاحية وإخفاقات المصافحة، بوصفه شبكة أمان حتى مع أتمتة التجديد.

مع انخفاض الأعمار نحو 47 يومًا، تصبح التذكيرات اليدوية غير قابلة للاستمرار حسابيًا — الأتمتة هي النهج الوحيد القابل للتوسع.

إعدادات الشهادات المختلطة عبر النطاقات الفرعية

يختلف هذا عن المحتوى المختلط (صفحة HTTPS تحمّل موارد فرعية عبر HTTP — يغطيه المحور). تعني الشهادات المختلطة أن أجزاء الموقع المختلفة مؤمّنة بشهادات مختلفة على جداول أو منصات مختلفة. النمط الشائع: نطاقك الأساسي لديه شهادة قوية، لكن blog.example.com يعمل على منصة أخرى بشهادة تنتهي وفق جدولها؛ أو لم يغطِّ حد التسمية الواحدة للبدل الشامل نطاقًا تسويقيًا فرعيًا على CDN منفصلة؛ أو تعطّل الاستضافة متعددة المستأجرين المعتمدة على SNI تجديد نطاق فرعي بصمت بينما يبدو النطاق الرئيسي سليمًا في الفحص السريع.

الدرس: القفل الصالح على صفحتك الرئيسية لا يخبرك بشيء عن التغطية في مواضع أخرى. احصر النطاقات الفرعية، وتأكد من أن كل مضيف لديه تغطية شهادة صالحة ومراقبة (بشهادته أو بدل شامل يصل إليه أو شهادة SAN تسرده)، ولا تعتمد على فحص SSL Labs لاسم مضيف واحد لاعتماد الموقع كله.

الخرافات الشائعة

• *«الشهادة المدفوعة أو EV ترتب أفضل من شهادة DV مجانية.» لا — الإشارة قائمة على المخطط؛ وعمق التحقق غير مرئي لـGoogle.
• *«شهادات البدل الشامل تغطي كل النطاقات الفرعية، ومنها الفرعية المتداخلة.» لا — تسمية DNS واحدة فقط؛ لا يغطي *.example.com ‏foo.bar.example.com.
• *«الشهادة المنتهية تضر ترتيبي مباشرةً.» ليس عبر إشارة الترتيب الأساسية — لكنها قد تقلب تفضيل Google المعتاد لـHTTPS على HTTP إلى HTTP (ولا يتجاوز HSTS ذلك)، وقد تدفعه كثرة مشكلات HTTPS بصورة منفصلة إلى وقف زحف صفحات HTTPS تمامًا. كلاهما أثر حقيقي، ولا يمر أيهما عبر إشارة الترتيب نفسها.
• *«شهادات Let’s Encrypt أقل جودة من المدفوعة.» لا — التشفير نفسه ومعاملة الترتيب نفسها؛ الفرق هو تحقق DV فقط والأعمار القصيرة التي ستصبح معيار الصناعة قريبًا.
• *«إذا عرضت الصفحة الرئيسية قفلًا صالحًا، فكل شهادات موقعي سليمة.» لا — تحمل النطاقات الفرعية شهادات منفصلة بجداول مختلفة.
• *«أخطاء السلسلة نادرة أو قديمة.» لا — هي شائعة في أي بنية تقدم شهادة الطرف فقط، ويخفيها تخزين Chrome المكتبي عن المختبر.

هذه المعالجة المتعمقة على مستوى الشهادة ضمن محور HTTPS؛ أما دليل الترحيل والمحتوى المختلط وHSTS فابدأ من هناك.

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

• لا يوثّق Google فرقًا في الترتيب بين فئات الشهادات. مادام HTTPS صالحًا، تُعامل DV وOV وIV وEV بالطريقة نفسها، وتساوي شهادة Let’s Encrypt المجانية المدفوعة. الشهادة الأغلى تشتري ثقة بشرية/مؤسسية، لا تحسين محركات البحث. جون مولر: “this does not ‘Boost your website’s SEO’, sorry.” (ترجمة) «هذا لا ‘يعزز تحسين محركات البحث لموقعك’، آسف.»
• محوران مستقلان: عمق التحقق (DV = التحكم في النطاق ← OV/IV = الهوية ← EV = تدقيق مؤسسي صارم) ونطاق التغطية (نطاق واحد/بدل شامل/SAN). لا يرى Google أيًا منهما.
• يغطي البدل الشامل تسمية DNS واحدة فقط. يغطي *.example.com ‏foo.example.com لكن ليس foo.bar.example.com. تسرد شهادات SAN أسماء مضيفين صريحة وقد تمتد عبر نطاقات.
• اختفت واجهة EV في المتصفح (Chrome 77 / Firefox 70، عام 2019)، فزالت ميزتها البشرية الأخيرة.
• الإصدار الآلي المجاني (ACME/Certbot) ليس تنازلًا — التشفير والترتيب نفسيهما. والأعمار القصيرة ميزة بعد الأتمتة.
• تحول الأعمار: يخفض اقتراع CA/B Forum ‏SC-081v3 الحد الأقصى 398 ← 200 (مارس 2026) ← 100 (مارس 2027) ← 47 يومًا (مارس 2029)؛ وتخفض Let’s Encrypt افتراضيها منفصلًا من 90 ← 64 ← 45 يومًا خلال العامين التاليين (وفق تحديث فبراير 2026؛ مواعيد الخطوات غير محسومة). أتمت التجديد الآن.
• تختفي إخفاقات السلسلة عنك: يرسل الخادم شهادة الطرف فقط ويحذف الوسيطة؛ يخزنها Chrome المكتبي فيعمل، ويفشل عملاء الجوال/API. شخّص عبر SSL Labs أو openssl s_client -showcerts.
• المستخدمون مقابل Google عند تعطل الشهادة: يتلقى المستخدمون تحذيرًا بملء الشاشة ويغادرون (حالة Gabe التي خُلط فيها بين شهادة منتهية وPanda)؛ لا تتغير إشارة الترتيب الأساسية، لكن الشهادة المعطلة قد تقلب تفضيل العنوان الأساسي من HTTPS إلى HTTP (ولا يتجاوزه HSTS)، وقد “stop crawling your HTTPS pages” (ترجمة) «توقف زحف صفحات HTTPS» — آليتان مختلفتان وعَرَض مرئي واحد.
• يعطل انتهاء الصلاحية الموقع كله دفعة واحدة؛ أتمت التجديد وراقبه. وتعني الشهادات المختلطة عبر النطاقات الفرعية (غير المحتوى المختلط) أن قفل الصفحة الرئيسية لا يثبت تغطيتها.

الوثائق الرسمية

وثائق المصادر الأولية عن الشهادات من محركات البحث وهيئات المعايير.

Google

• تقرير HTTPS (مساعدة Search Console) — يتضمن عبارات “invalid certificate” (ترجمة) «شهادة غير صالحة»؛ و*“affects an entire site,”* (ترجمة) «يؤثر في موقع كامل»؛ و*“stop crawling your HTTPS pages”* (ترجمة) «يوقف زحف صفحات HTTPS».
• مشكلات شهادة SSL (مساعدة Search Console) — أخطاء عدم تطابق اسم المضيف والشهادة غير الموثوقة/الموقعة ذاتيًا.
• فعّل HTTPS على خوادمك (web.dev) — سلطات التصديق وطلبات CSR ونطاق البدل الشامل وربط الأسماء المتعددة.
• دمج عناوين URL المكررة (Google Search Central) — نص تفضيل العنوان الأساسي: يفضل Google HTTPS “except when there are issues or conflicting signals” (ترجمة) «إلا عند وجود مشكلات أو إشارات متضاربة»، ويسمي الشهادات السيئة إحدى تلك المشكلات، مشيرًا إلى أن HSTS لا يستطيع تجاوز التفضيل.

سلطات التصديق والمعايير

• شهادات DV وOV وIV وEV ‏(SSL.com) — تعريفات مستويات التحقق.
• Let’s Encrypt — سلطة شهادات DV مجانية ومؤتمتة.
• بروتوكول ACME / Certbot — عميل الأتمتة الذي تستخدمه معظم الإعدادات ذاتية الاستضافة.
• أعمار شهادات أقصر وحدود المعدل (Let’s Encrypt) — خطة Let’s Encrypt الحالية لتقصير الأعمار.
• CA/Browser Forum — الهيئة التي تحدد الحدود القصوى لصلاحية الشهادات (الاقتراع SC-081v3).

اقتباسات من المصدر

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

Google — أخطاء الشهادات في Search Console

• “The HTTPS URL has an invalid SSL certificate. Typically this affects an entire site.” (ترجمة) «يحتوي عنوان HTTPS على شهادة SSL غير صالحة. يؤثر هذا عادةً في موقع كامل.» — مساعدة Google Search Console، تقرير HTTPS. الانتقال إلى الاقتباس
• “If a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (ترجمة) «إذا كثرت مشكلات HTTPS في موقع، فقد يدفع ذلك Google إلى وقف زحف صفحات HTTPS.» — مساعدة Google Search Console، تقرير HTTPS. أهم سطر في هذا الموضوع: أثر الزحف الحقيقي للشهادة المعطلة. الانتقال إلى الاقتباس
• “The host name of your site does not match any of the Subject Names in your SSL certificate.” (ترجمة) «لا يطابق اسم مضيف موقعك أيًا من أسماء Subject في شهادة SSL.» — مساعدة Google Search Console، مشكلات شهادة SSL. الانتقال إلى الاقتباس
• “Your site uses an SSL certificate which is not recognized by major web browsers.” (ترجمة) «يستخدم موقعك شهادة SSL لا تتعرف إليها المتصفحات الرئيسية.» — مساعدة Google Search Console، مشكلات شهادة SSL. الانتقال إلى الاقتباس

Google — تفضيل العنوان الأساسي والشهادات السيئة

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” (ترجمة) «يعتمد Google صفحة HTTPS عنواناً أساسياً بدلاً من نظيرتها HTTP، ما لم توجد مشكلة أو إشارة متعارضة». / “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” (ترجمة) «ابتعد عن شهادات TLS/SSL الرديئة وعن التحويل من HTTPS إلى HTTP؛ فكلاهما يرجّح HTTP بقوة لدى Google، ولا يلغي HSTS هذا الترجيح». — Google Search Central، دمج عناوين URL المكررة. قراءة المصدر

Google / web.dev — نطاق الشهادة وتكلفتها

• “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” (ترجمة) «لا يغطي البدل الشامل سوى مستوى DNS واحداً؛ لذلك تشمل شهادة *.example.com كلاً من foo.example.com وbar.example.com، لكنها لا تشمل foo.bar.example.com». — web.dev، فعّل HTTPS على خوادمك. الانتقال إلى الاقتباس
• “Different CAs charge different amounts of money for the service of vouching for your public key.” (ترجمة) «تتقاضى سلطات التصديق مبالغ مختلفة لقاء خدمة التصديق على مفتاحك العام». — web.dev، فعّل HTTPS على خوادمك. الانتقال إلى الاقتباس

SSL.com — مستويات التحقق

• “Domain Validation (DV) is the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (ترجمة) «التحقق من النطاق (DV) أدنى مستويات التحقق، ويتحقق من أن طالب الشهادة يتحكم في النطاق الذي تحميه.» الانتقال إلى الاقتباس
• “Extended Validation (EV), like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.” (ترجمة) «يتحقق التحقق الممتد (EV)، مثل OV، من هوية المؤسسة. لكنه يمثل معيار ثقة أعلى ويتطلب فحوص تحقق أشد.» الانتقال إلى الاقتباس

جون مولر، Google Search Relations (رد على وسائل التواصل نقله Search Engine Journal، مايو 2023)

• “@EncryptedFence this does not ‘Boost your website’s SEO’, sorry.” (ترجمة) «@EncryptedFence هذا لا ‘يعزز تحسين محركات البحث لموقعك’، آسف.» مقتبس من رد مولر على Mastodon عبر Search Engine Journal — تأييد على مستوى INDUSTRY للصياغة الرسمية القائمة على المخطط، وليس صفحة مملوكة لـGoogle. تحقق من المنشور الأصلي عند الاقتباس المباشر. قراءة التغطية

Glenn Gabe، ‏GSQi (دراسة حالة شهادة منتهية، سبتمبر 2013)

• “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.” (ترجمة) «قد يبدو الخلل مشكلة SEO وهو ليس كذلك؛ فتزامن عطل تقني مع تحديث خوارزمية قد يضلل التشخيص». دراسة حالة من الصناعة؛ تفاصيل واجهة المتصفح لعام 2013 قديمة، لكن الدرس التشخيصي دائم. قراءة دراسة الحالة

أي شهادة ينبغي أن أحصل عليها؟

تابع من الأعلى إلى الأسفل. يحسم السؤالان الأولان كل ما يهم؛ والباقي حساب نطاق التغطية.

1. هل تحتاج إلى أن يرتب Google الموقع؟ هذا يتحقق أصلًا بمجرد استخدام https:// — تمنحك أي شهادة صالحة إشارة الترتيب المطابقة. لذلك لا يوجهك هذا السؤال أبدًا إلى شهادة أغلى. تابع.

2. هل تحتاج إلى عرض هوية مؤسسية موثقة للبشر (وهل يفرضها القانون/الامتثال)؟

• لا (الأغلبية الساحقة — المدونات ومواقع المحتوى ومعظم التجارة الإلكترونية) ← شهادة DV. مجانية من Let’s Encrypt، مؤتمتة، وانتهى.
• نعم (الخدمات المصرفية وبعض السياقات المنظمة/المؤسسية التي يفرض فيها فريق الامتثال OV/EV) ← OV (أو EV إذا نص متطلب محدد عليها). اعلم أن EV لم تعد تعرض مؤشرًا خاصًا في المتصفح (Chrome 77+/Firefox 70+)، فأنت تدفع مقابل سجل التدقيق لا شارة مرئية.

3. كم اسم مضيف تؤمّن؟ (نطاق التغطية — مستقل عن الخطوة 2)

• اسم مضيف واحد (www.example.com فقط) ← شهادة نطاق واحد.
• نطاقات فرعية كثيرة من المستوى الأول تحت نطاق واحد (shop. وblog. وapp. ضمن example.com) ← بدل شامل (*.example.com). لكن تأكد أن لا شيء منها من المستوى الثاني (api.staging.example.com) — فلن يغطيه البدل.
• قائمة مختلطة محددة قد تمتد عبر نطاقات (example.com + example.net + brand.io) ← شهادة SAN / متعددة النطاقات (UCC) تسرد كل اسم.
• نطاقات فرعية من المستوى الثاني لا يصل إليها البدل ← إما بدل شامل ثانٍ على ذلك المستوى، أو إضافتها صراحةً إلى SAN.

4. أي خوارزمية مفتاح، وكم حافة/أصل يخدم اسم المضيف فعلًا؟ المفاضلة بين RSA وECDSA تتعلق بالأمان وتوافق العملاء، لا الترتيب — بعض العملاء القدماء أو المضمّنين لا يدعمون ECDSA، فتحقق مما توفره CDN أو موازن الحمل قبل الاختيار. وإذا واجه اسم المضيف أكثر من حافة أو منطقة أو أصل (CDN أو استضافة مشتركة بـSNI أو عدة موازنات حمل)، فاختبر كل مسار مستقلًا؛ النتيجة النظيفة على أحدها لا تؤكد تغطية البقية.

5. هل سيكون التجديد مؤتمتًا؟

• نعم ← جيد؛ الأعمار القصيرة مناسبة (وتقصر أكثر — حد أقصى 47 يومًا بحلول 2029).
• لا ← أصلح ذلك أولًا. التجديد اليدوي هش بالفعل وسيغدو غير عملي مع تقصير الأعمار. استخدم ACME/Certbot أو شهادة يديرها المضيف/CDN.

أتشخّص خطأ شهادة مباشرًا بدلًا من ذلك؟ ما العَرَض؟

• يعمل في Chrome المكتبي ويفشل في الجوال/الأدوات ← غالبًا خطأ وسيطة مفقودة (سلسلة). اختبر عبر SSL Labs أو openssl s_client -showcerts وثبّت السلسلة كاملة.
• الموقع كله يحذر/سقط فجأة ← تحقق من انتهاء الصلاحية أولًا (يعطل الموقع كله دفعة واحدة).
• نطاق فرعي واحد يحذر والباقي سليم ← فجوة شهادة مختلطة/تغطية — لا تغطيه شهادته أو حد التسمية الواحدة للبدل.
• يسمي التحذير موقعًا خاطئًا ← عدم تطابق اسم المضيف (لا تتضمن Subject Names في الشهادة المضيف المقدم).

قائمة تحقق من سلامة الشهادة

مرور للتأكد من أن شهاداتك صالحة ومغطاة ولن تنتهي بصمت:

• يُقدم كل اسم مضيف عام (الجذر وwww وكل نطاق فرعي) عبر شهادة صالحة موثوقة — لا الصفحة الرئيسية فقط.
• ثُبتت السلسلة الكاملة (الطرف والوسيطة) — وتُحقِّق منها عبر SSL Labs أو openssl s_client -showcerts، لا فحص Chrome المكتبي.
• التجديد مؤتمت (ACME/Certbot أو مُدار من المضيف/CDN أو PaaS) — ولا يوجد تجديد قائم على تذكير بشري.
• ينبه مراقب شهادة/وقت تشغيل إلى اقتراب الانتهاء وإخفاقات المصافحة كشبكة أمان.
• لا عدم تطابق لأسماء المضيفين — كل مضيف مقدم مدرج ضمن Subject Alternative Names للشهادة (أو يغطيه بدل يصل إليه).
• فُحصت البدائل الشاملة وفق حد التسمية الواحدة — ولا تقع نطاقات فرعية من المستوى الثاني (a.b.example.com) بصمت خارج *.example.com.
• لا شهادات موقعة ذاتيًا على أي مضيف إنتاج عام (مناسبة للتطوير/التجريب فقط).
• اخترت عمق التحقق وفق حاجة بشرية/امتثال لا توقع لتحسين محركات البحث (DV كافية للترتيب؛ OV/EV تشتريان الهوية لا الترتيب).
• روجع تقرير HTTPS في Google Search Console بحثًا عن علامتي “invalid certificate” (ترجمة) «شهادة غير صالحة» و”HTTPS not evaluated” (ترجمة) «لم يُقيّم HTTPS».
• حُصرت النطاقات الفرعية على منصات/CDN مختلفة — ولكل منها تجديد مراقب.

النماذج الذهنية

1. محوران، لا محور واحد. للشهادة عمق تحقق (DV/OV/IV/EV) ونطاق تغطية (مفرد/بدل شامل/SAN). وهما مستقلان — فقد تملك بدلًا شاملًا DV أو نطاقًا واحدًا OV. قرر كلًا منفصلًا، وتذكر أن Google لا يرى أيًا منهما.

2. إشارة الترتيب لا تميز فئات الشهادات. يمنحك استخدام https:// بشهادة صالحة عاملة الإشارة الضئيلة نفسها بصرف النظر عن جهة الإصدار أو السعر أو مستوى التحقق. لذلك فالسؤال «أي شهادة تساعد تحسين محركات البحث؟» خطأ فئوي بين المستويات — لا تفوق واحدة غيرها. وهذا لا يعني أن الصلاحية نفسها غير مرئية — انظر 3.

3. مشكلات الشهادة طوارئ في تفضيل العنوان الأساسي والوصول بالزحف وتجربة المستخدم — وليست مشكلة فئة ترتيب أبدًا. عند تعطل الشهادة، يغادر المستخدمون أمام تحذير المتصفح؛ وقد ينقلب تفضيل Google المعتاد لـHTTPS على HTTP إلى HTTP (ولا يتجاوزه HSTS)؛ وقد تجعله كثرة مشكلات HTTPS يوقف زحف صفحات HTTPS تمامًا. لا يمر شيء من ذلك عبر إشارة الترتيب نفسها — لكن «المخطط لم يتغير» ليس سببًا لعد الشهادة المعطلة غير ضارة. أصلح الشهادة؛ لا يوجد عامل ترتيب لملاحقته.

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

5. قفل الصفحة الرئيسية يثبت اسم مضيف واحدًا، ولا شيء أكثر. تختلف التغطية وجداول الانتهاء والمنصات عبر النطاقات الفرعية. احصر كل مضيف وراقبه — ولا تعمم من قفل أخضر واحد.

6. اختبر السلسلة، لا حاسوبك المحمول. يخزن Chrome المكتبي الوسائط ويضللك. تحقق ببنّاء نظيف (SSL Labs أو openssl s_client) حتى لا يختبئ خطأ الوسيطة المفقودة.

شهادات SSL/TLS — ورقة مرجعية

عمق التحقق (ما تحققت منه CA)

نطاق التغطية (أسماء المضيفين التي يؤمّنها)

تحول الأعمار (الحد الأقصى لصلاحية CA/Browser Forum)

عند تعطل شهادة

حقائق سريعة

• DV المجانية (Let’s Encrypt) = التشفير والترتيب نفسيهما كالمدفوعة.
• تقرأ إشارة Google المخطط، لا الشهادة.
• قد تجعل كثرة مشكلات HTTPS ‏Google يوقف زحف صفحات HTTPS.
• أتمت التجديد عبر ACME/Certbot أو شهادة يديرها المضيف/CDN.

افحص شهادة وسلسلتها الكاملة

أكثر الأوامر فائدة لتشخيص الشهادات. يطبع -showcerts كل شهادة يرسلها الخادم فعليًا — أسرع طريقة لاكتشاف وسيطة مفقودة.

macOS / Linux

# Show the full chain the server sends (leaf + intermediates)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Just the expiry dates (notBefore / notAfter)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

# The hostnames the cert actually covers (Subject Alternative Names)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

تضبط العلامة -servername ‏SNI — وهذا مهم في الاستضافة المشتركة/عبر CDN حيث يقدم عنوان IP واحد عدة شهادات، كي تختبر الشهادة الصحيحة.

Windows (PowerShell) — تحقق من انتهاء الصلاحية والأسماء المغطاة

# Pull the served certificate and read its expiry + Subject Alternative Names
$req = [Net.HttpWebRequest]::Create("https://example.com")
$req.GetResponse().Dispose()
$cert = $req.ServicePoint.Certificate
$cert2 = [System.Security.Cryptography.X509Certificates.X509Certificate2]$cert
"Expires: " + $cert2.NotAfter
$cert2.Extensions | Where-Object { $_.Oid.FriendlyName -eq "Subject Alternative Name" } |
  ForEach-Object { $_.Format($true) }

وحدة تحكم Chrome DevTools — علّم عناوين URL غير الآمنة للموارد الفرعية

الصق في Console على أي صفحة لسرد موارد http:// الفرعية التي ما زال HTML يشير إليها (فحص سريع للمحتوى المختلط أثناء تدقيق الشهادات):

[...document.querySelectorAll('[src],[href]')]
  .map(el => el.getAttribute('src') || el.getAttribute('href'))
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('insecure:', u));

للتغطية عبر كل أسماء المضيفين، يتفوق مدقق خارجي (SSL Labs) على كتابة سكربت لكل مضيف — لكن هذه هي الفحوص السريعة للمضيف الذي أمامك.

الأنماط المضادة في الشهادات

أنماط إخفاق أراها مرارًا:

شراء EV/OV «لتحسين محركات البحث». لا يستطيع Google رؤية عمق التحقق. دفع المزيد مقابل منفعة ترتيب غير موجودة هدر محض. اشتر عمق تحقق فقط لسبب حقيقي يتعلق بثقة البشر أو الامتثال.

التحقق من الشهادة في Chrome المكتبي فقط. يخزن Chrome الوسائط، وقد يعرض قفلًا أخضر فوق سلسلة معطلة تفشل في كل مكان آخر. تحقق دائمًا عبر بانٍ نظيف (SSL Labs أو openssl s_client -showcerts).

تذكيرات التجديد اليدوية. إدخال في التقويم ليس نظام تجديد. فهو يعطل الموقع كله دفعة واحدة عندما يكون شخص في إجازة — ويزداد الأمر سوءًا كل عام مع تقلص الأعمار نحو 47 يومًا. أتمت.

افتراض أن البدل الشامل يغطي كل ما تحت النطاق. يتوقف *.example.com عند تسمية DNS واحدة. لا يغطي staging.api.example.com وسيعرض أخطاء لا يلاحظها أحد حتى يصله مستخدم أو Googlebot.

فحص الصفحة الرئيسية وحدها. للنطاقات الفرعية على منصات/CDN أخرى شهاداتها وجداولها الخاصة. لا يقول قفل صالح عند الجذر شيئًا عن انتهاء blog. أو نطاق تسويقي فرعي بصمت.

شهادات موقعة ذاتيًا في الإنتاج العام. تعرض حاجز متصفح قاطعًا وتعلّمها معظم أدوات التحقق وبرامج الزحف كفشل. مناسبة للبيئات الداخلية/التطوير/التجريب؛ لا لموقع عام أبدًا.

معاملة الشهادة المعطلة كمشكلة فئة ترتيب، أو كأمر غير ضار. ليست رافعة فئة ترتيب، لكنها ليست غير ضارة: قد تقلب تفضيل Google للعنوان الأساسي من HTTPS إلى HTTP، وتطلق خنقًا للوصول بالزحف، وتسحق التحويلات بسبب مغادرة المستخدمين. أصلح الشهادة؛ لا تطارد عوامل الترتيب، ولا تفترض أن «المخطط لم يتغير» يعني أن شيئًا لم يحدث.

إجراء التشغيل القياسي لتجديد الشهادة ونشرها

1. احتفظ بحصر لأسماء المضيفين. سجل الجذر وwww والنطاقات الفرعية والأعمق ونقاط نهاية CDN أو موازن الحمل وجهة إصدار الشهادة ونوع التغطية ومالك التجديد ومسار الأتمتة.
2. راقب الانتهاء مستقلًا عن جهة الإصدار. نبّه مبكرًا بما يكفي للتحقيق في فشل الأتمتة، ووائم الجدول مع العمر الفعلي للشهادة؛ فتذكير التقويم وحده ليس نظام تجديد.
3. اختبر التجديد التلقائي. تأكد من أن سير ACME أو المضيف أو CDN يستطيع الطلب والتحقق والتثبيت والتفعيل وإعادة تحميل كل عملية تقديم تحتفظ بالشهادة القديمة في الذاكرة، دون خطوات يدوية.
4. تحقق من الشهادة المرشحة. افحص أسماء المضيفين/SAN المطلوبة وعمق البدل وجهة الإصدار ونافذة الصلاحية والسلسلة الوسيطة الكاملة قبل الإنتاج.
5. انشر عبر كل طبقة تقديم. حدّث كل حافة ووكيل وموازن حمل وأصل ينهي TLS؛ ولا تفترض أن نجاح نقطة نهاية واحدة يغطي كل المناطق أو الأسماء.
6. اختبر خارجيًا. استخدم مدقق سلسلة نظيفًا وopenssl s_client مع SNI على مضيفين ممثلين. ضمّن عملاء لا يشاركون الوسائط المخزنة في المتصفح.
7. أغلق الحلقة. تأكد من أن المراقبة ترى تاريخ الانتهاء الجديد، وسجل النشر، وتحقق من أي نقطة نهاية ما زالت تقدم الشهادة السابقة.

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

عدة أدوات لفحص الشهادات

• SSL Labs Server Test — تحقق خارجي من الشهادة المقدمة والسلسلة وتغطية اسم المضيف ودعم البروتوكولات والفروق بين نقاط النهاية.
• openssl s_client — افحص بالضبط ما يقدمه اسم مضيف مع SNI واطبع السلسلة كاملة؛ واقرنه بـopenssl x509 للتواريخ وSubject Alternative Names.
• عارض شهادات المتصفح وDevTools — أعد إنتاج خطأ اسم المضيف والثقة والانتهاء الظاهر للمستخدم على العميل المتأثر.
• مراقبة مستقلة للشهادات — نبّه على كل اسم مضيف محصور حتى حين تزعم جهة الإصدار أو CDN أن التجديد تلقائي.
• تقارير HTTPS في Google Search Console — راقب مشكلات تقديم HTTPS الأوسع؛ واستخدم أدوات الشهادات لتشخيص نقطة النهاية.

اختبر بحسب اسم المضيف، لا عنوان IP أو الصفحة الرئيسية فقط. قد تقدم البنية المشتركة شهادة مختلفة بحسب SNI أو المنطقة أو عقدة الحافة.

اختبارات إصدار الشهادة

الاختبار 1: تغطية اسم المضيف والسلسلة

• الغرض: إثبات أن كل اسم مضيف عام يتلقى شهادة موثوقة يُسمى فيها فعلًا.
• الطريقة: شغّل SSL Labs وopenssl s_client -servername على الجذر وwww وكل فئة نطاق فرعي والمضيفين الأعمق الذين لا يغطيهم بدل ذو تسمية واحدة.
• النتيجة المتوقعة: يطابق اسم المضيف SAN، وتكون السلسلة كاملة، ويتحقق منها عميل نظيف دون توفير وسيطة مخزنة.
• محفز الفشل: عدم تطابق الاسم، أو شهادة طرف موقعة ذاتيًا، أو وسيطة مفقودة، أو شهادة مختلفة على نقطة نهاية.
• الإجراء التالي: صحح تغطية الشهادة أو سلسلة التقديم، وأعد النشر، ثم أعد اختبار كل نقطة نهاية متأثرة.

الاختبار 2: بروفة أتمتة التجديد

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

الاختبار 3: فحص العميل بعد النشر

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

اختبر نفسك: شهادات SSL/TLS

خمسة أسئلة سريعة عن علاقة الشهادات بتحسين محركات البحث. اختر إجابة لكل سؤال، ثم تحقق.

موارد تستحق وقتك

محاضراتي

• الاحتياط أفضل مع HTTPS — مؤتمر SMX East 2016 (SlideShare) — معالجتي المتعمقة لـTLS وإخفاقات الشهادات/التنفيذ الشائعة ومزالق الترحيل. وفيها أيضًا نبهت إلى خطر إلغاء الفهرسة في TLS SNI مع Bing وBaidu — في العام نفسه الذي أبلغ فيه Search Engine Land عن انخفاضات حقيقية في زحف/ترتيب Bing من عمليات الانتقال إلى HTTPS القائمة على SNI. (ينطبق إخلاء المسؤولية الدائم: هذا فهمي لهذه الأنظمة، وإحصاءات الاعتماد في العرض من 2016 — فلا تستشهد بها كأرقام حالية.)

كتاباتي ذات الصلة

• The Beginner’s Guide to Technical SEO — موضع الشهادات وHTTPS ضمن الصورة التقنية الأوسع.

من الآخرين (رسمي / موثوق)

• تقرير HTTPS ومشكلات شهادة SSL من Google — القائمة الحاسمة لأخطاء الشهادات التي يعرضها Search Console ومعانيها.
• فعّل HTTPS على خوادمك (web.dev) من Google — سلطات التصديق وطلبات CSR ونطاق البدل الشامل/الأسماء المتعددة، مباشرةً من Google.
• دمج عناوين URL المكررة من Google — إرشادات تفضيل العنوان الأساسي التي تسمي الشهادات السيئة سببًا لتفضيل Google ‏HTTP على HTTPS.
• SSL Labs Server Test — يقيّم إعداد TLS، والأهم أنه يعلّم سلاسل الشهادات غير المكتملة.

من أنحاء الصناعة

• DV, OV, IV, and EV Certificates ‏(SSL.com) — تعريفات واضحة من سلطة تصديق لكل مستوى تحقق.
• A Wolf in Panda’s Clothing — How An Expired SSL Certificate Could Impact Organic Search Traffic ‏(Glenn Gabe، ‏GSQi) — دراسة الحالة المسماة لشهادة منتهية خُلط بينها وبين عقوبة Panda.
• Google: شهادة SSL لا تعزز تحسين محركات البحث ‏(Search Engine Journal) — رد جون مولر القاطع بأن الشهادة لا تمنح الموقع دفعة في SEO.
• أعمار شهادات أقصر وحدود المعدل ‏(Let’s Encrypt) — تحديث سلطة التصديق المجانية الحالي في فبراير 2026 عن خفض العمر الافتراضي من 90 إلى 64 ثم 45 يومًا.
• TLS Certificate Lifetimes Will Officially Reduce to 47 Days ‏(DigiCert) — جدول مراحل اقتراع CA/Browser Forum ‏SC-081v3.
• أخطاء SSL التي تؤثر في تحسين محركات البحث ‏(SISTRIX) — عرض عملي لمشكلات اسم المضيف والانتهاء والبروتوكول والمحتوى المختلط.
• Certbot ‏(EFF) — عميل ACME القياسي لأتمتة إصدار الشهادات وتجديدها.

إحصاءات تستحق الاستشهاد

• ينخفض الحد الأقصى لعمر الشهادة إلى 47 يومًا بحلول 2029. يخفض اقتراع CA/Browser Forum ‏SC-081v3 (أغلق التصويت في 11 أبريل 2025) الحد الأقصى على مراحل من 398 يومًا ← 200 (مارس 2026) ← 100 (مارس 2027) ← 47 (مارس 2029) — وهو الرقم الذي يجعل التجديد الآلي إلزاميًا. المصدر
• تخفض Let’s Encrypt عمرها الافتراضي من 90 إلى 64 ثم 45 يومًا. وفق تحديثها في فبراير 2026، تنتقل سلطة التصديق المجانية على خطوتين خلال العامين التاليين؛ ولم يحدد الإعلان مواعيد الطرح الدقيقة لكل خطوة. المصدر
• الشهادة المعطلة “typically affects an entire site.” (ترجمة) «تؤثر عادةً في موقع كامل.» هذه صياغة Google لنطاق الأثر — نادرًا ما تكسر إخفاقات الانتهاء والسلسلة صفحة واحدة؛ بل تكسر كل شيء دفعة واحدة. المصدر
• قد توقف كثرة مشكلات HTTPS زحف Google لصفحات HTTPS. أثر في الوصول بالزحف منفصل عن إشارة الترتيب الأساسية — ومنفصل عن انقلاب تفضيل Google للعنوان الأساسي نحو HTTP الذي قد تطلقه شهادة سيئة أيضًا. المصدر
• قد تتغلب الشهادة السيئة على تفضيل Google ‏HTTPS للعنوان الأساسي، ولا يستطيع HSTS منع ذلك. تسمي إرشادات Google شهادات TLS/SSL السيئة سببًا لتفضيل نسخة HTTP “very strongly”. (ترجمة) «بشدة كبيرة».* المصدر

سجل التغييرات