概要

この資料は認証 ロールオーバー IOS 公開鍵インフラストラクチャ （PKI）サーバおよびクライアントを詳しく on Cisco 記述したものです。 

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、次のハードウェアとソフトウェアのバージョンに基づくものです。

ハードウェア

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

ソフトウェア

• IOS
• ISR-G1 に関しては–最新の 15.1(4)M*
• ISR-G2 に関しては–最も遅く 15.4(3)M

• IOS XE
• XE 3.15 か 15.5(2)S

注: ISR デバイスのための一般のソフトウェアメンテナンスはもはやアクティブではないです、未来のバグ フィックスか機能強化は ISR-2 または ISR-4xxx シリーズ ルータにハードウェア アップグレードを必要とします。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

背景説明

認証 ロールオーバー別名更新 オペレーションは認証が切れるとき、新しい認証は引き継いで準備ができていることを確認します。 PKI サーバの観点から、このオペレーションは現在の認証が切れる前に先立って PKI クライアント全員が新しいサーバ ロールオーバー 認証によって署名する新しいクライアント ロールオーバー 認証を受け取ったことを確かめるために新しいサーバ ロールオーバー 認証をよく生成することを含みます。 PKI クライアントの観点から、クライアント 認証が切れればが、認証局 （CA）サーバ証明がなければ、新しい認証のための Client 要求は新しい認証が、クライアント 認証が CA サーバ証明と同時に切れれば、クライアントは CA サーバのロールオーバー 認証を最初に受け取ることを確かめ古い認証が切れる場合それから新しい CA サーバ ロールオーバー 認証によって署名するロールオーバー 認証のために要求し受け取られる両方ともアクティブになりますとすぐ古い認証を取り替え。

Setup

PKI および簡単な Ceritificate 登録プロトコル（SCEP）前提条件

信頼できる時刻ソース

IOS では、デフォルトでクロック ソースはハードウェア クロックが時間の最もよいもとではないので非権限であると考慮されます。 時間に敏感である PKI NTP を使用して時間の有効 な 送信元を設定することは重要です。 PKI 配備では、クライアント全員およびサーバを複数の NTP サーバを通して単一 NTP サーバにクロックを、必要であれば同期化してもらうことを推奨します。 これの多くは IOS PKI 配置ガイドで説明されます: 最初 の 設計および配備

IOS は保証された クロックなしでは PKI タイマーを初期化しません。 NTP が保証された使用ように、一時的な手段として、強く推奨されている管理者 ハードウェア クロックをマークできるが:

Router(config)# clock calendar-valid

HTTP 通信

アクティブ IOS PKI サーバのための要件はこの構成レベル コマンドを使用して有効に することができる 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 <days> <hours> <minutes>

90 という自動ロールオーバー値は IOS が 90 日現在のサーバ証明の終止の前にロールオーバー サーバ証明を作成する、この新しいロールオーバー 認証の有効性は現在のアクティブな認証の終止時と同時に開始しますことを示し。

自動ロールオーバーは確かめるそのような値でネットワークのどの PKI クライアントでも下記のシャドウ オペレーション 概観のセクションに記述されているように 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

IOS が現在の認証のライフタイムの丁度 80% で認証 更新を行う必要があることここでは、<percentage> [再生]コマンド待ち状態を自動登録して下さい。

キーワード再生は IOS が各認証 更新 オペレーションの間にシャドウ キー ペアとして知られている RSA キー ペアを再生する必要があることを示します。

注意は設定している間パーセントを自動登録しなさい奪取 する必要があります。 ID証明が発行 CA 認証と同時にどこに切れるか配備のある特定の PKI クライアントで条件が起これば、CA がロールオーバー 認証を作成した後そして自動登録値は[シャドウ]更新 オペレーションを常に引き起こす必要があります。 配備例の下で PKI タイマー 依存関係 セクションを参照して下さい。

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

