كيفية إنشاء شهادة SSL ذاتية التوقيع لـ Nginx على Ubuntu

  • 471 المشاهدات
  • قراءة دقيقة واحدة
هادي بهادوري
  • 11 أبريل 2024
0 الأسهم
0
0
0
0
0
الأسهم
0
0
0
0

مقدمة

TLS، أو Transport Layer Security، وسابقتها SSL، والتي تعني Secure Sockets Layer، هما بروتوكولان ويب يستخدمان لحماية وتشفير حركة المرور عبر شبكة الكمبيوتر.

باستخدام TLS/SSL، يمكن للخوادم إرسال بيانات آمنة بين الخادم والعملاء دون قدرة أي طرف خارجي على اعتراض الرسائل. كما يساعد نظام الشهادات المستخدمين على التحقق من هوية المواقع التي يتفاعلون معها.

في هذا الدليل، سوف تقوم بإعداد شهادة SSL ذاتية التوقيع لاستخدامها مع خادم الويب Nginx على خادم Ubuntu.

المتطلبات الأساسية
  • قبل أن تبدأ، يجب أن يكون لديك مستخدم غير جذر تم تكوينه بامتيازات sudo وجدار حماية ممكّن.
  • يجب عليك أيضًا تثبيت خادم الويب Nginx.
  • إذا كنت تريد تثبيت مجموعة LEMP كاملة (Linux، Nginx، MySQL، PHP) على الخادم الخاص بك.

الخطوة 1 - إنشاء شهادة TLS

يعمل بروتوكول TLS/SSL بمزيج من شهادة عامة ومفتاح خاص. يُحفظ مفتاح SSL سرًا على الخادم، ويُشفّر المحتوى المُرسل إلى العملاء. تُشارك شهادة SSL علنًا مع أي شخص يطلب المحتوى. ويمكن استخدامها لفك تشفير المحتوى المُوقّع بمفتاح SSL المُرتبط.

بإمكانك إنشاء زوج مفاتيح وشهادة ذاتية التوقيع باستخدام OpenSSL في أمر واحد:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

فيما يلي ملخص لما يفعله كل جزء من هذا الأمر:

  • سودويسمح أمر sudo لأعضاء مجموعة sudo بترقية صلاحياتهم مؤقتًا إلى مستخدم آخر (افتراضيًا، المستخدم الفائق أو المستخدم الجذر). هذا ضروري في هذه الحالة لأننا ننشئ شهادة وزوج مفاتيح في مجلد /etc/ لا يمكن الوصول إليهما إلا من قِبل المستخدم الجذر أو حسابات أخرى ذات امتيازات.
  • أوبن إس إس إل:هذه هي أداة سطر الأوامر الرئيسية لإنشاء وإدارة شهادات OpenSSL والمفاتيح والملفات الأخرى.
  • طلبيُحدد هذا الأمر الفرعي أننا نريد استخدام إدارة طلبات توقيع الشهادات (CSR) الخاصة بـ X.509. "X.509" هو معيار بنية تحتية للمفتاح العام تلتزم به بروتوكولات SSL وTLS لإدارة المفاتيح والشهادات. نريد إنشاء شهادة X.509 جديدة، لذلك نستخدم هذا الأمر الفرعي.
  • –x509:يؤدي هذا إلى تعديل الأمر الفرعي السابق من خلال القول بأننا نريد إنشاء شهادة موقعة ذاتيًا بدلاً من إنشاء طلب توقيع شهادة، كما هو الحال عادةً.
  • –العقدهذا يُلزم OpenSSL بتخطي خيار تأمين شهادتنا بعبارة مرور. نحتاج إلى أن يتمكن Nginx من قراءة الملف دون تدخل المستخدم عند بدء تشغيل الخادم. تمنع عبارة المرور حدوث ذلك، إذ يجب علينا إدخالها بعد كل إعادة تشغيل.
  • -أيام 365يحدد هذا الخيار مدة صلاحية الشهادة. حددناها هنا بسنة واحدة.
  • -newkey rsa:2048: يُحدد أننا نريد إنشاء شهادة جديدة ومفتاح جديد في آنٍ واحد. لم نُنشئ المفتاح اللازم لتوقيع الشهادة في الخطوة السابقة، لذا نحتاج إلى إنشائه مع الشهادة. يُشير الجزء rsa:2048 إلى إنشاء مفتاح RSA بطول 2048 بت.
  • -مفتاح الخروج:يخبر هذا السطر OpenSSL بالمكان الذي يجب أن يضع فيه ملف المفتاح الخاص الذي تم إنشاؤه والذي نقوم بإنشائه.
  • -خارج:هذا يخبر OpenSSL بالمكان الذي يجب أن يضع فيه الشهادة التي نقوم بإنشائها.

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

