دليل نشر IOS PKI: إعادة توجيه الشهادة - نظرة عامة على التكوين والتشغيل

المقدمة

يصف هذا المستند تمرير الشهادة على خوادم وعملاء Cisco IOS للبنية الأساسية للمفتاح العام (PKI) بالتفصيل. 

المتطلبات الأساسية

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى إصدارات المكونات المادية والبرامج التالية:

الأجهزة

• ISR-G1 [8xx، 18xx، 28xx، 38xx]
• ISR-G2 [19xx و 29xx و 39xx]
• ISR-4K [43xx، 44xx]
• ASR1k
• CSR1k

البرنامج

• IOS
• ل ISR-G1 - الأحدث 15.1(4)M*
• ل ISR-G2 - الأحدث 15.4(3)M

• IOS-XE
• XE 3.15 أو 15.5(2)S

ملاحظة: لم تعد صيانة البرامج العامة لأجهزة ISR نشطة، سيتطلب أي عمليات إصلاح للأخطاء أو تحسينات للميزات في المستقبل ترقية الأجهزة إلى موجهات سلسلة ISR-2 أو ISR-4xxx.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك مباشرة، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

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

إعداد

متطلبات بروتوكول التسجيل البسيط (SCEP) ل PKI

مصدر الوقت المخول

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

لا يقوم IOS بتهيئة وحدات توقيت PKI بدون ساعة موثوق بها. على الرغم من أنه يوصى بشدة باستخدام بروتوكول وقت الشبكة (NTP)، إلا أنه يمكن للمسؤول وضع علامة على ساعة الأجهزة كموثوق بها باستخدام:

Router(config)# clock calendar-valid

اتصال HTTP

متطلب لخادم IOS PKI نشط هو خادم HTTP، والذي يمكن تمكينه باستخدام الأمر config-level هذا:

ip http server <1024-65535>

يقوم هذا الأمر بتمكين خادم HTTP على المنفذ 80 بشكل افتراضي، والذي يمكن تغييره كما هو موضح أعلاه.

يجب أن يكون عملاء PKI قادرين على الاتصال بخادم PKI عبر HTTP إلى المنفذ الذي تم تكوينه.

تكوين PKI

الخادم - المرور

يبدو تكوين المرور التلقائي لخادم PKI كما يلي:

crypto pki server ROOTCA
  database level complete
  database archive pkcs12 password 7 01100F175804575D72
  issuer-name CN=RootCA,OU=TAC,O=Cisco
  grant auto
  lifetime certificate 365
  lifetime ca-certificate 730
  database url ftp://10.1.1.1/DB/ROOTCA/
  auto-rollover 90

يتم تحديد معلمة المرور التلقائي بالأيام. وعلى مستوى أكثر دقة، يبدو الأمر كما يلي:

auto-rollover <days> <hours> <minutes>

تشير قيمة التمرير التلقائي التي تبلغ 90 إلى أن IOS يقوم بإنشاء شهادة خادم تمرير قبل 90 يوما من انتهاء صلاحية شهادة الخادم الحالية، وتبدأ صلاحية شهادة التمرير الجديدة هذه في نفس وقت انتهاء صلاحية الشهادة النشطة الحالية.

يجب تكوين التمرير التلقائي باستخدام قيمة تضمن إنشاء شهادة مرجع مصدق المرور فوق خادم PKI بشكل مسبق قبل أن يقوم أي عميل PKI في الشبكة بتنفيذ عملية GetNextCACert كما هو موضح في قسم نظرة عامة على عملية الظل أدناه.

العميل - التجديد

يبدو تكوين تجديد الشهادة التلقائي لعميل PKI كما يلي:

crypto pki trustpoint Root-CA
   enrollment url http://172.16.1.1:80
   serial-number
   ip-address none
   password 0 Rev0cati0n$Passw0rd
   subject-name CN=spoke-1.cisco.com,OU=CVO
   revocation-check crl
   rsakeypair spoke-1-RSA
   auto-enroll 80

هنا، ينص الأمر <percentage> [regenerate] للتسجيل التلقائي على أن يقوم IOS بتجديد الشهادة بنسبة 80٪ تماما من العمر الافتراضي للشهادة الحالية.

تذكر الكلمة الأساسية regenerate أنه يجب على IOS إعادة إنشاء زوج مفاتيح RSA المعروف باسم زوج مفاتيح الظل أثناء كل عملية لتجديد الشهادة.

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

متطلبات تجديد/إعادة توجيه PKI

يتناول هذا المستند عمليات إعادة توجيه الشهادة وتجديدها بالتفصيل، وبالتالي تعتبر هذه الأحداث مكتملة بنجاح:

• تهيئة خادم PKI بشهادة CA صالحة.
• تم تسجيل عملاء PKI بنجاح مع خادم PKI، أي أن كل عميل PKI لديه شهادة CA وشهادة هوية مع شهادة موجه.

يتضمن تسجيل عميل هذه الأحداث. دون الخوض في تفاصيل كثيرة:

• مصادقة TrustPoint
• تسجيل TrustPoint

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

بعد إسترداد/تثبيت شهادة CA، يسترجع عميل PKI إمكانيات خادم PKI قبل تنفيذ التسجيل. يتم شرح إسترداد قدرات CA في هذا القسم.

قدرات CA

في IOS، عندما يقوم عميل PKI بمصادقة CA، بمعنى آخر، عندما يقوم المسؤول بإنشاء نقطة ثقة على موجه IOS وتنفيذ الأمر crypto pki authenticate <trustPoint-name>، تحدث هذه الأحداث على الموجه:

• يرسل IOS طلب SCEP يحتوي على نوع عملية GetCACert.
• الاستجابة المتوقعة هنا هي رسالة HTTP مع نوع محتوى تطبيق/x-x509-ca-cert في حالة نشر CA، أو تطبيق/x-x509-ca-ra-cert في حالة نشر RA و CA. يحتوي نص HTTP على شهادة CA. [وشهادة تقدير المخاطر في الحالة الأخيرة].
• بعد إسترداد وتثبيت شهادة CA/RA، يبدأ العميل طلب SCEP تلقائي يحتوي على عملية GetCACaps.
• الاستجابة المتوقعة هنا هي رسالة HTTP بنوع محتوى التطبيق/x-pki-message، والتي يمكن أن تكون أيضا نص/عادي ويحتوي نص HTTP على سلسلة من القدرات المدعومة من قبل CA، مفصولة بحرف تغذية خط. تظهر إستجابة نموذجية لخادم IOS PKI كما هو موضح في الرسم التخطيطي أدناه.

ويفسر عميل IOS PKI الاستجابة على أنها:

CA_CAP_GET_NEXT_CA_CERT
CA_CAP_RENEWAL
CA_CAP_SHA_1
CA_CAP_SHA_256

يركز هذا المستند على هاتين الميزتين.

GetNextCACert

عندما يتم إرجاع هذه الإمكانية من قبل المرجع المصدق (CA)، يدرك IOS أن المرجع المصدق يدعم إعادة تمرير شهادة المرجع المصدق. مع هذه الإمكانية التي تم إرجاعها، إذا لم يتم تكوين أمر التسجيل التلقائي ضمن TrustPoint، يقوم IOS بتهيئة مؤقت ظل معين إلى 90٪ من فترة صلاحية شهادة CA.

