IOS PKI部署指南：证书滚动 — 配置和操作概述

简介

本文档详细介绍Cisco IOS公钥基础设施(PKI)服务器和客户端上的证书滚动更新。 

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档中的信息基于下列硬件和软件版本：

Hardware

• ISR-G1 [8xx、18xx、28xx、38xx]
• ISR-G2 [19xx、29xx、39xx]
• ISR-4K [43xx、44xx]
• ASR1000
• 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服务器滚动更新证书签名的滚动更新证书的请求，当旧证书过期时，将激活这两个请求。

设置

PKI和简单证书注册协议(SCEP)前提条件

权威时间源

在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>

此命令默认在端口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应在每次证书续订操作期间重新生成RSA密钥对（称为影子密钥对）。

配置自动注册百分比时应小心。在部署中的任何给定PKI客户端上，如果出现身份证书与颁发CA证书同时过期的情况，则自动注册值应始终在CA创建滚动证书后触发[影子]续订操作。请参阅部署示例下的PKI计时器依赖项部分。

PKI续约/滚动更新先决条件

本文档详细介绍证书滚动更新和续约操作，因此认为这些事件已成功完成：

• 使用有效CA证书进行PKI服务器初始化。
• PKI客户端已成功注册到PKI服务器。即，每个PKI客户端都有CA证书和身份证书（也称路由器证书）。

注册客户端涉及这些事件。不用太多细节：

• 信任点身份验证
• 信任点注册

在IOS中，信任点是证书的容器。任何给定信任点都可以包含一个活动身份证书和/或一个活动CA证书。如果信任点包含活动CA证书，则该信任点被视为已通过身份验证。如果它包含身份证书，则视为已注册。注册前必须对信任点进行身份验证。PKI服务器和客户端配置以及信任点身份验证和注册在《IOS PKI部署指南》中有详细介绍：初始设计和部署

在CA证书检索/安装后，PKI客户端在执行注册之前检索PKI服务器功能。CA功能检索将在本节中介绍。

CA功能

在IOS中，当PKI客户端对CA进行身份验证时，即当管理员在IOS路由器上创建信任点并执行命令crypto pki authenticate <trustpoint-name>时，路由器上会发生以下事件：

• IOS发送包含GetCACert操作类型的SCEP请求。
• 在CA部署时，此处的预期响应是内容类型为application/x-x509-ca-cert的HTTP消息，在RA和CA部署时，则为application/x-x509-ca-ra-cert。HTTP正文包含CA证书。[和后一种情况下的RA证书]。
• 在CA/RA证书检索和安装后，客户端启动包含GetCACaps操作的自动SCEP请求。
• 此处的预期响应是包含内容类型application/x-pki-message的HTTP消息，该消息也可以是text/plain，并且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了解CA支持CA证书滚动更新。如果返回此功能，如果auto-enroll命令未在信任点下配置，则IOS将初始化SHADOW计时器，该计时器设置为CA证书有效期的90%。

当SHADOW计时器到期时，IOS执行GetNextCACert SCEP操作以获取滚动CA证书。

注意：如果在信任点下配置了auto-enroll命令以及注册URL，则RENEW计时器甚至在对信任点进行身份验证之前就已初始化，并且它会不断尝试向位于注册URL的CA进行注册，但在信任点进行身份验证之前不会发送实际注册消息[CSR]。

注意：GetNextCACert由IOS PKI服务器作为功能发送，即使未在服务器上配置自动回滚功能

续约

通过此功能，PKI服务器通知PKI客户端它可以使用活动ID证书签署证书签名请求以更新现有证书。

在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 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:
    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生成全反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服务器支持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客户端自动续约

客户端证书续约类型 — 续约和影子

PKI服务器上的IOS始终确保颁发给客户端的ID证书的到期时间不会超过CA证书的到期时间。

在PKI客户端上，在安排续约操作之前，IOS始终考虑以下计时器：

• 身份证书续约的到期时间
• 颁发者(CA)证书的到期时间

如果身份证书的到期时间与CA证书的到期时间不同，IOS将执行简单的续约操作。

如果身份证书的到期时间与CA证书的到期时间相同，IOS将执行影子续约操作。

RENEW — 路由器身份证书续约

如前所述，如果身份证书的到期时间与CA证书的到期时间不同，即在颁发者的证书触发简单身份证书的续订之前到期的身份证书，IOS PKI客户端执行简单的续订操作。

一旦安装了身份证书，IOS就会计算特定信任点的RENEW计时器，如下所示：

Current-Authoritative-Time表示系统时钟必须是此处所述的权威时间源。（链接到权威时间源部分）如果没有权威时间源，PKI计时器将不会初始化。因此，不会进行续约操作。

当RENEW计时器到期时，会发生以下事件：

