كيفية إصلاح الأخطاء الشائعة عند استخدام خدمة LetsEncrypt

قد تواجه عدة أخطاء شائعة عند ضبط نطاق موقعك أو عند ضبط إعدادات دعم بروتوكول HTTPS. وإن إصلاح مشاكل بروتوكول DNS أو ما يُعرف ببروتوكول نظام تسمية النطاقات (Domain Name System) ليس بالأمر السهل، إذ يصعُب الجزم أن سبب الأخطاء هو بروتوكول DNS، فقد يكون سببها قد يكون في مكان آخر في بنيتك الشبكية.

وفي حال طلبت من مسؤول الصيانة حل المشكلات المرتبطة بضبط نطاق موقعك ستسمع غالبًا منه العبارات التالية تباعًا:

اقتباس

الخطأ ليس من بروتوكول DNS

يستحيل أن يكون الخطأ من بروتوكول DNS

الخطأ هو من بروتوكول DNS

فكثيرًا ما تتكرر مشكلات DNS عند محاولة تنصيب شهادة SSL/HTTPS وضبط إعداداتها على خوادمك، عند استخدامك لخدمة Let's Encrypt على سبيل المثال. وسنراجع في هذا المقال بعض الأخطاء الشائعة التي قد تواجهها عند التعامل مع بروتوكولي DNS و HTTPS عند التعامل مع خدمة Let's Encrypt على وجه الخصوص، وسنُقدّم لك مجموعة نصائح وتوصيات يمكن تطبيقها سواء أكنت تستخدم خدمة DNS من مزود ديجيتال أوشن DigitalOcean أو من أي مزود آخر.

سجلات DNS

إن بروتوكول DNS هو المسؤول عن تعيين وتوجيه حركة البيانات إلى خوادم الويب باستخدام أسماء النطاقات، مثل your_domain.com بدلًا من الحاجة لاستخدام عناوين IP للمواقع. وتزوّد جميع مزودات النطاقات مستخدميها بواجهة خاصة لإدارة سجلات DNS. ولمطالعة مزيد من المعلومات حول أنواع سجلات نظام أسماء النطاق (DNS) يمكنك الرجوع إلى مقالنا مقدّمة إلى مُصطَلحات وعناصر ومفاهيم نظام أسماء النطاقات.

إن أحد أكثر سجلات الـ DNS شيوعًا هو السجل A، والذي يشكّل رابطًا أساسيًا من اسم النطاق domain name إلى عنوان الخادم server address. لذا سنرّكز في هذا المقال على السجل A لكونه السجل الذي تحتاج إليه لإسناد أسماء النطاقات الأساسية إلى عناوين IP للخوادم. عند استخدام خدمة DNS من مزود DigitalOcean على سبيل المثال سيكون السجل A مضبوطًا كما في الصورة التالية:

تحديث أو ترحيل سجلات DNS

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

يمكنك الاستعانة بموقع whatsmydns.net للتحقق من أن تعديلات سجل DNS قد نُشرت إلى معظم خوادم أسماء النطاقات العالمية المستخدمة للبحث عن سجلات DNS. فإذا لم تعدل السجلات لديك محليًا يمكنك التحقق فيما إذا كانت قد عدلت في معظم المواقع العالمية، فقد يكون سبب المشكلة هو أن مزود خدمة الانترنت الذي تستخدمه ربما يكون أبطأ في إجراء التعديلات من المخدمات العالمية، لكن لن يستغرق الأمر أكثر من بضع دقائق في معظم الحالات.

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

 nslookup digitalocean.com $ 
Output
…
Name:    digitalocean.com
Addresses:  2606:4700::6810:b50f
          2606:4700::6810:b60f
          104.16.181.15
          104.16.182.15

يمكنك بهذه الطريقة التأكد أن النتائج المحلية تطابق نتائج خوادم أسماء النطاقات العالمية. إن استخدام قيمة TTL مرتفعة أو ما يعرف بمدة البقاء Time-To-Live عند ضبط DNS، سيجعل التحديث يستغرق وقتًا أطول. إذ إن قيمة TTL الافتراضية المعتمدة في معظم مسجلي أسماء النطاقات هي 3600 ثانية، أو ساعة واحدة، وتُدرج عادةً هذه القيمة بجوار سجل A. تساعد قيمة مدة البقاء TTL الطويلة على تخزين الطلبات بفاعلية أكبر، ولكنها بالمقابل قد تجعل تغييرات DNS تستغرق وقتًا أطول في النشر. ننصحك في ضبط مدة TTL قصيرة مؤقتًا إذا أردت إجراء أو اختبار بعض التغييرات على DNS.

أخطاء المتصفح ومشاكل إعدادات بروتوكول HTTPS

قد تظن أحيانًا أنك ضبطت إعدادات بروتوكول HTTPS وإعدادات DNS على نحو صحيح، لكن قد تظهر لك رسائل خطأ في متصفح الويب عند طلب الموقع.