عند انتهاء صلاحية مؤقت الظل، يقوم IOS بتنفيذ عملية GetNextCacErt SCEP لجلب شهادة المرجع المصدق (CA) العابرة.

ملاحظة: إذا تم تكوين أمر التسجيل التلقائي ضمن TrustPoint مع عنوان URL للتسجيل، فسيتم تهيئة مؤقت RENEW حتى قبل مصادقة TrustPoint، ويحاول بشكل مستمر التسجيل مع CA الموجود في عنوان URL للتسجيل، رغم عدم إرسال رسالة تسجيل فعلية [CSR] حتى يتم مصادقة TrustPoint.

ملاحظة: يتم إرسال GetNextCACert كإمكانية بواسطة خادم IOS PKI حتى إذا لم يتم تكوين إعادة التوجيه التلقائي على SERV

تجديد

بهذه الإمكانية، يقوم خادم PKI بإعلام عميل PKI أنه يمكنه إستخدام شهادة معرف نشطة لتوقيع طلب توقيع شهادة لتجديد الشهادة الموجودة.

المزيد حول هذا الأمر في قسم التجديد التلقائي لعميل PKI.

النقل التلقائي لخادم PKI

مع التكوين المذكور أعلاه على خادم CA، يمكنك الاطلاع على:

Root-CA#show crypto pki certificates
CA Certificate
  Status: Available
  Certificate Serial Number (hex): 01
  Certificate Usage: Signature
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    cn=RootCA
    ou=TAC
    o=Cisco
  Validity Date:
    start date: 13:14:16 CET Oct 9 2015
    end   date: 13:14:16 CET Oct 8 2017
  Associated Trustpoints: ROOTCA

Root-CA#terminal exec prompt timestamp

Root-CA#show crypto pki timers
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 13:19:58.946 CET Fri Oct 9 2015
PKI Timers
|        7:49.003
  |        7:49.003  SESSION CLEANUP
  |  3d 7:05:24.003  TRUSTPOOL
CS Timers
|     5:54:17.977
  |     5:54:17.977  CS CRL UPDATE
  |639d23:54:17.977  CS SHADOW CERT GENERATION
  |729d23:54:17.971  CS CERT EXPIRE

لاحظ هذا:

عملية التمرير

 عند انتهاء صلاحية المؤقت لإنشاء شهادة ظل CS:

• يقوم IOS بإنشاء زوج مفاتيح إعادة توجيه أولا - وهو يحمل حاليا نفس اسم زوج المفاتيح النشط مع # تجزئة ملحقة به.
  
  

  
  Jul 10 13:14:16.510: CRYPTO_CS: shadow generation timer fired.
  Jul 10 13:14:16.510: CRYPTO_CS: key 'ROOTCA#' does not exist; generated automatically
  
  Root-CA# show crypto key mypubkey rsa
  Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
  Time source is NTP, 13:19:19.652 CET Mon Jul 10 2017
  
  % Key pair was generated at: 13:14:16 CET Oct 9 2015
  Key name: ROOTCA
  Key type: RSA KEYS
   Storage Device: private-config
   Usage: General Purpose Key
   Key is not exportable.
   Key Data:
    30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00B07127
    360CF006 13B259CE 7BB8158D E6BC8AA4 8A763F73 50CE64B0 71AC5D93 ED59C936
    F751D810 70CEA8C8 B0023B4B 0FB9A538 A1C118D3 5530D46D C4B4DC14 3BD1D231
    48B0C053 A781D0C7 86DEE9DE CCA58C18 B5804B29 911D1D57 76B3EC3F 42D38C3A
    1E0F8DD9 1DE228B9 95AC3C10 87C132FC 75956338 258727F6 1A1F0818 83020301 0001
  
  % Key pair was generated at: 13:14:18 CET Jul 10 2017
  Key name: ROOTCA#
  Key type: RSA KEYS
   Storage Device: not specified
   Usage: General Purpose Key
   Key is not exportable.
   Key Data:
    30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00BF2A52
    687F112B C9263541 BB402939 9C66D270 8D3EACED 4F63AA50 9FB340E8 38C8AC38
    1818EA43 93C17CA1 C4917F43 C9199C9E F9F9C059 FDE11DA9 C7991826 43736FCE
    A80D0CEE 2378F23B 6AC5FC3B 4A7A0120 D391BE8F A9AFD212 E05A2864 6610233C
    E0E58D93 23AA0ED2 A5B1C140 122E6E3D 98A7D974 E2363902 70A89CE3 BF020301 0001
  
  

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

  Jul 10 13:14:18.326: CRYPTO_CS: shadow CA successfully created.
  Jul 10 13:14:18.326: CRYPTO_CS: exporting shadow CA key and cert
  Jul 10 13:14:18.327: CRYPTO_CS: file opened: ftp://10.1.1.1/DB/ROOTCA/ROOTCA_00001.p12

Root-CA# show crypto pki certificates
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 13:14:46.820 CET Mon Jul 10 2017

CA Certificate (Rollover)
  Status: Available
  Certificate Serial Number (hex): 03
  Certificate Usage: Signature
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    Name: RootCA
    cn=RootCA
    ou=TAC
    o=Cisco
  Validity Date:
    start date: 13:14:16 CET Oct 8 2017
    end   date: 13:14:16 CET Oct 8 2019
  Associated Trustpoints: ROOTCA

CA Certificate
  Status: Available
  Certificate Serial Number (hex): 01
  Certificate Usage: Signature
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    cn=RootCA
    ou=TAC
    o=Cisco
  Validity Date:
    start date: 13:14:16 CET Oct 9 2015
    end   date: 13:14:16 CET Oct 8 2017
  Associated Trustpoints: ROOTCA
  Storage: nvram:RootCA#1CA.cer

Root-CA# show crypto pki server
Certificate Server ROOTCA:
 Status: enabled
 State: enabled
 Server's configuration is locked (enter "shut" to unlock it)
 Issuer name: CN=RootCA,OU=TAC,O=Cisco
 CA cert fingerprint: CC748544 A0AB7832 935D8CD0 214A152E
 Granting mode is: manual
 Last certificate issued serial number (hex): 6
 CA certificate expiration timer: 13:14:16 CET Oct 8 2017
 CRL NextUpdate timer: 19:11:54 CET Jul 10 2017
 Current primary storage dir: unix:/iosca-root/
 Database Level: Complete - all issued certs written as <serialnum>.cer
 Rollover status: available for rollover
 Rollover CA certificate fingerprint: 031904DC F4FAD1FD 8A866373 C63CE20F
 Rollover CA certificate expiration time: 13:14:16 CET Oct 8 2019
 Auto-Rollover configured, overlap period 90 days