• 如果配置了regenerate，则IOS会生成卷影密钥对[示例：auto-enroll 80 regenerate]。如果不重新生成IOS，将重新使用当前活动的RSA密钥对。
• IOS创建PKCS-10格式的证书请求，然后将其加密到PKCS-7信封中。此信封还包含RecipientInfo，该信息是颁发CA的主题名称和序列号。此PKCS7信封又打包为PKCS-7签名数据。在初始注册期间，IOS使用自签名证书签署此消息。在后续的注册（即重新注册）中，IOS使用活动身份证书签署消息。PKCS7签名数据还嵌入签名证书，即自签名证书或身份证书。

 有关此数据包结构的详细信息，请参阅SCEP概述文档

注意：此处的密钥信息是RecipientInfo，它是发出CA的主题名称和序列号，此CA的公钥用于加密对称密钥。PKCS7信封中的CSR使用此对称密钥进行加密。

此加密的对称密钥由接收CA使用其私钥解密，此对称密钥用于解密显示CSR的PKCS7信封。

• 然后，以PKCS7格式打包的此证书签名请求(CSR)将以SCEP消息类型PKCSReq和SCEP操作PKIOperation发送到CA。
• 如果CA拒绝请求，IOS将停止RENEW计时器。从此时起，要续订身份证书，管理员必须执行手动续订(链接至PKI客户端手动续订部分)
• 如果CA将SCEP状态发送为挂起，则PKI客户端上的IOS将启动从60秒或1分钟开始的POLL计时器。每次POLL计时器到期时，IOS都会通过PKIOperation操作发送GetCertInitial SCEP消息。当第一个POLL计时器到期时，如果GetCertInitial消息以SCEP Pending状态响应，指数回退算法将第一个POLL计时器重试间隔设置为1分钟，第二个POLL计时器重试间隔设置为2分钟，默认情况下，第三次POLL计时器重试间隔为4分钟，等待接下来的999次重试，或直到颁发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的HTTP消息和包含签名PKCS#7签名数据的正文进行响应。此PKCS7签名数据包含SCEP状态为已授权，以及PKCS7已包装数据。此PKCS封装数据包含已授予的证书和RecipientInfo，后者是初始注册期间自签名证书的使用者名称和序列号，以及重新注册期间活动身份证书的序列号。

PKCS7封装数据还包含使用收件人的公钥加密的对称密钥（新证书已为其授予）。 接收路由器使用私钥解密。然后，此清除对称密钥用于解密PKCS#7包络数据，揭示新的身份证书。

• 在此阶段，IOS会立即用新证书替换现有身份证书。如果配置了重新生成，则阴影密钥对也会替换活动密钥对。

• 此外，将新证书的结束日期与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服务器确保生成全反CA证书，其有效开始时间等于当前CA证书的有效结束时间。

• 如果GetNextCACert SCEP操作未成功，它将重试，直到收到预期响应（如上一步所述）或当前CA（颁发者）证书过期。
• 如果GetNextCACert SCEP操作成功，则全反CA证书将安装到数据库中更新为CA证书(全反)的信任点下。
• 在成功执行GetNextCACert操作后，如果已配置regenerate，IOS将生成卷影密钥对(例如：自动注册80重新生成)。 如果不重新生成IOS，将重新使用当前活动的RSA密钥对。
• IOS创建PKCS-10格式的证书请求，然后将其加密到PKCS-7信封中。此信封还包含RecipientInfo，它是颁发CA的Rollover CA证书的使用者名称和序列号。此PKCS7信封又打包为PKCS-7签名数据。这是使用当前活动身份证书签名的，也嵌入了PKCS7签名的数据。

有关此数据包结构的详细信息，请参阅SCEP概述文档

注意：此处的密钥信息是RecipientInfo，它包含颁发CA的全反CA证书的信息，而不是RENEW操作期间CA的当前活动证书。

此时，使用全反CA的公钥加密对称密钥。这是CA使用全反CA证书签署此请求时使用的信息。

注意：IOS PKI SCEP调试将此操作称为GetNewCert，但在内部这仍是GetCert操作，带有扭转。转换是指向全反CA证书的收件人信息。

• 然后，以PKCS7格式打包的此证书签名请求[CSR]将以SCEP消息类型PKCSReq和SCEP操作PKIOperation发送到CA。
• 从此处开始，该过程与RENEW操作的过程相同，即SCEP状态为“挂起”时的POLL计时器，并且每个POLL计时器到期都会触发GetCertInitial SCEP消息。
• 当证书在PKI服务器上授予时，下一条GetCertInitial SCEP消息将用内容类型application/x-pki-message的HTTP消息和包含签名PKCS7数据的正文进行响应。此PKCS7签名数据包含SCEP状态为Granded、由Rollover CA证书信息（Subject-name和serial-number）签名并嵌入其中的SCEP状态，以及PKCS7封装数据。此PKCS封装数据包含已授予的卷影证书和RecipientInfo，后者是当前活动身份证书的使用者名称和序列号。

