بالنسبة لخادم ownCloud المُستضاف مباشرةً والذي يعمل خلف مضيف افتراضي Apache، فإنّ الطريقة المعتادة هي ربط نطاق عام بالخادم، وجعل موقع HTTP متاحًا، وتشغيل مُثبِّت Apache الخاص بـ Certbot لهذا النطاق. على سبيل المثال، إذا كان عنوان ownCloud الخاص بك هو cloud.example.com، فيمكن لـ Certbot طلب شهادة Let's Encrypt وتكوين Apache لتقديم HTTPS باستخدام sudo certbot --apache -d cloud.example.com. اختبر الموقع والتجديد التلقائي قبل الاعتماد عليه.
هذا الإجراء مخصص لتثبيت ownCloud Classic 10.16 المُدار بواسطة Apache على نظام Ubuntu، كما هو مُفترض في دليل Apache الخاص بـ ownCloud. إذا كنت تُشغّل ownCloud Classic 11 في Docker، فإن ownCloud تُشير إلى ضرورة تهيئة HTTPS على خادم الوكيل (Proxy) أمام الحاوية. إذا كان مُزوّد خدمة الاستضافة أو خادم الوكيل العكسي يُنهي اتصال TLS بالفعل، فقم بتهيئة الشهادة هناك بدلاً من محاولة تثبيتها في حاوية ownCloud.
تُثبت Let's Encrypt ملكيتك لاسم النطاق المطلوب قبل إصدار الشهادة. في تحدي HTTP-01 الشائع، يجب أن تتمكن Let's Encrypt من استرداد ملف مؤقت من خادمك عبر بروتوكول HTTP العام على المنفذ 80. يجب أن يُشير اسم المضيف نفسه إلى نقطة النهاية العامة التي تُشغّل موقع ownCloud الخاص بك. ثم تصل حركة مرور HTTPS إلى نقطة نهاية Apache على المنفذ 443.
cloud.example.com، وتتحكم في سجلات نظام أسماء النطاقات (DNS) الخاصة به.إذا كان موقعك الإلكتروني محميًا بخادم وكيل أو موازن أحمال أو مضيف حاويات أو لوحة تحكم، فحدد نقطة انتهاء بروتوكول TLS العام قبل تشغيل Certbot. لن يؤدي تثبيت شهادة على جهاز خاطئ إلى تأمين اتصال المتصفح بالخادم. في ownCloud Classic 11، يدير تصميم Docker المدعوم خادم Apache داخل الحاوية ويضع بروتوكول HTTPS في خادم الوكيل.
استخدم اسم مضيف مخصصًا لـ ownCloud كلما أمكن ذلك. يتطلب ownCloud إدراج كل عنوان URL للمتصفح المستخدم لتسجيل الدخول ضمن trusted_domainsملفه config/config.php. إذا كنت تُغيّر من عنوان IP أو اسم مضيف آخر إلى اسم مضيف آخر cloud.example.com، فأضف المضيف الجديد إلى إدخال غير مستخدم في مصفوفة trusted-domains قبل اختبار العنوان الجديد. لا تقم بالكتابة فوق إدخال آخر عن طريق الخطأ.
تأكد من وصول بروتوكول HTTP العادي إلى موقع ownCloud المقصود قبل طلب الشهادة. في Apache، يجب أن يُحدد VirtualHost اسم المضيف بدقة باستخدام ServerNameتوجيه. تفترض تعليمات Apache الخاصة بـ ownCloud وجود تكوين VirtualHost، وفي Ubuntu، يتم وضع تعريفات الموقع ضمن /etc/apache2/sites-available/. قد تختلف المسارات وأسماء الخدمات في التوزيعات الأخرى.
قم بعمل نسخة احتياطية من إعدادات Apache VirtualHost النشطة قبل تغييرها. سيوفر لك هذا نقطة استعادة في حال اختار برنامج التثبيت التلقائي موقعًا خاطئًا أو أنشأ مضيف HTTPS متعارضًا. إذا كان لديك مواقع متعددة على نفس الخادم، فراجع ملفات VirtualHosts الموجودة للتأكد من ربط الشهادة باسم مضيف ownCloud بدلاً من الموقع الافتراضي.
قم بتثبيت Certbot باتباع التعليمات الخاصة بنظام التشغيل وإعدادات Apache لديك. توصي التعليمات الرسمية لـ Certbot باستخدام حزمة Snap الخاصة به للعديد من توزيعات Linux، ولكن توفر الحزمة وطرق التثبيت المدعومة تعتمد على التوزيعة. تجنب استخدام أكثر من نسخة من Certbot من مدير حزم نظام التشغيل وSnap معًا؛ certbotيجب أن يكون الأمر المستخدم هو الأمر الخاص بالنسخة التي تنوي استخدام إضافة Apache الخاصة بها.
على مضيف أوبونتو حيث تم تثبيت Snap ودعمه، تُظهر تعليمات Certbot مسار التثبيت هذا:
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbotإذا كان برنامج Certbot مثبتًا بالفعل، فتحقق من إصدار البرنامج الذي يعمل لديك وكيفية تثبيته قبل إضافة نسخة أخرى. اتبع دليل تثبيت Certbot Apache الحالي للاطلاع على خيارات التثبيت الأخرى المدعومة.
اطلب وقم بتثبيت الشهادة الخاصة باسم مضيف ownCloud الخاص بك:
sudo certbot --apache -d cloud.example.comاستبدل cloud.example.comاسم المضيف الحقيقي. سيقوم Certbot بالتحقق من صحة النطاق، وسيقوم، باستخدام مُثبِّت Apache، بتحديث Apache لاستخدام الشهادة الصادرة. إذا كنت ترغب في أن تغطي شهادة واحدة أكثر من اسم، فحدد كل اسم على حدة، على سبيل المثال -d cloud.example.com -d files.example.com. يجب أن يشير كل اسم مدرج إلى نقطة نهاية يمكن الوصول إليها وأن يجتاز التحقق.
قد يسأل Certbot عما إذا كان ينبغي إعادة توجيه طلبات HTTP إلى HTTPS. يُنصح بتفعيل إعادة التوجيه بمجرد أن يعمل VirtualHost عبر HTTPS. توصي ownCloud باستخدام HTTPS في بيئات الإنتاج وإعادة توجيه دائمة لحركة البيانات غير المشفرة. إذا كنت تفضل إدارة إعدادات Apache بنفسك، يوفر Certbot أيضًا وضعًا خاصًا بالشهادات فقط؛ استخدم دليل Apache الخاص بـ ownCloud لربط ملفات الشهادات وVirtualHost بشكل صحيح، ثم اختبر الإعدادات قبل إعادة تحميل Apache.
تستخدم طريقة HTTP-01 مسارًا /.well-known/acme-challenge/على المنفذ 80. إذا قام جهاز التوجيه بإعادة توجيه المنفذ 80 إلى جهاز آخر، أو قام جدار الحماية بحظره، أو قام خادم وكيل آخر بتوجيه هذا المسار إلى مكان آخر، فقد تفشل عملية التحقق حتى لو تم تحميل صفحة ownCloud عبر HTTPS. تحقق من نظام أسماء النطاقات العام وإعادة توجيه المنفذ، ثم تأكد من أن تحدي ACME يصل إلى نفس نقطة النهاية التي يعمل عليها Certbot.
إذا كان مزود خدمة الإنترنت أو سياسة الشبكة لديك يحظر المنفذ 80، ففكّر في استخدام التحقق من صحة DNS-01 بدلاً من ذلك. فهو يثبت ملكية النطاق من خلال سجل DNS TXT، ويمكنه إصدار شهادات شاملة، ولكن أتمتة التجديد تعتمد على ما إذا كان مزود خدمة DNS لديك لديه إضافة API مناسبة. تجنّب وضع بيانات اعتماد DNS واسعة النطاق على خادم الويب عندما تتوفر بيانات اعتماد محدودة النطاق أو مضيف تحقق منفصل. لا تستخدم إجراء HTTP-01 فقط لشهادة شاملة.
قبل إغلاق نافذة الصيانة، تحقق من صحة إعدادات Apache وأن Certbot يعرض الشهادة الجديدة:
sudo apache2ctl configtest
sudo certbot certificatesفي نظام أوبونتو، يُشير فحص بناء جملة أباتشي الناجح إلى صحة الإعدادات. افتح https://cloud.example.comالمتصفح وسجّل الدخول. تأكد من أن المتصفح يعرض شهادة صالحة لاسم المضيف المحدد، واختبر عميلًا نموذجيًا لتحميل الملفات وتنزيلها ومزامنتها. إذا فعّلتَ إعادة التوجيه، فانتقل إلى عنوان HTTP وتأكد من أنه يُعيد التوجيه إلى نفس اسم مضيف HTTPS دون تكرار عملية إعادة التوجيه.
إذا أبلغت صفحة تسجيل الدخول إلى ownCloud عن نطاق غير موثوق به، فتحقق trusted_domainsمن إعدادات الخادم. إذا أعاد المتصفح التوجيه إلى اسم مضيف خاطئ، أو إذا أنشأ ownCloud روابط HTTP خلف خادم وكيل عكسي، فراجع عناوين المضيف المُعاد توجيهها وعناوين HTTPS الخاصة بالخادم الوكيل، بالإضافة إلى إعدادات وكيل ownCloud. تعتمد هذه الإعدادات على بنية الخادم الوكيل؛ لذا لا تنسخ تعديلات الوكيل العكسي إلى تثبيت Apache مباشرةً دون سبب وجيه.
شهادات Let's Encrypt القياسية قصيرة الأجل، لذا يجب تجديدها تلقائيًا. توفر برامج Certbot عادةً مؤقتًا في systemd أو مهمة cron. اختبر التجديد مسبقًا باستخدام:
sudo certbot renew --dry-runيُجري اختبار تجريبي للتحقق من مسار التجديد دون استبدال الشهادة الحالية. في حال فشله، راجع مخرجات Certbot وصحّح المشكلة المذكورة في نظام أسماء النطاقات (DNS) أو جدار الحماية أو توجيه التحدي أو Apache. تأكد من وجود مؤقت أو مهمة مجدولة باستخدام أدوات خدمة نظام التشغيل لديك؛ لا تفترض أن التجديد نشط لمجرد إصدار الشهادة الأولى. أبقِ المنفذ 80 متاحًا إذا كان التجديد يستخدم HTTP-01، أو تأكد من أن أتمتة DNS-01 لا تزال قادرة على تحديث سجل TXT المطلوب.
| الموقف | المسار الموصى به |
|---|---|
| ownCloud Classic 10.16 على نظام Ubuntu مع Apache مكشوفًا مباشرةً | استخدم برنامج تثبيت Apache الخاص بـ Certbot لاسم مضيف ownCloud. |
| ownCloud Classic 11 في Docker | قم بتكوين بروتوكول HTTPS على وكيل الويب أمام الحاوية. |
| لوحة التحكم الخاصة بالاستضافة تدير الشهادات بالفعل. | استخدم آلية عمل Let's Encrypt الخاصة باللوحة وتحقق من تجديدها. |
| لا يمكن الوصول إلى خادم الويب عبر المنفذ 80 أو يلزم استخدام رمز بدل. | استخدم DNS-01 مع طريقة تجديد مناسبة. |
| يحتوي Apache على العديد من المضيفات الافتراضية | تأكد من أن Certbot قد اختار المضيف الظاهري الذي يتطابق اسم الخادم الخاص به مع اسم مضيف الشهادة. |
لا تُفعّل بروتوكول HSTS includeSubDomainsحتى يتم تقديم جميع النطاقات الفرعية ذات الصلة بشكل صحيح عبر HTTPS؛ إذ يؤثر رأس HTTP في اسم مضيف واحد على كيفية تعامل المتصفحات مع نطاقاته الفرعية. ابدأ بجعل الشهادة وعمليات إعادة التوجيه والتجديد موثوقة. ثم راجع إرشادات الأمان الخاصة بـ ownCloud لبروتوكول HSTS وإعدادات TLS الأخرى المناسبة لبنية نطاقك بالكامل.
تمت مراجعة الوثائق في 6 أكتوبر 2026. تفترض مسارات الملفات والأوامر الدقيقة أدناه استخدام Ubuntu مع Apache و ownCloud Classic 10.16؛ تحتاج عمليات النشر Docker و reverse-proxy و hosting-panel و Nginx و non-Ubuntu إلى تعليمات لنقطة نهاية TLS الفعلية الخاصة بها.
المراجع: ownCloud 10.16: تهيئة Apache مع Let's Encrypt ؛ ownCloud 11: إرشادات HTTPS والخادم الوكيل العكسي ؛ ownCloud 10.16: النطاقات الموثوقة ؛ Certbot: تثبيت Apache وتجديده ؛ Let's Encrypt: أنواع التحديات ؛ Let's Encrypt: إبقاء المنفذ 80 مفتوحًا .
قارن بين 10 أدوات مسح الشبكة المحلية (Ping) لاكتشاف الشبكات المحلية بسرعة، وإجراء مسح شامل للأنظمة الأساسية المختلفة، وإدارة عناوين IP. تعرّف على ما يمكن أن يكشفه لك المسح وما لا يمكنه كشفه.
قارن بين ست أدوات لإدارة الشبكة لمراقبة الأداء، بما في ذلك تغطية SNMP، ورسم الخرائط، والتنبيهات، ونماذج النشر، والمفاضلات المتعلقة بالتكلفة.
قارن بين أفضل برامج تحليل شبكة Wi-Fi لأنظمة Windows و iPhone و Android، بما في ذلك أدوات ازدحام القنوات وتغطية الإشارة والخرائط الحرارية واستكشاف أخطاء الشبكة وإصلاحها.
قارن بين سبعة برامج مراقبة زمن الاستجابة المجانية والمفتوحة المصدر، بدءًا من مجموعات الشبكة الكاملة وحتى مجسات زمن الاستجابة المركزة، واختر البرنامج المناسب من حيث التوافر وفقدان الحزم والسجل.
تعرف على معنى جودة الخدمة في الشبكات، وكيف تحدد علامات DSCP وقوائم انتظار حركة المرور أولويات تطبيقات الصوت والفيديو والأعمال، وما لا تستطيع جودة الخدمة إصلاحه.
قم ببناء نظام مراقبة شبكة عملي مع تغطية واضحة للأجهزة، ومقاييس أداء مفيدة، وتنبيهات قابلة للتنفيذ، ومقارنة بين SolarWinds NPM وPRTG وOpManager.
قارن بين برامج خوادم SFTP الموثوقة لأنظمة ويندوز ولينكس، بما في ذلك OpenSSH وBitvise وSolarWinds وSFTPGo. اعثر على الخيار الأمثل الذي يلبي احتياجاتك الأمنية واحتياجات نقل الملفات.
قارن بين سبع أدوات لإدارة عناوين IP لاكتشاف الشبكات الفرعية، وتنسيق DNS وDHCP، وجرد الشبكة، وIPAM مفتوح المصدر.
قارن بين أدوات فحص الشبكة لاكتشاف الأجهزة بسرعة، وعمليات فحص IP عبر الأنظمة الأساسية، وإدارة عناوين IP للمؤسسات، مع إرشادات حول مطابقة كل خيار مع شبكتك.
استخدم خيار --traceroute في Nmap لرسم خرائط القفزات إلى مضيف مصرح به، وفهم مخرجات القفزة وRTT، واستكشاف الأخطاء وإصلاحها في الاستجابات المفقودة دون الإفراط في المسح.