Root-CA# show run | section chain ROOTCA
crypto pki certificate chain ROOTCA
 certificate ca rollover 03
  30820237 308201A0 A0030201 02020103 300D0609 2A864886 F70D0101 04050030
  2F310E30 0C060355 040A1305 43697363 6F310C30 0A060355 040B1303 54414331
  0F300D06 03550403 1306526F 6F744341 301E170D 31373130 30383132 31343136
  5A170D31 39313030 38313231 3431365A 302F310E 300C0603 55040A13 05436973
  636F310C 300A0603 55040B13 03544143 310F300D 06035504 03130652 6F6F7443
  4130819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281 8100BF2A
  52687F11 2BC92635 41BB4029 399C66D2 708D3EAC ED4F63AA 509FB340 E838C8AC
  381818EA 4393C17C A1C4917F 43C9199C 9EF9F9C0 59FDE11D A9C79918 2643736F
  CEA80D0C EE2378F2 3B6AC5FC 3B4A7A01 20D391BE 8FA9AFD2 12E05A28 64661023
  3CE0E58D 9323AA0E D2A5B1C1 40122E6E 3D98A7D9 74E23639 0270A89C E3BF0203
  010001A3 63306130 0F060355 1D130101 FF040530 030101FF 300E0603 551D0F01
  01FF0404 03020186 301F0603 551D2304 18301680 1419FCA4 DDE84233 F79C066F
  93CCF6B3 E14F8355 31301D06 03551D0E 04160414 19FCA4DD E84233F7 9C066F93
  CCF6B3E1 4F835531 300D0609 2A864886 F70D0101 04050003 81810065 AC780BB4
  2398D765 BE4C4C0A 0D0F16C0 82530D85 99933BDC 8388C46D 926145D8 B0BA275A
  93AAB497 FC876F6A E951C138 F5D652AE C0C25E2A FDD80BAA C6BD5A78 E439158F
  5544F30F 33C59E22 1994A8D3 AADC1287 BD15A104 55CB5DC3 49A9401A 8DB3940A
  5054EA21 99CCE4F3 40B471FE DEB4BB38 AC3ACD48 4CDDCBC9 9829D3
      quit
certificate ca 01
  30820237 308201A0 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
  2F310E30 0C060355 040A1305 43697363 6F310C30 0A060355 040B1303 54414331
  0F300D06 03550403 1306526F 6F744341 301E170D 31353130 30393132 31343136
  5A170D31 37313030 38313231 3431365A 302F310E 300C0603 55040A13 05436973
  636F310C 300A0603 55040B13 03544143 310F300D 06035504 03130652 6F6F7443
  4130819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281 8100B071
  27360CF0 0613B259 CE7BB815 8DE6BC8A A48A763F 7350CE64 B071AC5D 93ED59C9
  36F751D8 1070CEA8 C8B0023B 4B0FB9A5 38A1C118 D35530D4 6DC4B4DC 143BD1D2
  3148B0C0 53A781D0 C786DEE9 DECCA58C 18B5804B 29911D1D 5776B3EC 3F42D38C
  3A1E0F8D D91DE228 B995AC3C 1087C132 FC759563 38258727 F61A1F08 18830203
  010001A3 63306130 0F060355 1D130101 FF040530 030101FF 300E0603 551D0F01
  01FF0404 03020186 301F0603 551D2304 18301680 148D421A BED6DCAD B8CFE4B4
  1B2C7E41 C73428AC 9A301D06 03551D0E 04160414 8D421ABE D6DCADB8 CFE4B41B
  2C7E41C7 3428AC9A 300D0609 2A864886 F70D0101 04050003 8181008C 3495278E
  DA6C14B0 533E746D 8DA743AF 06BE4088 913BF9BC A94576FA BC86EFD1 1DFE6B9F
  0D244144 473C67AD 24414A20 84E9B083 D1720766 0A698C29 115482C6 2FB57E86
  95CDECF2 29662362 866CDC91 730ADBB3 BDBBDC3C EA5301B0 150658E7 AF722BD7
  6B5C2D6A 661A4FED CDA32DE5 D6C2CE7A 544086DC F957A87C 2C07FF
      quit

النقل اليدوي لخادم PKI

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

يمكن تشغيل تمرير يدوي باستخدام الأمر مستوى التكوين:

crypto pki server <Server-name> rollover

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

crypto pki server <Server-name> rollover cancel

يؤدي ذلك إلى حذف زوج مفاتيح RSA الذي يتم المرور فوقه وشهادة CA التي يتم إرسالها. ينصح بعدم القيام بذلك لأن:

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

التجديد التلقائي لعميل PKI

أنواع تجديد شهادات العميل - التجديد والظل

يتأكد IOS على خادم PKI دائما من أن وقت انتهاء صلاحية شهادة المعرف الصادرة للعميل لا يتجاوز وقت انتهاء صلاحية شهادة CA.

على عميل PKI، يأخذ IOS دائما وحدات التوقيت التالية في الاعتبار قبل جدولة عملية التجديد:

• وقت انتهاء صلاحية شهادة الهوية التي يتم تجديدها
• وقت انتهاء صلاحية شهادة المصدر (CA)

إذا لم يكن وقت انتهاء صلاحية شهادة الهوية هو نفسه وقت انتهاء صلاحية شهادة CA، فإن IOS يجري عملية تجديد بسيطة.

إذا كان وقت انتهاء صلاحية شهادة الهوية هو نفسه وقت انتهاء صلاحية شهادة CA، فإن IOS يجري عملية تجديد ظل.

تجديد - تجديد شهادة هوية الموجه

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

بمجرد تثبيت شهادة هوية، يقوم IOS بحساب مؤقت التجديد لنقطة الثقة المحددة كما هو موضح أدناه:

يعني "الوقت الحالي - الموثوق به" أنه يجب أن تكون ساعة النظام مصدرا موثوق للوقت كما هو موضح هنا. (رابط إلى قسم مصدر الوقت المخول) لن تتم تهيئة وحدات توقيت PKI دون مصدر وقت موثوق. وكنتيجة لذلك، لن تجري عملية التجديد.

تحدث الأحداث التالية عند انتهاء صلاحية مؤقت التجديد:

• يقوم IOS بإنشاء زوج مفاتيح ظل إذا تم تكوين إعادة الإنشاء [مثال: إعادة إنشاء التسجيل التلقائي 80]. دون إعادة إنشاء IOS، قم بإعادة إستخدام زوج مفاتيح RSA النشط حاليا.
• يقوم IOS بإنشاء طلب شهادة بتنسيق PKCS-10، والذي يتم تشفيره بعد ذلك في مظروف PKCS-7. يحتوي هذا المغلف أيضا على RecipientInfo، وهو اسم الموضوع والرقم التسلسلي الخاص بإصدار المرجع المصدق. هذا PKCS7-envelope بدوره تم حزمه إلى PKCS-7 بيانات موقعة. أثناء التسجيل الأولي، يستخدم IOS شهادة موقعة ذاتيا لتوقيع هذه الرسالة. وأثناء عمليات التسجيل اللاحقة، أي عمليات إعادة التسجيل، يستخدم IOS شهادة الهوية النشطة لتوقيع الرسالة. كما يتم تضمين بيانات PKCS7 الموقعة مع شهادة التوقيع، أي إما شهادة التوقيع الذاتي أو شهادة الهوية.

 لمزيد من المعلومات حول بنية الحزمة هذه، ارجع إلى مستند نظرة عامة على SCEP

ملاحظة: المعلومات الأساسية هنا هي RecipientInfo وهو اسم الموضوع والرقم التسلسلي الخاص ب CA الإصدار، ويتم إستخدام المفتاح العام لهذا CA لتشفير المفتاح المتماثل. يتم تشفير CSR في مظروف PKCS7 باستخدام هذا المفتاح المتماثل.

يتم فك تشفير هذا المفتاح المتماثل المشفر بواسطة المرجع المصدق المتلقي باستخدام مفتاحه الخاص، ويتم إستخدام هذا المفتاح المتماثل لفك تشفير مظروف PKCS7 الذي يكشف CSR.