この資料によっては認証 ロールオーバーおよび更新 オペレーションが詳しく当たり、それ故にこれらのイベントは正常に完了すると考慮されます:

• 有効な CA 認証の PKI サーバ 初期化。
• PKI クライアントは PKI サーバと正常に登録されました。 すなわち。 各 PKI クライアントは CA 認証および ID証明別名ルータ認証を持っています。

クライアントを登録することはこれらのイベントを含みます。 詳細にあまりを得ることなし:

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

IOS では、トラストポイントは認証のためのコンテナーです。 ある特定のトラストポイントは 1 つのアクティブな ID証明や 1 アクティブ CA 認証が含まれている場合があります。 トラストポイントはアクティブ CA ceryificate が含まれている場合認証されたと考えられます。 そしてそれは ID証明が含まれている場合登録されたと考えられます。 トラストポイントは登録の前に認証する必要があります。 トラストポイント 認証および登録と共に PKI サーバおよびクライアントコンフィギュレーションは、IOS PKI 配置ガイドで詳しくカバーされます: 最初 の 設計および配備

CA 認証検索/インストールの後で、PKI クライアントは登録を行う前に PKI サーバ機能を取得します。 CA 機能検索はこのセクションで説明されます。

CA 機能

IOS では、すなわち、PKI クライアントが CA を認証する時、管理者が IOSルータのトラストポイントを作成する時、およびコマンド 暗号 PKI 認証する <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 要求を始めます。
• ここの予想される 応答はまたテキスト/明白の可能性があり、HTTP 本文が CA によってサポートされる一連の機能が含まれているライン フィード文字で分かれる application/x PKI メッセージのコンテンツ の タイプが付いている HTTP メッセージ、です。 典型的な 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 は CA証明の有効期間の 90% に設定 される シャドウ タイマーを初期化します。

シャドウ タイマーが切れるとき、IOS はロールオーバー CA 認証を取出すために GetNextCACert SCEP オペレーションを行います。

注: 実際の登録メッセージ[CSR]送信 されないが auto-enroll コマンドが登録 URL と共にトラストポイントの下で設定される場合、更新タイマーはトラストポイントの認証の前でさえも初期化され、トラストポイントが認証されるまで絶えず登録 URL にある CA と登録することを試みます。

注: GetNextCACert は IOS PKI サーバによって機能として自動ロールオーバーがサービスで設定されなくても送信 されます

Renewal

この機能と、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 シャドウ CERT 世代別タイマーが切れる時:

• IOS はアクティブなキー ペアと最初のロールオーバー キー ペアを現在それ持っています同じ名前をとのそれに追加 される a #ハッシュ生成します。
  
  

  
  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 認証の手動ロールオーバーをサポートします、すなわち管理者は PKI サーバコンフィギュレーションの下で自動ロールオーバーを設定する必要がないでロールオーバー CA 認証の生成を先立って引き起こすことができます。 それは 1 つがより安全な側であるために最初に展開された CA サーバのライフタイムを拡張することを計画するかどうか強く推奨されています自動ロールオーバーを設定するために。 PKICLIENTS はロールオーバー CA 認証なしで CA を過剰にすることができます。 PKI サーバ ロールオーバーの Dependencyof クライアント シャドウ オペレーションを参照して下さい。

手動ロールオーバーは設定水平なコマンドを使用して引き起こすことができます:

crypto pki server <Server-name> rollover

新しい 1 つを手動で生成するためにそして何かが実稼働環境で admin するべきではないどんなにまた、ロールオーバー CA 認証は使用取り消すことができます:

crypto pki server <Server-name> rollover cancel

これはロールオーバー RSA キー ペアおよびロールオーバー CA 認証を削除します。 これは次の理由でに対して助言されます:

• CA がロールオーバー 認証を生成すれば、複数のクライアントはロールオーバー CA 認証によって署名するロールオーバー CA 認証、またロールオーバー クライアント 認証をダウンロードするかもしれません。
• この段階ではロールオーバーが取り消されれば、クライアントは再登録されなければならないかもしれません。

