يمكن لأداة الشهادات (Certificates snap-in) في وحدة تحكم إدارة Microsoft (MMC) إنشاء طلب شهادة PKCS #10 على جهاز Windows دون الحاجة إلى أي برامج إضافية. يغطي هذا الدليل شاشات هذا المعالج خطوة بخطوة لإنشاء شهادة توقيع الأكواد (code signing certificate)، ويبدأ بالجزء الذي تتجاهله معظم الإرشادات القديمة: القواعد الخاصة بمفاتيح توقيع الأكواد الخاصة تغيّرت في 1 يونيو 2023، وهي التي تحدد ما إذا كان طلب MMC قابلًا للاستخدام أصلًا.
اقرأ هذا الشرط قبل فتح المعالج. باقي هذا الدليل يفترض أنك تعرف المسار الذي سيسلكه طلبك.
يجب إنشاء مفاتيح توقيع الأكواد على أجهزة عتادية
بموجب متطلبات الأساس لتوقيع الأكواد الصادرة عن منتدى CA/Browser، والسارية اعتبارًا من 1 يونيو 2023، يجب إنشاء المفتاح الخاص لكل شهادة توقيع أكواد موثوقة عمومًا وتخزينه واستخدامه داخل وحدة تشفير عتادية معتمدة على الأقل بمستوى FIPS 140-2 Level 2، أو Common Criteria EAL 4+، أو معيار مكافئ. ويشمل ذلك كلًا من الشهادات القياسية (التحقق من المؤسسة والتحقق الفردي) وشهادات التحقق الموسّع (Extended Validation). كانت شهادات EV لتوقيع الأكواد تعمل بهذه الطريقة أصلًا؛ وقد وسّع تعديل عام 2023 نفس القاعدة لتشمل المنتجات القياسية أيضًا.
كما تحدد المتطلبات خصائص المفتاح نفسه. يجب أن تكون مفاتيح RSA بحد أدنى 3072 بت، ويجب أن تستخدم مفاتيح ECDSA منحنيات NIST P-256 أو P-384 أو P-521، ولا يُسمح باستخدام SHA-1 لشهادات توقيع الأكواد.
وبنفس الأهمية، يجب على جهة إصدار الشهادات (Certificate Authority) إثبات أن المفتاح موجود فعليًا داخل جهاز عتادي، باستخدام إحدى الطرق التي تحددها المتطلبات. في الواقع العملي، هذه هي الطرق التي ستواجهها:
- ترسل لك الجهة المصدرة (CA) رمزًا عتاديًا (token) يحتوي بالفعل على زوج مفاتيح قامت الجهة بإنشائه على ذلك الجهاز.
- توقّع الطلب مضادًا بشهادة من الشركة المصنّعة، وهذا هو المقصود بـإثبات المفتاح (key attestation): دليل على أن المفتاح تم إنشاؤه بطريقة غير قابلة للتصدير داخل جهاز متوافق.
- تستخدم مكتبة تشفير مع تركيبة وحدة عتادية توصي بها الجهة المصدرة.
- تقدّم تدقيقًا تقنيًا داخليًا (IT audit)، أو تقريرًا من خدمة حماية مفاتيح سحابية، أو اتفاقية توقّعها من خلال خدمة توقيع متوافقة.
لا يفي أي من هذه الشروط بطلب تنشئه MMC باستخدام Microsoft Software Key Storage Provider. فهذا المزوّد ينشئ المفتاح داخل التخزين البرمجي لنظام Windows، وبالتالي سيتم رفض الطلب الناتج بالنسبة لشهادة توقيع أكواد موثوقة عمومًا، بغض النظر عن كيفية ملء باقي المعالج. كما توقفت جهات إصدار الشهادات عن تقديم إنشاء المفاتيح عبر المتصفح وتسليم ملفات .pfx القابلة للتنزيل لهذه المنتجات في الوقت نفسه.
إذا كان هدفك الحصول على شهادة موثوقة عمومًا، فإن المسار يُحدَّد عند تقديم الطلب. فإما أن تنشئ الجهة المصدرة (CA) المفتاح على رمز عتادي (token) وترسله إليك بالبريد، وفي هذه الحالة لا يوجد CSR عليك إنشاؤه، أو تنشئ المفتاح على جهاز عتادي تملكه بالفعل وتقدّم إثباتًا (attestation) مع الطلب. يقارن دليل طرق تسليم شهادة توقيع الأكواد بين الطريقتين، وخطوات كل جهاز على حدة موجودة هنا:
أين تظل أداة MMC مناسبة
المعالج ليس متجاوَزًا. فمزوّد الخدمة الذي تختاره داخله هو الذي يحدد أين يُولد المفتاح، وهناك ثلاث حالات يظل فيها هذا المعالج الأداة الصحيحة.
طلب مدعوم بمزوّد عتادي. تعرض قائمة Cryptographic Service Provider في المعالج كل مزوّد مثبَّت على الجهاز، وليس فقط المزوّدات البرمجية من Microsoft. بمجرد تثبيت مشغّل رمز عتادي (token) أو minidriver لبطاقة ذكية، يظهر مزوّده هناك أيضًا. الفرق يكمن في مكان توليد زوج المفاتيح: فالمزوّد البرمجي ينشئه على حاسوبك، بينما المزوّد المعتمد على العتاد، مثل مزوّد البطاقة الذكية أو الرمز العتادي، يوجّه الجهاز لإنشاء الزوج، ثم يحتفظ الجهاز بالمفتاح الخاص ويتحكم في الوصول إليه. عند اختيار مزوّد عتادي، تنتج MMC طلبًا لمفتاح لم يوجد قط في صورة برمجية.
هناك تحفظان قبل الاعتماد على ذلك. تنتج MMC طلب PKCS #10 فقط، ولا شيء غيره، فهي لا تُنشئ ملف إثبات المفتاح (key attestation) الذي تطلبه معظم جهات إصدار الشهادات إلى جانبه. هذا الملف يأتي من أدوات الجهاز نفسه. كما أن الجهة المصدرة (CA) هي التي تقرر طريقة التحقق التي ستقبلها، وكثير منها يوصي بأداة خاصة به لهذه المهمة. اسأل الجهة المصدرة عن المسار الذي تدعمه قبل إنشاء أي شيء، لأن المفتاح الذي تنشئه بالأداة الخاطئة لا يمكن نقله لاحقًا.
جهة إصدار داخلية أو مؤسسية. تحكم متطلبات الأساس الشهادات الموثوقة عمومًا. أما الشهادة الصادرة عن جهة إصدار Active Directory Certificate Services الخاصة بمؤسستك لأغراض التوقيع الداخلي فهي خارج هذا النطاق، لذا فإن سياستك الخاصة هي التي تحدد كيفية تخزين المفتاح، ويُعد المزوّد البرمجي خيارًا مشروعًا في هذه الحالة. لكن تذكّر ما تحصل عليه: فالكود الموقّع بهذه الطريقة موثوق فقط على الأجهزة التي تثق أصلًا بجذرك الداخلي، وفي كل مكان آخر ستظل Windows تعامل الناشر على أنه غير معروف.
التوقيع التجريبي والتحضير. الطلب البرمجي مناسب لشهادة اختبار، ولإعداد قيم الموضوع (subject) الدقيقة التي ستعيد استخدامها عند إنشاء الطلب الفعلي على جهازك العتادي.
الخطوة 1: فتح أداة الشهادات (Certificates snap-in)
اضغط على مفتاح Windows + R، اكتب mmc واضغط Enter. يمكنك أيضًا كتابة mmc في مربع بحث شريط المهام وفتحها من هناك. اقبل مطالبة التحكم في حساب المستخدم (User Account Control). ستفتح نافذة Console1 فارغة.
انقر على File، ثم Add/Remove Snap-in. في قائمة Available snap-ins، اختر Certificates وانقر Add.
سيسألك Windows الآن عن متجر الشهادات الذي ستديره الأداة: My user account، أو Service account، أو Computer account. هذا الاختيار أكثر أهمية لشهادة توقيع الأكواد منه لشهادة خادم ويب، لأنه يحدد أين يعيش المفتاح وأي متجر ستبحث فيه أداة التوقيع الخاصة بك:
- My user account يضع المفتاح في المتجر الشخصي للمستخدم المسجّل الدخول. هذا هو الاختيار المعتاد عندما يوقّع المطوّر بشكل تفاعلي، لأن أداة signtool من Microsoft تفتح متجر My الخاص بالمستخدم الحالي افتراضيًا.
- Computer account يضع المفتاح في متجر الجهاز، وهذا مناسب لخادم بناء (build server) يعمل التوقيع فيه ضمن حساب خدمة. يجب إخبار أدوات التوقيع بالبحث هناك: تأخذ signtool المعامل /sm لمتجر الجهاز.
إذا اخترت My user account، انقر Finish. وإذا اخترت Computer account، انقر Next، اترك Local computer (the computer this console is running on) محددًا وانقر Finish. في كلتا الحالتين، انقر OK لإغلاق نافذة Add or Remove Snap-ins.
هناك اختصاران يتجاوزان خطوة إضافة الأداة تمامًا عندما لا تحتاج إلى حفظ الوحدة: يفتح certmgr.msc متاجر شهادات المستخدم الحالي مباشرة، ويفتح certlm.msc متاجر الحاسوب المحلي. وإذا أنشأت الوحدة يدويًا وتتوقع الرجوع إليها، استخدم File ثم Save للاحتفاظ بها.
الخطوة 2: بدء طلب مخصص
في شجرة الوحدة، وسّع Certificates وانقر بزر الفأرة الأيمن على مجلد Personal (أو مجلد Certificates الموجود تحته، إذا كان المتجر يحتوي بالفعل على شهادات). اختر All Tasks، ثم Advanced Operations، ثم Create Custom Request. نفس الأوامر موجودة في قائمة Action إذا كنت تفضلها.
سيفتح معالج Certificate Enrollment على شاشة Before You Begin. انقر Next.
في شاشة Select Certificate Enrollment Policy، انظر تحت عنوان Custom Request واختر Proceed without enrollment policy، ثم انقر Next. هذا يخبر Windows بإنشاء طلب مستقل لجهة إصدار خارجية بدلًا من التسجيل مقابل قالب Active Directory.
تحتوي صفحة Custom request على ثلاثة إعدادات:
- Template. اختر (No template) CNG key. يستخدم هذا مزوّد تخزين المفاتيح (Key Storage Provider)، وهو ما تُسجَّل المزوّدات العتادية الحديثة تحته. أما (No template) Legacy key فيستخدم مزوّدات CryptoAPI الأقدم، وهو مطلوب فقط عندما يتطلب جهاز أو تطبيق معين ذلك تحديدًا.
- Suppress default extensions. اتركها غير محددة ما لم تنوِ إرسال الملحقات (extensions) التي تحددها يدويًا فقط.
- Request format. اختر PKCS #10. تقبله كل جهة إصدار. أما CMC فهو مخصص للطلبات الموجهة إلى أنظمة تطلبه تحديدًا.
انقر Next. في صفحة Certificate Information، سترى صفًا واحدًا بعنوان Custom request بحالة Available. انقر سهم Details على يمين ذلك الصف لتوسيعه، ثم انقر زر Properties الذي يظهر. سيفتح مربع حوار Certificate Properties بأربعة تبويبات: General، Subject، Extensions وPrivate Key.
الخطوة 3: إدخال تفاصيل الموضوع (Subject)
في تبويب General، اكتب Friendly name، وإن أردت، Description. كلاهما تسميتان محليتان تساعدانك على إيجاد الشهادة في المتجر لاحقًا. لا يشكّل أي منهما جزءًا من الطلب، ولا يتم التحقق من أي منهما.
انتقل إلى تبويب Subject. هنا يتم تجميع الهوية التي ستظهر كناشر البرنامج (software publisher). تحت Subject name، اختر عنصرًا من القائمة المنسدلة Type، اكتب النص المطابق في مربع Value، وانقر Add >. ينتقل كل عنصر إلى القائمة على اليمين، حيث يعرضه Windows في شكل مختصر (CN=، O=، OU=، L=، S=، C=). كرّر ذلك لكل مما يلي:
- Common name (CN): الاسم المسجّل لمؤسستك، أو الاسم القانوني الكامل للفرد بالنسبة للشهادة الفردية. هذه هي الهوية التي يراها المستخدمون عندما يسمّي Windows الناشر.
- Organization (O): اسم المؤسسة المسجّل الذي تنتمي إليه الشهادة. إذا كان الاسم يحتوي على رمز مثل علامة العطف (&)، اكتبه كتابة كاملة أو احذفه، لأن هذه الرموز غير مقبولة في هذا الحقل. “AB & C Corporation” تصبح “AB and C Corporation” أو “ABC Corporation”.
- Organizational unit (OU): القسم المسؤول عن التسجيل، مثل قسم تقنية المعلومات (IT). اختياري.
- Locality (L): المدينة التي تم فيها تسجيل المؤسسة.
- State (S): الولاية أو المحافظة، مكتوبة بالكامل. استخدم Florida، وليس FL.
- Country (C): رمز الدولة المكوّن من حرفين وفق معيار ISO للمكان الذي تم فيه تسجيل المؤسسة، مثل US.
أدخل التفاصيل بحيث تطابق سجلاتك القانونية تمامًا، لأن جهة الإصدار (CA) تتحقق منها مقابل مصادر عامة ورسمية قبل إصدار أي شيء. عدم التطابق هو السبب الأكثر شيوعًا لتعطّل طلب توقيع الأكواد.
اترك مربع Alternative name فارغًا. تُستخدم أسماء الموضوع البديلة (Subject Alternative Names) لتحديد هوية الخوادم بواسطة اسم المضيف، أما شهادة توقيع الأكواد فتحدد هوية ناشر وليس جهازًا، لذا لا تحمل أي إدخالات DNS.
الخطوة 4: اختيار المزوّد وحجم المفتاح ودالة التجزئة (Hash)
افتح تبويب Private Key. يحتوي على عدة مجموعات قابلة للطي: Cryptographic Service Provider، Key options، Select Hash Algorithm، Select Signature Format وKey permissions. انقر على عنوان لتوسيعه.
وسّع أولًا Cryptographic Service Provider، لأن هذا هو الإعداد الذي تفعّله متطلبات الأساس. تعرض القائمة كل مزوّد مثبَّت على الجهاز، لكل منها مربع اختيار. تأكد من أن المزوّد الوحيد المحدد هو الذي تريده فعلًا:
- بالنسبة لشهادة توقيع أكواد موثوقة عمومًا، اختر المزوّد الخاص برمزك العتادي (token) أو وحدة HSM. لن يظهر في هذه القائمة إلا بعد تثبيت مشغّل الجهاز أو minidriver الخاص به، لذا وصّل الجهاز وثبّت برمجياته أولًا.
- RSA, Microsoft Software Key Storage Provider هو الخيار البرمجي. استخدمه فقط لجهة إصدار داخلية أو شهادة اختبار.
- تحتوي القائمة أيضًا على مدخلات ECDSA مثل ECDSA_P256, Microsoft Software Key Storage Provider. تأكد من أن جهة الإصدار الخاصة بك تدعم ECDSA لتوقيع الأكواد قبل اختيار أحدها، لأن ليس كل منتج يدعمه.
وسّع Key options. اضبط Key size على 3072 أو 4096. يمثل RSA 3072 الحد الأدنى لتوقيع الأكواد، وسيتم رفض الطلب المنشأ بحجم 2048. إذا لم تقدّم القائمة المنسدلة خيار 3072 للمزوّد الذي اخترته، استخدم 4096.
في نفس المجموعة، اترك خيار Make private key exportable غير محدد. هذا هو التصحيح الأهم على الإطلاق مقارنة بإرشادات MMC القديمة. يمكن نسخ المفتاح القابل للتصدير خارج الجهاز على شكل ملف .pfx، وهذا بالضبط ما يهدف اشتراط العتاد إلى منعه، ومسار الإثبات (attestation) يشهد صراحة بأن المفتاح تم إنشاؤه بطريقة غير قابلة للتصدير. الحالة الوحيدة لتحديده هي إعداد توقيع داخلي حيث يجب نقل الشهادة والمفتاح إلى جهاز آخر، وحتى في هذه الحالة فإن ذلك يُضعف المفتاح. اترك أيضًا Allow private key to be archived غير محدد. أما Strong private key protection فهو اختياري ويجعل Windows يطالبك في كل مرة يُستخدم فيها المفتاح، وهذا معقول لمفتاح توقيع على محطة عمل مشتركة.
وسّع Select Hash Algorithm واضبط Hash Algorithm على sha256. لا يُسمح باستخدام SHA-1 لشهادات توقيع الأكواد.
يستحق تبويب Extensions النظر إذا كنت تسجّل مقابل جهة إصدار داخلية. وسّع Key usage وأضف Digital signature، ثم وسّع Extended Key Usage (application policies) وأضف Code Signing. تبني جهة الإصدار العامة الشهادة من المنتج الذي طلبته وليس من الملحقات الموجودة في طلبك، لذا فإن هذا التبويب لا يغيّر شيئًا في طلب عام. أما جهة الإصدار الداخلية فقد تأخذ به بعين الاعتبار.
انقر OK لإغلاق Certificate Properties، ثم Next.
الخطوة 5: حفظ الطلب
يسألك المعالج Where do you want to save the offline request? انقر Browse، اختر مجلدًا تتحكم فيه، أعطِ الملف اسمًا مثل codesigning.req وأكّد. تصفّح دائمًا للوصول إلى مجلد بدلًا من كتابة اسم ملف مجرد: فبدون مسار، سينتهي الطلب في أي مجلد تعمل منه الوحدة حاليًا، وهو نادرًا ما يكون المكان الذي تريده ويصعب إيجاده لاحقًا.
تحت File format، اترك Base 64 محددًا. هذا هو الشكل النصي الذي تلصقه جهات الإصدار في مربع التسجيل. أما Binary فيكتب DER خامًا، وهو ما ترفضه معظم نماذج الطلبات. انقر Finish.
افتح الملف في أي محرر نصوص عادي، مثل Notepad، وانسخ الكتلة بأكملها بما في ذلك أول وآخر سطر:
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEbDCCA1QCAQAwZDELMAkGA1UEBhMCVVMx...
...base64 encoded request...
-----END NEW CERTIFICATE REQUEST-----عادة ما تكتب أدوات تسجيل Windows الصياغة الأطول الموضحة أعلاه، مع كلمة NEW في أسطر العلامات، بينما تكتب OpenSSL BEGIN CERTIFICATE REQUEST وEND CERTIFICATE REQUEST. إذا كان ملفك يستخدم الصيغة الأقصر، فلا شيء خاطئ: المحتوى هو نفس طلب PKCS #10 وتقبله جهات إصدار الشهادات بأي من الصيغتين. انسخ ما تراه بالضبط ولا تعيد كتابة أسطر العلامات.
أحد الأمور التي لا ينتجها المعالج هو ملف مفتاح خاص يمكنك حفظه أو نسخه، والإرشادات القديمة التي تطلب منك الحفاظ على ملفات المفتاح العام والخاص تصف أداة مختلفة. تحتفظ MMC بالمفتاح الخاص الجديد داخل مخزن مفاتيح Windows، تحت الحساب الذي اخترته في الخطوة 1، وعلى ذلك الحاسوب فقط. يظهر الطلب المعلّق عادة في الأداة تحت Certificate Enrollment Requests. يترتب على ذلك ثلاث نتائج:
- لا تحذف الطلب المعلّق أثناء انتظار الإصدار. حذفه يتخلص من المفتاح، وستصبح الشهادة الصادرة عندئذ عديمة الفائدة.
- أكمل الطلب على نفس الحاسوب، وضمن نفس سياق الحساب. لا يمكن إنهاء طلب أُنشئ في متجر المستخدم في متجر الجهاز، أو العكس.
- لا تعِد بناء الجهاز أو إعادة تصويره (re-image) بين إنشاء الطلب وتثبيت الشهادة.
الخطوة 6: التحقق من الطلب قبل إرساله
لا يمكن تعديل الطلب بعد إنشائه، لذا تحقق منه الآن بدلًا من اكتشاف خطأ إملائي بعد بدء عملية التحقق. يمكن لـ Windows قراءته دون أي برامج إضافية. افتح موجّه الأوامر (Command Prompt) في المجلد الذي يحتوي على الملف ونفّذ:
certutil -dump codesigning.reqإذا كان OpenSSL مثبتًا، فإن هذا الأمر يقرأ نفس الملف ويتحقق أيضًا من توقيع الطلب:
openssl req -noout -text -verify -in codesigning.reqتأكد من أربعة أمور في المخرجات: أن الموضوع (subject) يسرد الدولة والولاية والمدينة والمؤسسة والاسم الشائع (common name) بالضبط كما تريد؛ وأن المفتاح العام 3072 بت أو أكثر، أو منحنى ECDSA معتمد؛ وأن خوارزمية التوقيع هي SHA-256؛ وأنه في حالة أمر OpenSSL، يظهر سطر verify OK، الذي يؤكد أن الطلب موقّع بالمفتاح الخاص المطابق له. يمكنك أيضًا لصق الكتلة في أداة فك تشفير CSR لقراءتها في المتصفح.
إذا كان هناك خطأ ما، أنشئ طلبًا جديدًا من الخطوة 2. لمعرفة المزوّدات المتاحة على الجهاز، بما فيها أي مزوّدات عتادية قمت بتثبيتها، نفّذ:
certutil -csplistالخطوة 7: تثبيت الشهادة الصادرة على نفس الجهاز
قدّم كتلة Base 64 أثناء طلب الشهادة، أكمل عملية التحقق التي تطلبها جهة الإصدار، وقم بتنزيل الشهادة الصادرة عند وصولها. وبما أن المفتاح الخاص بقي في مخزن مفاتيح Windows، فيجب أن تعود الشهادة إلى نفس المتجر لتكون قابلة للاستخدام.
في نفس الأداة، انقر بزر الفأرة الأيمن على Personal، اختر All Tasks، ثم Import، ووجّه المعالج إلى الملف. يقوم Windows بمطابقة الشهادة مع المفتاح الذي احتفظ به من الطلب، ويختفي الإدخال المعلّق تحت Certificate Enrollment Requests. افتح الشهادة بعد ذلك وتحقق من أن تبويب General يذكر أن لديك مفتاحًا خاصًا يتوافق مع هذه الشهادة. إذا كان هذا السطر مفقودًا، فإن الاقتران لم يحدث، ويمكنك إعادة ربطه باستخدام الرقم التسلسلي للشهادة:
certutil -repairstore My <serial-number>أضف المعامل -user إذا كانت الشهادة تخص المستخدم الحالي بدلًا من الجهاز:
certutil -user -repairstore My <serial-number>من هنا، تلتقط أداة التوقيع الخاصة بك الشهادة من المتجر. تذكّر المتجر الذي اخترته في الخطوة 1: تقرأ signtool متجر My الخاص بالمستخدم الحالي ما لم تمرّر /sm لمتجر الجهاز.
هناك طرق أخرى لإنشاء نفس الطلب مغطاة في أدلة CertReq، وOpenSSL، وJava Keystore، وmacOS Keychain Access. قد تحتاج أيضًا إلى دروس توقيع الأكواد الأشمل أو طرق أخرى لـإنشاء CSR.
الأسئلة الشائعة
نعم، لكن فقط عندما يكون الطلب مدعومًا بجهاز عتادي أو موجّهًا إلى جهة إصدار خاصة (private CA). منذ 1 يونيو 2023، يشترط منتدى CA/Browser أن يتم إنشاء المفتاح الخاص لكل شهادة توقيع أكواد موثوقة عمومًا والاحتفاظ به داخل وحدة تشفير عتادية تستوفي FIPS 140-2 Level 2 أو Common Criteria EAL 4+. يُنشئ الطلب الذي تبنيه MMC باستخدام Microsoft Software Key Storage Provider المفتاح في صورة برمجية وسيُرفض. أما اختيار مزوّد الرمز العتادي (token) أو HSM الخاص بك في المعالج فيبقي المفتاح في العتاد، ويظل الطلب البرمجي مناسبًا لجهة إصدار داخلية أو شهادة اختبار.
لا، ليس لمفتاح توقيع أكواد. يمكن نسخ المفتاح القابل للتصدير خارج الجهاز على شكل ملف .pfx، وهذا يُفشل الغرض من اشتراط العتاد، ومسار إثبات المفتاح (key attestation) يشهد بأن المفتاح تم إنشاؤه بطريقة غير قابلة للتصدير. تخبرك إرشادات MMC القديمة بتحديد هذا المربع، وتلك النصيحة قديمة. الحالة الوحيدة التي يصح فيها ذلك هي إعداد توقيع داخلي حيث يجب فعلًا نقل الشهادة والمفتاح إلى جهاز آخر.
اختر المتجر الذي سيعمل منه التوقيع. يضع My user account المفتاح في المتجر الشخصي للمستخدم المسجّل الدخول، وهو ما تبحث فيه signtool افتراضيًا، لذا فهو يناسب المطوّر الذي يوقّع بشكل تفاعلي. أما Computer account فيضع المفتاح في متجر الجهاز، وهذا يناسب خادم بناء (build server) يعمل ضمن حساب خدمة، ويجب حينها إخبار أدوات التوقيع بالبحث هناك. أيًا كان اختيارك، أنشئ الطلب وثبّت الشهادة الصادرة ضمن نفس السياق.
لا يوجد ملف مفتاح خاص لحفظه. تحتفظ MMC بالمفتاح داخل مخزن مفاتيح Windows على الحاسوب الذي أنشأت عليه الطلب، تحت الحساب الذي اخترته، وتعرض الطلب المعلّق تحت Certificate Enrollment Requests. لا تحذف ذلك الطلب المعلّق، ولا تعِد بناء الجهاز قبل تثبيت الشهادة، لأن أيًا من هذين الإجراءين يدمّر المفتاح ويجعل الشهادة الصادرة غير قابلة للاستخدام.
RSA بحد أدنى 3072 بت، و4096 خيار شائع. إذا استخدمت ECDSA، يجب أن يكون المنحنى NIST P-256 أو P-384 أو P-521، ويجب أن تتأكد أولًا من أن جهة إصدار الشهادات الخاصة بك تدعم ECDSA لتوقيع الأكواد. اضبط خوارزمية التجزئة على sha256. لا يُسمح باستخدام SHA-1 لشهادات توقيع الأكواد.
اختر CNG key في كل الحالات تقريبًا. يستخدم مزوّد تخزين مفاتيح (Key Storage Provider)، وهي الطريقة التي تسجّل بها الرموز العتادية ووحدات HSM الحديثة نفسها على Windows، وهو ما ستعرضه قائمة Cryptographic Service Provider في تبويب Private Key. أما Legacy key فيرجع إلى مزوّدات CryptoAPI الأقدم، ولا يستحق اختياره إلا عندما يتطلب جهاز أو تطبيق معين ذلك.
نفّذ certutil -dump codesigning.req، الذي لا يحتاج إلى أي برامج إضافية على Windows، أو openssl req -noout -text -verify -in codesigning.req إذا كان OpenSSL مثبتًا. راجع قيم الموضوع (subject)، وحجم المفتاح، وخوارزمية التوقيع. لا يمكن تعديل الطلب بمجرد إنشائه، فإذا كان هناك خطأ، أنشئ طلبًا جديدًا بدلًا من محاولة تصحيح الملف.
وفِّر 10% على شهادات SSL عند الطلب اليوم!
إصدار سريع، وتشفير قوي، وثقة في المتصفح بنسبة 99.99%، ودعم مخصص، وضمان استرداد المال خلال 25 يومًا. رمز القسيمة: SAVE10