للحصول على دليل عام حول رموز أخطاء HTTP، ننصحك بمراجعة المقال التالي حول كيفية إصلاح رموز أخطاء HTTP الشائعة. لا تشير معظم هذه الرموز إلى الخطأ بشكل صريح ومباشر ولكنها تنتج عن الإعدادات غير الصحيحة. على سبيل المثال، إذا استخدمت خادم إنجن إكس كوسيط عكسي Nginx Reverse Proxy لتوفير بوابة HTTPS لتطبيق آخر يعمل على خادمك، ولم تضبط إعدادات البوابة على نحو صحيح، فقد يظهر لك الخطأ ذو الرمز 502 الذي يدل على أن إنجن إكس غير قادر على إحالة الطلب.

وأحد الأخطاء التي قد تظهر لك هو رسالة انتهاء صلاحية الشهادة، إذ إن شهادات LeysEncrypt تبقى صالحة لمدة ثلاثة أشهر فقط، على عكس شهادات HTTPS التجارية. وعند عدم تجديد الشهادة قبل انتهاء مدة الصلاحية يتسبب في ظهور الخطأ ERR_CERT_DATE_INVALID لكل من يحاول الوصول إلى موقعك.

يبدو هذا الخطأ، عند استخدام متصفح كروم Chrome على النحو التالي:

عندما تضبط إعدادات LetsEncrypt لأول مرة، تُفَعّل خاصيّة تجديد الشهادة تلقائيًا. كما ترسل خدمة LetsEncrypt بريدًا إلكترونيًا لتذكيرك عندما تكون شهادتك على وشك الانتهاء، لكن إن ضبطت هذه العملية بشكل خاطئ، أو لم ينجح تشغيلها، يمكنك تجديد الشهادة يدويًا عن طريق إعادة تشغيل الأمر certbot باستخدام الوسيط renew:

sudo certbot renew --nginx -d example.com -d www.example.com

ربما ستحتاج إلى إعادة تشغيل خادم الويب بعد تجديد الشهادة،وفي حال لم تقم بإجراء أي تعديلات أخرى على إعدادات خادمك يمكنك عندها أتمتة هذه العملية (عن طريق إضافته إلى أداة الجدولة cron) بواسطة تشغيل الأمر systemctl restart nginx بعد تجديد الشهادة.

المحتوى المختلط

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

وسبب ذلك هو سياسة الويب الافتراضية التي تنص على عدم استخدام أو تضمين محتوى بروتوكول HTTP في المواقع التي تستخدم بروتوكول HTTPS. قد يظهر هذا الخطأ عندما يُحَمل موقع ما محتوىً من خادمي ويب مختلفين، أو عندما نُخَدّم تطبيق ويب بواسطة بوابة خادم Nginx لكن إعادة توجيه SSL لا تعمل على وجه صحيح. إذا كنت تستخدم خادم Nginx وتوجه البيانات/حركة البيانات إلى تطبيق آخر يعمل خلف خادم الويب، وظهرت لك رسالة تحذير المحتوى المختلط، يمكنك حينها إضافة معلومات لضبط توجيه SSL وذلك ضمن كتلة الموقع location:

…
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }

وعدا عن ذلك، احرص على استخدام بروتوكول HTTPS في جميع المواقع التي تُخَدمها. كما يمكنك الاطلاع على المقال التالي عن أخطاء المحتوى المختلط

الأخطاء التي تظهر عند تشغيل سكربت LetsEncrypt Certbot

قد تظهر لك بعض الأخطاء عند تشغيل سكربت Certbot المتوفر من خدمة LetsEncrypt، بعض الأخطاء لها خرج يشرح سبب الخطأ ويمكنك اتباع الإرشادات المذكورة، وبعضها الآخر قد لا يكون واضحًا. على سبيل المثال، إذا ظهر لك خطأ انتهاء المدة أو Timing out في السكربت، فالأرجح أن المشكلة متعلقة بجدار الحماية Firewall :

certbot --nginx -d example.com -d www.example.com

الخرج
Press Enter to Continue
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. example.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://example.com/.well-known/acme-challenge/EWbLNaAWwRZGM1UCqSvbIIxFFaoH09wPUEwVuYucCb0: 93 Timeout during connect (likely firewall problem)

وتحدث عادةً أخطاء انتهاء المدة أو Timeout بسبب عدم قدرة الاتصال على الحصول على استجابة أو تأكيد للعملية لأن جدار الحماية يهمل أو يتخلص من حركة البيانات. لتلافي حدوث هذا الخطأ، تأكد أن جدار الحماية لا يحجب المنفذ رقم 80 ولا المنفذ 443 قبل تشغيل certbot. تشير بعض الوثائق أنك ستحتاج إلى فتح واحد من المنفذين، إما المنفذ 80 أو المنفذ 443، ولكن افتح كلا المنفذين لاستبعاد إمكانية حدوث الأخطاء. إن كنت تستخدم UFW، أو Uncomplicated Firewall أي الجدار الناري غير المعقَّد، يمكنك تنفيذ ما سبق عن طريق تفعيل أمر الضبط الكامل Nginx Full:

sudo ufw allow 'Nginx Full'

ثم أعد تشغيل certbot بعد أن غيّرت إعدادات جدار الحماية. لكن، إن أعدت تشغيل certbot عدة مرات متتالية خلال مدة قصيرة فقد يظهر لك خطأ “failed validation limit” الذي يخبرك أنك وصلت إلى الحد المسموح به من محاولات التحقق:

الخرج
too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/

يجب عليك الانتظار لمدة ساعة قبل أن تستطيع إعادة المحاولة مجددًا من حسابك. يمكنك الاطلاع على التوثيق التالي للحصول على معلومات أكثر عن الحد المسموح به لمحاولات التحقق وأخطاء certbot الأخرى. إذا تلقيت أخطاء أخرى عند تشغيل certbot غير الأخطاء المتعلقة بالمدة Timeout أو أخطاء DNS أو مشاكل الاتصال، فمن المحتمل أن يكون سبب هذه الأخطاء مشكلةً في بيئةPython على خادمك والتي ضُبطت إعداداتها بواسطة certbot. يمكن إصلاح هذه الأخطاء دائمًا عن طريق إزالة certbot ثم إعادة تنزيله من الصفر. لن يؤثر ذلك على إعدادات HTTPS الحالية، بل سيؤثر فقط على الأدوات المستخدمة للحفاظ على تلك الإعدادات وتجديدها. لتنفيذ ذلك، يمكن اتباع الإرشادات في مقال كيف تؤمّن خادم ويب NGINX على أوبنتو

حالة عدم عمل بروتوكول HTTPS مع عدم ظهور أخطاء مرئية

إن تأكدت من أن Certbot وDNS يعملان على نحو صحيح، لكن موقعك لم ينتقل من استخدام HTTP إلى استخدام HTTPS، فسبب هذا عادةً هو مشكلة في إعدادات خادم الويب. يحدث certbot تلقائيًا إعدادات ضبط خادم الويب أولًا ثم يعمل بعدها، ولهذا يجب عليك تحديد الخادم nginx عند كتابة أمر تشغيل certbot كي يعلم ما هو نوع إعدادات الخادم الذي عليه تحديثها بعد تجديد الشهادة. لكن، إن كانت إعدادات خادم الويب الحالية معقدةً جدًا، فقد يفشل Certbot في تحديثه للانتقال إلى استخدام بروتوكول HTTPS، وستحتاج حينها إلى إجراء التغييرات بنفسك. أولًا، تأكد من إضافة كتلة اسم خادمك server_name في ملف ضبط إعدادات الخادم، إذ إنه بدون هذه الخطوة، لن يعلم certbot ما هي الإعدادات الواجب تحديثها. إن واجهت مشاكل بعد هذه الخطوة، فقد تحتاج إلى تشغيل certbot في الوضع المستقل Standalone mode يجلب الشهادة فقط، ثم ستحتاج إلى ضبط إعدادات خادم الويب يدويًا لاستخدام بروتوكول HTTPS. تتضمن الإعدادات الأساسية لخادم Ngnix الذي يستخدم بروتوكول HTTPS السطر التالي listen 443 ssl ومسار شهادة SSL والمفتاح Key كما يلي:

…
    listen 443 ssl;
    # RSA certificate
    ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;

    # Redirect non-https traffic to https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
…

عند ضبط إعدادات خادم Nginx تذكر أنه يمكنك التحقق من التعديلات التي أجريتها على إعدادات خادم Nginx وتأكيدها بواسطة الأمر nginx -t قبل إعادة تشغيل الخادم. عند الانتهاء من التعديلات بإمكانك إعادة تشغيل خادم Nginx كي تأخذ الإعدادات الجديدة مفعولها باستخدام الأمر systemctl restart nginx

sudo systemctl restart nginx

ختامًا

راجعنا في هذا المقال عدة أخطاء شائعة قد تظهر عند استخدام خدمة LetsEncrypt وتعلمنا خطوات إصلاحها، إذ إن الهدف من خدمة LetsEncrypt هو إتاحة استخدام البروتوكول الآمن HTTPS لجميع الأفراد في أي مكان ودون دفع أي تكاليف، وهي تُعد خدمةً سهلة الاستخدام عندما تعمل تلقائيًا بدون ظهور أيّة أخطاء، ولكن قد يكون التعامل معها مربكًا لمن لا يملك خبرةً كافية في ضبط إعدادات شهادة SSL أو DNS. إذا واجهت أي مشكلات عند استخدام خدمة LetsEncrypt يمكنك الحصول على الدعم والمساعدة عبر إضافة سؤالك في قسم الأسئلة والأجوبة في أكاديمية حسوب.

ترجمة -وبتصرف- للمقال How To Fix Common LetsEncrypt Errors من موقع DigitalOcean.