• يتم بعد ذلك إرسال طلب توقيع الشهادة (CSR) هذا المجهز بتنسيق PKCS7 إلى CA مع نوع رسالة SCEP من PKCSReq وعملية SCEP تسمى PKIOperation.
• إذا رفض المرجع المصدق الطلب، يقوم IOS بإيقاف مؤقت التجديد. من هذه النقطة فصاعدا، لتجديد شهادة الهوية، يجب على المسؤول إجراء تجديد يدوي (إرتباط بقسم التجديد اليدوي لعميل PKI)
• إذا قام المرجع المصدق بإرسال حالة SCEP معلقة، فإن IOS الموجود على عميل PKI يبدأ تشغيل مؤقت الاستطلاع في 60 ثانية أو دقيقة واحدة. في كل مرة تنتهي فيها صلاحية مؤقت للاستطلاع، يرسل IOS رسالة GetCertInitial SCEP من خلال عملية PKIOperation.عندما تنتهي صلاحية المؤقت الأول للاستطلاع، إذا تم الاستجابة لرسالة GetCertInitial بحالة SCEP معلق، تقوم خوارزمية التراجع الأسي بتعيين الفاصل الزمني الأول لإعادة محاولة إجراء الاستطلاع إلى دقيقة واحدة، والفاصل الزمني الثاني لإعادة محاولة إجراء الاستطلاع إلى دقيقتين، والفاصل الزمني الثالث لإعادة محاولة إجراء الاستطلاع إلى 4 دقائق، وهكذا لإعادة المحاولة التالية ل 999 مرة بشكل افتراضي أو حتى انتهاء صلاحية شهادة CA الإصدار.
  يمكن تكوين عدد الاستقصاء وفترة إعادة المحاولة الأولى باستخدام:

   crypto pki trustpoint <TP>
      enrollment retry count <total retry count>
      enrollment retry period <first retry period in minutes>

• عندما يتم منح الشهادة على خادم PKI، فإن رسالة GetCertInitial SCEP التالية يتم الرد عليها باستخدام رسالة HTTP من نوع المحتوى application/x-pki-message ونص يحتوي على بيانات موقعة من PKCS#7. تحتوي هذه البيانات الموقعة على PKCS7 حالة SCEP كما هي مفوضة، وأيضا بيانات PKCS7 المظلة. تحتوي بيانات PKCS المغلفة هذه على الشهادة الممنوحة و RecipientInfo، وهو اسم الموضوع والرقم التسلسلي للشهادة الموقعة ذاتيا أثناء التسجيل الأولي وشهادة الهوية النشطة أثناء عمليات إعادة التسجيل.

تحتوي أيضا بيانات PKCS7 المغلفة على مفتاح متماثل مشفر باستخدام المفتاح العام الخاص بالمستلم (والذي تم منح الشهادة الجديدة له). يؤدي إستلام الموجه إلى فك تشفيره باستخدام المفتاح الخاص. ثم يتم إستخدام هذا المفتاح المتناظر الواضح لفك تشفير بيانات PKCS#7 المظمنة، كاشفا شهادة الهوية الجديدة.

• في هذه المرحلة، يستبدل IOS شهادة الهوية الحالية بالشهادة الجديدة فورا. وإذا تم تكوين إعادة الإنشاء، فإن زوج مفاتيح الظل يحل محل زوج المفاتيح النشط كذلك.

• كما تتم مقارنة تاريخ انتهاء الشهادة الجديدة بتاريخ انتهاء شهادة CA لتحديد ما إذا كان يجب تهيئة مؤقت "التجديد" أو أنه يجب تهيئة مؤقت "الظل" كما هو موضح هنا <أنواع href من "تجديد شهادة العميل" - تجديد و SHADOW>

التحقق

سيحصل عميل PKI المسجل حديثا على شهادة هوية (تعرف أيضا بشهادة الموجه أو شهادة الكيان النهائي) وشهادة المرجع المصدق (CA) الصادرة تحت نقطة الثقة المسجلة

PKI-Client# show crypto pki certificates
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 14:10:38.279 CET Wed Jul 27 2016

Certificate
  Status: Available
  Certificate Serial Number (hex): 05
  Certificate Usage: General Purpose
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    Name: PKI-Client.cisco.com
    Serial Number: 104
    serialNumber=104+hostname=PKI-Client.cisco.com
    cn=PKI-Client
    ou=Root
  Validity Date:
    start date: 14:12:34 CET Oct 9 2015
    end   date: 14:12:34 CET Oct 8 2016
    renew date: 14:12:18 CET Jul 27 2016
  Associated Trustpoints: Root-CA
  Storage: nvram:RootCA#5.cer

CA Certificate
  Status: Available
  Certificate Serial Number (hex): 01
  Certificate Usage: Signature
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    cn=RootCA
    ou=TAC
    o=Cisco
  Validity Date:
    start date: 13:14:16 CET Oct 9 2015
    end   date: 13:14:16 CET Oct 8 2017
  Associated Trustpoints: Root-CA
  Storage: nvram:RootCA#1CA.cer

مؤقت PKI المتوافق هو:

PKI-Client# show crypto pki timers
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 14:29:34.054 CET Fri Oct 9 2015
PKI Timers
|       14:51.284
  |       14:51.284  SESSION CLEANUP
  |291d23:42:59.946  RENEW Root-CA

الحساب كما هو موضح هنا

RENEW = 0.8 ((end date: 14:12:34, Oct 8 2016) - (start date: 14:12:24, Oct 9 2015))
      = 292 days from (14:12:34, Oct 9 2015)
      = 291 days 23:42:59 hours from (14:29:34, Oct 9 2015)
      = at 14:12:18 CET Jul 27 2016

عند انتهاء صلاحية مؤقت التجديد:

Jul 27 14:12:18.800: %PKI-6-CERTRENEWAUTO: Renewing the router certificate for trustpoint Root-CA
Jul 27 14:12:23.056: %CRYPTO-6-AUTOGEN: Generated new 2048 bit key pair
Jul 27 14:12:23.084: CRYPTO_PKI: using private key PKI-Key# for enrollment

لاحظ أنه تم توقيع طلب التجديد باستخدام شهادة المعرف النشطة الحالية:

Jul 27 14:12:25.117: PKI: Trustpoint Root-CA has router cert and loaded
Jul 27 14:12:25.117: PKI: Signing pkcs7 with Root-CA trustpoint router cert
Jul 27 14:12:25.117: PKI: key rollover configured and active

إذا كانت إستجابة SCEP المستلمة معلقة، سنبدأ تشغيل مؤقت الاستطلاع:

Jul 27 14:12:25.167: CRYPTO_PKI_SCEP: Client received CertRep - PENDING (F9A1FB9813EEA8AC86AE334DDC7CF488)
Jul 27 14:12:25.167: CRYPTO_PKI: status = 102: certificate request pending

PKI-Client# show crypto pki timer
PKI Timers
|        3:44.484
  |        0:44.484  POLL Root-CA

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

عند انتهاء صلاحية مؤقت الاستقصاء، يتم منح إستجابة SCEP:

Jul 27 14:16:25.301: CRYPTO_PKI_SCEP: Client received CertRep - GRANTED (F9A1FB9813EEA8AC86AE334DDC7CF488)
Jul 27 14:16:25.301: CRYPTO_PKI: status = 100: certificate is granted