PKI クライアント自動更新

クライアント 認証 更新の型-更新し、シャドウイングして下さい

PKI サーバの IOS はクライアントに発行される CA 認証の終止時を越えて ID 認証の終止時が決して行かないことを常に確かめます。

PKI クライアントで、IOS は考慮事項に更新 オペレーションをスケジュールする前に次のタイマーを常に運びます:

• 更新される ID証明の終止時間
• 発行者（CA）の認証の終止時間

ID証明の終止時が CA 認証の終止時と同じではない場合、IOS は簡単な更新 オペレーションを行います。

ID証明の終止時が CA 認証の終止時と同じである場合、IOS はシャドウ 更新 オペレーションを行います。

更新して下さい- ルータ ID証明 更新

前述のように、IOS PKI クライアントは発行者の認証が ID証明の簡単な更新を引き起こす前に ID証明の終止時が CA 認証の終止時と同じでなければ簡単な更新 オペレーションを、要するに切れる ID証明行います。

ID証明がインストールされているとすぐ、IOS は下記に示されているように特定の信頼点のための更新タイマーを計算します:

現在の保証された時間はシステム クロックがここに記述されているように時間の保証されたもとでなければならないことを意味します。 （信頼できる時刻ソース セクションへのリンク） PKI タイマーは時間の保証されたもとなしでは初期化されません。 そして結果として、更新 オペレーションは起こりません。

次のイベントはタイマーを切れる更新しなさい時起こります:

• IOS は再生が設定される場合シャドウ キー ペアを生成します[例: 80 再生を自動登録して下さい]。 再生 IOS なしで現在アクティブ な RSA キー ペアを再使用します。
• IOS は PKCS-7 エンベロープに暗号化される PKCS-10 によってフォーマットされている証明書要求を作成します。 このエンベロープはまた発行 CA の subject-name およびシリアル番号である RecipientInfo が含まれています。 この PKCS7-envelope は PKCS-7 署名されたデータに次々と詰まります。 最初の登録の間に、IOS は自己署名証明書をこのメッセージに署名するのに使用します。 そしてそれに続く登録の間に、すなわち再登録は、IOS アクティブな ID証明をメッセージに署名するのに使用します。 PKCS7 署名されたデータはまた署名証明書と、すなわち自己署名証明書か ID証明組み込まれます。

 このパケット構造に関する詳細については SCEP 概要 ドキュメントを参照して下さい

注: ここの鍵情報は発行 CA の subject-name およびシリアル番号の、この CA の公開キーが対称鍵を暗号化するのに使用されています RecipientInfo であり。 PKCS7 エンベロープの CSR はこの対称鍵を使用して暗号化されます。

この暗号化された対称鍵はプライベートキーを使用して受信 CA によって復号化され、CSR を明らかにする PKCS7 エンベロープを復号化するのにこの対称鍵が使用されています。

• PKCS7 形式で実装されるこの証明書署名要求（CSR）は PKCSReq の SCEP メッセージタイプおよび PKIOperation と呼ばれる SCEP オペレーションを用いる CA にそれから送信 されます。
• CA が要求を拒否する場合、IOS は更新タイマーを停止します。 ここから先は、ID証明を更新するために、管理者は手動更新（PKI クライアント手動更新 セクションへのリンク）を行う必要があります
• CA が保留中ように SCEP ステータスを送信 する場合、PKI クライアントの IOS は POLL タイマーを 60 秒か 1 分に開始させ始めます。 POLL タイマーが切れる度に、IOS は PKIOperation オペレーションによって GetCertInitial SCEP メッセージを送信 します。とき最初の POLL タイマーが切れる、GetCertInitial メッセージが SCEP 保留中のステータスでに応答されれば、指数バックオフアルゴリズムは次の 999 の再試行のための 4 分に 2 分に 1 分に発行 CA 認証が切れるまで最初の POLL タイマー リトライ間隔を、秒 POLL タイマー リトライ間隔、第 3 POLL タイマー リトライ間隔デフォルトでまたは等設定 します。
  ポーリング数および最初再試行期間はを使用して設定することができます:

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

