إذا كان أحد العناصر الرئيسية للبنية التحتية للمفتاح العام (PKI) هو شهادات X509 ، فإن الموضوع الرئيسي لـ PKI هو سلطات التصديق (CAs). CA هو الذي يصدر الشهادات ، وينهي صلاحيتها (إبطال الشهادة) ، ويؤكد صحتها. على صفحات
Habrahabr ، يمكنك العثور على منشورات مختلفة حول إصدار الشهادات الرقمية باستخدام
OpenSSL .
بشكل أساسي ، تناقش هذه المقالات استخدام
الأداة المساعدة opensl ، وتصف واجهة سطر الأوامر الخاصة بها وتعمل مع الملفات التي تخزن كل شيء: المفاتيح والطلبات والشهادات ، بما في ذلك الجذر ، إلخ. ولكن إذا قمت بتطوير مركز شهادات (CA) واسع النطاق يعتمد على OpenSSL ، فمن الطبيعي أن ترغب في التخلص من هذه المجموعة المتنوعة من الملفات والانتقال إلى العمل مع قواعد البيانات ، بالإضافة إلى وجود واجهة رسومية لإصدار الشهادات وإدارتها. وإذا تذكرت القانون الاتحادي الصادر في 6 أبريل 2011. رقم 63- بشأن التوقيعات الإلكترونية ، من الضروري أن تمتثل CA لمتطلبات هذا القانون ، وكذلك متطلبات نموذج شهادة مؤهلة لمفتاح التحقق من التوقيع الإلكتروني ، المعتمد بأمر من خدمة الأمن الفيدرالي لروسيا بتاريخ 27 ديسمبر 2011 رقم 795.
لدى المواطنين العاديين انطباع بأن UTs شيء هائل (حسنًا ، المركز ، مثل مركز التحكم في المهمة تقريبًا).
من وجهة نظر مسؤولية CA - هذا هو بالضبط. بعد كل شيء ، الشهادات الصادرة عن CA متساوية بالفعل في جواز السفر اليوم.
من وجهة نظر المبرمج ، كل شيء ليس مخيفًا جدًا. لذلك ولد مشروع مركز شهادة CAFL63. يعتمد تنفيذ مشروع CAFL63 على ثلاث "ركائز" ، وهي OpenSSL و
SQLite3 و
Tcl / Tk .
إذن ما هي هيئة إصدار الشهادات اليوم؟ بادئ ذي بدء ، هو مركز التسجيل ، حيث يأتي ممثلو الكيانات القانونية والأفراد ورجال الأعمال الأفراد للحصول على شهادات مع مجموعة من الوثائق اللازمة ، على وجه الخصوص ، تحديد هوية وسلطة مقدم الطلب. يمكن أن تأتي مع تطبيقات جاهزة إلكترونيا. يتحقق مندوب السجل من المستندات والطلب (البيانات المكتملة وصحة التوقيع الإلكتروني وما إلى ذلك) ، وإذا سار كل شيء على ما يرام ، فإنهم يقبلون الطلب ويوافقون عليه ويرسلونه إلى مركز التصديق (CA). لكن هذا مثالي. عمليا ، كل شيء يبدو مختلفا.
يحتاج المواطنون والمنظمات إلى شهادة (للوصول إلى بوابة خدمات الدولة ، لإعداد التقارير الضريبية ، لتقديم العطاءات) ، لكنهم لا يعرفون ما هو وماذا يفعلون به. إنهم على قناعة تامة بأن CA يتلقى توقيعًا إلكترونيًا مثل الفاكس. لكن هذه مشاكل التنوير. لذلك ، يأتي المتقدمون إلى الإدارة المركزية للإدارة المركزية ويقدمون المستندات. بالتعاون مع موظف المكتب المركزي ، يذهبون إلى مكان عمل منفصل
ويعدون طلب شهادة:
يتسلم ممثل الجمهورية طلباً جاهزاً لوسائل الإعلام الإلكترونية كما سبق ذكره. ما الذي يحتاج مقدم الطلب إلى تذكره؟ أولاً وقبل كل شيء ، التقط الوسائط باستخدام المفتاح الخاص الذي تم إنشاؤه!
يتم إرسال طلب معتمد على الوسائط الإلكترونية إلى المرجع المصدق ، حيث سيتم إصدار الشهادة على أساسه.
هذا هو مفهوم CA. ستصبح التفاصيل واضحة أدناه. ملاحظة واحدة ، من أجل راحة العرض التوضيحي ، يتم دمج الأداة المساعدة لإعداد الطلب ، CR و CA في مجمع مظاهرة واحد. ولكن لا توجد مشاكل مع التنوع الوظيفي. أبسطها هو الحصول على مثيل CAFL63 في كل مكان عمل واستخدام الوظائف المطلوبة فقط.
عندما كان المشروع على قدم وساق ،
لفت انتباهي مشروع
SimpleCA . ساعدت دراسة هذا المشروع كثيرًا في التنفيذ النهائي لـ CAFL63 CA.
يمكن العثور على التعليمات البرمجية المصدر للأداة وتوزيعها لمنصات Linux و MS Windows
لذا ، قم بتشغيل الأداة المساعدة CAFL63 وتظهر صفحة البداية على الشاشة:
نبدأ العمل بالضغط على مفتاح "إنشاء قاعدة بيانات". يتم إنشاء قاعدة بيانات CA باستخدام
DBMS3 عبر منصة DBMS. تحتوي قاعدة بيانات CA على عدة جداول. يحتوي الجدول الرئيسي mainDB على سجل واحد فقط ، والذي يخزن الشهادة الجذر والمفتاح الخاص المشفر بكلمة مرور وإعدادات المرجع المصدق. يوجد جدولين متعلقين بطلبات الشهادة: طلبات reqDB الحالية وأرشيف طلبات reqDBArc. يتم إنشاء ثلاثة جداول للشهادات: جدول الشهادات الجديدة certDBNew ، وجدول أرشيف الشهادات certDB وجدول الشهادات التي تم إبطالها certDBRev:
. . . certdb eval {create table certDB( ckaID text primary key , nick text, sernum text, certPEM text, subject text, notAfter text, notBefore text, dateRevoke text, state text )} certdb eval {create table certDBRev( ckaID text primary key )} certdb eval {create table certDBNew( ckaID text primary key )} certdb eval {create table reqDB (ckaID text primary key, nick text, sernum text, subject text, type text, datereq text, status text, reqpem text, pkcs7 text)} certdb eval {create table reqDBAr (ckaID text primary key, nick text, sernum text, subject text, type text, datereq text, status text, reqpem text, pkcs7 text)} certdb eval {create table crlDB(ID integer primary key autoincrement, signtype text, issuer text, publishdate text, nextdate text, crlpem text)} . . .
تستخدم جميع جداول الطلبات والشهادات
قيمة التجزئة (sha1) من المفتاح العام كمفتاح (المفتاح الأساسي). للراحة ، في المستقبل ، سيتم تسمية قيمة التجزئة من قيمة المفتاح العام CKAID (مصطلحات PKCS # 11). اتضح أن هذا مناسب جدًا ، على سبيل المثال ، عند البحث عن شهادة عند الطلب أو العكس. يوجد جدول crlDB آخر في قاعدة البيانات يخزن قوائم الشهادات المبطلة.
يتم تخزين قيمة المفتاح العام في الطلب وفي الشهادة. لذلك ، قبل وضعها في قاعدة البيانات ، من الضروري استخراج المفتاح العام منها وحساب CKAID. لاستخراج قيمة المفتاح العام ، من الملائم استخدام حزمة pki (تتطلب الحزمة pki) ، والتي تحتوي على أدوات للعمل مع الشهادات والطلبات. ومع ذلك ، لم يتم تصميم هذه الحزمة للعمل مع التشفير الروسي. في هذا الصدد ، بناءً على إجراءات parse_cert و parse_csr المضمنة في حزمة pki ، اكتب إجراءات parce_cert_gost و parse_csr_gost:
... ## Convert Pubkey type to string set pubkey_type [::pki::_oid_number_to_name $pubkey_type] # Parse public key, based on type switch -- $pubkey_type { "rsaEncryption" { set pubkey [binary format B* $pubkey] binary scan $pubkey H* ret(pubkey) ::asn::asnGetSequence pubkey pubkey_parts ::asn::asnGetBigInteger pubkey_parts ret(n) ::asn::asnGetBigInteger pubkey_parts ret(e) set ret(n) [::math::bignum::tostr $ret(n)] set ret(e) [::math::bignum::tostr $ret(e)] set ret(l) [expr {int([::pki::_bits $ret(n)] / 8.0000 + 0.5) * 8}] set ret(type) rsa } "1.2.643.2.2.19" - "1.2.643.7.1.1.1.1" - "1.2.643.7.1.1.1.2" { # gost2001, gost2012-256,gost2012-512 set pubkey [binary format B* $pubkey] binary scan $pubkey H* ret(pubkey) set ret(type) $pubkey_type ::asn::asnGetSequence pubkey_algoid pubalgost #OID - ::asn::asnGetObjectIdentifier pubalgost oid1 #OID - ::asn::asnGetObjectIdentifier pubalgost oid2 } default { error "Unknown algorithm" } } ...
على عكس الإجراءات "الأصلية" ، فإنها تسمح لك بالعمل مع الكائنات ليس فقط بتنسيق PEM ، ولكن أيضًا بتنسيق DER. للعمل مع قوائم إبطال شهادات CRL ، تمت كتابة إجراء parse_crl. يمكن العثور على كل هذه الإجراءات في التعليمات البرمجية المصدر ، والتي يتم تخزينها مع التوزيع.
أيضا في حزمة pki لا يوجد OID-S الروسي ، على سبيل المثال ، TIN ، SNILS ، إلخ. يتم حل هذه المشكلة بسهولة عن طريق إضافة oid-s الروسية إلى الصفيف :: pki :: oids:
. . . set ::pki::oids(1.2.643.100.1) "OGRN" set ::pki::oids(1.2.643.100.5) "OGRNIP" set ::pki::oids(1.2.643.3.131.1.1) "INN" set ::pki::oids(1.2.643.100.3) "SNILS" # set ::pki::oids(1.2.643.2.2.3) " 34.10-2001" set ::pki::oids(1.2.643.7.1.1.3.2) " 34.10-2012-256" set ::pki::oids(1.2.643.7.1.1.3.3) " 34.10-2012-512" . . .
باستخدام الدالتين parse_cert_gost و parse_csr_gost ، يتم حساب قيم CKAID (المفتاح الأساسي لقاعدة البيانات) على النحو التالي:
. . . array set b [parse_csr_gost $req] set pem $b(pem) set subject $b(subject) set pubkey $b(pubkey) set key1 [binary format H* $pubkey] set ckaID [::sha1::sha1 $key1] . . .
لذا ، انقر فوق الزر "إنشاء قاعدة بيانات":
يبدأ إنشاء المرجع المصدق (CA) باختيار الدليل الذي سنقوم فيه بتخزين إعدادات قاعدة البيانات وكلمة المرور للوصول إلى المفتاح الخاص CA. تراقب الأداة المساعدة CAFL63 طول كلمة المرور بعناية:
يتم تخزين كلمة المرور في قاعدة بيانات المرجع المصدق (CA) كتجزئة:
. . . set hash256 [::sha2::sha256 $wizData(capassword)] . . .
بعد الضغط على مفتاح "التتبع" ، تبدأ عملية تكوين شهادة جذر موقعة ذاتيًا لمرجع المصدق المنشور. في الخطوة الأولى من هذه العملية ، يتم تحديد نوع ومعلمات زوج المفاتيح:
بعد تحديد الزوج الأساسي للشهادة الجذرية لمركز الشهادة الذي تم إنشاؤه ، ننتقل إلى ملء النموذج بمعلومات عن المالك (الصورة الأولى مفقودة).
لاحظ أن الأداة CAFL63 لديها "ذكاء" معين وبالتالي فهي تتحكم ليس فقط في توفر البيانات في الحقول ، ولكن أيضًا في صحة (التحديد الأحمر - غير صحيح) لملء الحقول مثل TIN و PSRN و SNILS و PSRNIP وعنوان البريد الإلكتروني ، وما إلى ذلك:
بعد ملء الحقول بمعلومات حول مالك المرجع المصدق ، سيتم عرض تحديد إعدادات النظام للمرجع المصدق:
إذا كنت لن تعمل مع التشفير الروسي ، فيمكنك استخدام OpenSSL المعتاد. للعمل مع التشفير الروسي ، يجب عليك تحديد الإصدار المناسب ، وتعديل OpenSSL. لمزيد من التفاصيل ، اقرأ README.txt في التوزيع الذي تم تنزيله. نظرًا لأنه من المخطط إصدار شهادات مؤهلة ، فمن الضروري أيضًا تقديم معلومات حول شهادة المرجع المصدق نفسه ونظام حماية معلومات التشفير المستخدم من قبله (انظر "متطلبات نموذج الشهادة المؤهلة لمفتاح التحقق من التوقيع الإلكتروني" ، المعتمد بأمر من خدمة الأمن الفيدرالي لروسيا بتاريخ 27 ديسمبر 2011 رقم 795).
بعد ملء جميع الحقول بشكل صحيح ، سيتم تقديمها مرة أخرى للتحقق من دقتها والنقر على زر "إنهاء":
بعد النقر فوق الزر "إنهاء" ، سيتم إنشاء قاعدة بيانات المرجع المصدق (CA) حيث سيتم حفظ شهادة الجذر CA ، والمفتاح الخاص ، وإعدادات النظام ، وستظهر صفحة بدء الأداة المساعدة CAFL63 على الشاشة مرة أخرى. الآن بعد أن أنشأنا قاعدة بيانات المرجع المصدق الذي تم إنشاؤه حديثًا ، نقوم بالنقر فوق الزر "فتح قاعدة البيانات" ، وتحديد الدليل بقاعدة البيانات ، والانتقال إلى نافذة العمل الرئيسية للمرجع المصدق والنقر فوق الزر "عرض المرجع المصدق CA" ، تأكد من أن الشهادة الجذر التي أنشأناها :
الخطوة التالية هي إعداد قوالب / ملفات تعريف التطبيق للكيانات القانونية والأفراد ورجال الأعمال الأفراد (
أدوات-> إعدادات-> أنواع الشهادات-> جديد ):
بعد تحديد اسم ملف التعريف الجديد ، سيتم اقتراح تحديد تكوينه:
يتم تحديد تكوين ملف التعريف بواسطة الاسم المميز (الاسم المميز / الفريد لحامل الشهادة). كل ملف تعريف له تكوينه الخاص به مع الحقول المطلوبة (المطلوبة) أو لا. يتم تحديد تكوين الملف الشخصي للكيانات القانونية والأفراد ورجال الأعمال الأفراد وفقًا لمتطلبات القانون الفيدرالي -63 و "متطلبات نموذج الشهادة المؤهلة لشهادة مفتاح التحقق من التوقيع الإلكتروني" FSB لروسيا.
بعد إعداد الملفات الشخصية ، يكون المرجع المصدق جاهزًا لاستقبال المتقدمين والطلبات منهم. كما هو مذكور أعلاه ، يمكن لمقدم الطلب أن يأتي مع أو بدون طلب جاهز للحصول على شهادة.
إذا جاء مقدم الطلب مع طلب جاهز ، فعند التحقق من مستنداته ، يتم استيراد التطبيق إلى قاعدة بيانات CA. للقيام بذلك ، حدد علامة التبويب "طلبات الشهادات" في نافذة العمل الرئيسية ، وانقر فوق الزر "استيراد طلب / CSR" ، وحدد الملف مع الطلب. بعد ذلك ، ستظهر نافذة تحتوي على معلومات حول الطلب:
بعد مراجعة الطلب والتأكد من ملئه بشكل صحيح ، يمكنك النقر فوق الزر "استيراد" لإدخاله في قاعدة البيانات. على الفور ، نلاحظ أنه عند محاولة إعادة تقديم طلب في قاعدة بيانات المرجع المصدق ، سيتم عرض رسالة:
يتم وضع علامة على الطلبات إلى قاعدة بيانات المرجع المصدق (عمود "النوع") إما على أنها "لغة" تم إنشاؤها في مركز تسجيل CA ، أو على أنها "استيراد" تم إنشاؤها بواسطة مقدم الطلب نفسه ، كما يتم تسجيل وقت استلام الطلب في المرجع المصدق. يمكن أن يكون هذا مفيدًا في حل حالات الصراع. لذلك ، عند استيراد طلب شهادة ، يجب أن تشير إلى من أنشأ الطلب (انظر لقطة الشاشة).
يقع التطبيق المستورد في قاعدة بيانات المرجع المصدق ويتم عرضه في النافذة الرئيسية في علامة التبويب "طلبات الشهادات". الطلبات المستلمة في مرحلة "النظر" (عمود "الحالة" في علامتي التبويب "طلبات الشهادات" و "أرشيف الطلبات"). لكل طلب تم تلقيه حديثًا ، يجب اتخاذ قرار (القائمة المنسدلة عند النقر بزر الماوس الأيمن على الطلب المحدد):
يجب رفض كل طلب أو الموافقة عليه:
إذا تم رفض الطلب ، يتم نقله من جدول طلبات reqDB الحالية إلى جدول أرشيف طلبات reqDBArc ، وبالتالي يختفي في علامة التبويب "طلبات الشهادات" ويظهر في علامة التبويب "طلب الأرشيف".
يظل التطبيق المعتمد في جدول reqDB وفي علامة التبويب "طلبات الشهادات" حتى يتم إصدار الشهادة ، ثم ينتهي به الأمر أيضًا في الأرشيف.
قبل إصدار الشهادة ، من الضروري التوضيح مع مقدم الطلب للأغراض (على سبيل المثال ، للوصول إلى بوابة خدمات الدولة) سيتم استخدام الشهادة (
أدوات-> إعدادات-> أنواع الشهادات -> فردي -> تحرير -> استخدام المفتاح ):
لإصدار شهادة ، يجب عليك تحديد التطبيق المعتمد في علامة التبويب "طلب الشهادات" ، انقر بزر الماوس الأيمن وحدد "إصدار الشهادة" في القائمة المنسدلة. في الأداة التي تظهر ، ستحتاج إلى تحديد ملف التعريف الذي يجب أن يتوافق مع ملف تعريف الطلب / الشهادة:
لاحظ أنه في عملية إصدار الشهادة ، يمكنك توضيح قيم حقل معين:
يختلف إجراء إصدار الشهادة نفسها (عنصر القائمة "إصدار شهادة") قليلاً عن إجراء إنشاء شهادة الجذر أو إصدار طلب:
ستظهر الشهادة الصادرة على الفور في علامة التبويب الشهادات. في هذه الحالة ، تقع الشهادة نفسها في جدول certDBNew لقاعدة بيانات المرجع المصدق وتبقى هناك حتى يتم نشرها. تعتبر الشهادة منشورة بعد تصديرها إلى تفريغ SQL للشهادات الجديدة التي يتم نقلها إلى خدمة عامة. يؤدي نشر شهادة إلى نقلها من جدول certDBNew إلى جدول certDB.
إذا نقرت بزر الماوس الأيمن على الخط المحدد في علامة التبويب "الشهادات" ، فستظهر قائمة بالوظائف التالية:
تسمح لك هذه الوظائف بعرض كل من الشهادة نفسها والطلب الذي تم إصدارها على أساسها. يمكنك أيضًا تصدير الشهادة إلى ملف أو إلى محرك أقراص محمول لمقدم الطلب. أهم وظيفة هنا هي وظيفة إبطال الشهادة! هناك ميزة غريبة مثل تصدير شهادة إلى حاوية آمنة PKCS # 12. يتم استخدامه عندما يريد مقدم الطلب استلام مثل هذه الحاوية. بالنسبة لمثل هؤلاء المتقدمين ، يتم توفير وظيفة إنشاء الطلبات مع حفظ المفتاح الخاص في ملف بشكل خاص (الزر "إنشاء طلب / CSR" في علامة التبويب "طلبات الشهادات").
لذا ، بدأت CA حياتها ، وأصدرت أول شهادة. أحد أهداف CA هو تنظيم الوصول المجاني إلى الشهادات الصادرة. يمر نشر الشهادات عادة عبر خدمات الويب. لدى CAFL63 أيضًا هذه الخدمة:
لنشر الشهادات وقوائم الشهادات التي تم إبطالها في خدمة عامة ، يقوم المرجع المصدق (CA) بتحميل الشهادات مسبقًا إما إلى الملفات (
الشهادات-> تصدير الشهادات ) ، أو يقوم بعمل تفريغ SQL لجدول الشهادات بأكمله الذي يمكنك من خلاله إنشاء قاعدة بيانات للشهادات وتحميلها عليها ، ثم القيام بها تفريغ SQL للشهادات الجديدة التي ستتم إضافتها منها إلى قاعدة بيانات الخدمة العامة:
الوظيفة الأساسية للمرجع المصدق (CA) هي نشر قائمة الشهادات التي تم إلغاؤها ، على غرار ما تفعله وزارة الشؤون الداخلية فيما يتعلق بجوازات السفر منتهية الصلاحية. يجوز إلغاء الشهادة بناءً على طلب المالك. السبب الرئيسي للإلغاء هو فقدان المفتاح الخاص أو فقدان الثقة فيه.
لإلغاء شهادة ، ما عليك سوى تحديدها في علامة التبويب "الشهادات" ، ثم انقر بزر الماوس الأيمن وحدد عنصر القائمة "إبطال الشهادة":
لا يختلف إجراء الإلغاء عن إجراء الموافقة على طلب أو إصدار شهادة. تقع الشهادة المبطلة في جدول cerDBRev لقاعدة بيانات المرجع المصدق (CA) وتظهر في علامة التبويب "الشهادات المبطلة".
يبقى النظر في الوظيفة الأخيرة للمرجع المصدق - إصدار قائمة الشهادات الباطلة - قائمة الشهادات التي تم إبطالها. يتم تكوين قائمة CRL في علامة التبويب "الشهادات المبطلة" عند النقر فوق الزر "إنشاء SOS / CRL". كل ما هو مطلوب من المسؤول هو إدخال كلمة مرور المرجع المصدق وتأكيد نيتك إصدار CRL:
يقع CRL الذي تم إصداره في جدول crlDB لقاعدة البيانات ويتم عرضه في علامة التبويب CRL / SOS.
لتحليل قائمة إبطال الشهادات (CRL) قبل وضعها في قاعدة البيانات ، تمت كتابة إجراء parse_crl:
proc parse_crl {crl} { array set ret [list] if { [string range $crl 0 9 ] == "-----BEGIN" } { array set parsed_crl [::pki::_parse_pem $crl "-----BEGIN X509 CRL-----" "-----END X509 CRL-----"] set crl $parsed_crl(data) } ::asn::asnGetSequence crl crl_seq ::asn::asnGetSequence crl_seq crl_base ::asn::asnGetSequence crl_base crl_full ::asn::asnGetObjectIdentifier crl_full ret(signtype) #puts "KEY_TYPE=$ret(signtype)" ::::asn::asnGetSequence crl_base crl_issue set ret(issue) [::pki::x509::_dn_to_string $crl_issue] #puts "ISSUE=$ret(issue)" ::asn::asnGetUTCTime crl_base ret(publishDate) ::asn::asnGetUTCTime crl_base ret(nextDate) #puts "publishDate=$ret(publishDate)" return [array get ret] }
لعرض قائمة إبطال الشهادات (CRL) أو تصديرها للنشر في خدمة عامة ، يجب ، كما هو الحال دائمًا ، تحديد الخط المطلوب ، والنقر فوق زر الماوس الأيمن وتحديد عنصر القائمة المناسب:
هذا كل شيء ، المرجع المصدق جاهز.
تعرف على كيفية تجميع OpenSSL وتوصيله بالتشفير الروسي
هنا .