Jul 27 14:16:25.325: Newly-issued Router Cert: issuer=cn=RootCA,ou=TAC,o=Cisco serial=6
Jul 27 14:16:25.325: start date: 14:15:05 CET Jul 27 2016
Jul 27 14:16:25.325: end date: 14:15:05 CET Jul 27 2017
Jul 27 14:16:25.325: Router date: 14:16:25 CET Jul 27 2016
Jul 27 14:16:25.325: Received router cert from CA
Jul 27 14:16:25.325: CRYPTO_PKI: Setting renewal timers

Jul 27 14:16:25.325: CRYPTO_PKI: removing superceded cert serial #: 05
Jul 27 14:16:25.325: CRYPTO_PKI: Key Rollover - Switched from keypair PKI-Key# to PKI-Key

Jul 27 14:16:25.325: PKI: our cert expires before the CA cert for Root-CA
Jul 27 14:16:25.326: CRYPTO_PKI: current date: 14:16:25 CET Jul 27 2016
Jul 27 14:16:25.326: CRYPTO_PKI: seconds until reenroll: 1494854105
Jul 27 14:16:25.326: CRYPTO_PKI: cert expire date: 14:15:05 CET Jul 27 2017
Jul 27 14:16:25.326: CRYPTO_PKI: renew date: 14:15:05 CET May 15 2017

بعد تجديد شهادة الموجه:

PKI-Client# show crypto pki certificates
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 14:22:07.799 CET Wed Jul 27 2016

Certificate
  Status: Available
  Certificate Serial Number (hex): 06
  Certificate Usage: General Purpose
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    Name: PKI-Client.cisco.com
    Serial Number: 104
    serialNumber=104+hostname=PKI-Client.cisco.com
    cn=PKI-Client
    ou=Root
  Validity Date:
    start date: 14:15:05 CET Jul 27 2016
    end   date: 14:15:05 CET Jul 27 2017
    renew date: 14:15:04 CET May 15 2017
  Associated Trustpoints: Root-CA

CA Certificate
  Status: Available
  Certificate Serial Number (hex): 01
  Certificate Usage: Signature
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    cn=RootCA
    ou=TAC
    o=Cisco
  Validity Date:
    start date: 13:14:16 CET Oct 9 2015
    end   date: 13:14:16 CET Oct 8 2017
  Associated Trustpoints: Root-CA
  Storage: nvram:RootCA#1CA.cer

PKI-Client# show crypto pki timers
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 14:22:17.231 CET Wed Jul 27 2016
PKI Timers
|       14:48.735
  |       14:48.735  SESSION CLEANUP
  |291d23:52:48.094  RENEW Root-CA

الظل - هوية الموجه وتجديد شهادة CA الإصدار

يجري عميل IOS PKI عملية تجديد ظل إذا كان وقت انتهاء صلاحية شهادة الهوية هو نفسه وقت انتهاء صلاحية شهادة CA، بمعنى آخر تنتهي شهادة الهوية في نفس الوقت الذي تقوم فيه شهادة المصدر بتشغيل عملية تجديد ظل.

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

تحدث الأحداث التالية عند انتهاء صلاحية مؤقت الظل لنقطة ثقة معينة:

• يقوم IOS بتنفيذ عملية GetNextCACert SCEP، حيث تكون الاستجابة المتوقعة هي رسالة HTTP من نوع المحتوى application/x-x509-ca-cert والنص الذي يحتوي على PKCS7 شهادة مرجع مصدق تالي، أي شهادة المصدر مع وقت بدء الصلاحية مساو [أو سابق] لوقت انتهاء الصلاحية لشهادة المصدر الحالي.

ملاحظة: على الرغم من أن مشروع SCEP RFC ينص على أن نوع محتوى الاستجابة يمكن أن يكون application/x-x509-next-ca-cert، فإن تنفيذ IOS يرسل التطبيق/x-x509-ca-cert ويقبله.

ملاحظة: يمكن أن يكون وقت بدء شهادة مرجع مصدق المرور قبل وقت انتهاء صلاحية شهادة المرجع المصدق النشطة الحالية. ومع ذلك، سيتم تنشيط شهادة مرجع مصدق المرور فقط بعد انتهاء صلاحية شهادة المرجع المصدق النشطة الحالية. ومع ذلك، يتأكد خادم Cisco IOS PKI من إنشاء شهادة مرجع مصدق المرور مع وقت بدء الصلاحية المساو لوقت انتهاء الصلاحية لشهادة CA الحالية.

• إذا لم تنجح عملية SCEP ل GetNextCACert، فستحاول مرة أخرى حتى يتم تلقي الاستجابة المتوقعة كما هو موضح في آخر إصدار تنتهي صلاحية شهادة CA (المصدر) الحالية.
• في حالة نجاح عملية GetNextCACert SCEP، يتم تثبيت شهادة المرجع المصدق (CA) العابرة في قاعدة البيانات تحت TrustPoint التي يتم تجديدها كشهادة CA (إعادة توجيه).
• بعد عملية GetNextCACert ناجحة، يقوم IOS بإنشاء زوج مفاتيح ظل إذا تم تكوين إعادة الإنشاء (مثال: التسجيل التلقائي لإعادة إنشاء 80). دون إعادة إنشاء IOS، قم بإعادة إستخدام زوج مفاتيح RSA النشط حاليا.
• يقوم IOS بإنشاء طلب شهادة بتنسيق PKCS-10، والذي يتم تشفيره بعد ذلك في مظروف PKCS-7. يحتوي هذا المظروف أيضا على RecipientInfo، وهو اسم الموضوع والرقم التسلسلي لشهادة مرجع المصدق (CA) المتداول الخاصة بإصدار المرجع المصدق. هذا PKCS7-envelope بدوره تم حزمه إلى PKCS-7 بيانات موقعة. يتم توقيع هذا باستخدام شهادة الهوية النشطة الحالية، ويتم تضمينه أيضا مع بيانات PKCS7 الموقعة.

لمزيد من المعلومات حول بنية الحزمة هذه، ارجع إلى مستند نظرة عامة على SCEP

ملاحظة: المعلومات الأساسية هنا هي RecipientInfo، التي تحتوي على معلومات شهادة المرجع المصدق (CA) المتتالية الخاصة بإصدار المرجع المصدق (CA)، مقارنة بالشهادة النشطة حاليا للمرجع المصدق كما هو الحال أثناء عملية التجديد.

هذه المرة، يتم تشفير المفتاح المتماثل باستخدام المفتاح العام CA الذي يتم المرور عليه. وهذه هي المعلومات التي يستخدمها المرجع المصدق لتوقيع هذا الطلب باستخدام شهادة مرجع مصدق المرور.

ملاحظة: يقوم IOS PKI SCEP بتعبير هذه العملية باسم GetNewCert، على الرغم من أن هذه العملية ما زالت داخليا عبارة عن عملية GetCert، مع حدوث تغيير. والمحور هو معلومات المستلم التي تشير إلى شهادة مرجع مصدق تمرير الملف.