• 認証が PKI サーバで許可されるとき、GetCertInitial 次の SCEP メッセージはコンテンツ の タイプ application/x PKI メッセージの HTTP メッセージとおよび署名された PKCS#7 署名されたデータが含まれている本文に応答されます。 この PKCS7 署名されたデータは許可されるように SCEP ステータスが含まれ、また PKCS7 はデータを囲みました。 この PKCS によって囲まれるデータは許可された認証および最初の登録の間に自己署名証明書と再登録の間にアクティブな ID証明の subject-name およびシリアル番号である RecipientInfo が含まれています。

PKCS7 によって囲まれるデータはまた新しい認証が許可されたかどれをのために）受信者の公開キーを使って暗号化される対称鍵が含まれています（。 ルータを受け取ることはプライベートキーを使用してそれを復号化します。 このクリア対称鍵がそれから新しい ID証明を明らかにする PKCS#7 によって囲まれるデータを復号化するのに使用されています。

• この段階では、IOS は新しい認証と既存の ID証明をすぐに取り替えます。 そして再生が設定されたら、シャドウ キー ペアはアクティブなキー ペアを同様に取り替えます。

• また、新しい認証の終了日は CA 認証の終了日とタイマーを初期化されなければならない更新したまたはシャドウ タイマーがクライアント 認証 更新のここに説明された <href 型として-初期化されなければならなければかどうか確認するために比較されます SHADOW> 更新すれば

確認

最近登録された 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

更新タイマーが切れる時:

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 応答が保留中である場合、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 タイマーは受け取った SCEP 応答が許可されるか、または ID 認証が切れるまで 1 分、そして 2 分、そして 4 分に開始する指数バックオフアルゴリズムに従って等続きます。

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

シャドウ- ルータ識別および CA 認証 更新を発行すること

IOS PKI クライアントは発行者の認証がシャドウ 更新 オペレーションを引き起こすと同時に ID証明の終止時が CA 認証の終止時と同じならシャドウ 更新 オペレーションを、要するに切れる ID証明行います。

発行者の認証と同じ終了日を過す ID証明がインストールされているとすぐ、IOS は特定のトラストポイントのためのシャドウ タイマーを計算します。 このように、いつでも、シャドウ タイマーの値は次のとおりです:

次のイベントはある特定のトラストポイントのためのシャドウ タイマーが切れると起こります:

• IOS は予期される応答はコンテンツ の タイプ application/x-x509-ca-cert および現在の発行者の認証の有効性終了時刻に CA 認証有効性開始時刻等号が付いているすなわち発行者の認証[または前]次の PKCS7 がフォーマットされていて含まれている本文の HTTP メッセージである GetNextCACert SCEP オペレーションを行います。

注: 応答コンテンツ の タイプは application/x-x509-next-ca-cert である可能性があることを SCEP RFC ドラフトが示すが IOS 実装は application/x-x509-ca-cert を送信 し、受け入れます。

注: ロールオーバー CA証明の開始時刻は現在のアクティブ CA証明の有効性終了時間より早い場合もあります。 ただし、ロールオーバー CA 認証は現在のアクティブな CA 認証が切れる後やっとアクティブになります。 しかし Cisco IOS PKI サーバは現在の CA 認証の有効性終了時刻と等しい有効性開始時刻のロールオーバー CA 認証を生成することを確かめます。

