كيفية إنشاء CSR لشهادة توقيع التعليمات البرمجية باستخدام Java Keytool

تُنشئ أداة keytool المرفقة مع Java Development Kit (JDK) زوج مفاتيح داخل مخزن مفاتيح Java (keystore) وتحوّله إلى CSR (طلب توقيع الشهادة)، وهو الكتلة المُرمّزة التي تقرؤها جهة إصدار الشهادات (CA) لتحديد هويتك قبل إصدار الشهادة. بالنسبة لتوقيع الأكواد، فإن ما يُسمح باستخدام keytool من أجله شرعيًا قد تغيّر في 1 يونيو 2023. يوضح هذا الدليل القاعدة أولًا، ثم يستعرض أوامر keytool التي لا تزال صحيحة: مقابل مخزن مفاتيح برمجي للتوقيع الداخلي، ومقابل رمز مادي (token) أو HSM من خلال PKCS#11.

يجب إنشاء مفاتيح توقيع الأكواد على الأجهزة (Hardware)

منذ 1 يونيو 2023، تشترط متطلبات الأساس لتوقيع الأكواد الصادرة عن منتدى CA/Browser أن يُنشأ المفتاح الخاص لكل شهادة توقيع أكواد موثوقة عمومًا ويُخزَّن في وحدة تشفير مادية تلبي معيار FIPS 140-2 Level 2، أو Common Criteria EAL4+، أو معيارًا مكافئًا. يجب أن يكون المفتاح غير قابل للتصدير. ينطبق هذا على الشهادات القياسية (التحقق من المؤسسة) وكذلك على شهادات التحقق الموسّع. كانت شهادات EV لتوقيع الأكواد تتطلب دائمًا أجهزة مادية؛ وقد وسّع تغيير عام 2023 القاعدة نفسها لتشمل الشهادات القياسية. وتحدد المتطلبات نفسها حدًا أدنى لحجم المفتاح وهو RSA 3072 لشهادات توقيع الأكواد، ساريًا منذ 1 يونيو 2021.

النتيجة المترتبة على هذه الصفحة مباشرة. ملف مخزن المفاتيح الذي تنشئه keytool على جهاز الكمبيوتر المحمول أو الخادم الخاص بك، سواء كان بصيغة PKCS12 أو تنسيق JKS الأقدم، يحتوي على مفتاح برمجي. طلب CSR المُنشأ منه لا يُقبل من قِبل جهة إصدار شهادات عامة لشهادة توقيع أكواد. توقفت جهات إصدار الشهادات عن دعم إنشاء المفاتيح عبر المتصفح وملفات المفاتيح القابلة للتنزيل لهذه المنتجات. يصدر مفتاحك الآن من أحد مكانين:

• رمز (token) مُهيّأ مسبقًا ترسله لك جهة CA. تُنشئ جهة CA زوج المفاتيح وCSR على رمز USB معتمد من جانبها، وتُحمّل الشهادة الصادرة عليه، وترسل لك الرمز بالبريد. لا يوجد CSR يتوجب عليك إنشاؤه.
• HSM أو رمز خاص بك، مع إثبات المفتاح (key attestation). تُنشئ المفتاح داخل الجهاز، وتُصدر CSR منه، وتقدّم ملف إثبات يُثبت لجهة CA أن المفتاح تم إنشاؤه على جهاز متوافق ولا يمكن تصديره. كلا الجزأين مطلوب؛ CSR بدون إثبات صالح يُرفض.

يُحدَّد المسار المناسب عند الطلب. للمقارنة، راجع طرق تسليم شهادة توقيع الأكواد. إذا كنت تمتلك بالفعل جهازًا متوافقًا، اتبع الدليل الخاص بجهازك: إنشاء CSR وإثبات المفتاح لجهاز YubiKey 5 FIPS أو دليل CSR وإثبات المفتاح لجهاز Luna Network Attached HSM v7.x.

أين لا تزال keytool مناسبة

لا شيء مما سبق يُلغي دور keytool. فهي تبقى الأداة المناسبة في ثلاث حالات، والأولى فقط منها تُنتج CSR يمكنك إرساله إلى جهة CA عامة:

• كواجهة أمامية لـ PKCS#11 مع الرمز أو HSM الخاص بك. تتحدث keytool بلغة PKCS#11 بشكل أصلي. وجّهها نحو مكتبة PKCS#11 الخاصة بمورّدك، ولن يغادر المفتاح الجهاز أبدًا، بينما لا يزال الأمر المألوف -certreq يُنتج CSR. الأوامر موجودة في قسم الأجهزة أدناه.
• للتوقيع الداخلي أو على مستوى المؤسسة. إذا كنت توقّع برامج داخلية باستخدام جهة CA خاصة بمؤسستك، فإن سياستك الداخلية هي التي تحكم تخزين المفاتيح، وليس متطلبات الأساس العامة. مخزن المفاتيح البرمجي خيار طبيعي في هذه الحالة.
• للتدريب المسبق. يصبح ضبط اسم الموضوع (subject name) بشكل صحيح من المحاولة الأولى أسهل إذا نفّذت الأسئلة مرة واحدة مقابل مخزن مفاتيح مؤقت للاستخدام لمرة واحدة.

هناك حد واحد يستحق معرفته قبل أن تبدأ: keytool لا تُنشئ إثبات المفتاح (key attestation). يُنتج الإثبات باستخدام أداة المورّد الخاصة بالرمز أو HSM، لذلك حتى على مسار PKCS#11 ستستخدم أداة المورّد لهذا الملف وستستخدم keytool فقط لـ CSR.

إنشاء CSR باستخدام keytool

إذا كنت قد أنشأت CSR بالفعل وأصدرت جهة CA الشهادة، انتقل مباشرة إلى استيراد رد جهة CA، وهي الخطوة التي تفشل بصمت عندما لا يتطابق اللقب (alias).

تأتي keytool مرفقة مع JDK، لذا ثبّت نسخة حديثة من JDK أولًا إن لم تكن تمتلك واحدة. JDK 25 هو الإصدار الحالي طويل الأمد للدعم وJDK 26 هو الإصدار الحالي قصير الأمد. تعمل الأوامر أدناه على JDK 17 وما بعده، وتم الإشارة إلى اختلافات الإصدارات المهمة حيث تحدث. تأكد من أن الأداة موجودة ضمن مسارك:

java -version
keytool -help
jarsigner -version

بيئة تشغيل Java (JRE) وحدها لا تكفي، ووجود keytool عاملة ليس دليلاً على امتلاكك JDK: فبيئة Oracle JRE 8 القديمة تأتي مع keytool لكن بدون jarsigner. نفّذ الأوامر الثلاثة الآن. إذا استجاب الأمران الأولان ولم يستجب الثالث، فأنت تستخدم JRE فقط، وتثبيت JDK في هذه المرحلة أسهل من اكتشاف ذلك عندما تحاول التوقيع.

الخطوة 1: إنشاء مخزن المفاتيح وزوج المفاتيح

نفّذ هذا في الطرفية، أو في Command Prompt أو PowerShell على Windows، من داخل المجلد الذي تريد أن يوجد فيه ملف مخزن المفاتيح:

keytool -genkeypair -alias codesign -keyalg RSA -keysize 3072 -storetype PKCS12 -keystore codesign.p12

هناك أربعة تفاصيل في هذا الأمر تختلف عن التعليمات القديمة، وكل منها مهم:

• -genkeypair، وليس -genkey. لا تزال صيغة -genkey القديمة تعمل ولا تطبع keytool أي تحذير بشأنها، إلا أنها محفوظة في الكود المصدري فقط كلقب قديم (legacy alias) ولم تعد تظهر في أي مكان في وثائق JDK. اكتب -genkeypair.
• -storetype PKCS12، وليس JKS. JKS تنسيق مخزن مفاتيح مملوك لشركة Oracle. أما PKCS12 فهو التنسيق المعياري في الصناعة وهو الافتراضي في JDK منذ Java 9. إذا أنشأت مخزن مفاتيح بصيغة JKS رغم ذلك، تحذّرك keytool في كل أمر يتعامل معه: “The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format.”
• اسم الملف لا يحدد التنسيق. تسمية ملف باسم keystore.jks لا يجعله مخزن مفاتيح بصيغة JKS. تأخذ keytool النوع من -storetype، أو من خاصية keystore.type في ملف الأمان الخاص بـ JDK عندما تُغفلها. على JDK 9 وما بعده، تكون تلك الخاصية pkcs12، لذا فإن أمرًا يكتب إلى keystore.jks بدون -storetype ينتج بصمت ملف PKCS12 باسم مضلل.
• -keysize 3072، وليس 2048. تحدد متطلبات الأساس RSA 3072 كحد أدنى لتوقيع الأكواد، لذا فإن طلبًا بحجم 2048 بت يُرفض. تفترض إصدارات JDK الحالية 3072 لخوارزمية RSA افتراضيًا، لكن JDK 17 وما قبله يفترض 2048 بت افتراضيًا، لذا مرّر الخيار صراحةً ليعمل الأمر بنفس الطريقة في كل مكان.