أدخل الأوامر بشكل صحيح. السطر الأهم هو الذي يطلب اسم المشترك (مثل اسم النطاق المؤهل بالكامل للخادم أو اسمك). ستحتاج إلى إدخال اسم النطاق المرتبط بخادمك، أو على الأرجح عنوان IP العام لخادمك.

سيكون الأمر بأكمله على النحو التالي:

Output
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name (eg, section) []:Ministry of Water Slides
Common Name (e.g. server FQDN or YOUR name) []:server_IP_address
Email Address []:admin@your_domain.com

سيتم وضع كلا الملفين اللذين قمت بإنشائهما في الدلائل الفرعية المناسبة لدليل /etc/ssl.

أثناء استخدام OpenSSL، يجب عليك أيضًا إنشاء مجموعة Diffie-Hellman (DH) قوية، والتي تستخدم السرية التامة عند التفاوض مع العملاء.

يمكنك القيام بذلك عن طريق الكتابة:

sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

سيستغرق هذا بعض الوقت، ولكن بمجرد الانتهاء منه، سيكون لديك مجموعة DH قوية في /etc/nginx/dhparam.pem والتي سيتم استخدامها أثناء التكوين.

الخطوة 2 - تكوين Nginx لاستخدام SSL

الآن بعد إنشاء ملفات المفتاح والشهادة في الدليل /etc/ssl، تحتاج إلى تعديل تكوين Nginx لاستخدامها.

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

تتيح لك طريقة تكوين Nginx هذه الحفاظ على نظافة كتل الخادم ووضع أقسام التكوين المشتركة في وحدات قابلة لإعادة الاستخدام.

إنشاء جزء تكوين يشير إلى مفتاح SSL والشهادة

أولاً، استخدم محرر النصوص المفضل لديك لإنشاء مقتطف جديد لتكوين Nginx في مجلد /etc/nginx/snippets. المثال التالي يستخدم nano.

لتحديد غرض هذا الملف بشكل صحيح، قم بتسميته self-signed.conf:

sudo nano /etc/nginx/snippets/self-signed.conf

في هذا الملف، يجب ضبط توجيه ssl_certificate لملف الشهادة، ومفتاح ssl_certificate_key للمفتاح المرتبط. سيبدو الشكل كما يلي:

ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

بعد إضافة هذه الأسطر، احفظ الملف واخرج من المحرر. إذا استخدمت برنامج nano لتحرير الملف، يمكنك القيام بذلك بالضغط على CTRL + X، Y، ثم ENTER.

إنشاء جزء تكوين بإعدادات تشفير قوية

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

يمكن إعادة استخدام المعلمات التي قمت بتعيينها في تكوينات Nginx المستقبلية، حتى تتمكن من إعطاء الملف اسمًا عامًا:

sudo nano /etc/nginx/snippets/ssl-params.conf

لإعداد Nginx SSL بشكل آمن، نعتمد على توصيات Cipherlist.eu. يُعد Cipherlist.eu موردًا مفيدًا وسهل الفهم لفهم إعدادات التشفير المستخدمة في البرامج الشائعة.

بالنسبة لأغراضك، انسخ الإعدادات المقدمة بالضبط، ولكنك ستحتاج إلى إجراء بعض التغييرات الصغيرة أولاً.

أولاً، أضف مُحلِّل DNS المُفضَّل لديك لطلبات التوجيه الصاعد. سنستخدم جوجل (8.8.8.8 و8.8.4.4) لهذا الدليل.

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

