سؤال شهادة تجزئة سلطة إصدار الشهادات والتجديد


في عام 2004 ، أنشأت هيئة مصادقة صغيرة باستخدام OpenSSL على لينكس ونصوص الإدارة البسيطة المقدمة مع OpenVPN. وفقًا للأدلة التي اكتشفتها في ذلك الوقت ، قمت بتعيين فترة صلاحية شهادة CA الجذرية إلى 10 سنوات. منذ ذلك الحين ، قمت بتوقيع العديد من الشهادات لأنفاق OpenVPN ، ومواقع الويب وخوادم البريد الإلكتروني ، وكلها فترة صلاحية لمدة 10 سنوات (قد يكون هذا خطأ ، لكنني لم أكن أعرف بشكل أفضل في ذلك الوقت).

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

  • هل ستصبح الشهادات التي لها فترة صلاحية تمتد بعد انتهاء صلاحية شهادة CA الجذر غير صالحة بمجرد انتهاء صلاحية هذه الأخيرة ، أم أنها ستظل صالحة (لأنها كانت موقّعة خلال فترة صلاحية شهادة CA)؟
  • ما هي العمليات اللازمة لتجديد شهادة CA الجذر وضمان انتقال سلس على انتهاء صلاحيتها؟
    • هل يمكنني إعادة توقيع شهادة CA الجذر الحالية مع فترة صلاحية مختلفة ، وتحميل الشهادة الموقعة حديثًا إلى العملاء بحيث تظل شهادات العميل صالحة؟
    • أو هل أحتاج إلى استبدال جميع شهادات العميل بأخرى جديدة موقعة بواسطة شهادة CA جذرية جديدة؟
  • متى يجب تجديد شهادة CA الجذر؟ على وشك الانتهاء ، أو وقت معقول قبل انتهاء الصلاحية؟
  • إذا أصبح تجديد شهادة CA الجذرية عملًا رئيسيًا ، فما الذي يمكنني فعله بشكل أفضل الآن لضمان انتقال أكثر سلاسة في التجديد التالي (ما عدا قصر فترة الصلاحية إلى 100 سنة ، بالطبع)؟

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


87
2017-08-30 08:34


الأصل




الأجوبة:


إن الحفاظ على نفس المفتاح الخاص في المرجع المصدق الجذري يسمح لجميع الشهادات بالاستمرار في التحقق بنجاح من الجذر الجديد ؛ كل ما هو مطلوب منك هو الوثوق بالجذر الجديد.

تعتمد علاقة توقيع الشهادة على توقيع من المفتاح الخاص ؛ الاحتفاظ بنفس المفتاح الخاص (وضمنًا المفتاح العام نفسه) أثناء إنشاء شهادة عامة جديدة ، مع فترة صلاحية جديدة وأي سمات جديدة أخرى تم تغييرها حسب الحاجة ، يحافظ على علاقة الثقة في مكانها. يمكن أيضًا أن تستمر CRLs من الشهادة القديمة إلى الجديد ، كما هي ، مثل الشهادات الموقعة بواسطة المفتاح الخاص.


لذا ، دعونا نتحقق!

جعل CA الجذر:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

إنشاء شهادة طفل منه:

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

التوقيع على شهادة الطفل:

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

كل مجموعة هناك ، علاقة الشهادة العادية. دعونا نتحقق من الثقة:

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

حسنا ، الآن ، دعنا نقول 10 سنوات مرت. لنقم بإنشاء شهادة عامة جديدة من نفس المفتاح الخاص الجذر.

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

و .. هل نجحت؟

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

لكن لماذا؟ انهم ملفات مختلفة ، أليس كذلك؟

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

نعم ، ولكن هذا لا يعني أن المفتاح العام الجديد لا يتوافق مع التشفير على التوقيع على الشهادة. الأرقام التسلسلية المختلفة ، نفس المعامل:

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

لنذهب أبعد قليلاً للتحقق من أنه يعمل في التحقق من صحة شهادات العالم الحقيقي.

أطلق النار على نسخة Apache ، ودعنا نعطها (بنية ملف debian ، اضبطها حسب الحاجة):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

سنضع هذه التوجيهات على VirtualHost الاستماع على 443 - تذكر ، و newroot.pem شهادة الجذر لم تكن موجودة حتى عندما cert.pem تم إنشاؤه وتوقيعه.

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

دعونا نتحقق من كيفية رؤية openssl:

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

