SSD Nodes Learn Hosting plans →
الأدلة Matt Connorبقلم Matt Connor · آخر تحديث في 2026-08-07

شهادة TLS مقبولة في Chrome على Ubuntu 24.04

أنشئ شهادة TLS موقّعة ذاتياً يقبلها Chrome على Ubuntu 24.04: أمر openssl واحد مع SAN، إعداد nginx أو Apache، وثقة صحيحة من دون curl -k.

ما الذي ستبنيه

شهادة TLS موقّعة ذاتياً تقبلها المتصفحات والعملاء الحديثون فعلياً، مع subjectAltName صحيح، وصلاحيات آمنة للمفتاح، وربطها بـ nginx أو Apache، إضافة إلى الجزء الذي تتجاهله معظم الأدلة تقريباً: جعل عملائك يثقون بها بطريقة صحيحة، بدلاً من تجاوز التحذيرات بالنقر عليها وتثبيت curl -k داخل البرامج النصية إلى الأبد. وفي النهاية، ستنشئ CA خاصة من خلال خمسة أوامر عندما تتحول خدمة داخلية واحدة إلى ست خدمات.

ابدأ بالقرار، لأن الشهادة الموقّعة ذاتياً ليست الأداة المناسبة في معظم الحالات التي تُستخدم فيها. إذا كانت الخدمة متاحة من الإنترنت العام باستخدام اسم DNS حقيقي، فتوقف عن القراءة واحصل على شهادة Let's Encrypt مجانية باستخدام certbot مع nginx أو ما يعادلها مع Apache بدلاً من ذلك. لا تكلف شيئاً، وتتجدد تلقائياً، وكل متصفح في العالم يثق بها مسبقاً. استخدام شهادة موقّعة ذاتياً على موقع عام يدرّب المستخدمين على تجاوز تحذيرات الأمان بالنقر عليها، وهذه عادة أسوأ من استخدام HTTP العادي.

تكون الشهادة الموقّعة ذاتياً مناسبة عندما لا يكون للإنترنت العام أي دور: لوحة إدارة مرتبطة بـ عنوان نفق WireGuard على VPS الخاص بك، أو خادم staging على شبكة خاصة، أو حركة مرور بين الخدمات الخلفية، أو جهاز في مختبر منزلي، أو استبدال الشهادة المؤقتة التي ينشئها Webmin لنفسه على المنفذ 10000. لا يستطيع Let's Encrypt إصدار شهادات لـ 10.8.0.1 أو git.internal.lan على أي حال؛ فلن تضع أي CA عامة عنوان IP خاصاً أو TLD غير حقيقي في شهادة. بالنسبة إلى هذه الأسماء، ستكون أنت CA.

تعمل جميع الخطوات التالية على خادم Ubuntu 24.04 جديد، الذي يأتي مع OpenSSL 3.0.x (openssl version للتأكيد). لا تحتاج أي خطوة هنا إلى اتصال بالإنترنت؛ فجميعها تعمل في بيئة معزولة عن الشبكة.

لماذا يُنتج الأمر القديم في سطر واحد شهادات يرفضها Chrome

يبدو الأمر الذي تقدمه كل إرشادات ما قبل 2017 هكذا:

# Do not run this — shown so you recognise it in old guides
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout selfsigned.key -out selfsigned.crt

يطرح سلسلة من الأسئلة التفاعلية، ويضع اسم المضيف في حقل Common Name، وينتج شهادة بلا الامتداد subjectAltName. هذه الشهادة مرفوضة منذ البداية. توقف Chrome عن قراءة Common Name في الإصدار 58، في أبريل 2017. وكان RFC 2818 قد أوقف مطابقة CN في عام 2000. وتتصرف Firefox وSafari وcurl وPython بالطريقة نفسها. تحدد الشهادة خادمها من خلال امتداد SAN، أو لا تحدده إطلاقاً. ويعرض المتصفح ذلك بهذه الكلمات حرفياً:

NET::ERR_CERT_COMMON_NAME_INVALID

This server could not prove that it is git.internal.lan; its security
certificate does not specify Subject Alternative Names.

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

إصدار شهادة تقبلها المتصفحات: أمر واحد