أضف ما يلي إلى ملف ssl-params.conf الخاص بك:

ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem; 
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_ecdh_curve secp384r1;
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# Disable strict transport security for now. You can uncomment the following
# line if you understand the implications.
#add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

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

عندما تنتهي، قم بحفظ الملف وإغلاقه بالضغط على CTRL + X ثم Y وENTER.

تكوين Nginx لاستخدام SSL

الآن بعد أن أصبحت لديك القطع الخاصة بك، يمكنك ضبط تكوين Nginx لتمكين SSL.

يفترض هذا الدليل أنك تستخدم ملف تكوين كتلة خادم مخصص في المجلد /etc/nginx/sites-available. يتبع هذا الدليل أيضًا قواعد البرنامج التعليمي الأساسي لـ Nginx، ويستخدم /etc/nginx/sites-available/your_domain في هذا المثال. استبدل اسم ملف التكوين إذا لزم الأمر.

قبل المضي قدمًا، قم بعمل نسخة احتياطية لملف التكوين الحالي لديك:

sudo cp /etc/nginx/sites-available/your_domain /etc/nginx/sites-available/your_domain.bak

الآن افتح ملف التكوين لإجراء الإعدادات:

sudo nano /etc/nginx/sites-available/your_domain

داخليًا، من المحتمل أن تبدأ كتلة الخادم لديك على نحو مشابه لما يلي:

server {
listen 80;
listen [::]:80;
root /var/www/your_domain/html;
index index.html index.htm index.nginx-debian.html;
server_name your_domain www.your_domain;
location / {
try_files $uri $uri/ =404;
}
}

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

في ملف التكوين الموجود، قم بتحديث عبارتي الاستماع لاستخدام المنفذ 443 وssl، ثم أضف ملفي التجزئة اللذين قمت بإنشائهما في الخطوات السابقة:

server {
listen 443 ssl;
listen [::]:443 ssl;
include snippets/self-signed.conf;
include snippets/ssl-params.conf;
root /var/www/your_domain/html;
index index.html index.htm index.nginx-debian.html;
server_name your_domain.com www.your_domain.com;
location / {
try_files $uri $uri/ =404;
}
}

بعد ذلك، أضف كتلة خادم ثانية إلى ملف التكوين بعد القوس الختامي (}) للكتلة الأولى:

server {
listen 80;
listen [::]:80;
server_name your_domain.com www.your_domain.com;
return 302 https://$server_name$request_uri;
}

هذا تكوين أساسي يستمع إلى المنفذ 80 ويعيد التوجيه إلى HTTPS. عند الانتهاء من التحرير، احفظ الملف وأغلقه بالضغط على CTRL + X ثم Y ثم ENTER.

الخطوة 3 – تكوين جدار الحماية

إذا قمتَ بتفعيل جدار حماية ufw، كما هو موصى به في دليل المتطلبات الأساسية، فستحتاج إلى ضبط الإعدادات للسماح بحركة مرور SSL. لحسن الحظ، يُسجّل Nginx بعض الملفات الشخصية مع ufw عند التثبيت.

يمكنك تصفح الملفات الشخصية المتاحة عن طريق الكتابة:

sudo ufw app list

ستظهر قائمة مثل القائمة أدناه:

Output
Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH

يمكنك التحقق من الإعدادات الحالية عن طريق كتابة sudo ufw status:

sudo ufw status

من المحتمل أن يؤدي ذلك إلى إنتاج الاستجابة التالية، مما يعني أنه يُسمح فقط بحركة مرور HTTP إلى خادم الويب:

Output
Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)

للسماح بحركة مرور HTTPS، يمكنك تحديث أذونات ملف التعريف "Nginx Full" ثم إزالة إذن "Nginx HTTP" الإضافي:

sudo ufw allow 'Nginx Full'
sudo ufw delete allow 'Nginx HTTP'

بعد تشغيل sudo ufw status، يجب أن تحصل على الناتج التالي:

sudo ufw status
Output
Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx Full ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx Full (v6) ALLOW Anywhere (v6)

يؤكد هذا الإخراج أن تكوين جدار الحماية الخاص بك قد اكتمل بنجاح وأنك جاهز لتمكين التغييرات في Nginx.