حسنًا ، وماذا عن المتصفح الذي يستخدم واجهة برمجة تطبيقات التشفير لـ MS؟ فلدي ثقة في الجذر ، أولا ، ثم كل شيء جيد ، مع الرقم التسلسلي للجذر الجديد:

newroot

ويجب أن نواصل العمل مع الجذر القديم أيضًا. قم بتبديل تكوين Apache حول:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

قم بإعادة التشغيل الكامل على Apache ، لن تقوم إعادة التحميل بتحويل الشاشة بشكل صحيح.

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

وباستخدام مستعرض واجهة برمجة تطبيقات التشفير MS ، يقدم Apache الجذر القديم ، لكن الجذر الجديد لا يزال في مخزن الجذر الموثوق به للكمبيوتر. سيعثر عليه تلقائيًا ويتحقق من صحة الشهادة ضد الجذر (الجديد) الموثوق به ، على الرغم من أن Apache يقدم سلسلة مختلفة (الجذر القديم). بعد تجريد الجذر الجديد من الجذور الموثوقة وإضافة شهادة الجذر الأصلية ، كل شيء على ما يرام:

oldroot


لذا ، هذا كل شيء! احتفظ بنفس المفتاح الخاص عند التجديد ، ثم قم بتبديل الجذر الجديد الموثوق به ، وكل ذلك إلى حد كبير يعمل فقط. حظا سعيدا!


124
2017-09-04 18:40



على أي حال ، ما الهدف من إنشاء شهادة جذر جديدة إذا كنت فقط ستعيد استخدام نفس المفتاح الخاص؟ إذا استمررت في القيام بذلك مرارا وتكرارا ، فما الفائدة من وجود تاريخ انتهاء صلاحية للشهادة؟ اعتقدت أن انتهاء صلاحية الجذر قد استخدم لإجبار المسؤولين على إنشاء مفتاح خاص أحدث (أقوى على الأرجح) أكثر أمانًا ضد الماكينات المتطورة التي تحاول كسر المفاتيح. إن مفتاح 40 بت الذي تم إنشاؤه قبل 20 عامًا ليس آمنًا بما يكفي - jvhashe
jvhashe إذا لم تعد شهادة الجذر قوية بدرجة كافية ، فيجب التخلص منها بغض النظر عن تاريخ انتهاء صلاحيتها. إذا كنت تولد الجذر الخاص بك ، لا يوجد شيء يمنعك من وضعه حتى تنتهي مئات السنين الماضية عندما لن تكون على كوكب الأرض. انتهاء الصلاحية لا يكاد يكون ذا صلة على شهادة الجذر - وبالنسبة لشهادة الطفولة ، فإن صلاحية انتهاء الصلاحية ليست في الواقع قوة التشفير (اسأل CAs الذين يستعدون لإلغاء جميع لوحات 1024 بت في أكتوبر) - انظر هنا لمزيد من المعلومات. - Shane Madden♦
بالإضافة إلى ما سبق ، وجدت أن الرقم المسلسل يجب أن يكون هو نفسه لهذه الطريقة في العمل. - Scott Presnell
-set_serial 01 - WTF ؟؟؟ لا يمكنك إعادة الأرقام التسلسلية. هل استشرت حتى RFC 4158 ، البنية التحتية للمفتاح العام للإنترنت X.509: مسار مسار الشهادة؟ أم أنك تصنعها بينما تمضي؟ ليست لديك فكرة عن المشكلات التي تسببها في وكلاء المستخدمين عند بدء إنشاء المسار. - jww
jww هل قرأت الإجابة؟ هذا مجرد دليل على حقيقة أن التشفير يعمل. هذا الأمر هو حرفياً مجرد توليد شهادة اختبار يمكننا التحقق منها لاحقًا ، لأغراض اختبار العلاقة بين شهادة الجذر القديمة والجديدة. اذا كان شخص ما هو باستخدام هذه الأوامر مباشرة ، آمل بالتأكيد أن يحدث شيء ما ، وأنهم يدركون أنهم بحاجة إلى الانتباه إلى سياق شيء ما قبل تشغيله بشكل أعمى (أو تحريك المقبض حول ما إذا كان 01 هو مسلسل مقبول في المختبر). - Shane Madden♦


