IOS PKI 導入ガイド：証明書のロールオーバー：構成と動作の概要

ダウンロードオプション

PDF (893.7 KB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (843.0 KB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (817.2 KB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2021 年 7 月 16 日

Document ID:211322

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

概要

本書では、Cisco IOS Public Key Infrastructure（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 と Simple Ceritificate Enrollment Protocol（SCEP）の前提条件

正規の時刻源

ハードウェアクロックは最適な時刻源とはならないため、IOS ではデフォルトのクロックソースは信頼できないと見なされます。PKI は時間が正確であることが求められるため、NTP を使用して有効な時間源を設定することが重要になります。PKI の導入では、すべてのクライアントとサーバで、単一の NTP サーバとクロックを同期させることが推奨されています。しかし、必要な場合は、複数の NTP サーバも使用できます。この詳細については、『IOS PKI 導入ガイド：初期設計と展開』を参照してください。

IOS は、正規のクロックがないと PKI タイマーを初期化しません。NTP を使用することが強く推奨されますが、一時的な手段として、管理者は次のコマンドを使用して、ハードウェアクロックに正規としてマークを付けることができます。

Router(config)# clock calendar-valid

HTTP 通信

アクティブ IOS PKI サーバの要件は、次の config レベルのコマンドを使用して有効にすることができる HTTP サーバです。

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 のパラメータは日単位で定義されます。さらに細かいレベルで定義するには、次のようにコマンドを指定します。

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

auto-rollover の値「90」は、IOS が現在のサーバ証明書の期限が切れる 90 日前に、ロールオーバーサーバ証明書を作成することを意味します。この新しいロールオーバー証明書は、現在のアクティブな証明書の失効と同時に有効になります。

auto-rollover は、ネットワーク内の PKI クライアントが後続の「SHADOW 操作の概要」セクションで説明されているように GetNextCACert 操作を実行するよりも十分前もってロールオーバー CA 証明書を PKI サーバで生成できるような値に設定する必要があります。

クライアント：更新

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 キーペアを再生成する必要があることを示しています。

auto-enroll のパーセンテージを設定する際は、細心の注意を払う必要があります。展開内の特定の PKI クライアントで、発行側 CA 証明書と同時に ID 証明書が期限切れになる状況が発生した場合、CA がロールオーバー証明書を作成した後に、auto-enroll 値によって常に [shadow] 更新操作がトリガーされる必要があります。導入例の下にある「PKI タイマーの依存関係」セクションを参照してください。

PKI の更新/ロールオーバーの前提条件

ここでは、証明書ロールオーバーおよび更新操作について詳しく説明します。そのため、以下のイベントは正常に完了したものと見なします。

有効な CA 証明書を用いた PKI サーバの初期化。
PKI サーバでの PKI クライアントの登録。つまり、各PKIクライアントにはCA証明書とID証明書（ルータ証明書）があります。

クライアントの登録には、以下のイベントが含まれます（詳細については扱いません）。

トラストポイント認証
トラストポイント登録

IOS では、トラストポイントは証明書のコンテナになります。1 つのトラストポイントには、1 つのアクティブな ID 証明書および/または 1 つのアクティブな CA 証明書を含めることができます。アクティブな CA 証明書が含まれている場合、トラストポイントは認証されていると見なされます。また、ID 証明書が含まれていると、登録されていると見なされます。登録前に、トラストポイントを認証する必要があります。トラストポイントの認証および登録とともに行う PKI サーバとクライアントの設定について詳しくは、『IOS PKI 導入ガイド：初期設計と展開』を参照してください。

CA 証明書の取得/インストールに続いて、PKI クライアントは登録を行う前に、PKI サーバ機能を取得します。CA の検索機能については、次のセクションで説明します。

CA 機能

IOS では、PKI クライアントが CA を認証すると、つまり管理者が IOS ルータにトラストポイントを作成してコマンド crypto pki authenticate <trustpoint-name> を実行すると、以下のイベントがルータで発生します。

IOS は GetCACert 操作タイプを含む SCEP 要求を送信します。
ここで期待される応答は、コンテンツタイプが application/x-x509-ca-cert（CA の導入の場合）、または application/x-x509-ca-ra-cert（RA および CA の導入の場合）である HTTP メッセージです。また 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

このドキュメントでは、これらの機能のうち以下の 2 つに焦点を合わせます。

GetNextCACert

この機能が CA によって返されると、IOS は、CA がサポートする CA 証明書ロールオーバーを把握します。この機能が返されるときに、auto-enroll コマンドがトラストポイントで設定されていない場合、IOS は CA 証明書の有効期間の 90 % に設定されている SHADOW タイマーを初期化します。

SHADOW タイマーが期限切れになると、IOS は GetNextCACert SCEP 操作を実行して、ロールオーバー CA 証明書をフェッチします。

注意:auto-enrollコマンドがトラストポイントの下にenrollment urlと共に設定されている場合は、トラストポイントの認証前にRENEWタイマーが初期化され、トラストポイントが認証されるまで実際の登録メッセージ[CSR]は送信されません。

注：サーバで auto-rollover が設定されていない場合、GetNextCACert は IOS PKI サーバによって、機能として送信されます。

更新

この機能により、PKI サーバは、既存の証明書を更新するために、アクティブな ID 証明書を使用して証明書署名要求に署名できることを 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 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

有効期間の開始日が現在のアクティブな CA 証明書の有効期間の終了日と同じである場合、次に IOS はロールオーバー 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 証明書の手動ロールオーバーをサポートします。つまり、管理者は、事前に PKI サーバ設定で自動ロールオーバーを設定せずに、ロールオーバー CA 証明書の生成をトリガーできます。最初に導入した 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 は更新操作をスケジュールする前に、必ず次のタイマーを考慮に入れます。

更新される ID 証明書の有効期限
発行者の（CA）証明書の有効期限

ID 証明書の有効期限が CA 証明書の有効期限と同じでない場合、IOS は簡単な更新操作を行います。

ID 証明書の有効期限が CA 証明書の有効期限と同じ場合、IOS はシャドウ更新操作を行います。

RENEW – ルータID証明書の更新

前述のとおり、ID 証明書の有効期限が CA 証明書の有効期限と同じでない場合、IOS PKI クライアントは簡単な更新操作を実行します。つまり発行者の証明書の前に失効する ID 証明書は、ID 証明書の簡単な更新をトリガーします。

ID 証明書がインストールされるとすぐに、IOS は以下に示すように特定のトラストポイントの RENEW タイマーを計算します。

現在の正規の時刻（Current-Authoritative-Time）は、ここで示されているように、システムクロックが正規の時刻源となる必要があることを意味します（「正規の時刻源」セクションを参照）。PKI タイマーは正規の時刻源なしには初期化されません。そのため、更新操作は行われません。

次のイベントは、RENEW タイマーが期限切れになると発生します。

IOS は、regenerate が設定されている場合に、シャドウキーペアを生成します（例：auto-enroll 80 regenerate）。regenerate が設定されない場合、IOS は現在アクティブな RSA キーペアを再利用します。
IOS は PKCS-7 エンベロープに暗号化される PKCS-10 形式の証明書要求を作成します。このエンベロープには、RecipientInfo（発行側 CA のサブジェクト名とシリアル番号）が含まれます。この PKCS7 エンベロープは、PKCS-7 署名済みデータに格納されます。最初の登録時に、IOS は、自己署名証明書を使用して、このメッセージに署名します。後続の登録（つまり再登録）中、IOS はアクティブな ID 証明書を使用してメッセージに署名します。PKCS7 署名済みデータは、署名する証明書（つまり、自己署名証明書または ID 証明書のいずれか）に組み込まれます。

このパケット構造の詳細については、SCEP の概要ドキュメントを参照してください。

注：ここでの重要な情報は、RecipientInfo（発行側 CA のサブジェクト名とシリアル番号）です。また、この CA の公開キーは対称キーの暗号化に使用されます。PKCS7 エンベロープの CSR は、この対称キーを使用して暗号化されます。

この暗号化された対称キーは、受信側 CA によって、秘密キーを使用して復号されます。この対称キーは CSR を公開する PKCS7 エンベロープを復号するために使用されます。

PKCS7 形式でパッケージされたこの証明書署名要求（CSR）は、SCEP メッセージタイプの PKCSReq および PKIOperation と呼ばれる SCEP 操作と一緒に CA に送信されます。
CA が要求を拒否すると、IOS は RENEW タイマーを停止します。この時点で、ID 証明書を更新するために、管理者は手動更新を実行する必要があります（「PKI クライアントの手動更新」セクションを参照）。
CA が SCEP ステータスを pending として送信する場合、PKI クライアントの IOS は POLL タイマーを 60 秒または 1 分から開始します。POLLタイマーが期限切れになるたびに、IOSはPKIOperation操作でGetCertInitial SCEPメッセージを送信します。最初のPOLLタイマーが期限切れになると、SCEP PendingステータスでGetCertInitialメッセージに応答すると、指数バックオフアルゴリズムは1分、再試行間隔2ですminutes、3番目の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 署名データには、Granted の SCEP ステータスと PKCS7 エンベロープデータが含まれます。この PKCS エンベロープデータには、許可された証明書と RecipientInfo が含まれます。この情報は、初回登録時の自己署名証明書と再登録時のアクティブな ID 証明書のサブジェクト名とシリアル番号です。

PKCS7 エンベロープデータには、受信者の公開キー（新しい証明書が許可されたキー）で暗号化された対称キーが含まれています。受信側のルータは、秘密キーを使って復号化します。この暗号化されていない対称キーが、新しい ID 証明書を公開する PKCS#7 エンベロープデータを復号するために使用されます。

この段階で、IOS はすぐに既存の ID 証明書を新しい証明書と交換します。regenerate が設定されている場合、シャドウキーペアもアクティブなキーペアと交換されます。

また、<href クライアント証明書更新のタイプ：RENEW と SHADOW> で説明されているように、RENEW タイマーまたは SHADOW タイマーのいずれを初期化する必要があるかを判断するために、新しい証明書の終了日が CA 証明書の終了日と比較されます。

検証

新たに登録された PKI クライアントでは、登録されたトラストポイントの下に ID 証明書（ルータ証明書またはエンドエンティティ証明書とも呼ばれます）と発行側 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 応答が GRANTED になるまで、または ID 証明書が期限切れになるまで増え続ける指数関数的なバックオフアルゴリズムに従います。

POLL タイマーが期限切れになると、SCEP 応答は GRANTED になります。

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：ルータIDと発行CA証明書の更新

ID 証明書の有効期限が CA 証明書の有効期限と同じ場合、IOS PKI クライアントはシャドウ更新操作を実行します。つまり発行者の証明書と同時に失効する ID 証明書は、シャドウ更新操作をトリガーします。

発行者の証明書と同じ終了日の ID 証明書がインストールされるとすぐに、IOS は特定のトラストポイントの SHADOW タイマーを計算します。そのため、SHADOW タイマー値は常に次のようになります。

特定のトラストポイントの SHADOW タイマーが期限切れになると、次のイベントが発生します。

IOS は GetNextCACert SCEP 操作を実行します。この場合、期待される応答は、コンテンツタイプ application/x-x509-ca-cert の HTTP メッセージと PKCS7 形式の次の 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 操作が成功した後、IOS は regenerate が設定されている場合に、シャドウキーペアを生成します（例：auto-enroll 80 regenerate）。 regenerate が設定されない場合、IOS は現在アクティブな RSA キーペアを再利用します。
IOS は PKCS-7 エンベロープに暗号化される PKCS-10 形式の証明書要求を作成します。このエンベロープには、RecipientInfo（発行側 CA のロールオーバー CA 証明書のサブジェクト名とシリアル番号）が含まれます。この PKCS7 エンベロープは、PKCS-7 署名済みデータに格納されます。これは、現在のアクティブな ID 証明書を使用して署名され、PKCS7 署名済みデータと一緒に組み込まれます。

このパケット構造の詳細については、SCEP の概要ドキュメントを参照してください。

注：ここでの重要な情報は、現在のアクティブな CA 証明書とは異なり、RENEW 操作中と同様、RecipientInfo（発行側 CA のロールオーバー CA 証明書の情報）になります。

この場合、対称キーはロールオーバー CA の公開キーを使用して暗号化されます。これは、ロールオーバー CA 証明書を使用してこの要求に署名するために、CA によって使用される情報です。

注：内部的には GetCert 操作のままですが、IOS PKI SCEP デバッグではこの操作に GetNewCert という名前が付けられていて、相違があります。また、この相違はロールオーバー CA 証明書を指す受信者の情報にも見られます。

PKCS7 形式でパッケージされたこの証明書署名要求（CSR）は、SCEP メッセージタイプの PKCSReq および PKIOperation と呼ばれる SCEP 操作と一緒に CA に送信されます。
これ以降、プロセスは RENEW 操作のプロセスと同じになります（つまり、SCEP ステータスが Pending の場合は POLL タイマー）。すべての POLL タイマーが期限切れになると、GetCertInitial SCEP メッセージをトリガーします。
証明書が PKI サーバで許可されると、次の GetCertInitial SCEP メッセージに、コンテンツタイプ application/x-pki-message の HTTP メッセージと署名された PKCS データを含む本文で応答します。この PKCS7 署名済みデータの SCEP ステータスは Granted で、ロールオーバー CA 証明書の情報（サブジェクト名およびシリアル番号）と PKCS7 エンベロープデータで署名され、組み込まれています。この PKCS エンベロープデータには、許可されたシャドウ証明書と RecipientInfo（現在のアクティブな ID 証明書のサブジェクト名とシリアル番号）が含まれています。

注：PKCS7 エンベロープデータには、受信者の公開キー（シャドウ証明書が許可されたキー）で暗号化された対称キーが含まれています。受信側のルータは、シャドウ秘密キーを使って復号化します。この暗号化されていない対称キーが、シャドウ ID 証明書を公開する PKCS#7 エンベロープデータを復号するために使用されます。

注：許可されたシャドウ証明書の開始データはロールオーバー CA 証明書の開始データと同じです。これは、現在のアクティブな ID 証明書の終了データおよび CA 証明書の終了データと同じです。

注: PKCS7署名データに埋め込まれたロールオーバーCA証明書情報は、PKCS7エンベロープデータにシャドウ証明書が含まれていることをクライアントルータに通知する情報の1つです。

ロールオーバー証明書は、現在のアクティブな証明書に影響を与えずに、トラストポイントの証明書データベースにロールオーバー証明書としてインストールされます。regenerate が設定されている場合、シャドウキーペアの <active-keypair-name#> は一時的な名前として保持されます。
現在のアクティブな証明書が CA 証明書と一緒に期限切れになる場合、ロールオーバー CA 証明書とロールオーバー ID 証明書の両方がそれぞれの対応する証明書と置き換えられ、それらがアクティブになります。またシャドウキーペアがあれば、その古いキーペアも置き換えられます。
その後、<href “クライアント証明書更新のタイプ：RENEW と SHADOW> で説明されているように、RENEW タイマーまたは SHADOW タイマーのいずれを初期化する必要があるかを判断するために、新しい証明書の終了日が CA 証明書の終了日と比較されます。

検証

上記の PKI クライアントの例では、最初の更新後、2 番目の更新は 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 は 2017 年 9 月 9 日 8 時 38 分 26 秒に設定された 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 日で期限切れになると、最初に送信される要求は、ロールオーバー CA 証明書をダウンロードするための 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 クライアントは 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 応答が GRANTED である場合：

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 タイマーが期限切れになるとトリガーされます。

PKI サーバのロールオーバーにおけるクライアント SHADOW 操作の依存関係

PKI クライアントの SHADOW 登録は、発行側 CA のロールオーバー証明書なしで続行することはできません。SHADOW タイマーが期限切れになった後に最初に行われるのは、GetNextCACert 操作を含む SCEP 要求です。

CA が GetNextCACert SCEP 要求をクライアントから受け取ると、CA はロールオーバー CA 証明書としてマークされた証明書があるか確認します（ここを参照）。

CA がロールオーバー CA 証明書を検出すると、HTTP コンテンツタイプが application/x-x509-ca-cert に設定された HTTP 応答の本文に含めて送信されます。SCEP ドラフトには、コンテンツタイプは application/x-x509-next-ca-cert に設定する必要があると記載されていますが、IOS の実装では、GetCACert 応答時のものと同じコンテンツタイプが使用されます。

CA がロールオーバー CA 証明書を検出できなかった場合、「HTTP 404 Not Found」メッセージがクライアントに送信されます。クライアントはこれをエラーとして処理します。実際、「application/x-x509-ca-cert」に厳密に設定されたコンテンツタイプ以外の HTTP 応答はエラーとして扱われます。クライアントは、サーバがロールオーバー CA 証明書について応答するまで、次の 20 日間 20 秒ごとにロールオーバー CA 証明書の取得を再試行します。

注:GetNextCACertをサポートするCAとともに導入された数百のPKIクライアントでは、PKIクライアントがCAで生成されたロールオーバー証明書なしでGetNextCACert要求を開始しないようにする必要があります。そうしないと、CA が正当な要求も含め、すべての要求への応答に失敗する可能性があります。適切なタイマーの設計については、導入例を参照してください。

PKI クライアントの登録：再試行メカニズム

PKI クライアントの登録は、クライアントが再試行を実行することが期待される状況で、SCEP Pending メッセージのために、失敗するか、遅延する可能性があります。

CONNECT RETRY タイマー

PKI クライアントから PKI サーバへの通信が TCP ソケットの障害または HTTP 要求のタイムアウトにより失敗した場合、PKI はクライアントの CONNECT RETRY タイマーを初期化します。このタイマーを初期化している間は、SCEP エラーメッセージは考慮されません。CONNECT RETRY タイマーは、障害が発生するたびに、デフォルトでは 1 分後に初期設定されます。また、デフォルトでは 999 回まで繰り返されます。これは、次のコマンドを使用して構成することができます。

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

このタイマーは、すべてのタイプの登録（初回、更新、またはシャドウ登録）に適用されます。

POLL タイマー

PKI クライアントがサーバから GetCertInitial メッセージ（最初の証明書署名要求またはそれ以降の証明書のポーリング）への応答として SCEP Pending メッセージを受信すると、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> および現在のシステム時間に応じて再初期化されます。

再計算されたタイマー値が現在の ID 証明書の有効期限を超えている場合、または現在の ID 証明書が期限切れになる場合、これらのタイマーは初期化されません。

PKI クライアントの手動更新

管理者は、IOS PKI クライアントで証明書の手動更新を実行できます。証明書の手動更新は、以下のロジックに従います。

ここでは、対象のトラストポイントが CA にすでに登録されていることを前提としています。

自動更新（auto-enroll <percentage> [regenerate]）がトラストポイントの下に設定されている場合：

RENEW タイマーが実行されている場合（これは、ルータ ID 証明書が発行側 CA 証明書の前に期限切れになることを示しています）、<link RENEW 操作の概要> で説明されているとおり、このコマンドを実行すると RENEW 操作が実行されます。

crypto pki enroll <trustpoint-name>

SHADOW タイマーが実行されている場合（これは、ルータ ID 証明書が発行側 CA 証明書と同時に期限切れになることを示しています）、<link SHADOW 操作の概要> で説明されているとおり、このコマンドを実行すると SHADOW 操作が実行されます。

crypto pki enroll <trustpoint-name>

自動更新がトラストポイントの下に設定されていない場合、ここで説明されているとおり、SHADOW タイマーは CA 証明書の 90 % の有効期間で GetNextCACert を実行するように初期化されます。ただし、手動更新は、更新された ID 証明書の有効期間と発行側 CA 証明書の有効期間に基づき、RENEW および SHADOW 操作の同じロジックに従います。

注：POLL タイマーが実行されている場合、手動更新を実行するには、管理者は次の config レベルのコマンドを実行して、ポーリングされている登録をキャンセルする必要があります。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 サーバ証明書によって署名/発行される場合（つまり、証明書署名要求が、ROOTCA という名前の PKI サーバによって以前に発行された証明書の更新要求である場合）、要求は自動的に許可されることを示します。

最初の証明書署名要求時に、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 クライアントがシャドウ登録を開始する前に、ロールオーバー証明書を作成する必要があります。

上記の設定スニペットから例を示します。

ルート CA が有効期日より 90 日前にロールオーバー CA 証明書を作成します。
クライアント証明書の最も長い有効期間は、365 日です。
シャドウ登録条件が発生すると、クライアントは 365 日の 80 %（つまり 292 日目または証明書の有効期限の 73 日前）で GetNextCACert を実行します。

Revision History

Revision	Publish Date	Comments
1.0	05-Jun-2017	Initial Release

シスコエンジニア提供

Praveena Shanubhogue
Cisco TAC Engineer