الخطوة 4 – تمكين التغييرات في Nginx

بمجرد الانتهاء من تغييرات وتكوينات جدار الحماية، يمكنك إعادة تشغيل Nginx لتطبيق التغييرات الجديدة.

أولاً، تأكد من عدم وجود أخطاء لغوية في الملفات. يمكنك القيام بذلك بكتابة sudo nginx -t:

sudo nginx -t

إذا كان كل شيء ناجحًا، فستتلقى النتيجة التي تبدو مثل هذا:

Output
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt"
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

لاحظ التحذير في البداية. كما ذكرنا سابقًا، سيؤدي هذا الإعداد تحديدًا إلى ظهور تحذير لأن شهادتك المُوقّعة لا يمكنها استخدام تشفير SSL. هذا أمر متوقع، وسيظل خادمك قادرًا على تشفير الاتصالات بشكل صحيح.

إذا تطابقت نتائجك مع مثالنا، فهذا يعني أن ملف التكوين لديك خالٍ من الأخطاء النحوية. في هذه الحالة، يمكنك إعادة تشغيل Nginx بأمان لتطبيق التغييرات:

sudo systemctl restart nginx

الآن بعد إعادة تشغيل النظام بالتغييرات الجديدة، يمكنك مواصلة الاختبار.

الخطوة 5 – اختبار التشفير

أنت الآن جاهز لاختبار خادم SSL الخاص بك.

افتح متصفح الويب الخاص بك واكتب https:// متبوعًا باسم نطاق الخادم أو عنوان IP في شريط العناوين:

/* Your code... */https://server_domain_or_IP

اعتمادًا على متصفحك، قد تتلقى تحذيرًا لأن الشهادة التي تم إنشاؤها لم يتم توقيعها بواسطة إحدى هيئات الشهادات الموثوقة في متصفحك:


هذا التحذير متوقع وطبيعي. نحن مهتمون فقط بتشفير شهادتنا، وليس بالتحقق من بيانات اعتماد مُضيفك من قِبل جهة خارجية. انقر على "خيارات متقدمة" ثم على الرابط المُرفق للانتقال إلى مُضيفك:


في هذه المرحلة، سيتم إعادة توجيهك إلى موقعك. في مثالنا، سيظهر في شريط عنوان المتصفح رمز قفل عليه علامة "x"، مما يعني أنه لا يمكن التحقق من الشهادة. سيظل الاتصال مشفرة. يُرجى ملاحظة أن هذا الرمز قد يختلف باختلاف متصفحك.

إذا قمت بتكوين Nginx مع كتلتين خادم، وإعادة توجيه محتوى HTTP إلى HTTPS تلقائيًا، فيمكنك أيضًا التحقق مما إذا كانت عملية إعادة التوجيه تعمل بشكل صحيح:

http://server_domain_or_IP... */

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

الخطوة 6 - التغيير إلى إعادة التوجيه الدائمة

إذا نجحت عملية إعادة التوجيه بشكل صحيح وكنت متأكدًا من أنك تريد السماح بحركة المرور المشفرة فقط، فستحتاج إلى تغيير تكوين Nginx لجعل إعادة التوجيه دائمة.

أعد فتح ملف تكوين كتلة الخادم الخاص بك:

sudo nano /etc/nginx/sites-available/your_domain

ابحث عن إعادة التوجيه 302 وقم بتغييره إلى إعادة توجيه 301:

 return 301 https://$server_name$request_uri;

احفظ وأغلق الملف بالضغط على CTRL + X ثم Y وENTER.

تحقق من إعداداتك بحثًا عن أخطاء نحوية:

sudo nginx -t

عندما تكون مستعدًا، أعد تشغيل Nginx لجعل إعادة التوجيه دائمة:

sudo systemctl restart nginx

بعد إعادة التشغيل، سيتم تطبيق التغييرات وسيصبح إعادة التوجيه الآن دائمًا.

نتيجة

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

في هذه المقالة:
,,
تم كتابة التدوينة بواسطة:
يتبع
اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

المقال السابق
المقال التالي
قد يعجبك أيضاً