لو موقعك بيطلّع للزوار رسالة NET::ERR_CERT_AUTHORITY_INVALID، خلّي بالك من حاجة واحدة قبل أي خطوة: المشكلة في السيرفر بتاعك، مش في متصفح الزائر. ومهما قريت نصايح عن حذف الكاش وتصحيح ساعة الجهاز، دي حلول للزائر لا لصاحب الموقع. الكلام اللي جاي مكتوب لصاحب الموقع، وفي 90% من الحالات السبب واحد من تلاتة، وكلهم بيتحلّوا في أقل من نص ساعة بدون أدوات خاصة.
ماذا يعني هذا الخطأ فعلًا
كل شهادة أمان (SSL) تصدر عن جهة إصدار شهادات (Certificate Authority – CA) تتفق المتصفحات على الثقة بها، مثل Let’s Encrypt أو DigiCert أو Sectigo. الرسالة تعني أن المتصفح لم يستطع إكمال سلسلة الثقة: إما أنه لا يجد الجهة التي أصدرت شهادتك، أو أن الشهادة موقّعة من السيرفر نفسه (Self-Signed) لا من جهة حقيقية.
انتبه للفرق بين هذا الخطأ وخطأ عدم تطابق النطاق NET::ERR_CERT_COMMON_NAME_INVALID. أصحاب المواقع يخلطون بينهما كثيرًا بعد نقل الاستضافة، والسبب والحل مختلفان تمامًا.
السبب الأول: الشهادة الوسيطة مفقودة
هذا السبب الأكثر شيوعًا بفارق كبير. شهادتك ليست موقّعة مباشرة من شهادة جذرية مثبتة في كل متصفح، بل موقّعة من شهادة وسيطة (Intermediate Certificate)، والوسيطة بدورها موقّعة من الجذرية. إذا كان سيرفرك يرسل شهادتك فقط ويتجاهل الوسيطة، فلن يستطيع المتصفح إكمال السلسلة، مع أن شهادتك صحيحة تمامًا.
كيف تفحص:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -issuer -dates
إذا توقف الأمر أو أعطى خطأ، أو أظهر تشغيل أوسع لـ openssl s_client النتيجة Verify return code: 21 (unable to verify the first certificate)، فالسلسلة ناقصة.
كيف تصلح:
- Nginx — يجب أن يشير الإعداد إلى ملف السلسلة الكاملة لا إلى الشهادة المجردة:
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;وليسcert.pem. ثم أعد التحميل بـsudo nginx -t && sudo systemctl reload nginx. - Apache — تأكد من ضبط
SSLCertificateChainFileفي النسخ الأقدم، أو استخدام ملفSSLCertificateFileمدمج يحتوي الوسيطة، ثمsudo apachectl configtest && sudo systemctl reload apache2. - cPanel الاستضافة المشتركة نوع يتقاسم فيه موقعك موارد سيرفر واحد مع مئات المواقع الأخرى، فتكون أرخص الخيارات وأسهلها للبداية، لكن أداءها يتأثر إذا استهلك جار ما موارد…">والاستضافة المشتركة — من WHM ← SSL/TLS ← Install an SSL Certificate والصق الحزمة الكاملة التي أعطتك إياها جهة الإصدار (الشهادة + الوسيطة)، أو أعد تشغيل AutoSSL من WHM ← Manage AutoSSL. وإذا كنت على cPanel عميل بلا صلاحيات WHM، اطلب من الدعم إعادة تشغيل AutoSSL للنطاق تحديدًا.
- الاستضافة المُدارة — أوقف SSL وأعد تفعيله من لوحة الاستضافة. هذه الشركات تدير السلسلة نيابة عنك، وإجبار إعادة الإصدار يحل المشكلة عادةً في دقائق.
السبب الثاني: شهادة Let’s Encrypt لم تتجدد
شهادات Let’s Encrypt صالحة 90 يومًا فقط بالتصميم، حتى يصبح التجديد آليًا لا منسيًا. وإذا تعطلت مهمة التجديد بصمت — وأشهر الأسباب تغيير في جدار الحماية، أو نقل مجلد الجذر، أو امتلاء القرص — فالشهادة تنتهي والمتصفح يرفضها وهو محق.
كيف تفحص:
sudo certbot certificates
يعرض كل شهادة يديرها Certbot وتاريخ انتهائها. إذا كانت منتهية أو مكتوب أمامها INVALID، فهذه هي إجابتك.
كيف تصلح:
- شغّل تجربة أولًا حتى لا تصطدم بحدود الإصدار:
sudo certbot renew --dry-run - إذا نجحت التجربة، جدّد فعليًا:
sudo certbot renew - أعد تحميل السيرفر:
sudo systemctl reload nginxأوapache2 - تأكد أن مؤقّت التجديد يعمل أصلًا:
systemctl list-timers | grep certbot
على الاستضافة المشتركة أنت لا تشغّل Certbot بنفسك، بل المستضيف يفعل ذلك عبر AutoSSL. المكافئ العملي لمهمة تجديد معطّلة هو مهمة AutoSSL متوقفة: راسل الدعم أو أعد تشغيل قسم SSL من ووردبريس لتضيف له ميزة جديدة، مثل متجر أو نموذج تواصل أو تحسين للسيو، دون كتابة كود. اختر الإضافات الموثوقة المحدّثة، ولا…">الإضافات والقوالب والمستخدمين والإعدادات، وما يظهر فيها يختلف حسب دور المستخدم.">لوحة التحكم.
ملاحظة تهمّ المواقع المصرية والخليجية: امتلاء القرص سبب شائع جدًا لفشل التجديد الصامت على الخطط الاقتصادية، خصوصًا مع تراكم النسخ الاحتياطية وسجلات الأخطاء داخل مساحة الحساب. راجع المساحة المتاحة قبل أن تتهم الشهادة.
السبب الثالث: شهادة لنطاق آخر (خطأ قريب ومربك)
إذا نقلت الاستضافة حديثًا، أو أضفت www، أو انتقلت لسيرفر جديد، وكانت الشهادة المثبتة لا تشمل نطاقك الحالي، فسيظهر NET::ERR_CERT_COMMON_NAME_INVALID — خطأ شقيق لا نفس الخطأ، لكن الناس تبحث عنهما بالتبادل. هذا بالضبط سيناريو «الاتصال ليس خاصًا بعد تجديد الاستضافة»: المستضيف الجديد أصدر شهادة قبل أن يكتمل توجيه اسم النطاق مثل arabcms.com إلى عنوان IP السيرفر الذي يستضيف الموقع. أي تعديل في سجلاته قد يحتاج ساعات…">DNS، أو أصدرها لنطاق فرعي خاطئ، فيرى الزوار شهادة تخص سيرفرًا آخر.
كيف تفحص: افتح موقعك في Chrome، اضغط تحذير «غير آمن»، ثم تفاصيل الشهادة، وقارن النطاقات المذكورة فيها بالنطاق في شريط العنوان.
كيف تصلح:
- تأكد أن DNS انتشر بالكامل إلى المستضيف الجديد قبل إعادة الإصدار —
dig yourdomain.comيجب أن يعيد عنوان IP الجديد من كل نقطة تفحص منها. - أعد إصدار الشهادة لكل اسم مضيف تخدمه فعلًا، بما يشمل
yourdomain.comوwww.yourdomain.comمعًا إذا كان الزوار يصلون بالاثنين. - افحص وجود سجل CAA في DNS يمنع الإصدار — إن وُجد فيجب أن يسمح لجهة إصدارك صراحة، مثل
yourdomain.com. CAA 0 issue "letsencrypt.org".
السبب الرابع: شهادة تجريبية أو موقّعة ذاتيًا منسية
إذا ترك مطوّر أو سكربت نقل أو تثبيت Nginx/Apache افتراضي شهادة موقّعة ذاتيًا نشطة — أو اختبرت على بيئة Let’s Encrypt التجريبية (Staging) ونسيت التحويل إلى الإنتاج — فالشهادة صحيحة تقنيًا لكنها صادرة من جهة لا يثق بها أي متصفح. لا يوجد إعداد يُصلح هذا: أعد إصدار شهادة إنتاج حقيقية واحذف البديلة.
لو الموقع وراء Cloudflare
نقطة تخصّ كثيرًا من المواقع العربية التي تستخدم Cloudflare لتقليل زمن الاستجابة: الزائر في هذه الحالة يرى شهادة Cloudflare لا شهادة سيرفرك. فإذا ظهر الخطأ، افحص شهادة السيرفر الأصلي (Origin) مباشرة، أو أوقف الوكيل (السحابة الرمادية) مؤقتًا واختبر النطاق، ثم أعد التفعيل. وإذا كان وضع SSL في Cloudflare على Full (strict) وسلسلة السيرفر الأصلي مكسورة، فستظهر لك مشكلة على مستوى الاتصال بالأصل لا تحذير شهادة عادي — صلّح الأصل ولا تخفّض الوضع لتسكيت الرسالة.
قائمة فحص سريعة
- [ ] شغّل أمر
openssl s_clientأعلاه — هل تكتمل السلسلة بدون أخطاء؟ - [ ] شغّل
sudo certbot certificatesأو افتح قسم SSL في لوحة المستضيف — هل الشهادة منتهية؟ - [ ] افتح تفاصيل الشهادة في المتصفح — هل حقل «صادرة إلى» يطابق نطاقك فعلًا؟
- [ ] افحص حقل «صادرة من» — هل هي جهة حقيقية أم يظهر اسم سيرفرك؟
- [ ] افحص DNS بـ
dig— هل نطاقك يشير حاليًا إلى السيرفر الذي تظن أنه أصدر الشهادة؟
| العَرَض | السبب المرجّح | أسرع إصلاح |
|---|---|---|
Verify return code: 21 في openssl | شهادة وسيطة مفقودة | قدّم fullchain.pem لا cert.pem |
| — | — | — |
| الشهادة انتهت حديثًا | فشل تجديد Let’s Encrypt | certbot renew ثم فحص المؤقّت |
| الشهادة تذكر نطاقًا آخر | شهادة خاطئة لنطاق أو مستضيف جديد | أعد الإصدار بعد انتشار DNS |
| جهة الإصدار هي اسم سيرفرك | شهادة موقّعة ذاتيًا أو تجريبية | استبدلها بشهادة إنتاج |
بعد الإصلاح: تأكّد أنه نجح فعلًا
لا تكتفِ بأن متصفحك توقف عن الشكوى — قد يكون خزّن الشهادة القديمة. اختبر من بيئة نظيفة بأداة Qualys SSL Labs المجانية، التي تعرض السلسلة الكاملة وتاريخ الانتهاء وأي مشكلة متبقية يراها المتصفح. لا تحتاج حسابًا.
وبينما أنت في Elementor وينظّم ترتيبها واتجاهها ومسافاتها، وتعتمد على Flexbox أو Grid. حلّت محل الأقسام والأعمدة القديمة، وتنتج صفحات أخف وأسهل…">القسم ده، اعمل مرور سريع على باقي إعدادات الأمان. الشهادة الوسيطة المفقودة بالتحديد من النوع اللي بيجي مع فراغات تانية صغيرة زي غياب ترويسات الأمان (Security Headers) أو ملفات إعداد مكشوفة — لأنها كلها بتيجي من نفس السبب: إعداد تم مرة واحدة ومحدش راجعه بعدها.
الخلاصة
خمس نقاط تحفظهم: الخطأ ده معناه إن المتصفح مش قادر يتحقق من جهة الإصدار، والفحص بالترتيب ده — السلسلة، تاريخ الانتهاء، النطاق. الشهادة الوسيطة المفقودة هي السبب الأول، وتقديم fullchain.pem بيحلّها. شهادات Let’s Encrypt بتنتهي كل 90 يوم بالتصميم، فتأكد إن certbot renew --dry-run بينجح فعلًا مش بس بتفترض كده. وبعد نقل الاستضافة، متعيدش إصدار الشهادة غير لما DNS يكون انتشر بالكامل، وشمّل كل الأسماء اللي زوارك بيستخدموها.
والأهم: حدّد تنبيه في تقويمك قبل انتهاء كل شهادة بأسبوع. أرخص من أي عميل بيكلّمك الساعة 11 بالليل يقولك «الموقع بيقول إنه غير آمن».
مرجع المقال (بالإنجليزية): Fix NET::ERR_CERT_AUTHORITY_INVALID: Owner’s Guide
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.
اقرأ أيضًا
الأسئلة الشائعة
ماذا يعني خطأ NET::ERR_CERT_AUTHORITY_INVALID؟
يعني أن المتصفح لم يستطع التحقق من الجهة التي أصدرت شهادة موقعك: إما أن سلسلة الثقة ناقصة، أو أن الشهادة موقّعة من السيرفر نفسه لا من جهة إصدار معتمدة. السبب في السيرفر دائمًا، لا في متصفح الزائر.
ما أشهر سبب لهذا الخطأ؟
غياب الشهادة الوسيطة. في Nginx يحدث هذا عند الإشارة إلى cert.pem بدلًا من fullchain.pem، فيرسل السيرفر شهادتك فقط ولا يرسل الشهادة التي تربطها بالجهة الجذرية.
كيف أعرف إذا كانت الشهادة منتهية؟
على سيرفر خاص شغّل sudo certbot certificates وسترى تاريخ انتهاء كل شهادة. على استضافة مشتركة افتح قسم SSL في لوحة التحكم، أو افحص الشهادة من المتصفح مباشرة.
ما الفرق بين هذا الخطأ وخطأ NET::ERR_CERT_COMMON_NAME_INVALID؟
الأول يعني أن جهة الإصدار غير موثوقة أو السلسلة ناقصة. الثاني يعني أن الشهادة صحيحة لكنها صادرة لنطاق آخر غير النطاق الذي يزوره الزائر، وهو ما يحدث كثيرًا بعد نقل الاستضافة أو إضافة www.
لماذا اختفى الخطأ من متصفحي ولم يختفِ عند العملاء؟
لأن متصفحك قد يكون خزّن السلسلة القديمة مؤقتًا. اختبر من بيئة نظيفة بأداة مستقلة مثل Qualys SSL Labs التي تعرض السلسلة الكاملة وتاريخ الانتهاء وأي مشكلة متبقية.
موقعي وراء Cloudflare، فأين أفحص الشهادة؟
الزائر يرى شهادة Cloudflare لا شهادة سيرفرك، فالخطأ الظاهر قد يكون في شهادة السيرفر الأصلي (Origin). افحص السيرفر الأصلي مباشرة، أو أوقف الوكيل مؤقتًا واختبر النطاق، ثم أعد التفعيل.