• يتم بعد ذلك إرسال طلب توقيع الشهادة [CSR] الذي يتم تجميعه بتنسيق PKCS7 إلى CA مع نوع رسالة SCEP الخاصة ب PKCSReq وعملية SCEP تسمى PKIOperation.
• من هنا فصاعدا، العملية هي نفسها العملية الخاصة بعملية التجديد، أي مؤقت الاستطلاع إذا كانت حالة SCEP معلقة، ويقوم كل انتهاء صلاحية مؤقت للاستطلاع بتشغيل رسالة GetCertInitial SCEP.
• عندما يتم منح الشهادة على خادم PKI، فإن رسالة GetCertInitial SCEP التالية يتم إستجابتها باستخدام رسالة HTTP من نوع المحتوى application/x-pki-message ونص يحتوي على بيانات PKCS7 موقعة. تحتوي هذه البيانات الموقعة على PKCS7 حالة SCEP كما هي مفوضة، وموقعة من قبل ومضمنة مع معلومات شهادة OverThrough CA (اسم الموضوع والرقم التسلسلي) وكذلك بيانات PKCS7 المظللة. تحتوي بيانات PKCS المظللة هذه على شهادة الظل الممنوحة و RecipientInfo، وهو اسم الموضوع والرقم التسلسلي لشهادة الهوية النشطة الحالية.

ملاحظة: تحتوي أيضا بيانات PKCS7 المغلفة على مفتاح متماثل مشفر باستخدام المفتاح العام للمستلم [الذي تم منح شهادة الظل له]. يقوم الموجه المتلقي بفك تشفيره باستخدام مفتاح الظل الخاص. بعد ذلك يتم إستخدام هذا المفتاح المتناظر الواضح لفك تشفير بيانات PKCS#7 المغلفة، كاشفا شهادة هوية الظل.

ملاحظة: بيانات بدء شهادة الظل الممنوحة هي نفس بيانات شهادة مرجع مصدق المرور الفوقي. وهذه أيضا نفس بيانات نهاية شهادة الهوية النشطة الحالية وكذلك بيانات شهادة CA.

ملاحظة: المعلومات الخاصة بشهادة OverCA المدمجة مع بيانات PKCS7 الموقعة هي أحد الأمور التي تنبه موجه العميل إلى أن البيانات المغلفة ب PKCS7 تحتوي على شهادة ظل.

• يتم تثبيت شهادة المرور الفوقي في قاعدة بيانات الشهادات تحت TrustPoint كشهادة مرور، بدون التأثير على الشهادة النشطة الحالية. وإذا تم تكوين إعادة الإنشاء، يتم الاحتفاظ بزوج مفاتيح الظل <active-keypair-name#> باستخدام اسمه المؤقت.
• عندما تنتهي صلاحية الشهادة النشطة الحالية، بالإضافة إلى شهادة CA، فإن كل من شهادة OverCA وشهادة الهوية العابرة تستبدل نظيراتها وتصبح نشطة. وإذا كان زوج مفاتيح الظل موجودا، فإنه يستبدل زوج المفاتيح القديم أيضا.
• بعد ذلك، تتم مقارنة تاريخ انتهاء الشهادة الجديدة بتاريخ انتهاء شهادة المرجع المصدق لتحديد ما إذا كان يجب تهيئة مؤقت التجديد أو تهيئة مؤقت الظل كما هو موضح هنا <أنواع تجديد شهادة العميل - التجديد والظل>

التحقق

ومن المثال الذي قدمه PKI-Client أعلاه، بعد التجديد الأول، عندما يتم التجديد الثاني في 15 مايو/أيار.

May 15 14:15:41.264: Newly-issued Router Cert: issuer=cn=RootCA,ou=TAC,o=Cisco serial=7
May 15 14:15:41.264: start  date: 14:15:10 CET May 15 2017
May 15 14:15:41.264: end    date: 13:14:16 CET Oct 8 2017
May 15 14:15:41.264: Router date: 14:15:41 CET May 15 2017

May 15 14:15:41.265: PKI:Cert valid: 14:15:10 CET May 15 2017-13:14:16 CET Oct 8 2017 shadow 08:38:26 CET Sep 9 2017

لاحظ هنا أن تاريخ انتهاء صلاحية الشهادة الجديدة هو نفس تاريخ انتهاء صلاحية شهادة المرجع المصدق الإصدار، ومن ثم يبدأ IOS في تعيين مؤقت الظل على 08:38:26، SEP 9 2017:

PKI-Client# show crypto pki timer
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 14:18:32.444 CET Mon May 15 2017

PKI Timers
| 14:40.458
 | 14:40.458 SESSION CLEANUP
 |116d18:19:53.821 SHADOW Root-CA

عندما تنتهي صلاحية مؤقت الظل في 9 سبتمبر، أول طلب يتم إرساله هو GetNextCACert، لتنزيل شهادة مرجع مصدق التمرير:

Sep 9 08:38:26.004: PKI: Shadow timer went off for Root-CA

Sep 9 08:38:28.019: PKI: Shadow state for Root-CA now GET_NEW_CA_CERT
Sep 9 08:38:33.027: CRYPTO_PKI_SCEP: Client sending GetNextCACert request
Sep 9 08:38:33.027: CRYPTO_PKI: Sending Next CA Certificate Request:
GET /cgi-bin/pkiclient.exe?operation=GetNextCACert&message=Root-CA HTTP/1.0

Sep 9 08:38:33.035: CRYPTO_PKI: Reply HTTP header:
HTTP/1.1 200 OK
Date: Sat, 09 Sep 2017 07:38:33 GMT
Server: cisco-IOS
Content-Type: application/x-x509-ca-cert

Sep  9 08:38:33.035: PKI: Shadow state for Root-CA now HAVE_NEW_CA_CERT

ملاحظة: بدون GetNextCACert ناجح، لن يستمر عميل PKI في تسجيل الظل.

بمجرد تنزيل شهادة مرجع مصدق المرور، يقوم عميل PKI بتنفيذ GetNextCert، وهو نفس إصدار GetCert، فلا يتم تنشيط الشهادة المستلمة حتى تنتهي صلاحية الشهادة الحالية:

Sep  9 08:38:33.035: PKI: Shadow state for Root-CA now GET_NEW_ROUTER_CERT
Sep  9 08:38:56.466: %CRYPTO-6-AUTOGEN: Generated new 2048 bit key pair
Sep  9 08:38:56.493: CRYPTO_PKI: using private key PKI-Key# for enrollment
Sep  9 08:38:56.493: PKI: Shadow state for Root-CA now GET_NEW_ROUTER_CERT_ACTIVE

Sep  9 08:38:56.513: PKI: Trustpoint Root-CA has router cert and loaded
Sep  9 08:38:56.513: PKI: Signing pkcs7 with Root-CA trustpoint router cert
Sep  9 08:38:56.542: CRYPTO_PKI_SCEP: Client sending GetNewCert (6C0BD832D0C3143BAB604D63D8DF1D72)

هنا، يطبق نفس خوارزمية الخلفية الأسية. عندما يجري منح جواب لاستطلاع الرأي:

Sep  9 08:47:56.728: CRYPTO_PKI_SCEP: Client received CertRep - GRANTED (6C0BD832D0C3143BAB604D63D8DF1D72)
Sep  9 08:47:56.728: CRYPTO_PKI: status = 100: certificate is granted