• GetNextCACert SCEP オペレーションが成功しない場合、予想される 応答が電流 CA （発行元）認証が切れる最後の stepor に記述されているように受け取られるまで再試行します。
• GetNextCACert SCEP オペレーションが成功する場合、ロールオーバー CA 認証は CA 認証（ロールオーバー）として更新されるトラストポイントの下のデータベースにインストールされています。
• GetNextCACert 正常なオペレーションの後で、IOS は再生が設定される場合シャドウ キー ペアを生成します（例: 80 再生を自動登録して下さい）。 再生 IOS なしで現在アクティブ な RSA キー ペアを再使用します。
• IOS は PKCS-7 エンベロープに暗号化される PKCS-10 によってフォーマットされている証明書要求を作成します。 このエンベロープはまた発行 CA のロールオーバー CA 認証の subject-name およびシリアル番号である RecipientInfo が含まれています。 この PKCS7-envelope は PKCS-7 署名されたデータに次々と詰まります。 これは現在のアクティブな ID証明を使用して署名し、また PKCS7 署名されたデータと組み込まれます。

このパケット構造に関する詳細については SCEP 概要 ドキュメントを参照して下さい

注: ここの鍵情報は CA の現在アクティブ な 認証に対してケースがの間に更新するオペレーションをあるように発行 CA のロールオーバー CA 認証の情報が含まれている RecipientInfo です。

今回、対称鍵はロールオーバー CA 公開鍵を使用して暗号化されます。 そしてこれはロールオーバー CA 認証を使用してこの要求に署名するのに CA によって使用される情報です。

注: IOS PKI SCEP デバッグは GetNewCert として内部でこれが今でも GetCert オペレーションであるがねじれのこのオペレーションを命名します。 そしてロールオーバー CA 認証を指す受信者のヒントであるねじれ。

• PKCS7 形式で実装されるこの証明書署名要求[CSR] PKCSReq の SCEP メッセージタイプおよび PKIOperation と呼ばれる SCEP オペレーションを用いる CA にそれから送信 されます。
• から、ここに、プロセスは更新オペレーションのそれと同じです、すなわち SCEP ステータスが保留中なら POLL タイマー、および各 POLL タイマー満了は GetCertInitial SCEP メッセージを引き起こします。
• 認証が PKI サーバで許可されるとき、GetCertInitial 次の SCEP メッセージはコンテンツ の タイプ application/x PKI メッセージの HTTP メッセージとおよび署名された PKCS7 データが含まれている本文に応答されます。 この PKCS7 署名されたデータは許可され、によって署名され、ロールオーバー CA 認証ヒント（Subject-name およびシリアル番号）およびまた PKCS7 によって囲まれるデータと組み込まれるように SCEP ステータスが含まれています。 この PKCS によって囲まれるデータは許可されたシャドウ 認証および現在のアクティブな ID証明の subject-name およびシリアル番号である RecipientInfo が含まれています。