أضاف OpenSSL الخيار -addext في الإصدار 1.1.1، لذلك لم تعد بحاجة إلى تعقيدات ملفات الإعداد التي كانت تستخدمها الأدلة القديمة لإضافة SAN. على Ubuntu 24.04:

sudo openssl req -x509 -newkey rsa:4096 -sha256 -days 730 -noenc \
  -keyout /etc/ssl/private/git.internal.key \
  -out /etc/ssl/certs/git.internal.crt \
  -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"

وظيفة كل خيار:

  • -x509 ينشئ شهادة موقّعة ذاتياً مباشرةً بدلاً من إنشاء طلب توقيع.
  • -newkey rsa:4096 ينشئ مفتاحاً جديداً في الخطوة نفسها. لا يسبب RSA 4096 مشكلة لأي عميل قديم؛ وإذا كانت كل الاتصالات من عملاء حديثين، فإن -newkey ec -pkeyopt ec_paramgen_curve:P-256 أصغر وأسرع.
  • -noenc هي صيغة OpenSSL 3.x للخيار القديم -nodes، أي عدم وضع عبارة مرور على المفتاح. تعمل الصيغتان. إذا كان المفتاح محمياً بعبارة مرور، فسيتوقف nginx منتظراً إدخالها عند كل إقلاع. لذلك استخدم هذا الخيار لمفتاح الخادم.
  • -days 730 لمدة عامين؛ راجع قسم انتهاء الصلاحية لمزيد من المعلومات عن هذا الرقم.
  • -subj يجيب عن الأسئلة التفاعلية ضمن الأمر. أصبح CN تجميلياً الآن، لكن اضبطه على الاسم الأساسي على أي حال، لأن بعض الأدوات تعرضه.
  • -addext "subjectAltName=..." هو الخيار الأساسي هنا. أدرج كل اسم وكل عنوان IP سيكتبه العملاء: إدخالات DNS: لأسماء المضيفين، وتُقبل أحرف البدل مثل DNS:*.internal.lan، وإدخالات IP: للعناوين. إذا كان أي مستخدم سيفتح https://10.8.0.1، فيجب أن يكون إدخال IP:10.8.0.1 موجوداً؛ وإلا فسيواجه المشكلة نفسها NET::ERR_CERT_COMMON_NAME_INVALID بسبب استخدام SAN خاص بـDNS فقط.

تحقق من إضافة SAN فعلياً قبل إعداد أي شيء آخر:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -ext subjectAltName

الناتج الصحيح:

X509v3 Subject Alternative Name:
    DNS:git.internal.lan, IP Address:10.8.0.1

إذا طبع الأمر بدلاً من ذلك No extensions in certificate، فلا تحتوي الشهادة على SAN، وسترفضها المتصفحات. أعد إنشاء الشهادة بدلاً من المتابعة.

حماية المفتاح

المفتاح الخاص الذي يمكن لكل مستخدم على الخادم قراءته ليس مفتاحاً خاصاً. في Ubuntu، تكون /etc/ssl/private بالفعل 710 root:ssl-cert، ما يمنع الاطلاع العارض عليها، لكن اضبط أذونات الملف نفسه صراحةً:

sudo chown root:root /etc/ssl/private/git.internal.key
sudo chmod 600 /etc/ssl/private/git.internal.key

يقرأ كل من nginx وApache الشهادات بصلاحيات root قبل خفض الصلاحيات، لذلك يعمل الوضع root:root 600 معهما. إذا كان المفتاح مخصصاً لخدمة تعمل بحساب مستخدم خاص بها وتحمّل المفتاح بنفسها، مثل تطبيق Node أو Gitea أو خدمة Python، فغيّر ملكية الملف إلى مستخدم تلك الخدمة عبر chown، مع الإبقاء على الوضع 600. لا تفعل مطلقاً ما يلي: استخدام الوضع 644، أو وضع نسخة في مستودع git، أو وضع نسخة في /tmp.

اربطه بـ nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name git.internal.lan;

    ssl_certificate     /etc/ssl/certs/git.internal.crt;
    ssl_certificate_key /etc/ssl/private/git.internal.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}
sudo nginx -t && sudo systemctl reload nginx

