IOS PKI部署指南：證書滾動更新 — 配置和操作概述

下載選項

PDF (1.3 MB)
在多種裝置上使用 Adobe Reader 檢視
ePub (850.2 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
Mobi (Kindle) (785.8 KB)
在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視

已更新: 2021 年 7 月 16 日

文件 ID:211322

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本檔案將詳細介紹Cisco IOS公開金鑰基礎架構(PKI)伺服器和使用者端上的憑證滾動更新。

必要條件

需求

本文件沒有特定需求。

採用元件

本檔案中的資訊是根據以下硬體和軟體版本：

硬體

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

軟體

對於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伺服器的滾動證書簽名的滾動證書，舊證書到期時將啟用這兩個證書。

設定

PKI和簡單證書註冊協定(SCEP)前提條件

授權時間源

在IOS中，由於硬體時鐘不是最佳時間來源，因此預設時鐘來源會視為非授權來源。PKI對時間敏感，因此使用NTP配置有效的時間源非常重要。在PKI部署中，建議讓所有客戶端和伺服器通過多個NTP伺服器（如果需要）將其時鐘同步到單個NTP伺服器。IOS PKI Deployment Guide中會詳細介紹此問題：初始設計和部署

IOS不會在沒有授權時鐘的情況下初始化PKI計時器。雖然強烈建議使用NTP，但作為臨時措施，管理員可以使用以下方法將硬體時鐘標籤為權威的：

Router(config)# clock calendar-valid

HTTP通訊

活動IOS PKI伺服器的要求是HTTP伺服器，可以使用以下config-level命令啟用該伺服器：

ip http server <1024-65535>

預設情況下，此命令在埠80上啟用HTTP伺服器，可以按上述方式更改。

PKI客戶端應該能夠通過HTTP與已配置的埠的PKI伺服器通訊。

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客戶端執行GetNextCACert操作之前，在PKI伺服器上提前很長時間生成翻轉的CA證書，如下面SHADOW操作概述一節所述。

客戶端 — 續訂

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

此處，auto-enroll <percentage> [regenerate]命令說明IOS應在當前證書生存期的80%準確執行證書續訂。

關鍵字regenerate表明，IOS應該在每次證書續訂操作期間重新生成名為shadow key-pair的RSA金鑰對。

設定自動註冊百分比時請務必小心。在部署中的任何特定PKI客戶端上，如果出現身份證書與頒發CA證書同時到期的情況，則自動註冊值應始終在CA建立滾動證書後觸發[shadow]續訂操作。請參閱部署示例下的PKI計時器依賴性部分。

PKI續訂/更新先決條件

本文檔詳細介紹證書滾動更新和更新操作，因此認為這些事件已成功完成：

使用有效的CA證書初始化PKI伺服器。
PKI客戶端已成功註冊到PKI伺服器。即每個PKI客戶端都具有CA證書和身份證書（稱為路由器證書）。

註冊客戶端涉及這些事件。不要過多地細說：

信任點身份驗證
信任點註冊

在IOS中，信任點是證書的容器。任何指定的信任點可以包含一個活動身份證書和/或一個活動CA證書。如果信任點包含活動的CA證書，則此信任點被視為已驗證。如果包含身份證書，則被視為已註冊。註冊前必須驗證信任點。IOS PKI Deployment Guide中詳細介紹了PKI伺服器和客戶端配置以及信任點身份驗證和註冊：初始設計和部署

在CA證書檢索/安裝之後，PKI客戶端在執行註冊之前檢索PKI伺服器功能。本節將介紹CA功能檢索。

CA功能

在IOS中，當PKI客戶端對CA進行身份驗證時(換句話說，當管理員在IOS路由器上建立信任點並執行命令crypto pki authenticate <trustpoint-name>)，以下事件在路由器上發生：

IOS傳送包含GetCACert操作型別的SCEP請求。
此處預期的響應是內容型別為application/x-x509-ca-cert（在CA部署中）的HTTP消息，或application/x-x509-ca-ra-cert（在RA和CA部署中）。HTTP正文包含了CA證書。[後一種情況下為RA證書]。
在CA/RA證書檢索和安裝之後，客戶端啟動包含GetCACaps操作的自動SCEP請求。
此處預期的響應是包含內容型別application/x-pki-message的HTTP消息，該消息也可以是文本/純文字檔案，並且HTTP正文包含一系列由CA支援的功能，並以換行符分隔。典型的IOS PKI伺服器響應如下圖所示。

IOS PKI Client會將此響應解釋為：

CA_CAP_GET_NEXT_CA_CERT
CA_CAP_RENEWAL
CA_CAP_SHA_1
CA_CAP_SHA_256

在這些功能中，本文檔重點介紹這兩種功能。

GetNextCACert

當CA返回此功能時，IOS知道CA支援CA證書滾動更新。若在信任點下未配置auto-enroll命令，IOS將設定為CA證書有效期90%的SHADOW計時器初始化為已返回此功能。

當SHADOW計時器到期時，IOS會執行GetNextCACert SCEP操作以提取滾動更新CA證書。

註：如果在信任點下配置了auto-enroll命令以及enrollment url，則在驗證信任點之前會初始化RENEW計時器，並且它不斷嘗試使用位於enrollment url的CA進行註冊，儘管在驗證信任點之前不會傳送實際註冊消息[CSR]。

附註：GetNextCACert由IOS PKI伺服器作為功能進行傳送，即使伺服器上未配置自動滾動更新

續約

通過此功能，PKI伺服器通知PKI客戶端它可以使用活動ID證書來簽署證書簽名請求以更新現有證書。

在PKI Client Auto-Renewal部分對此進行詳細說明。

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 SHADOW CERT GENERATION計時器到期時：

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&colon;
  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&colon;
  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生成全反CA證書，其中有效開始日期與當前有效CA證書的有效結束日期相同。

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 Server支援CA證書的手動翻轉，即管理員可以提前觸發生成翻轉CA證書，而無需在PKI伺服器配置下配置自動翻轉。強烈建議配置自動回滾，無論使用者是否計畫將初始部署的CA伺服器的生命週期延長到更安全的一端。PKI客戶端無需翻轉CA證書即可使CA過載。請參閱在PKI伺服器滾動更新上依賴客戶端SHADOW操作。

可以使用配置級別命令觸發手動滾動更新：

crypto pki server <Server-name> rollover

此外，還可以取消滾動更新CA證書以手動生成新的證書，但管理員不應在生產環境中執行以下操作：

crypto pki server <Server-name> rollover cancel

這將刪除滾動更新rsa金鑰對和滾動更新CA證書。建議不要這樣做，因為：

一旦CA生成滾動更新證書，多個客戶端可以下載滾動更新CA證書以及由該滾動更新CA證書簽名的滾動更新客戶端證書。
在這個階段，如果取消滾動更新，則可能需要重新註冊客戶端。

PKI使用者端自動續訂

客戶端證書續訂的型別 — RENEW和SHADOW

PKI伺服器上的IOS一律確保核發給使用者端的ID憑證的到期時間不會超過CA憑證的到期時間。

在PKI客戶端上，IOS在安排續訂操作之前始終會考慮以下計時器：

正在續訂標識證書的到期時間
頒發者(CA)證書的到期時間

如果身份證書的到期時間與CA證書的到期時間不同，IOS會執行簡單的續訂操作。

如果身份證書的到期時間與CA證書的到期時間相同，IOS將執行卷影續訂操作。

RENEW — 路由器身份證書續訂

如前所述，如果身份證書的到期時間與CA證書的到期時間不同，IOS PKI客戶端執行簡單的續訂操作，換句話說，在頒發者的證書觸發簡單身份證書的續訂之前到期的身份證書。

一旦安裝身份證書，IOS就會計算特定信任點的RENEW計時器，如下所示：

Current-Authoritative-Time表示系統時鐘必須是此處所述的權威時間源。（連結到授權時間源部分）如果沒有授權時間源，PKI計時器將無法初始化。因此，不會進行續訂操作。

當RENEW計時器到期時，發生以下事件：

如果已設定regenerate，則IOS會產生卷影金鑰對[範例：自動註冊[80 regenerate]。如果沒有regenerate IOS，將重新使用當前活動的RSA金鑰對。
IOS建立一個PKCS-10格式的證書請求，然後將其加密到PKCS-7信封中。此信封還包含RecipientInfo，它是發佈CA的主題名稱和序列號。此PKCS7-envelope又打包為PKCS-7 signed-data。在初始註冊過程中，IOS使用自簽名證書對此消息進行簽名。在後續的註冊（即重新註冊）期間，IOS使用活動身份證書對消息進行簽名。PKCS7簽名資料還嵌入了簽名證書，即自簽名證書或身份證書。

有關此資料包結構的詳細資訊，請參閱SCEP概述文檔

附註：此處的金鑰資訊是RecipientInfo，它是發佈CA的主題名稱和序列號，此CA的公鑰用於加密對稱金鑰。PKCS7信封中的CSR使用此對稱金鑰加密。

此加密的對稱金鑰由接收CA使用其私鑰解密，並且此對稱金鑰用於解密顯示CSR的PKCS7信封。

然後，將打包為PKCS7格式的此證書簽名請求(CSR)傳送給CA，該請求的SCEP消息型別為PKCSReq，並且執行名為PKIOperation的SCEP操作。
如果CA拒絕該請求，IOS將停止續訂計時器。從此以後，要續訂身份證書，管理員必須執行手動續訂(連結到PKI client Manual-Renewal部分)
如果CA將SCEP狀態傳送為pending，則PKI客戶端上的IOS會啟動一個POLL計時器，開始時間為60秒或1分鐘。每次POLL計時器到期時，IOS都會通過PKIOperation操作傳送GetCertInitial SCEP消息。當第一個POLL計時器到期時，如果使用SCEP Pending狀態響應GetCertInitial消息，則指數回退演算法會將第一個POLL計時器重試間隔設定為1分鐘，將第二個POLL計時器重試間隔設定為2分鐘，將第三個POLL計時器重試間隔設定為4分鐘，等等，以預設方式執行下一個999999重試或發出CA證書到期。
可以使用以下命令配置輪詢計數和第一個重試週期：

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

在PKI伺服器上授予證書時，下一個GetCertInitial SCEP消息將用內容型別application/x-pki-message和包含已簽名PKCS#7簽名資料的正文進行響應。此PKCS7簽名資料包含Granted的SCEP狀態以及PKCS7封裝資料。此PKCS封裝資料包含已授予的證書和RecipientInfo，後者是初始註冊期間自簽名證書的主題名稱和序列號，以及重新註冊期間活動身份證書的主題名稱和序列號。

PKCS7封裝資料還包含使用接收者的公鑰（為其授予新證書）加密的對稱金鑰。接收路由器使用私鑰對其進行解密。然後，此清除對稱金鑰用於解密PKCS#7封裝的資料，顯示新的身份證書。

在這個階段，IOS會立即用新證書替換現有的身份證書。如果配置了regenerate，則卷影金鑰對也會替換活動的金鑰對。

此外，新憑證的結束日期會與CA憑證的結束日期進行比較，以確定是否必須初始化RENEW計時器或必須初始化SHADOW計時器，如以下所述<href Types of Client Certificate Renew - RENEW and 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

RENEW計時器到期時：

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

請注意，續訂請求是使用當前有效的ID證書簽名的：

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響應為PENDING，我們將啟動POLL計時器：

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

如前所述，此POLL計時器遵循指數回退演算法，從1分鐘開始，然後是2分鐘，然後是4分鐘等，直到收到的SCEP響應被授予或ID證書過期。

當POLL計時器到期時，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

SHADOW — 路由器標識和頒發CA證書續訂

如果身份證書的到期時間與CA證書的到期時間相同，IOS PKI客戶端執行影子更新操作，換句話說，與頒發者的證書同時到期的身份證書觸發影子更新操作。

一旦安裝了與頒發者證書的結束日期相同的身份證書，IOS就會計算特定信任點的SHADOW計時器。因此，在任意給定時間，SHADOW計時器的值將為：

當給定信任點的SHADOW計時器過期時，會發生以下事件：

IOS執行GetNextCACert SCEP操作，其中預期的響應是內容型別application/x-x509-ca-cert的HTTP消息和包含PKCS7格式化Next CA證書的正文，即頒發者的證書，其有效開始時間等於或早於當前頒發者證書的有效結束時間。

附註：雖然SCEP RFC草案宣告響應內容型別可以是application/x-x509-next-ca-cert，但IOS實現會傳送和接受application/x-x509-ca-cert。

附註：滾動更新CA證書的開始時間可以早於當前活動CA證書的有效性結束時間。但是，只有在當前活動CA證書到期後，才會啟用滾動更新CA證書。但是，Cisco IOS PKI Server確保生成有效期開始時間等於當前CA證書有效結束時間的滾動CA證書。

如果GetNextCACert SCEP操作未成功，它將重試直至收到預期響應（如最後步驟所述）或當前CA（頒發者）證書過期。
如果GetNextCACert SCEP操作成功，則會將滾動更新CA證書安裝在作為CA證書（滾動更新）的信任點下的資料庫中。
在成功執行GetNextCACert操作後，如果已配置regenerate，則IOS會生成一個影子金鑰對(示例：自動註冊80重新生成)。如果沒有regenerate IOS，將重新使用當前活動的RSA金鑰對。
IOS建立一個PKCS-10格式的證書請求，然後將其加密到PKCS-7信封中。此信封還包含RecipientInfo，它是頒發機構的CA的滾動CA證書的使用者名稱和序列號。此PKCS7-envelope又打包為PKCS-7 signed-data。使用當前活動身份證書對此進行簽名，並且嵌入在PKCS7簽名的資料中。

有關此資料包結構的詳細資訊，請參閱SCEP概述文檔

附註：此處的金鑰資訊是RecipientInfo，其中包含頒發CA的滾動CA證書的資訊，與RENEW操作期間的CA的當前活動證書相對。

這一次，對稱金鑰是使用滾動更新CA的公鑰加密的。並且，這是CA使用滾動更新CA證書對此請求進行簽名所使用的資訊。

附註：IOS PKI SCEP調試將此操作命名為GetNewCert，雖然內部此操作仍為GetCert操作，但有所扭曲。扭動是指向滾動更新CA證書的收件人資訊。

然後，打包為PKCS7格式的此證書簽名請求[CSR]將傳送至CA，其SCEP消息型別為PKCSReq，並且執行名為PKIOperation的SCEP操作。
從這裡開始，此過程與RENEW操作的過程相同，即，如果SCEP狀態為Pending，則POLL計時器會觸發GetCertInitial SCEP消息。
當在PKI伺服器上授予證書時，下一個GetCertInitial SCEP消息將使用內容型別application/x-pki-message的HTTP消息和包含已簽名的PKCS7資料的正文進行響應。此PKCS7簽名資料包含的SCEP狀態為Granted，由簽署並嵌入了滾動CA證書資訊（Subject-name和serial-number）以及PKCS7封裝資料。此PKCS封裝資料包含已授予的卷影證書和RecipientInfo，後者是當前活動身份證書的使用者名稱和序列號。

附註：PKCS7封裝資料還包含使用接收者的公鑰[為其授予影子證書]加密的對稱金鑰。接收路由器使用影子私鑰對其進行解密。然後，此清除對稱金鑰用於解密PKCS#7封裝的資料，顯示影子身份證書。

附註：授予的卷影證書的起始資料與滾動更新CA證書的起始資料相同。這也與當前活動身份證書的終端資料以及CA證書的終端資料相同。

注意:嵌入了PKCS7簽名資料的全反CA證書資訊是通知客戶端路由器的PKCS7封裝資料包含卷影證書的資訊之一。

滾動更新證書作為滾動更新證書安裝在信任點下的證書資料庫中，不會影響當前活動的證書。如果配置了regenerate，則會使用臨時名稱保留卷影金鑰對<active-keypair-name#>。
當當前活動證書過期時，CA證書將與CA證書一起過期，滾動更新CA證書和滾動更新身份證書將替換其對應證書並變為活動狀態。如果存在影子金鑰對，它也會替換舊的金鑰對。
之後，將新憑證的結束日期與CA憑證的結束日期進行比較，以確定是否必須初始化續訂計時器，或必須初始化陰影計時器，如下文<href "Types of Client Certificate Renewing - RENEW and SHADOW">所述

驗證

從上面的PKI-Client示例來看，第一次續訂之後，第二次續訂在5月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

請注意，新的證書到期日期與頒發CA證書的到期日期相同，因此IOS會啟動一個設定為08:38:26（2017年9月9日）的SHADOW計時器：

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

當SHADOW計時器在9月9日到期時，第一個發出的請求是GetNextCACert，下載滾動更新CA證書：

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客戶端將不會進行SHADOW註冊。

下載滾動更新CA證書後，PKI-Client會執行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

一旦安裝了影子證書，SHADOW計時器現在指示當前活動ID證書以及CA證書的到期時間，這也表示陰影ID證書和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

在這個階段，當系統時鐘到達這些滾動更新證書的有效開始日期時，會啟用滾動更新ID和CA證書，當SHADOW計時器到期時觸發該有效開始日期。

客戶端SHADOW操作對PKI伺服器翻轉的依賴性

PKI客戶端上的SHADOW註冊無法繼續，因為在SHADOW計時器到期後發生的第一件事是帶有GetNextCACert操作的SCEP請求。

當CA收到來自客戶端的GetNextCACert SCEP請求時，CA將檢查其證書是否標籤為滾動更新CA證書，如下所示

如果CA發現一個全反CA證書，則會在HTTP響應響應正文中傳送該證書，其中HTTP content-type設定為application/x-x509-ca-cert。雖然SCEP草案建議應將content-type設定為application/x-x509-next-ca-cert，但IOS實現使用與GetCACert響應期間相同的內容型別。

如果CA找不到回滾CA證書，則會向客戶端傳送「HTTP 404 Not Found」消息。客戶端將此視為失敗。事實上，除了將content-type嚴格設定為「application/x-x509-ca-cert」的HTTP響應外，任何HTTP響應都被視為失敗。除非伺服器使用轉滾CA證書進行響應，否則客戶端在未來20天內，每20秒會重試獲取轉滾CA證書。

註：數百個PKI客戶端部署了CA支援GetNextCACert，管理員需要確保PKI客戶端在沒有CA上生成滾動證書的情況下永遠不會啟動GetNextCACert請求。否則，CA可能完全無法響應所有請求，包括合法請求。有關良好的計時器設計，請參閱部署示例。

PKI客戶端註冊 — 重試機制

PKI客戶端註冊可能由於SCEP掛起消息而失敗或延遲，客戶端需要在該消息中執行重試

連線重試計時器

當PKI客戶端由於TCP套接字故障或HTTP請求超時而與PKI伺服器通訊失敗時，PKI在客戶端上初始化CONNECT RETRY Timer。初始化此計時器時不考慮SCEP錯誤消息。每次失敗後，CONNECT RETRY計時器預設初始化為1分鐘，預設情況下重複了999次。可通過以下方式配置：

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

此計時器適用於所有型別的註冊 — 初始、續訂或影子註冊。

輪詢計時器

當PKI客戶端從伺服器接收SCEP掛起消息作為對其的GetCertInitial消息（初始證書簽名請求或後續證書輪詢）的響應時，它初始化POLL計時器。預設情況下，第一個POLL計時器初始化為1分鐘。後續的POLL計時器遵循指數回退演算法：

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]
...

在這裡，可以使用以下命令配置第一個POLL計時器間隔：

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

POLL計時器不會超出頒發CA證書到期時間。這裡的邏輯是，對可能在頒發CA證書到期之後頒發的證書進行輪詢不再有用。

續約/陰影計時器

當PKI客戶端註冊由於HTTP響應解析失敗或SCEP錯誤消息而失敗時，將根據auto-enroll <percentage>和當前系統時間重新初始化RENEW計時器或SHADOW計時器。

如果重新計算的計時器值超過當前身份證書到期時間或當前身份證書到期，將不再初始化這些計時器。

PKI客戶端手動更新

管理員可以在IOS PKI客戶端上執行手動證書續訂。手動證書續訂遵循以下邏輯：

這裡假設相關的信任點已向CA註冊。

如果在信任點下配置了自動續訂(auto-enroll <percentage> [regenerate]):

如果正在運行RENEW計時器（表示路由器身份證書在頒發CA證書之前過期），則執行此命令將執行如下所述的RENEW操作<link RENEW Operation Overview>

crypto pki enroll <trustpoint-name>

如果正在運行SHADOW計時器（表示路由器身份證書在頒發CA證書的同時過期），則執行此命令將執行下面所述的SHADOW操作<link SHADOW Operation Overview>

crypto pki enroll <trustpoint-name>

如果尚未在信任點下配置自動續訂(如此所述)，則會初始化SHADOW計時器，以在CA證書的90%生存期執行GetNextCACert。但是，基於要續訂的身份證書的有效性和頒發CA證書的有效性，手動續訂遵循相同的RENEW和SHADOW操作邏輯。

附註：如果POLL計時器正在運行，要執行手動續訂，管理員必須通過執行以下配置級別命令取消進行POLL的註冊：no crypto pki enroll <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伺服器後，將自動建立一個與PKI伺服器同名的信任點，該信任點儲存PKI伺服器證書以及全域性PKI伺服器證書。
命令grant auto trustpoint ROOTCA宣告，如果用於對證書簽名請求進行簽名的客戶端證書是由載入在信任點ROOTCA中的PKI伺服器證書簽署/頒發的，換句話說，如果證書簽名請求是對以前由PKI伺服器頒發的名為ROOTCA的證書的更新請求，則自動授予該請求。

在初始證書簽名請求期間，IOS PKI客戶端使用自簽名證書對請求進行簽名，該證書不符合如上定義的自動授予條件，因此初始證書簽名請求在PKI伺服器上置於掛起隊列中： show crypto pki server ROOTCA requests

需要使用以下工具手動授予這些請求：

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

當PKI伺服器處於滾動更新狀態時（即PKI伺服器已生成滾動更新PKI伺服器證書），此配置也起作用。

PKI計時器依賴性

總結需要精心設計的所有計時器：

CA伺服器證書生存期
這是CA伺服器證書的生存期
客戶端證書生存期
這是由給定PKI伺服器頒發給客戶端的證書的生存期
Subordinate-CA certificate lifetime
Subordinate-CA是根CA所對應的客戶端，因此根CA上定義的客戶端證書生存期也適用於Subordinate-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部署時，以下計時器考慮非常重要：

Root-CA或Subordinate-CA應在PKI客戶端啟動卷影註冊之前建立滾動證書

從上面的配置代碼段開始示例：

Root-CA在到期前90天建立滾動更新CA證書
此處最長客戶端證書有效期為365天。
當出現卷影註冊條件時，客戶端以365天的80%（即在第292天或證書到期時間之前的73天）執行GetNextCACert。

修訂記錄

修訂	發佈日期	意見
1.0	05-Jun-2017	初始版本

由思科工程師貢獻

Praveena Shanubhogue
Cisco TAC Engineer