注: PKCS7 によって囲まれるデータはまたシャドウ 認証が許可されたかどれをのために]受信者の公開キーを使って暗号化される対称鍵が含まれています[。 ルータを受け取ることはシャドウ プライベートキーを使用してそれを復号化します。 このクリア対称鍵がそれからシャドウ ID証明を明らかにする PKCS#7 によって囲まれるデータを復号化するのに使用されています。

注: 許可されたシャドウ 認証の開始する データはロールオーバー CA 認証のそれと同じです。 そしてこれはまた現在のアクティブな ID証明の終わりデータと同じ、また CA 認証の同じです。

注: PKCS7 署名されたデータと組み込まれるロールオーバー CA 認証 情報は PKCS7-enveloped データがシャドウ 認証が含まれていることクライアントルータを知らせる事柄の 1 つです。

• ロールオーバー 認証はロールオーバー 認証としてトラストポイントの下の認証 データベースに現在のアクティブな認証に影響を与えないで、インストールされています。 そして再生が設定されれば、シャドウ キー ペア <active-keypair-name#> は一時名前と保たれます。
• 現在のアクティブな認証が、CA 認証と共に、ロールオーバー CA 認証切れ、ロールオーバーが ID証明対応側をおよび取り替えるときアクティブになって下さい。 そして存在 する シャドウ キー ペアがそれ古いキー ペアを同様に取り替えれば。
• これの後でタイマーを初期化されなければならない更新したまたはシャドウ タイマーがクライアント 認証 更新のここに説明された <href 「型として-初期化されなければならなければかどうか確認するために、新しい認証の終了日は 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 は 08:38:26 9月9日 2017 に設定 される シャドウ タイマーを開始します:

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

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

シャドウ タイマーがロールオーバー CA 認証をダウンロードするために送信される 9 月 9 日切れるとき、第 1 は要求で 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 クライアントはシャドウ登録を続行しません。

ロールオーバー CA 認証がダウンロードされれば、PKI クライアントは現在の認証が切れるまで GetCert と同じである GetNextCert を、受け取った認証アクティブになるべきではないです行います:

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

シャドウ 認証がインストールされていれば、シャドウ タイマーは今またシャドウ 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証明はアクティブになります。

PKI サーバ ロールオーバーのクライアント シャドウ オペレーションの依存関係

PKI クライアントのシャドウ登録は起こる最初の事柄として発行 CA でロールオーバー 認証なしでシャドウ タイマー満了が GetNextCACert オペレーションを用いる SCEP 要求だった後、続くことができません。

CA がクライアントから GetNextCACert SCEP 要求を受け取るときここに示されているようにロールオーバー CA 認証としてマークされる認証があるかどうか、CA は確認します

CA がロールオーバー CA 認証を見つける場合、application/x-x509-ca-cert に設定 される HTTP コンテンツ の タイプを持つ HTTP応答応答本体で送信 されます。 コンテンツ の タイプは application/x-x509-next-ca-cert に設定 する必要があることを SCEP ドラフトが提案するが IOS 実装は GetCACert 応答の間にのと同じコンテンツ の タイプを使用します。

CA がロールオーバー CA 認証を見つけない場合「HTTP 404 Not Found」メッセージはクライアントに送られます。 クライアントは失敗としてこれを扱います。 実際厳しく「application/x-x509-ca-cert に」失敗としてコンテンツ の タイプが設定されているともの以外のどの HTTP応答でも扱われます。 クライアントはサーバがロールオーバー CA 認証と応答しなければロールオーバー CA 認証に次の 20 日のための 20 秒毎に得るために再試行します。

注: 何百もの GetNextCACert をサポートする CA を使うと展開される PKI クライアントで管理者は PKI クライアントが CA で生成されるロールオーバー 認証なしでは決して GetNextCACert 要求を開始しないことを確かめる必要があります。 さもなければ CA は完全にかもしれません正当 な物を含むすべての要求に応答しないために。 よいタイマー 設計のための配備例を参照して下さい。

PKI クライアント登録-リトライ メカニズム

PKI クライアント登録は失敗するか、またはクライアントが再試行を行うと期待されるところである SCEP 保留状態のメッセージが原因で遅れることができます

接続応答再試行タイマー

PKI サーバ コミュニケーションへの PKI クライアントが TCP ソケット障害か HTTP 要求 タイムアウトが原因で失敗するとき、PKI はクライアントの接続応答リトライ タイマーを初期化します。 SCEP エラーメッセージはこのタイマーを初期化している間考慮されません。 接続応答再試行タイマーは各失敗の後で 1 分にデフォルトで初期化され、これは 999 回デフォルトで繰り返されます。 これは confihurable 使用です:

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

このタイマーは登録のすべての型に-頭文字、更新またはシャドウ登録適用します。

POLL タイマー

PKI クライアントがサーバから GetCertInitial メッセージ（最初の証明書署名要求かそれに続く認証 ポーリング）への応答として SCEP 保留状態のメッセージを受け取る時、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 認証終止を越えてもはや役立つ発行されるかもしれない ceretificate のためにポーリングします。

RENEW/SHADOW タイマー

PKI クライアント登録が失敗か SCEP エラーメッセージを解析する HTTP応答が原因で失敗するとき更新タイマーかシャドウ タイマーは自動登録 <percentage> および現在のシステムの時刻によって初期設定をやり直されます。

計算し直されたタイマー値が現在の ID証明終止時間を越えて下るかまたは現在の ID証明が切れれば、これらのタイマーはもはや初期化されません。

PKI クライアント手動更新

 管理者は IOS PKI クライアントの手動認証 更新を行うことができます。 手動認証 更新はこれらのロジックに従います:

ここでは、想定は疑わしいトラストポイントが CA と既に登録されてしまったことです。

自動更新が信頼点の下で（<percentage> [再生を自動登録して下さい]）設定されます:

• ルータ ID証明は発行 CA 認証の前に切れること示す値である更新タイマーが動作する場合、このコマンドを実行することはここに記述されていた <link がオペレーション Overview> を更新するように更新しますオペレーションを実行します

crypto pki enroll <trustpoint-name>

• ルータ ID証明は発行 CA 認証と同時に切れること示す値であるシャドウ タイマーが動作する場合、このコマンドを実行することはここに記述されていた <link シャドウ オペレーション Overview> としてシャドウ オペレーションを行います

crypto pki enroll <trustpoint-name>

自動更新がトラストポイントの下で設定されない場合、ここに記述されているようにシャドウ タイマー CA 認証の 90% ライフタイムで GetNextCACert を行うために初期化されます。 ただし、手動更新は更新される ID証明の有効性および発行 CA 認証の有効性に基づいて RENEW およびシャドウ オペレーションの同じロジックに従います。

注: POLL タイマーが動作する場合、手動更新を行うために管理者は次の構成レベル コマンドの実行によってポーリングされる登録を取り消す必要があります: 暗号 PKI は <trustpoint> を登録しません

PKI サーバ-更新要求の承認された自動許可

IOS PKI サーバで、最初の登録を手動許可方式を使用して制御し、自動的にクライアントからの更新 証明書要求を許可することは可能性のあるです。

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

これらに注意して下さい:

• IOS CA/PKI サーバが有効に なるとき、トラストポイントは PKI サーバと PKI サーバ証明を保持する、またロールオーバー PKI サーバ証明作成されます同じ名前によって自動的に。
  
  
• 証明書署名要求が以前に ROOTCA と指名される PKI サーバによって発行される認証のための更新要求である場合証明書署名要求に署名すればのに使用されるクライアント 認証がトラストポイント ROOTCA でロードされる PKI サーバ証明によって署名したり/発行されればコマンド アクセス許可オート トラストポイント ROOTCA はことを要するに示します要求は自動的に許可されます。
  
  
• 最初の証明書署名要求の間に、IOS PKI クライアントは要求に署名するのに上で定義されるように基準を与える自動に会わないそれ故に最初の証明書署名要求は PKI サーバに保留中のキューの下に置かれます自己署名証明書を使用し: 暗号 PKI サーバ ROOTCA 要求を示して下さい
  
  
• これらの要求は手動でを使用して許可される必要があります:

  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 配備を設計している間タイマー考慮事項は重要です:

PKI クライアントがシャドウ登録を開始する前にルートCA か下位 CA はロールオーバー 認証を作成する必要があります

上でコンフィギュレーション の 断片からの例を使って考えます:

• ルートCA は 90 日終止の前にロールオーバー CA 認証を作成します
• ここの最も長いクライアント 認証 有効期間は 365 日です。
• シャドウ登録状態が発生するとき、クライアントは 292nd 日の 365 日すなわちか認証終止時間の前に 73 日の 80% で GetNextCACert を行います。
そして CA が既にロールオーバー 認証をこの時までに生成していたので、GetNextCACert は正常です