اللقب (alias)، وهو codesign في المثال، هو تسمية هذا الإدخال داخل مخزن المفاتيح. اختر شيئًا ستتعرف عليه، ودوّنه: تحتاج إليه كل الأوامر اللاحقة، وعدم التطابق هو ما يفسد استيراد الشهادة الموصوف لاحقًا.

يُسمح أيضًا باستخدام مفتاح ECDSA. استبدل خيارات RSA بـ -keyalg EC -groupname secp256r1 إذا كنت تفضل P-256، وتأكد مع جهة CA أن المنتج الذي طلبته يدعم ECDSA.

الخطوة 2: الإجابة على الأسئلة التي تبني اسمك المميز (Distinguished Name)

تطلب keytool كلمة مرور مخزن المفاتيح مرتين، ثم تطرح ستة أسئلة بهذا الترتيب بالضبط. الترتيب مهم: يسأل السؤال الثاني عن الوحدة التنظيمية (organizational unit)، وليس عن المؤسسة، وتُدرجه الأدلة القديمة بشكل خاطئ، لذا فإن القارئ الذي يكتب اسم الشركة هناك يضعه في المكوّن الخاطئ من الاسم.

• ما هو اسمك الأول والأخير؟ يصبح هذا هو الاسم الشائع (CN)، رغم الصياغة. بالنسبة لشهادة توقيع الأكواد، فإن CN هو هوية الناشر التي سيراها المستخدمون، لذا أدخل الاسم القانوني الدقيق لمؤسستك، أو اسمك القانوني الكامل لشهادة فردية. لا تُدخل اسم نطاق (domain name) هنا.
• ما هو اسم وحدتك التنظيمية؟ القسم، مثل تقنية المعلومات (IT). لا تضغط Enter لتخطي هذا السؤال: عندئذ تكتب keytool القيمة الحرفية Unknown في الاسم، وينتهي الأمر بظهور OU=Unknown في CSR الخاص بك. إذا كنت لا تريد أي وحدة تنظيمية على الإطلاق، استخدم صيغة -dname أدناه واترك مكوّن OU خارج السلسلة.
• ما هو اسم مؤسستك؟ الاسم القانوني المسجّل، مكتوبًا كما يظهر في السجلات الرسمية. تتحقق جهة CA من هذا مقابل السجلات العامة.
• ما هو اسم مدينتك أو منطقتك؟ مدينة التسجيل، مكتوبة بالكامل.
• ما هو اسم ولايتك أو مقاطعتك؟ الاسم الكامل، وليس اختصارًا.
• ما هو رمز الدولة المكوّن من حرفين لهذه الوحدة؟ رمز ISO، مثل US.

تطبع keytool بعدها الاسم المُجمّع وتطلب منك تأكيده:

Is CN=Example LLC, OU=IT, O=Example LLC, L=Miami, ST=Florida, C=US correct?
  [no]:

الإجابة الافتراضية هي no، لذا فإن الضغط على Enter يعيدك عبر جميع الأسئلة الستة. اكتب yes للموافقة. اقرأ السطر بعناية أولًا: هذا هو الاسم المميز الكامل، وليس فقط الاسم الشائع، وكل مكوّن منه يذهب إلى CSR.