لقد لاحظت أن ملحقات CA قد تكون مفقودة في الشهادة المجدّدة لمفتاح CA الأصلي. هذا عمل أكثر ملاءمة لي (يخلق ./renewedselfsignedca.conf حيث يتم تعريف ملحقات CA3 CA ، و ca.key و ca.crt يفترض أن يكون مفتاح CA الأصلي والشهادة):

openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca

13
2018-04-22 10:31



لقد كان هذا إضافة مفيدة للغاية. لا ينتج عن الإجابة الصالحة فعلاً شهادة متوافقة بشكل كافٍ لي إذا كان لديك إعدادات عشوائية في الجذر الأصلي الخاص بك. - Theuni
مثار ، مفيدة للغاية. إضافة أخرى: مثل سكوت بريسنيل في التعليقات على الإجابة المقبولة ، كان عليّ أيضاً تحديد الرقم التسلسلي الستين للشهادة المجددة يدويًا بحيث تتطابق مع الرقم القديم. هذا يعني إضافة -set_serial 0xdeadbeefabba (وليس المسلسل الحقيقي لا :)) إلى الأمر الأخير x509. عندئذ فقط تحقق شهادات العميل بنجاح من شهادة CA المتجددة. - JK Laiho
هذه الطريقة أسهل لأنها تحتفظ بنفس المعلومات من الشهادة السابقة. - lepe
لقد قمت بإنشاء برنامج نصي لهذا الحل plus -set_serial - انظر إجابتي - Wolfgang Fahl
أنقذتني هذه الإجابة الكثير من العمل ، بعد أن أمضيت يومًا تقريبًا في مسألة تتطلب ذلك ، كنت على وشك الاستسلام ، فأنا أضع قبعتي لك على هذا! - Onitlikesonic


الوضع الأساسي لتمديد الفترة الصالحة من الجذر (تحتاج إلى X.509 العام والمفتاح الخاص المنتقل):

قم بتوليد CSR من X.509 العام والمفتاح الخاص:

openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

أعد التوقيع على CSR بالمفتاح الخاص:

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365

2
2018-01-22 16:35





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

لا يمكنك "تجديد" شهادة الجذر. كل ما يمكنك فعله هو إنشاء واحدة جديدة.

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

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


0
2017-09-03 23:59



هذا الرد يبدو أنه من الممكن تجديد شهادة الجذر ، عن طريق إعادة استخدام مفتاحها. ولكني أظن أن هذا لا يختلف عن البدء من الصفر ، لأن الشهادة الجديدة سيكون لها توقيع مختلف ، ومن ثم لن تثبت صحة سير العميل الحالي. - Remy Blank
نعم ، يمكنك تمديد فترة صالحة ... وأقل عمل من إعادة إنشاء جميع شهادات pki ، العميل ، واستعادة جذر جديد ... - ggrandes
الجزء المتعلق بإصدار شهادات الكيان النهائي الجديد ليس صحيحًا بالضرورة. ويعتمد ذلك على كيفية تمثيل معرّف مفتاح السلطة (AKID) في المرؤوسين التابعين للجنة شهادات CA وشهادات الكيان النهائي. إذا كان AKID يعتمد على {الاسم المميز ، الرقم التسلسلي}، ثم سيتم تحقيق الاستمرارية. انظر أيضا RFC 4518 ، إنترنت X.509 البنية التحتية للمفتاح العام: مبنى مسار الشهادة. - jww


عملتBianconiglio plus -set_serial بالنسبة لي. الخادم الخاص بي هو إنترانت فقط لذا لا أشعر بالقلق للكثير من الآثار الجانبية ولدي الآن الوقت للعمل على حل "مناسب".

لقد استخدمت البرنامج النصي التالي القابل للتكوين. فقط قم بتعيين المتغيرات CACRT و CAKEY و NEWCA.

# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout

0
2018-06-30 17:33





لقد واجهتنا نفس المشكلة ، وكان ذلك في حالتنا نظرًا لأن خادم دبيان كان على دراية حتى الآن ، وكانت openSSL تعاني من هذه المشكلة:

https://en.wikipedia.org/wiki/Year_2038_problem

يوفر الإصدار الأخير من OpenSSL المتوفر لـ Debian 6 هذه المشكلة. جميع الشهادات التي تم إنشاؤها بعد 23.01.2018 تنتج Vality: لسنة 1901!

الحل هو تحديث OpenSSL. يمكنك إنشاء ملفات التكوين (مع الشهادات) مرة أخرى للعملاء.


0
2018-03-09 10:38