Sep  9 08:47:56.747: Newly-issued Router Cert: issuer=cn=RootCA,ou=TAC,o=Cisco serial=8
Sep  9 08:47:56.747: start  date: 13:14:16 CET Oct 8 2017
Sep  9 08:47:56.747: end    date: 14:15:10 CET May 15 2018
Sep  9 08:47:56.747: Router date: 08:47:56 CET Sep 9 2017
Sep  9 08:47:56.747: Shadow certificate valid
Sep  9 08:47:56.747: Received shadow router cert from CA

Sep  9 08:47:56.747: PKI: Shadow state for Root-CA now HAVE_NEW_ROUTER_CERT

بمجرد تثبيت شهادة الظل، يشير مؤقت الظل الآن إلى الوقت الذي تنتهي فيه صلاحية شهادة المعرف النشط وشهادة CA، وهو أيضا إشارة إلى الوقت الذي يتم فيه تنشيط شهادة معرف الظل وشهادة CA:

PKI-Client#show crypto pki timers
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 08:49:51.993 CET Sat Sep 9 2017

PKI Timers
|       14:18.013
  |       14:18.013  SESSION CLEANUP
  | 29d 4:24:24.754  SHADOW Root-CA

في هذه المرحلة، تبدو قاعدة بيانات الشهادات كما يلي:

PKI-Client#show crypto pki certificates
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 08:53:28.688 CET Sat Sep 9 2017

Router Certificate (Rollover)
  Status: Available
  Certificate Serial Number (hex): 08
  Certificate Usage: General Purpose
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    Name: PKI-Client.cisco.com
    Serial Number: 104
    serialNumber=104+hostname=PKI-Client.cisco.com
    cn=PKI-Client
    ou=Root
  Validity Date:
    start date: 13:14:16 CET Oct 8 2017
    end   date: 14:15:10 CET May 15 2018
  Associated Trustpoints: Root-CA

CA Certificate (Rollover)
  Status: Available
  Certificate Serial Number (hex): 03
  Certificate Usage: Signature
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    Name: RootCA
    cn=RootCA
    ou=TAC
    o=Cisco
  Validity Date:
    start date: 13:14:16 CET Oct 8 2017
    end   date: 13:14:16 CET Oct 8 2019
  Associated Trustpoints: Root-CA

Certificate
  Status: Available
  Certificate Serial Number (hex): 07
  Certificate Usage: General Purpose
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    Name: PKI-Client.cisco.com
    Serial Number: 104
    serialNumber=104+hostname=PKI-Client.cisco.com
    cn=PKI-Client
    ou=Root
  Validity Date:
    start date: 14:15:10 CET May 15 2017
    end   date: 13:14:16 CET Oct 8 2017
  Associated Trustpoints: Root-CA
  Storage: nvram:RootCA#7.cer

CA Certificate
  Status: Available
  Certificate Serial Number (hex): 01
  Certificate Usage: Signature
  Issuer:
    cn=RootCA
    ou=TAC
    o=Cisco
  Subject:
    cn=RootCA
    ou=TAC
    o=Cisco
  Validity Date:
    start date: 13:14:16 CET Oct 9 2015
    end   date: 13:14:16 CET Oct 8 2017
  Associated Trustpoints: Root-CA
  Storage: nvram:RootCA#1CA.cer

في هذه المرحلة، يتم تنشيط شهادات معرف المرور و CA عندما تصل ساعة النظام إلى تاريخ بدء صلاحية شهادات المرور، والتي يتم تشغيلها عند انتهاء صلاحية مؤقت الظل.

تبعية عملية ظل العميل على إعادة توجيه خادم PKI

لا يمكن متابعة تسجيل الظل في عميل PKI بدون شهادة مرور على المرجع المصدق الإصدار، حيث أن أول شيء يحدث بعد انتهاء صلاحية مؤقت الظل هو طلب SCEP مع عملية GetNextCACert.

عندما يستلم مرجع مصدق طلب GetNextCACert SCEP من عميل، يتحقق المرجع المصدق مما إذا كان لديه شهادة محددة على أنها شهادة مرجع مصدق تمرير كما هو موضح هنا

إذا عثر المرجع المصدق على شهادة Rollover CA، يتم إرسالها في نص إستجابة HTTP مع تعيين نوع محتوى HTTP على التطبيق/x-x509-ca-cert. على الرغم من أن مسودة بروتوكول SCEP تقترح تعيين نوع المحتوى على التطبيق/x-509-next-ca-cert، إلا أن تطبيق IOS يستخدم نوع المحتوى نفسه الذي يستخدمه أثناء إستجابة GetCACert.

إذا فشل المرجع المصدق في العثور على شهادة CA مرور، يتم إرسال رسالة "HTTP 404 Not Found" إلى العميل. يتعامل العميل مع هذا كفشل. في الواقع، يتم التعامل مع أي إستجابة من HTTP بخلاف تلك التي تم تعيين نوع المحتوى فيها بشكل صارم على "application/x-x509-ca-cert" على أنها فشل. يحاول العميل الحصول على شهادة مرجع مصدق المرور كل 20 ثانية على مدى ال 20 يوما التالية، إلا إذا استجاب الخادم مع شهادة مرجع مصدق المرور.

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

تسجيل عميل PKI - آليات إعادة المحاولة

يمكن أن تفشل عمليات تسجيل عميل PKI أو تتأخر بسبب رسائل SCEP المعلقة، حيث من المتوقع أن يقوم العميل بإعادة المحاولة

مؤقت إعادة محاولة الاتصال

عندما يفشل اتصال عميل PKI إلى خادم PKI بسبب فشل مقبس TCP أو انتهاء مهلة طلب HTTP، تقوم PKI بتهيئة مؤقت إعادة محاولة الاتصال على العميل. لا يتم مراعاة رسائل خطأ SCEP أثناء تهيئة هذا المؤقت. تمت تهيئة مؤقت إعادة محاولة الاتصال إلى دقيقة واحدة بشكل افتراضي بعد كل فشل، ويتم تكرار هذا الأمر 999 مرة بشكل افتراضي. يمكن تكوين هذا باستخدام:

   crypto pki trustpoint <TP>
      enrollment retry count <total retry count>
      enrollment retry period <first retry period in minutes>

ينطبق هذا المؤقت على كافة أنواع عمليات التسجيل - الأولية أو التجديد أو تسجيل الظل.

مؤقت الاستقصاء

عندما يتلقى عميل PKI رسالة SCEP معلقة من الخادم كاستجابة لرسالة GetCertInitial الخاصة به (طلب توقيع الشهادة الأولية أو التحقق من الشهادة التالية)، فإنه يقوم بتهيئة مؤقت الاستطلاع. يتم تهيئة مؤقت الاستقصاء الأول إلى دقيقة واحدة بشكل افتراضي. تتبع وحدات توقيت الاستطلاع اللاحقة خوارزمية نسخ إحتياطي أسية:

Assuming that we get SCEP Pending at time "t", 
and the Pending messages are sent after every GetCertInitial message - 
1st POLL Timer = 1 minute [t + 1]
2nd POLL Timer = 2 minutes [t + 1 + 2 = t + 3]
3rd POLL Timer = 4 minutes [t + 7]
4th POLL Timer = 8 minutes [t + 15]
...

هنا، يمكن تكوين الفاصل الزمني الأول للاستطلاع باستخدام:

   crypto pki trustpoint <TP>
      enrollment retry count <total retry count>