لا توجد كلمة مرور منفصلة للمفتاح في مخزن مفاتيح PKCS12. تنهي الأدلة القديمة هذه الخطوة بـ “أدخل كلمة مرور للمفتاح”، وهو سلوك JKS. في مخزن مفاتيح PKCS12، كلمة مرور المفتاح هي كلمة مرور المخزن نفسها، وإذا مررت -keypass بقيمة مختلفة تُخبرك keytool بذلك: “Different store and key passwords not supported for PKCS12 KeyStores. Ignoring user-specified -keypass value.”

لتخطي الأسئلة تمامًا، مرّر الاسم الكامل باستخدام -dname. احتفظ بالقيمة داخل زوج واحد من علامات الاقتباس المستقيمة:

keytool -genkeypair -alias codesign -keyalg RSA -keysize 3072 -storetype PKCS12 -keystore codesign.p12 -dname "CN=Example LLC, OU=IT, O=Example LLC, L=Miami, ST=Florida, C=US"

اترك -storepass بعيدًا عن سطر الأوامر ودع keytool تطلبها. تمرير كلمة المرور كوسيطة يكتبها في سجل الأوامر الخاص بالصدفة (shell history) ويعرّضها لأي شخص يستطيع سرد العمليات الجارية.

الخطوة 3: إنشاء CSR

يحتفظ مخزن المفاتيح الآن بمفتاح خاص وشهادة موقّعة ذاتيًا مؤقتة. حوّل هذا الإدخال إلى طلب شهادة:

keytool -certreq -alias codesign -keystore codesign.p12 -file codesign.csr

أدخل كلمة مرور مخزن المفاتيح عند مطالبتك بها. لا تحتاج إلى -storetype هنا: تكتشف keytool تنسيق ملف مخزن مفاتيح موجود بالفعل. يجب أن يكون اللقب هو نفسه من الخطوة 1، لأن CSR يُوقَّع بالمفتاح الخاص لذلك الإدخال.

هذا الأمر لا يُنشئ مفتاحًا خاصًا. أُنشئ المفتاح في الخطوة 1 ويبقى داخل مخزن المفاتيح، ولهذا السبب أصبح ملف مخزن المفاتيح وكلمة مروره الآن حساسين تمامًا مثل المفتاح نفسه. أي شخص يمتلك كليهما يمكنه توقيع البرامج باسمك.

الخطوة 4: فحص CSR قبل إرساله

يكلّفك رفض CSR دورة تحقق كاملة، لذا فك تشفيره واقرأه:

keytool -printcertreq -file codesign.csr

تأكّد من ثلاثة أمور في الناتج. يجب أن يدرج سطر Subject تفاصيلك في المكوّنات الصحيحة، مع اسم المؤسسة القانوني في O وهوية الناشر في CN. يجب أن يقرأ سطر المفتاح العام 3072-bit RSA key أو أكبر. يجب أن تكون خوارزمية التوقيع من عائلة SHA-2: توقّع إصدارات JDK الحالية طلب RSA بحجم 3072 بت باستخدام SHA384withRSA وتستخدم الإصدارات الأقدم SHA256withRSA، وكلاهما مقبول. تلك الخوارزمية تثبت فقط أنك تمتلك المفتاح الخاص، وهي ليست الخوارزمية التي ستستخدمها جهة CA لتوقيع شهادتك.

يمكنك أيضًا لصق الطلب في أداة فك تشفير CSR الخاصة بنا لقراءة نفس الحقول في المتصفح.

عند إرسال الطلب، افتح الملف في محرر نصوص عادي وانسخ كل شيء، بما في ذلك السطرين الأول والأخير. تكتب keytool هذه العلامات بالضبط، بخمس شرطات على كل جانب:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIID3TCCAkUCAQAwaDELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExDjAM
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----

صياغة NEW CERTIFICATE REQUEST طبيعية بالنسبة لناتج keytool وتقبلها نماذج التسجيل. إذا استبدل محررك أي سلسلة من الشرطات بشرطة طويلة، سيُرفض الطلب: أعد كتابة العلامات كشرطات عادية أو انسخ الملف باستخدام محرر أكواد بدلاً من ذلك.

إنشاء CSR على رمز (token) أو HSM باستخدام keytool