注意：PKCS7封装数据还包含使用收件人的公钥[为其授予影子证书]加密的对称密钥。接收路由器使用影子私钥解密它。然后，此清除对称密钥用于解密PKCS#7封装数据，从而揭示影子身份证书。

注意：授予的卷影证书的开始数据与滚动CA证书的开始数据相同。这也与当前活动身份证书和CA证书的最终数据相同。

注意: 嵌入了PKCS7签名数据的全反CA证书信息是通知客户端路由器PKCS7包络数据包含影子证书的内容之一。

• 滚动更新证书作为滚动更新证书安装在信任点下的证书数据库中，不会影响当前活动证书。如果配置regenerate，则阴影密钥对<active-keypair-name#>将保留其临时名称。
• 当前活动证书和CA证书过期时，将CA证书滚动更新和将身份证书滚动更新将替换其对应证书并变为活动状态。如果存在影子密钥对，它也会替换旧密钥对。
• 然后，将新证书的结束日期与CA证书的结束日期进行比较，以确定是必须初始化RENEW计时器还是必须初始化SHADOW计时器（如下所述）<href "Types of Client Certificate Renew - 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的SHADOW计时器，2017年9月9日：

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月9日SHADOW计时器到期时，发出的第一个请求是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客户端将执行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)

在这里，同样的指数退避算法适用。当授予POLL响应时：

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注册无法在颁发CA上没有滚动证书的情况下继续，因为在SHADOW计时器到期后发生的第一件事是具有GetNextCACert操作的SCEP请求。

当CA收到来自客户端的GetNextCACert SCEP请求时，CA会检查其是否具有标记为“滚动CA证书”的证书

如果CA找到滚动CA证书，则会在HTTP响应响应正文中发送该证书，其中HTTP内容类型设置为application/x-x509-ca-cert。虽然SCEP草案建议将content-type设置为application/x-x509-next-ca-cert，但IOS实施使用的内容类型与GetCACert响应期间相同。

如果CA找不到全反CA证书，则会向客户端发送“HTTP 404 Not Found”（HTTP 404未找到）消息。客户端将其视为故障。实际上，除内容类型严格设置为“application/x-x509-ca-cert”的HTTP响应外，任何HTTP响应都被视为故障。除非服务器使用全反CA证书做出响应，否则客户端将在接下来的20天内每20秒重试一次获取全反CA证书。

注意：由于部署了数百个PKI客户端的CA支持GetNextCACert，管理员需要确保PKI客户端在CA上生成滚动证书的情况下从不启动GetNextCACert请求。否则，CA可能完全无法响应所有请求，包括合法请求。请参阅部署示例，了解良好的计时器设计。

PKI客户端注册 — 重试机制

PKI客户端注册可能因SCEP待处理消息而失败或延迟，而SCEP待处理消息是客户端应执行重试的场所

连接重试计时器

当PKI客户端与PKI服务器的通信因TCP套接字故障或HTTP请求超时而失败时，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证书到期后可能颁发的证书的轮询不再有用。

RENEW/SHADOW计时器

当PKI客户端注册因HTTP响应解析失败或SCEP错误消息而失败时，RENEW计时器或SHADOW计时器将根据auto-enroll <percentage>和当前系统时间重新初始化。

如果重新计算的计时器值超出当前身份证书过期时间或当前身份证书过期，则这些计时器不再初始化。

PKI客户端手动续约

 管理员可以在IOS PKI客户端上执行手动证书续订。手动证书续订遵循以下逻辑：

此处，假设相关信任点已注册到CA。

如果在信任点下配置了自动续约(auto-enroll <percentage> [regenerate]):

• 如果RENEW计时器正在运行，表示路由器身份证书在颁发CA证书之前过期，则执行此命令会执行RENEW操作，如下所述<link RENEW操作概述>

crypto pki enroll <trustpoint-name>

• 如果SHADOW计时器正在运行，即表示路由器身份证书在发出CA证书的同时过期，则执行此命令会执行SHADOW操作，如下所述<link SHADOW操作概述>

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服务器证书和全反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服务器颁发给客户端的证书的有效期
• 从属CA证书有效期
  从属CA就根CA而言是客户端，因此在根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部署时，以下计时器注意事项非常重要：

根CA或从属CA应在PKI客户端启动卷影注册之前创建全反证书

以上配置片段中的示例为例：

• Root-CA在到期前90天创建滚动CA证书
• 此处客户端证书有效期最长为365天。
• 当卷影注册条件出现时，客户端在365天（即证书到期时间之前的292天或73天）的80%执行GetNextCACert。
由于CA此时已生成滚动证书，因此GetNextCACert成功