يجب أن يطبع nginx -t القيمتين syntax is ok وtest is successful قبل أن تنفّذ إعادة التحميل أي إجراء. إذا طبع بدلاً من ذلك SSL_CTX_use_PrivateKey_file() failed ... key values mismatch، فهذا يعني أن الشهادة والمفتاح ناتجان عن عمليتي إنشاء مختلفتين؛ راجع قسم أوضاع الفشل.

اربطه بـApache

sudo a2enmod ssl proxy proxy_http

لا يكفي ssl وحده هنا: يستخدم الـvhost أدناه ProxyPass، ومن دون mod_proxy وmod_proxy_http يفشل اختبار الإعدادات برسالة Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration. احفظ الـvhost باسم /etc/apache2/sites-available/git-internal.conf:

<VirtualHost *:443>
    ServerName git.internal.lan
    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/git.internal.crt
    SSLCertificateKeyFile   /etc/ssl/private/git.internal.key

    ProxyPass        / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>
sudo a2ensite git-internal
sudo apache2ctl configtest && sudo systemctl reload apache2

يجب أن يستجيب configtest على Syntax OK. اختبر الآن من جهاز عميل:

curl -v https://git.internal.lan/

وستحصل على خطأ:

curl: (60) SSL certificate problem: self-signed certificate

هذا ليس خطأً برمجياً. هذا يعني أن TLS يعمل: لم يسمع curl بشهادتك من قبل، ويرفض الاتصال بخادم لا يستطيع التحقق من هويته. يقدّم القسم التالي الحل الفعلي، وهو ليس ما يفعله نصف الإنترنت في هذه اللحظة تحديداً.

اجعل العملاء يثقون بها، والأنماط الخاطئة التي يجب رفضها

لنبدأ بالإصلاحات الخاطئة، مع تسميتها كما هي. إن تضمين curl -k (أو --insecure) في نص برمجي، أو استخدام verify=False في Python requests، أو NODE_TLS_REJECT_UNAUTHORIZED=0 في Node، لا يجعل الشهادة موثوقة. هذه الخيارات تعطّل التحقق من الشهادة، ما يعني أن العميل سيتصل بلا تردد بأي خادم يقدّم أي شهادة، بما في ذلك شهادة وضعها مهاجم في مسار الاتصال. بذلك تحتفظ بكلفة TLS وتفقد المصادقة التي كان TLS يوفّرها أساساً. والأسوأ أن هذه الخيارات تنتشر: تُلصق في مهمة cron واحدة، ثم في نص نشر، ثم في شيفرة الإنتاج، إلى أن لا يعود أحد يعرف أي اتصالات كان يفترض أن تكون مؤقتة. إذا بقي verify=False بعد انتهاء جلسة تصحيح الأخطاء التي أنشأته، فالتصميم خاطئ.

الإصلاح الصحيح هو تعريف نظام تشغيل كل عميل بأن هذه الشهادة جذر موثوق. على عملاء Ubuntu وDebian:

sudo cp git.internal.crt /usr/local/share/ca-certificates/git.internal.crt
sudo update-ca-certificates

السطر المهم في الناتج (تتبعه كتلة Running hooks in /etc/ca-certificates/update.d...):

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

توجد مشكلتان خفيتان في هذين السطرين. يجب أن ينتهي الملف بـ.crt، أما الامتداد .pem فيُتجاهل بصمت، وتحصل على 0 added من دون رسالة خطأ. ويجب أن تكون المحتويات بصيغة PEM، أي أن يبدأ الملف بـ-----BEGIN CERTIFICATE-----؛ حوّل ملف DER الثنائي أولاً باستخدام openssl x509 -inform der -in file.der -out file.crt. إن إضافة الشهادة الموقعة ذاتياً نفسها كجذر موثوق تعمل لأن الشهادة الموقعة ذاتياً هي جذرها الخاص.

بعد ذلك، يثق curl وwget وgit وapt وأي عميل آخر يستخدم OpenSSL مع مخزن النظام بالشهادة، من دون أي خيارات. تحتفظ بعض العملاء بمخازن ثقة خاصة بها وتحتاج إلى إعداد منفصل:

  • Chrome/Chromium على Linux يقرأ قاعدة بيانات NSS، وليس مخزن النظام: sudo apt install libnss3-tools، ثم certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt لكل مستخدم.
  • Firefox لديه مخزن خاص به: Settings → Privacy & Security → Certificates → Import، أو غيّر security.enterprise_roots.enabled إلى true في about:config لكي يقرأ مخزن النظام.
  • Python requests يضم حزمة شهادات CA خاصة به (certifi) ويتجاهل مخزن النظام: مرّر verify="/usr/local/share/ca-certificates/git.internal.crt" أو صدّر REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt.
  • Node.js: صدّر NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt.