هذا هو المسار الذي يُنتج CSR يمكن لجهة CA عامة العمل به. تتحدث keytool مع الرمز المادي عبر موفّر SunPKCS11، لذا يُنشأ زوج المفاتيح داخل الجهاز ولا يوجد أبدًا كملف. ابدأ بكتابة ملف تكوين صغير، مثل token.cfg، يسمّي رمزك ويشير إلى مكتبة PKCS#11 التي ثبّتها مورّدك:

name = token
library = /usr/local/lib/libeToken.so

هذان السطران، name وlibrary، هما الوحيدان المطلوبان. مسار المكتبة خاص بالمورّد ويختلف حسب نظام التشغيل، لذا خذه من وثائق رمزك بدلاً من هذا المثال. على Windows، يكون مكتبة DLL ضمن دليل النظام. بدون سطر slot، يرتبط الموفّر بأول فتحة (slot) يُبلغ عنها الجهاز، وهو ما تريده عند توصيل رمز واحد فقط. إذا كان لديك أكثر من قارئ أو رمز، أضف إما slotListIndex مع الموضع في تلك القائمة، بدءًا من الصفر، أو slot مع معرّف الفتحة الرقمي الذي تطبعه أداة المورّد الخاصة بك. يجوز ظهور واحد فقط من الاثنين في الملف، ومعرّف الفتحة ليس نفس رقم موضع القائمة، لذا لا تُخمّن slot = 0.

اسرد ما هو موجود على الجهاز. يوفر الرمز اللقب (alias)، لذا تحتاج إلى هذا قبل أي شيء آخر:

keytool -list -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg

-keystore NONE مطلوب كلما لم يكن مخزن المفاتيح ملفًا، وطلب كلمة المرور يسأل عن رمز PIN الخاص بالرمز المادي. تقبل keytool أيضًا -addprovider SunPKCS11 -providerarg token.cfg بدلًا من زوج -providerClass و-providerArg؛ كلا الشكلين يعمل، وتُظهر وثائق جهات CA عادة الشكل الأقدم.

وبعد معرفة اللقب، أنشئ المفتاح على الجهاز ثم اطلب CSR مقابله:

keytool -genkeypair -alias codesign -keyalg RSA -keysize 3072 -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg -dname "CN=Example LLC, O=Example LLC, L=Miami, ST=Florida, C=US"

keytool -certreq -alias codesign -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg -file codesign.csr

ينطبق تحذيران هنا. بعض الرموز لا تسمح بإنشاء المفتاح عبر PKCS#11 وتتوقع منك استخدام أداة المورّد الخاصة، وهذا أمر جيد: لا تزال keytool قادرة على إنشاء CSR مقابل مفتاح أنشأته أداة المورّد. كما لا يمكن لـ keytool إنتاج ملف الإثبات الذي ستطلبه جهة CA، لذا أنشئ ذلك باستخدام أداة المورّد في نفس وقت إنشاء المفتاح، باتباع دليل YubiKey أو Luna HSM.

استيراد رد جهة CA إلى نفس اللقب (alias)

عندما تصل الشهادة، يجب أن تعود إلى الإدخال الذي أنشأ CSR. استيرادها في أي مكان آخر لا يزال يجعل keytool تُبلّغ بالنجاح بينما تُنتج مخزن مفاتيح غير قادر على التوقيع، لذا اقرأ هذا القسم قبل تشغيل أي شيء.

استورد جذر جهة CA وأي شهادات وسيطة أولًا، كل واحدة تحت لقبها الخاص:

keytool -importcert -trustcacerts -alias caroot -file root.crt -keystore codesign.p12

تطبع keytool الشهادة التي على وشك تخزينها وتسأل Trust this certificate؟ مع كون no هو الإجابة الافتراضية، لذا اكتب yes. تحقّق من البصمة (fingerprint) مقارنةً بتلك التي تنشرها جهة CA الخاصة بك قبل الإجابة.

تجاوز استيراد الجذر ويفشل الأمر التالي برسالة لا تقدم أي تلميح عن السبب:

keytool error: java.lang.Exception: Failed to establish chain from reply

الآن استورد الشهادة الصادرة لك باستخدام نفس اللقب الذي استخدمته في الخطوة 1:

keytool -importcert -alias codesign -file codesign.crt -keystore codesign.p12

الرسالة التي تريدها هي Certificate reply was installed in keystore. تعني أن keytool تعرّفت على مفتاح خاص موجود تحت ذلك اللقب وربطت الشهادة الصادرة وسلسلتها به.

إذا اخترعت لقبًا جديدًا بدلًا من ذلك، تقبل keytool الملف وتطبع Certificate was added to keystore. يبدو هذا وكأنه نجاح لكنه ليس كذلك. خزّنت keytool الشهادة كإدخال موثوق مستقل بدون مفتاح خاص خلفه، ولا يمكن لهذا الإدخال أبدًا توقيع أي شيء. أما اللقب الأصلي، فلا يزال يحتفظ بالشهادة الموقّعة ذاتيًا المؤقتة من الخطوة 1. تحقّق من أي الاثنين لديك:

keytool -list -keystore codesign.p12

يجب أن يُدرج لقب التوقيع الخاص بك كـ PrivateKeyEntry. اللقب المعروض كـ trustedCertEntry هو الخطأ الموصوف أعلاه. احذفه باستخدام keytool -delete -alias wrongalias -keystore codesign.p12 وكرر الاستيراد مع اللقب الصحيح. أضف -v إلى أمر list للتأكد من أن الإدخال يحمل الآن سلسلة شهادات كاملة بدلاً من شهادة موقّعة ذاتيًا مفردة.

على الرمز المادي، لا يوجد ما تستورده في معظم الحالات، لأن جهة CA تُحمّل الشهادة على الجهاز قبل شحنه. إذا أرسلت لك جهة CA ملف شهادة لمفتاح أنشأته على HSM الخاص بك، استخدم نفس أمر -importcert مع خيارات PKCS#11 من القسم السابق.

توقيع ملف JAR باستخدام الشهادة

الغرض من وضع شهادة توقيع أكواد في مخزن مفاتيح Java هو توقيع ملفات JAR باستخدام jarsigner، التي تأتي أيضًا مرفقة مع JDK. مع تثبيت الشهادة تحت اللقب الصحيح:

jarsigner -keystore codesign.p12 -tsa https://your-ca-timestamp-url application.jar codesign

مرّر دائمًا -tsa مع رابط الطابع الزمني (timestamp URL) الذي تنشره جهة CA الخاصة بك. يسجّل الطابع الزمني أن ملف JAR وُقّع بينما كانت الشهادة لا تزال سارية المفعول، لذا يستمر التوقيع في العمل بعد انتهاء صلاحية الشهادة. بدونه، ستتوقف كل نسخة من برنامجك عن التحقق منها في اليوم الذي تنتهي فيه صلاحية الشهادة.

عندما يوجد المفتاح على رمز مادي، وجّه jarsigner إلى PKCS#11 تمامًا كما تفعل keytool:

jarsigner -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg token.cfg -tsa https://your-ca-timestamp-url application.jar codesign

إذا كانت مساحة الرمز غير كافية لسلسلة الشهادات الكاملة، وفّرها بشكل منفصل باستخدام -certchain. تحقّق من النتيجة بعد ذلك:

jarsigner -verify -verbose -certs application.jar

يطبع التشغيل الناجح jar verified إلى جانب الاسم المميز للموقّع وتفاصيل الطابع الزمني. تستخدم إصدارات JDK الحالية SHA-384 كخوارزمية تلخيص افتراضية، لذا نادرًا ما تحتاج إلى تعيين -digestalg أو -sigalg يدويًا.

الطرق الأخرى لإنشاء هذا الطلب مغطاة في أدلة OpenSSL، وCertReq، وMicrosoft Management Console، وmacOS Keychain Access، وتنطبق قاعدة الأجهزة نفسها على جميعها. راجع أيضًا مجموعتنا الكاملة من دروس توقيع الأكواد والنظرة العامة على إنشاء CSR لشهادات توقيع الأكواد. إذا كنت بحاجة إلى CSR باستخدام keytool لشهادة موقع ويب بدلًا من شهادة توقيع أكواد، اتبع دليل Tomcat أو JBoss بدلاً من ذلك.

الأسئلة الشائعة