لا يتم تمديد مؤقت الاستطلاع بعد انتهاء صلاحية شهادة CA الصادرة. والمنطق هنا هو أن الاقتراع بالنسبة لمخبر قد يكون أصدر بعد انتهاء صلاحية شهادة مرجع مصدق الإصدار لم يعد مفيدا.

تجديد/مؤقت الظل

عند فشل تسجيل عميل PKI بسبب فشل تحليل إستجابة HTTP أو رسائل خطأ SCEP، تتم إعادة تهيئة وحدة توقيت التجديد أو وحدة توقيت الظل وفقا للنسبة المئوية للتسجيل التلقائي ووقت النظام الحالي.

إذا تجاوزت قيمة المؤقت المعاد حسابه وقت انتهاء صلاحية شهادة الهوية الحالية أو انتهت صلاحية شهادة الهوية الحالية، فإن وحدات التوقيت هذه لم تعد مهيأة.

التجديد اليدوي لعميل PKI

 يمكن أن يقوم المسؤول بتجديد الشهادة يدويا على عملاء IOS PKI. يتم اتباع هذا المنطق من خلال تجديد الشهادة اليدوي:

والافتراض هنا هو أن نقطة الثقة المعنية قد سجلت بالفعل مع مرجع مصدق.

إذا تم تكوين التجديد التلقائي (التسجيل التلقائي <النسبة المئوية> [إعادة إنشاء]) ضمن نقطة الثقة:

• إذا كانت وحدة توقيت التجديد قيد التشغيل، وهي إشارة إلى أن شهادة هوية الموجه تنتهي قبل إصدار شهادة CA، فإن تنفيذ هذا الأمر يجري عملية تجديد كما هو موضح هنا <link تجديد نظرة عامة على عملية>

crypto pki enroll <trustpoint-name>

• إذا كانت وحدة توقيت الظل قيد التشغيل، وهي إشارة إلى أن شهادة هوية الموجه تنتهي صلاحيتها في نفس وقت إصدار شهادة CA، فإن تنفيذ هذا الأمر يجري عملية ظل كما هو موضح هنا <نظرة عامة على عملية الارتباط SHADOW>

crypto pki enroll <trustpoint-name>

إذا لم يتم تكوين التجديد التلقائي تحت TrustPoint، كما هو موضح هنا، فسيتم تهيئة مؤقت SHADOW لتنفيذ GetNextCACert على مدى حياة شهادة CA بنسبة 90٪. ومع ذلك، يتبع التجديد اليدوي منطق التجديد وعملية الظل استنادا إلى صحة تجديد شهادة الهوية وصلاحية شهادة المرجع المصدق الصادرة.

ملاحظة: إذا كان مؤقت الاستطلاع قيد التشغيل، لتنفيذ التجديد اليدوي، يجب على المسؤول إلغاء التسجيل الذي يتم استطلاعه من خلال تنفيذ الأمر التالي على مستوى التكوين: لا يوجد تسجيل ل PKI للتشفير <trustPoint>

خادم PKI - منح طلبات تجديد العميل تلقائيا المعتمدة

على خوادم IOS PKI، من الممكن التحكم في التسجيل الأولي باستخدام طريقة المنح اليدوية ومنح طلبات شهادات التجديد تلقائيا من العملاء.

crypto pki server ROOTCA
  database level complete
  database archive pkcs12 password 7 01100F175804575D72
  issuer-name CN=RootCA,OU=TAC,O=Cisco
  grant auto trustpoint ROOTCA
  lifetime certificate 365
  lifetime ca-certificate 730
  database url ftp://10.1.1.1/DB/ROOTCA/
  auto-rollover 90

لاحظ ما يلي:

• عند تمكين خادم IOS CA/PKI، يتم إنشاء TrustPoint تلقائيا بنفس اسم خادم PKI، الذي يحمل شهادة خادم PKI، بالإضافة إلى شهادة خادم Rollover PKI.
  
  
• يذكر الأمر grant autoTrustPoint ROOTCA أنه إذا كانت شهادة العميل المستخدمة لتوقيع طلب توقيع الشهادة موقعة/صادرة عن شهادة خادم PKI المحملة في ROOTCA، بعبارة أخرى إذا كان طلب توقيع الشهادة هو طلب تجديد لشهادة صادرة مسبقا من خادم PKI المسمى ROOTCA، يتم منح الطلب تلقائيا.
  
  
• أثناء طلب توقيع الشهادة الأولية، يستخدم عميل IOS PKI شهادة موقعة ذاتيا لتوقيع الطلب، والتي لا تستوفي معايير المنح التلقائية على النحو المحدد أعلاه، ومن ثم يتم وضع طلبات توقيع الشهادة الأولية في قائمة انتظار معلقة على خادم PKI: إظهار طلبات ROOTCA لخادم PKI crypto
  
  
• يلزم منح هذه الطلبات يدويا باستخدام:

  crypto pki server ROOTCA grant [all | request-id-number]

• يعمل هذا تشكيل أيضا عندما يكون خادم PKI في حالة إعادة توجيه، أي عندما يكون خادم PKI قد قام بإنشاء شهادة خادم PKI تمرير.

تبعيات مؤقت PKI

تلخيص جميع وحدات التوقيت التي يلزم تصميمها بعناية:

• عمر شهادة خادم CA
  هذه هي مدة صلاحية شهادة خادم CA
• عمر شهادة العميل
  هذه هي مدة صلاحية الشهادة التي تم إصدارها لعميل بواسطة خادم PKI معين
• عمر شهادة المرجع المصدق (CA) الثانوي
  CA التابع هو عميل بقدر ما يتعلق الأمر ب ROOT-CA، لذلك تنطبق مدة صلاحية شهادة العميل المعرفة على Root-CA أيضا على CA التابع
• وقت إعادة توجيه CA
  عدد الأيام قبل انتهاء مدة صلاحية شهادة CA.
• وقت تجديد العميل
  هذه هي النسبة المئوية لإجمالي مدة صلاحية شهادة العميل.

خادم PKI:

crypto pki server ROOTCA
  lifetime certificate 365         -----> 2 and 3
  lifetime ca-certificate 730      -----> 1
  auto-rollover 90                 -----> 4

عميل PKI:

crypto pki trustpoint Root-CA
   auto-enroll 80                  -----> 5

يتأكد خادم IOS CA دائما من أن وقت انتهاء صلاحية شهادة العميل يساوي وقت انتهاء صلاحية شهادة خادم CA أو أقل منه.

أثناء تصميم نشر PKI، يكون إعتبار المؤقت هذا مهما:

يجب أن يقوم المرجع المصدق الجذر أو المرجع المصدق الثانوي بإنشاء شهادة مرور قبل أن يبدأ عميل PKI تسجيل ظل

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

• يقوم المرجع المصدق الجذر بإنشاء شهادة مرجع مصدق (CA) إعادة توجيه قبل انتهاء الصلاحية ب 90 يوما
• أطول فترة لصلاحية شهادة العميل هنا هي 365 يوما.
• عند حدوث حالة تسجيل الظل، يقوم العميل بتنفيذ GetNextCACert بنسبة 80٪ من 365 يوما، أي في اليوم 292 أو قبل وقت انتهاء صلاحية الشهادة ب 73 يوما.
وبما أن المرجع المصدق قد أنشأ بالفعل شهادة المرور في هذا الوقت، فإن GetNextCACert ناجح