على عملاء Windows، انقر نقراً مزدوجاً على .crt وثبّته ضمن Trusted Root Certification Authorities؛ وعلى macOS، أضفه إلى سلسلة مفاتيح System باستخدام Keychain Access، وحدد له Always Trust.

جذر واحد لخدمات متعددة: CA خاص صغير

يتوقف التوسع باستخدام الثقة لكل شهادة فوراً: ست خدمات مضروبة في أربع أجهزة عميلة تعني 24 عملية تثبيت للثقة، وكل خدمة جديدة تضيف عمليات أخرى. الحل هو استخدام CA خاص؛ يثق العملاء بجذر واحد، وتوقّع به شهادة كل خدمة.

الخيار السهل هو mkcert، وهو متوفر في مستودعات Ubuntu 24.04 ويتعامل مع مخازن NSS، مثل Chrome وFirefox، التي لا يتعامل معها update-ca-certificates:

sudo apt install -y mkcert libnss3-tools
mkcert -install
mkcert git.internal.lan "*.internal.lan" 10.8.0.1

ينشئ mkcert -install جذراً ويسجّله في كل مخزن ثقة على ذلك الجهاز؛ ويُخرج الأمر الثالث git.internal.lan+2.pem وgit.internal.lan+2-key.pem، وهما جاهزان للإضافة إلى مقاطع nginx أو Apache السابقة. يفترض تصميمه وجود جهاز تطوير؛ إذ يبقى مفتاح الجذر على الجهاز الذي شغّل -install. لذلك فهو مناسب جداً للحاسوب المحمول الخاص بالتطوير، لكنه غير مناسب لأسطول من الخوادم.

بالنسبة إلى الخوادم، ينفّذ OpenSSL العادي مهام CA كاملة باستخدام خمسة أوامر:

openssl genrsa -out lab-ca.key 4096
openssl req -x509 -new -key lab-ca.key -sha256 -days 3650 \
  -out lab-ca.crt -subj "/CN=Lab Internal CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"
openssl genrsa -out git.key 2048
openssl req -new -key git.key -out git.csr -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"
openssl x509 -req -in git.csr -CA lab-ca.crt -CAkey lab-ca.key \
  -CAcreateserial -days 730 -sha256 -copy_extensions copy -out git.crt

المشكلة في الأمر الأخير: يحذف openssl x509 -req جميع الامتدادات من CSR افتراضياً، بما فيها SAN الذي أضفته بعناية. ينقل -copy_extensions copy هذه الامتدادات، وهو خيار متوفر في OpenSSL 3.x، ولذلك يعمل على 24.04. إذا حذفته، فلن تحتوي الشهادة الموقّعة على SAN، وسيعرض Chrome NET::ERR_CERT_COMMON_NAME_INVALID مجدداً. تحقّق باستخدام فحص openssl x509 -noout -ext subjectAltName نفسه كما سبق.

وزّع lab-ca.crt على العملاء باستخدام خطوات مخزن الثقة السابقة، مرة واحدة لكل جهاز. احمِ lab-ca.key كما تحمي الآن أهم المفاتيح: اضبط نمطه على 600، ويفضّل أن تحتفظ به على جهاز ليس من الخوادم التي يوقّع لها، لأن من يملكه يستطيع إنشاء شهادة لأي اسم يثق به عملاؤك.

انتهاء الصلاحية والتدوير

تتقلص مدد صلاحية شهادات CA العامة بسرعة. حدّد CA/Browser Forum مدة الشهادات الموثوقة علناً التي أُصدرت حديثاً بـ200 يوماً في مارس 2026، بعد أن كانت 398 يوماً، وستنخفض المدة إلى 100 يوم في 2027 وإلى 47 يوماً بحلول مارس 2029. لكن هذه القواعد تنطبق على جهات CA الموثوقة علناً فقط. لا تخضع لها CA الخاصة بك، ولا تفرضها المتصفحات على الجذور المثبّتة يدوياً. توجد قاعدة عملية واحدة تنطبق فعلياً: ترفض منصات Apple أي شهادة خادم TLS تتجاوز مدة صلاحيتها 825 يوماً، بغض النظر عن الجهة التي أصدرتها. لذلك، إذا كانت أجهزة iPhone أو أجهزة Mac ستتصل، فاجعل مدة صلاحية شهادات leaf سنتين أو أقل. تتوافق -days 730 مع هذا الحد في كل مكان. ويُعد استخدام root مدته عشر سنوات مع شهادات leaf مدتها سنتان بنية داخلية مريحة.

تفشل الشهادات الطويلة الصلاحية بطريقة واحدة تحديداً: تنتهي صلاحيتها بصمت وفي الوقت نفسه، في تاريخ لا يتذكر أحد أنه اختاره. تحقّق مما لديك:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -enddate

ضع التجديد في تقويم فعلي، أو اجعل cron يذكّرك قبل 30 يوماً. تُرجع openssl x509 -checkend 2592000 -in cert.crt قيمة غير صفرية عندما يصبح وقت انتهاء الصلاحية ضمن ذلك العدد من الثواني. وإذا كنت تستخدم Uptime Kuma لمراقبة الحالة، فستشير شاشات مراقبة HTTPS فيه إلى اقتراب انتهاء صلاحية الشهادة مجاناً.

يكون تدوير الشهادات باستخدام CA خاصة مملاً بشكل مفيد: أعد تشغيل أوامر CSR والتوقيع، واستبدل الملفات، ثم أعد تحميل خادم الويب. لم يتغير root، لذلك لن يلاحظ العملاء أي شيء.

أوضاع الفشل، مع النصوص التي ستظهر لك

NET::ERR_CERT_AUTHORITY_INVALID، وهذه هي الحالة المتوقعة قبل تثبيت الثقة، وليست عيباً في الشهادة. إذا استمرت بعد تثبيت الجذر: يقرأ Chrome في Linux مخزن NSS بدلاً من مخزن النظام، راجع خطوة certutil؛ أو إنّ الملف المنسوخ لم ينتهِ بـ.crt وكانت update-ca-certificates تقول 0 added؛ أو إنّ الخادم يقدّم شهادة مختلفة عن الشهادة التي وثقت بها. قارن بصمات الشهادات باستخدام openssl s_client -connect git.internal.lan:443 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256.

NET::ERR_CERT_COMMON_NAME_INVALID، لا تحتوي الشهادة على SAN، أو لا يغطي SAN الاسم الظاهر في شريط العنوان. الحالة الشائعة هي أن SAN يسرد DNS:git.internal.lan، بينما انتقل المستخدم إلى https://10.8.0.1. لا يمكن لتغييرات مخزن الثقة إصلاح هذه المشكلة؛ أعد إصدار الشهادة مع إضافة الإدخال المفقود.

curl: (60) SSL certificate problem: self-signed certificate، لا يثق curl بالشهادة. ويعني البديل self-signed certificate in certificate chain الشيء نفسه بالنسبة إلى شهادة موقّعة من CA الخاص بك. الإصلاح لمرة واحدة هو curl --cacert lab-ca.crt https://...؛ والإصلاح الدائم هو تعديل مخزن الثقة. لا تستخدم -k.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (أو Expecting: CERTIFICATE REQUEST، أو no start line)، وهذا يعني وجود التباس في PEM. لقد مرّرت إلى OpenSSL نوع الملف الخطأ: مفتاحاً أو CSR عندما كان يتوقع شهادة، أو ملف DER ثنائياً عندما كان يتوقع PEM. يوضح لك head -1 filename ما لديك فعلياً، بينما تبدأ الشهادة بـ-----BEGIN CERTIFICATE-----. بالنسبة إلى DER، حوّله باستخدام openssl x509 -inform der -in file.der -out file.crt.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch)، لا تنتمي الشهادة والمفتاح إلى الزوج نفسه، ويحدث ذلك عادةً لأن أمر التوليد شُغّل مرتين واختلطت الملفات. تحقّق باستخدام openssl x509 -in git.internal.crt -noout -pubkey | sha256sum مقابل openssl pkey -in git.internal.key -pubout | sha256sum؛ فتطابق التجزئات يعني تطابق الزوج. إذا اختلفت، فأعد توليدهما معاً.

FAQ

لماذا يستمر Chrome في عرض الرسالة "غير آمن" بعد أن أنشأت شهادة موقعة ذاتياً؟

إذا كان الخطأ هو NET::ERR_CERT_AUTHORITY_INVALID، فالشهادة سليمة، لكن Chrome لا يملك سبباً للوثوق بها بعد. ثبّتها، أو ثبّت جذر CA الخاص بك، في مخزن الثقة لدى العميل. تذكّر أن Chrome على Linux يستخدم قاعدة بيانات NSS عبر certutil، وليس مخزن النظام. إذا كان الخطأ هو NET::ERR_CERT_COMMON_NAME_INVALID، فالشهادة تفتقر إلى Subject Alternative Name يطابق URL، ويجب إعادة إصدارها باستخدام -addext "subjectAltName=...".

كيف أجعل curl يثق بشهادة موقعة ذاتياً من دون -k؟

انسخ الشهادة، بتنسيق PEM وامتداد .crt، إلى /usr/local/share/ca-certificates/، ثم شغّل sudo update-ca-certificates. يجب أن يظهر في الخرج 1 added. بعد ذلك، يتحقق curl منها مثل أي شهادة عامة. لطلب واحد من دون تعديل النظام، يتحقق curl --cacert /path/to/cert.crt من الشهادة باستخدام ذلك الملف وحده. أما -k فيعطّل التحقق بالكامل، ولا ينبغي استخدامه في أي سكربت.

ما مدة صلاحية الشهادة الموقعة ذاتياً؟

تقنياً، يمكن أن تكون صالحة للمدة التي تريدها. تنطبق حدود CA/Browser Forum، وهي 200 يوم حالياً و47 يوماً بحلول 2029، على مراجع التصديق الموثوقة علناً، وليس على الثقة الخاصة. عملياً، حدّد صلاحية شهادات الخوادم بـ825 يوماً، لأن أجهزة Apple ترفض الشهادات الأطول بغض النظر عن الجهة المصدرة. يُعدّ جذر خاص صالحاً لمدة عشر سنوات، مع شهادات طرفية صالحة لمدة سنتين (-days 730)، إعداداً مناسباً. حدّد موعد التجديد في التقويم، لأن انتهاء شهادة داخلية قد يوقف كل شيء بصمت في تاريخ لا يتذكره أحد.

هل أستخدم شهادة موقعة ذاتياً أم Let's Encrypt؟

إذا كان للخدمة اسم DNS عام ويمكن الوصول إليها من الإنترنت، فاستخدم Let's Encrypt دائماً. فهي مجانية ومؤتمتة وموثوقة مسبقاً لدى كل عميل. تُستخدم الشهادة الموقعة ذاتياً، أو CA خاص، للحالات التي لا تستطيع Let's Encrypt إصدار شهادة لها: عناوين IP الخاصة، وأسماء المضيفين الداخلية مثل .lan، والشبكات المعزولة، والخدمات المخفية عمداً خلف VPN. يعتمد القرار على إمكانية الوصول والتسمية، وليس على قوة الأمان. التشفير متماثل.

لماذا تُرفض شهادتي حتى بعد إضافتها إلى /usr/local/share/ca-certificates؟

تحقق من ثلاثة أمور. يجب أن ينتهي اسم الملف بالامتداد .crt. يُتخطى الملف الذي يستخدم امتداد .pem بصمت، ويعرض update-ca-certificates الرسالة 0 added. يجب أن يكون المحتوى نص PEM يبدأ بـ-----BEGIN CERTIFICATE-----، وليس ملفاً ثنائياً بتنسيق DER. ويجب أن يستخدم التطبيق مخزن النظام فعلياً. يحتفظ كل من Chrome على Linux وFirefox وPython requests وNode.js وJava بمخزن ثقة خاص، ولذلك يجب إضافة الشهادة إلى كل منها بشكل منفصل.

#openssl#tls#self-signed#ubuntu#أمان