Guide de déploiement de l'ICP IOS : Transfert de certificat - Vue d'ensemble de la configuration et de l'opération

Introduction

Ce document décrit en détail le transfert de certificat sur les serveurs et les clients de l'infrastructure à clé publique (PKI) de Cisco IOS. 

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

Matériel

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

le logiciel Cisco IOS

• IOS
• Pour ISR-G1 - Dernière version 15.1(4)M*
• Pour ISR-G2 - Dernière version 15.4(3)M

• IOS-XE
• XE 3.15 ou 15.5(2)S

Note: La maintenance logicielle générale des périphériques ISR n'est plus active, les correctifs de bogues ou les améliorations de fonctionnalités futurs nécessiteront une mise à niveau matérielle vers les routeurs de la gamme ISR-2 ou ISR-4xxx.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

Le transfert de certificat, également appelé opération de renouvellement, garantit que lorsqu'un certificat expire, un nouveau certificat est prêt à prendre le relais. Du point de vue d'un serveur PKI, cette opération implique la génération du nouveau certificat de renversement de serveur bien à l'avance pour s'assurer que tous les clients PKI ont reçu un nouveau certificat de renversement de client signé par le nouveau certificat de renversement de serveur avant l'expiration du certificat actuel. Du point de vue d'un client PKI, si le certificat client expire mais que le certificat du serveur de l'autorité de certification (AC) ne l'est pas, le client demande un nouveau certificat et remplace l'ancien certificat dès la réception du nouveau certificat, et si le certificat client expire en même temps que le certificat du serveur AC, le client s'assure de recevoir d'abord le certificat de substitution du serveur AC, puis il demande un transfert certificat signé par le nouveau certificat de substitution de serveur AC, et les deux seront activés lorsque les anciens certificats expireront.

Configuration

Configuration requise pour l'ICP et le protocole SCEP (Simple Ceritificate Enrollment Protocol)

Source temporelle autorisée

Dans IOS, par défaut, la source d'horloge est considérée comme non autorisée, car l'horloge matérielle n'est pas la meilleure source de temps. PKI étant sensible au temps, il est important de configurer une source de temps valide à l'aide de NTP. Dans un déploiement PKI, il est recommandé que tous les clients et le serveur synchronisent leur horloge sur un seul serveur NTP, via plusieurs serveurs NTP si nécessaire. Plus d'informations à ce sujet sont expliquées dans le Guide de déploiement de l'ICP IOS : Conception et déploiement initiaux

IOS n’initialise pas les compteurs PKI sans horloge faisant autorité. Bien que NTP soit fortement recommandé, à titre de mesure temporaire, l'administrateur peut marquer l'horloge matérielle comme faisant autorité en utilisant :

Router(config)# clock calendar-valid

Communication HTTP

Un serveur ICP IOS actif est requis par le serveur HTTP, qui peut être activé à l’aide de cette commande de niveau de configuration :

ip http server <1024-65535>

Cette commande active le serveur HTTP sur le port 80 par défaut, qui peut être modifié comme indiqué ci-dessus.

Les clients PKI doivent pouvoir communiquer avec le serveur PKI via HTTP au port configuré.

Configuration PKI

Serveur - Renvoi

La configuration automatique de transfert du serveur PKI ressemble à :

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

Le paramètre de substitution automatique est défini en jours. À un niveau plus précis, la commande ressemble à :

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

Une valeur de substitution automatique de 90 indique que l'IOS crée un certificat de serveur de substitution 90 jours avant l'expiration du certificat de serveur actuel et que la validité de ce nouveau certificat de substitution commence en même temps que l'expiration du certificat actif actuel.

Le transfert automatique doit être configuré avec une valeur telle que le certificat d'autorité de certification de transfert soit généré bien à l'avance sur le serveur PKI avant que n'importe quel client PKI du réseau n'effectue l'opération GetNextCACert comme décrit dans la section Vue d'ensemble de l'opération SHADOW ci-dessous.

Client - Renouvellement

La configuration de renouvellement automatique de certificat du client PKI ressemble à :

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

Ici, la commande auto-enroll <pourcentage> [régénération] indique que IOS doit effectuer le renouvellement du certificat à 80 % exactement de la durée de vie du certificat actuel.

Le mot clé régénération indique qu'IOS doit régénérer la paire de clés RSA connue sous le nom de paire de clés cachées lors de chaque opération de renouvellement de certificat.

Soyez prudent lors de la configuration du pourcentage d'inscription automatique. Sur un client PKI donné dans le déploiement, si une condition se produit lorsque le certificat d'identité expire en même temps que le certificat d'autorité de certification émetteur, la valeur d'inscription automatique doit toujours déclencher l'opération de renouvellement [shadow] après que l'autorité de certification a créé le certificat de substitution. Reportez-vous à la section Dépendances du temporisateur PKI dans les exemples de déploiement.

Conditions préalables au renouvellement/transfert de l'ICP

Ce document traite en détail des opérations de transfert et de renouvellement de certificat et, par conséquent, ces événements sont considérés comme ayant réussi :

• Initialisation du serveur PKI avec un certificat CA valide.
• Les clients PKI ont été correctement inscrits au serveur PKI. Par exemple, chaque client PKI possède le certificat CA et un certificat d'identité, c'est-à-dire le certificat de routeur.

L'inscription d'un client implique ces événements. Sans trop entrer dans les détails :

• Authentification Trustpoint
• Inscription à Trustpoint

Dans IOS, un point de confiance est un conteneur de certificats. Tout point de confiance donné peut contenir un certificat d'identité actif et/ou un certificat d'autorité de certification actif. Un point de confiance est considéré comme authentifié s'il contient un certificat CA actif. Et il est considéré comme inscrit s'il contient un certificat d'identité. Un point de confiance doit être authentifié avant une inscription. La configuration du serveur et du client PKI, ainsi que l'authentification et l'inscription des points de confiance sont traitées en détail dans le Guide de déploiement de l'ICP IOS : Conception et déploiement initiaux

Après avoir récupéré/installé le certificat de l'autorité de certification, le client PKI récupère les capacités du serveur PKI avant d'effectuer une inscription. La récupération des capacités de l'autorité de certification est expliquée dans cette section.

Capacités CA

Dans IOS, lorsqu’un client PKI authentifie une CA, en d’autres termes, lorsqu’un administrateur crée un point de confiance sur un routeur IOS et exécute la commande crypto pki authenticate <trustpoint-name>, ces événements se produisent sur le routeur :

• IOS envoie une requête SCEP contenant le type d'opération GetCACert.
• La réponse attendue ici est un message HTTP avec un type de contenu d'application/x-x509-ca-cert en cas de déploiement d'autorité de certification, ou application/x-x509-ca-ra-cert en cas de déploiement d'autorité de certification et d'autorité de certification. Et le corps HTTP contient le certificat CA. [et un certificat RA dans ce dernier cas].
• Après la récupération et l'installation du certificat CA/RA, le client lance une demande SCEP automatique contenant l'opération GetCACaps.
• La réponse attendue ici est un message HTTP avec un type de contenu d'application/x-pki-message, qui peut également être texte/clair et le corps HTTP contient une série de fonctionnalités prises en charge par l'autorité de certification, séparées par un caractère de flux de ligne. Une réponse typique du serveur ICP IOS est présentée dans le schéma ci-dessous.

La réponse est interprétée comme ceci par le client ICP IOS :

CA_CAP_GET_NEXT_CA_CERT
CA_CAP_RENEWAL
CA_CAP_SHA_1
CA_CAP_SHA_256

Parmi ces capacités, le présent document porte sur ces deux aspects.

GetNextCACert

Lorsque cette fonctionnalité est renvoyée par l'autorité de certification, IOS comprend que l'autorité de certification prend en charge le transfert de certificat CA. Avec cette fonctionnalité retournée, si la commande auto-enroll n'est pas configurée sous le point de confiance, IOS initialise un temporisateur SHADOW défini à 90 % de la période de validité du certificat CA.

Lorsque le minuteur SHADOW expire, IOS exécute l'opération GetNextCACert SCEP pour récupérer le certificat de l'autorité de certification de renversement.

Remarque : si la commande auto-enroll a été configurée sous le trustpoint avec une url d'inscription, un minuteur RENEW est initialisé avant même d'authentifier le trustpoint, et il tente constamment de s'inscrire auprès de l'autorité de certification située à l'url d'inscription, bien qu'aucun message d'inscription réel [truR] ne soit envoyé jusqu'authentification.

Note: GetNextCACert est envoyé en tant que fonctionnalité par le serveur ICP IOS même si le basculement automatique n'est pas configuré sur le serveur

Renouvellement

Grâce à cette fonctionnalité, le serveur PKI informe le client PKI qu'il peut utiliser un certificat d'ID actif pour signer une demande de signature de certificat pour renouveler le certificat existant.

Pour en savoir plus, consultez la section Renouvellement automatique du client PKI .

Transfert automatique du serveur PKI

Avec la configuration ci-dessus sur le serveur AC, vous voyez :

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

Notez ceci :

Opération de substitution

 Lorsque le minuteur CS SHADOW CERT GENERATION expire :

• IOS génère d'abord une paire de clés à paires inversées. Actuellement, elle porte le même nom que la paire de clés active à laquelle un hachage # est ajouté.
  
  

  
  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 génère ensuite le certificat d'autorité de certification de substitution, où la date de début de validité est identique à la date de fin de validité du certificat d'autorité de certification actif actuel.
  
  

  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

Transfert manuel du serveur PKI

IOS PKI Server prend en charge le renversement manuel du certificat d'autorité de certification, c'est-à-dire qu'un administrateur peut déclencher la génération d'un certificat d'autorité de certification de renversement à l'avance sans avoir à configurer le renversement automatique sous la configuration du serveur PKI. Il est fortement recommandé de configurer le transfert automatique, que l'on envisage ou non de prolonger la durée de vie d'un serveur AC initialement déployé pour qu'il soit plus sûr. Les clients PKI peuvent surcharger l'autorité de certification sans certificat d'autorité de certification inversé. Référez-vous à Dépendance de l'opération SHADOW du client sur le basculement du serveur PKI.

Un basculement manuel peut être déclenché à l'aide de la commande configuration level :

crypto pki server <Server-name> rollover

De plus, un certificat CA à paires inversées peut être annulé pour en générer un nouveau manuellement. Toutefois, un administrateur ne doit pas faire quelque chose dans un environnement de production, en utilisant :

crypto pki server <Server-name> rollover cancel

Cette opération supprime la paire de clés rsa inversée et le certificat CA inversé. Il est déconseillé de le faire car :

• Une fois que l'autorité de certification génère le certificat de substitution, plusieurs clients peuvent télécharger le certificat d'autorité de certification de substitution ainsi qu'un certificat de client de substitution signé par le certificat d'autorité de certification de substitution.
• À ce stade, si le transfert est annulé, le client devra peut-être être réinscrit.

Renouvellement automatique du client PKI

Types de renouvellement de certificat client - RENOUVEAU et SHADOW

IOS sur le serveur PKI s'assure toujours que le délai d'expiration du certificat d'ID émis au client ne dépasse jamais le délai d'expiration du certificat d'autorité de certification.

Sur un client PKI, IOS prend toujours en compte les temporisateurs suivants avant de planifier l'opération de renouvellement :

• Heure d'expiration du renouvellement du certificat d'identité
• Heure d'expiration du certificat de l'émetteur (CA)

Si le délai d'expiration du certificat d'identité n'est pas le même que le délai d'expiration du certificat d'autorité de certification, IOS effectue une opération de renouvellement simple.

Si le délai d'expiration du certificat d'identité est le même que le délai d'expiration du certificat d'autorité de certification, IOS effectue une opération de renouvellement instantané.

RENOUVEAU - Renouvellement du certificat d'identité du routeur

Comme mentionné précédemment, le client ICP IOS effectue une opération de renouvellement simple si le délai d’expiration du certificat d’identité n’est pas le même que le délai d’expiration du certificat d’AC, c’est-à-dire que le certificat d’identité expirant avant que le certificat de l’émetteur ne déclenche un renouvellement simple du certificat d’identité.

Dès qu'un certificat d'identité est installé, IOS calcule le compteur RENEW pour le point d'approbation spécifique comme indiqué ci-dessous :

Current-Authoritative-Time signifie que l'horloge système doit être une source de temps faisant autorité, comme décrit ici. (lien vers la section source temporelle faisant autorité) Les temporisateurs PKI ne seront pas initialisés sans une source temporelle faisant autorité. Et par conséquent, l'opération de renouvellement n'aura pas lieu.

Les événements suivants se produisent à l'expiration du compteur RENEW :

• IOS génère une paire de clés cachées si la régénération est configurée [exemple : auto-enroll 80 regénérer]. Sans régénérer IOS, il réutilise la paire de clés RSA active.
• IOS crée une demande de certificat formatée PKCS-10, qui est ensuite cryptée dans une enveloppe PKCS-7. Cette enveloppe contient également les informations sur le destinataire, qui sont le nom du sujet et le numéro de série de l'autorité de certification émettrice. Cette enveloppe PKCS7 est à son tour conditionnée en données signées PKCS-7. Au cours de l'inscription initiale, IOS utilise un certificat auto-signé pour signer ce message. Et lors des inscriptions suivantes, c'est-à-dire des réinscriptions, IOS utilise le certificat d'identité actif pour signer le message. Les données signées PKCS7 sont également intégrées au certificat de signature, c'est-à-dire au certificat auto-signé ou au certificat d'identité.

 Pour plus d'informations sur cette structure de paquets, reportez-vous au document de présentation SCEP

Note: Les informations de clé ici sont le RecipientInfo qui est le nom du sujet et le numéro de série de l'autorité de certification émettrice, et la clé publique de cette autorité de certification est utilisée pour chiffrer la clé symétrique. Le CSR de l'enveloppe PKCS7 est chiffré à l'aide de cette clé symétrique.

Cette clé symétrique cryptée est déchiffrée par l'autorité de certification réceptrice à l'aide de sa clé privée, et cette clé symétrique est utilisée pour déchiffrer l'enveloppe PKCS7 révélant la CSR.

• Cette demande de signature de certificat (CSR) emballée au format PKCS7 est ensuite envoyée à l'AC avec un type de message SCEP de PKCSReq et une opération SCEP appelée PKIOperation.
• Si l’autorité de certification rejette la demande, IOS arrête le compteur RENEW. À partir de ce moment, pour renouveler le certificat d'identité, l'administrateur doit effectuer un renouvellement manuel (lien vers la section Renouvellement manuel du client PKI)
• Si l'autorité de certification envoie un état SCEP comme en attente, IOS sur le client PKI démarre un compteur de POLL à partir de 60 secondes ou 1 minute. Chaque fois qu'un minuteur de POLL expire, IOS envoie un message GetCertInitial SCEP via une opération PKIOperation.Lorsque le premier minuteur de POLL expire, si le message GetCertInitial reçoit une réponse avec un état SCEP En attente, un algorithme de désactivation exponentiel définit le premier intervalle de temporisation de POLL à 1 minute, le deuxième intervalle de temporisation à 2 minutes, le troisième. intervalle de nouvelle tentative du temporisateur à 4 minutes, etc., pour les 999 prochaines tentatives par défaut ou jusqu'à l'expiration du certificat de l'autorité de certification émettrice.
  Le nombre d'interrogations et la première période de nouvelle tentative peuvent être configurés à l'aide des éléments suivants :

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

• Lorsque le certificat est accordé sur le serveur PKI, le prochain message GetCertInitial SCEP reçoit une réponse avec un message HTTP de type application/x-pki-message et un corps contenant des données signées PKCS#7. Ces données signées PKCS7 contiennent l'état SCEP comme Granted, ainsi qu'une donnée enveloppée PKCS7. Ces données enveloppées PKCS contiennent le certificat accordé et les informations sur le destinataire, qui sont le nom du sujet et le numéro de série du certificat auto-signé lors de l'inscription initiale et du certificat d'identité actif lors des réinscriptions.

Les données enveloppées PKCS7 contiennent également une clé symétrique chiffrée avec la clé publique du destinataire (pour laquelle le nouveau certificat a été accordé). La réception du routeur le déchiffre à l’aide de la clé privée. Cette clé symétrique claire est ensuite utilisée pour déchiffrer les données enveloppées PKCS#7, révélant le nouveau certificat d'identité.

• À ce stade, IOS remplace immédiatement le certificat d'identité existant par le nouveau certificat. Et si la régénération a été configurée, la paire de clés cachées remplace également la paire de clés active.

• En outre, la date de fin du nouveau certificat est comparée à la date de fin du certificat CA pour déterminer si le compteur RENEW doit être initialisé ou si un compteur SHADOW doit être initialisé comme expliqué ici <href Types de renouvellement de certificat client - RENEW et SHADOW>

Vérification

Un client PKI nouvellement inscrit aurait un certificat d'identité (également appelé certificat de routeur ou certificat d'entité finale) et le certificat d'autorité de certification émetteur sous le point de confiance inscrit

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

Le compteur PKI correspondant est :

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

Calcul comme indiqué ici

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

Lorsque le compteur RENOUVEAU expire :

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

Notez que la demande de renouvellement est signée à l'aide du certificat d'ID actif actuel :

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

Si la réponse SCEP reçue est EN ATTENTE, nous lançons un compteur de sondage :

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

Comme illustré précédemment, ce compteur de POLL suit un algorithme de réémission exponentielle, commençant à 1 minute, puis 2 minutes, puis 4 minutes, etc., jusqu'à ce que la réponse SCEP reçue soit ACCORDÉE ou que le certificat d'ID expire.

Lorsque le compteur de POLL expire et que la réponse SCEP est ACCORDÉE :

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

Après le renouvellement du certificat du routeur :

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 - Identité du routeur et renouvellement du certificat CA

Le client ICP IOS effectue une opération de renouvellement instantané si le délai d'expiration du certificat d'identité est le même que le délai d'expiration du certificat d'autorité de certification, c'est-à-dire si le certificat d'identité expirant au même moment que le certificat de l'émetteur déclenche une opération de renouvellement instantané.

Dès qu'un certificat d'identité est installé, qui a la même date de fin que le certificat de l'émetteur, IOS calcule le temporisateur SHADOW pour le point de confiance spécifique. Ainsi, à un moment donné, la valeur du compteur SHADOW serait :

Les événements suivants se produisent lorsque le compteur SHADOW d'un point de confiance donné expire :

• IOS exécute l'opération GetNextCACert SCEP, où la réponse attendue est un message HTTP de type de contenu application/x-x509-ca-cert et le corps contenant le certificat Next CA formaté PKCS7, c'est-à-dire le certificat de l'émetteur dont la durée de validité est égale [ou antérieure] à l'heure de fin de validité du certificat actuel.

Note: Bien que le brouillon RFC SCEP indique que le type de contenu de réponse peut être application/x-x509-next-ca-cert, l'implémentation IOS envoie et accepte application/x-x509-ca-cert.

Note: L'heure de début du certificat d'autorité de certification de substitution peut être antérieure à l'heure de fin de validité du certificat d'autorité de certification actif actuel. Cependant, le certificat d'autorité de certification de substitution ne sera activé qu'après l'expiration du certificat d'autorité de certification actif actuel. Le serveur PKI de Cisco IOS s'assure toutefois de générer un certificat d'autorité de certification inversé avec une heure de début de validité égale à l'heure de fin de validité du certificat d'autorité de certification actuel.

• Si l'opération GetNextCACert SCEP ne réussit pas, elle recommence jusqu'à ce que la réponse attendue soit reçue comme décrit dans le dernier rapport d'étape, le certificat CA (émetteur) actuel expire.
• Si l'opération GetNextCACert SCEP réussit, le certificat d'autorité de certification de renversement est installé dans la base de données sous le point de confiance renouvelé en tant que certificat d'autorité de certification (renversement).
• Suite à une opération GetNextCACert réussie, IOS génère une paire de clés cachées si la régénération est configurée (exemple : auto-enroll 80 (régénération). Sans régénérer IOS, il réutilise la paire de clés RSA active.
• IOS crée une demande de certificat formatée PKCS-10, qui est ensuite cryptée dans une enveloppe PKCS-7. Cette enveloppe contient également les informations sur le destinataire, qui sont le nom du sujet et le numéro de série du certificat de l'autorité de certification inversée de l'autorité de certification émettrice. Cette enveloppe PKCS7 est à son tour conditionnée en données signées PKCS-7. Il est signé à l'aide du certificat d'identité actif actuel et est également incorporé aux données signées PKCS7.

Pour plus d'informations sur cette structure de paquets, reportez-vous au document de présentation SCEP

Note: Les informations clés ici sont les informations de destinataire, qui contiennent les informations du certificat d'autorité de certification inversé de l'autorité de certification émettrice, par opposition au certificat actuellement actif de l'autorité de certification, comme c'est le cas lors de l'opération RENOUVEAU.

Cette fois, la clé symétrique est chiffrée à l'aide de la clé publique de l'autorité de certification inversée. Il s'agit des informations utilisées par l'autorité de certification pour signer cette demande à l'aide du certificat de l'autorité de certification inversée.

Note: Les débogages IOS PKI SCEP appellent cette opération GetNewCert, bien qu'en interne, il s'agisse toujours de GetCert, avec une torsion. Et la torsion étant les informations du destinataire pointant vers le certificat CA inversé.

• Cette demande de signature de certificat [CSR] emballée au format PKCS7 est ensuite envoyée à l'AC avec un type de message SCEP de PKCSReq et une opération SCEP appelée PKIOperation.
• À partir de, ici, le processus est le même que celui de l'opération RENEW, c'est-à-dire le minuteur POLL si l'état SCEP est En attente, et chaque temporisateur POLL déclenche un message GetCertInitial SCEP.
• Lorsque le certificat est accordé sur le serveur PKI, le prochain message GetCertInitial SCEP reçoit une réponse avec un message HTTP de type application/x-pki-message et un corps contenant des données PKCS7 signées. Ces données signées PKCS7 contiennent l'état SCEP comme accordé, signé et incorporé avec les informations de certificat de l'autorité de certification de transfert (nom du sujet et numéro de série) ainsi qu'une donnée enveloppée PKCS7. Ces données enveloppées PKCS contiennent le certificat caché accordé et l'information du destinataire, qui est le nom du sujet et le numéro de série du certificat d'identité actif actuel.

Note: Les données enveloppées PKCS7 contiennent également une clé symétrique chiffrée avec la clé publique du destinataire [pour laquelle le certificat instantané a été accordé]. La réception du routeur le décrypte à l’aide de la clé privée cachée. Cette clé symétrique claire est ensuite utilisée pour déchiffrer les données enveloppées PKCS#7, révélant le certificat d'identité cachée.

Note: Les données de début du certificat instantané accordé sont identiques à celles du certificat CA inversé. Et c'est aussi la même chose que les données de fin du certificat d'identité actif actuel ainsi que celles du certificat de CA.

Remarque : Les informations de certificat de l'autorité de certification inversée incorporées aux données signées PKCS7 sont une des choses qui informent le routeur client que les données enveloppées PKCS7 contiennent un certificat instantané.

• Le certificat de renversement est installé dans la base de données de certificats sous le point de confiance en tant que certificat de renversement, sans affecter le certificat actif actuel. Et si régénération est configurée, la paire de clés cachées <nom-paire-clé active#> est conservée avec son nom temporaire.
• Lorsque le certificat actif actuel expire, ainsi que le certificat CA, le certificat CA de substitution et le certificat d'identité de substitution remplacent leurs homologues et deviennent actifs. Et si une paire de clés de l'ombre existe, elle remplace également l'ancienne paire de clés.
• Par la suite, la date de fin du nouveau certificat est comparée à la date de fin du certificat CA pour déterminer si le compteur RENEW doit être initialisé ou si un compteur SHADOW doit être initialisé comme expliqué ici <href “ Types de renouvellement de certificat client - RENEW et SHADOW ”>

Vérification

À partir de l'exemple PKI-Client ci-dessus, après le premier renouvellement, lorsque le deuxième renouvellement a lieu le 15 mai.

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

Ici, notez que la nouvelle date d'expiration du certificat est identique à celle du certificat de l'autorité de certification émettrice, par conséquent, IOS démarre un minuteur SHADOW défini à 08:38:26, le 9 septembre 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

Lorsque le minuteur SHADOW expire le 9 septembre, la première demande envoyée est GetNextCACert, pour télécharger le certificat CA à paires inversées :

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

Note: Sans GetNextCACert réussi, un client PKI ne pourra pas poursuivre l'inscription SHADOW.

Une fois le certificat d'autorité de certification de substitution téléchargé, PKI-Client exécute GetNextCert, qui est identique à GetCert, le certificat reçu n'est pas activé avant l'expiration du certificat actuel :

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)

Ici, le même algorithme de réémission temporisée exponentielle s'applique. Lorsqu'une réponse de sondage est ACCORDÉE :

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

Une fois le certificat instantané installé, le minuteur SHADOW indique maintenant l'heure à laquelle le certificat d'ID actif actuel et le certificat d'Autorité de certification expirent, ce qui indique également l'heure à laquelle le certificat d'ID instantané et le certificat d'Autorité de certification sont activés :

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

À ce stade, la base de données des certificats ressemble à :

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

À ce stade, l'ID de renversement et les certificats d'autorité de certification sont activés lorsque l'horloge système atteint la date de début de validité de ces certificats de renversement, qui est déclenchée lorsque le temporisateur SHADOW expire.

Dépendance de l'opération SHADOW du client sur le transfert de serveur PKI

L'inscription SHADOW sur le client PKI ne peut pas se poursuivre sans certificat de substitution sur l'autorité de certification émettrice, car la première chose qui se passe après l'expiration du compteur SHADOW est une demande SCEP avec l'opération GetNextCACert.

Lorsqu'une autorité de certification reçoit une demande GetNextCACert SCEP d'un client, l'autorité de certification vérifie si elle a un certificat marqué comme certificat d'autorité de certification inversé, comme indiqué ici

Si l'autorité de certification détecte un certificat d'autorité de certification inversé, il est envoyé dans le corps de réponse HTTP avec le type de contenu HTTP défini sur application/x-x509-ca-cert. Bien que le projet SCEP suggère que le type de contenu doit être défini sur application/x-x509-next-ca-cert, l'implémentation IOS utilise le même type de contenu que lors de la réponse GetCACert.

Si l'autorité de certification ne trouve pas de certificat d'autorité de certification inversé, un message HTTP “ 404 Not Found ” est envoyé au client. Le client traite cela comme un échec. En fait, toute réponse HTTP autre que celle dont le type de contenu est strictement défini sur “ application/x-x509-ca-cert ” est traitée comme un échec. Le client tente à nouveau d'obtenir le certificat CA inversé toutes les 20 secondes pendant les 20 prochains jours, sauf si le serveur répond avec le certificat CA inversé.

Remarque : avec des centaines de clients PKI déployés avec une autorité de certification prenant en charge GetNextCACert, l'administrateur doit s'assurer que les clients PKI ne démarrent jamais la demande GetNextCACert sans certificat de transfert généré sur l'autorité de certification. Sinon, l'AC peut ne pas répondre à toutes les demandes, y compris les demandes légitimes. Référez-vous à Exemples de déploiement pour une bonne conception de minuteur.

Inscription des clients PKI - Mécanismes de nouvelle tentative

Les inscriptions au client PKI peuvent échouer ou être retardées en raison des messages SCEP En attente, où le client doit effectuer des nouvelles tentatives

CALENDRIER CONNECTER RETRY

Lorsque la communication entre le client PKI et le serveur PKI échoue en raison d'une défaillance de socket TCP ou d'un délai d'attente de requête HTTP, PKI initialise CONNECT RETRY Timer sur le client. Les messages d'erreur SCEP ne sont pas pris en compte lors de l'initialisation de ce compteur. Le minuteur CONNECT RETRY est initialisé à 1 minute par défaut après chaque défaillance, et il est répété 999 fois par défaut. Cette configuration est possible à l'aide des éléments suivants :

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

Ce compteur s'applique à tous les types d'inscriptions : inscription initiale, renouvellement ou inscription instantanée.

Temporisateur de POLL

Lorsque le client PKI reçoit un message SCEP En attente du serveur en réponse à son message GetCertInitial (demande de signature de certificat initiale ou interrogation de certificat ultérieure), il initialise le minuteur POLL. Par défaut, le premier compteur de POLL est initialisé à 1 minute. Les compteurs POLL suivants suivent un algorithme de réémission exponentielle :

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

Ici, le premier intervalle de minuteur de POLL peut être configuré à l'aide des éléments suivants :

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

Le compteur POLL n'est pas étendu au-delà de l'expiration du certificat CA émetteur. Ici, la logique est que l'interrogation d'un certificat qui aurait pu être émis au-delà de l'expiration du certificat de l'autorité de certification émettrice n'est plus utile.

RENOUVELER/SHADOW Timer

Lorsque l'inscription du client PKI échoue en raison d'échecs d'analyse de réponse HTTP ou de messages d'erreur SCEP, le minuteur RENEW ou le minuteur SHADOW est réinitialisé en fonction du pourcentage d'inscription automatique et de l'heure système actuelle.

Si la valeur du compteur recalculé dépasse le délai d'expiration du certificat d'identité actuel ou si le certificat d'identité actuel expire, ces compteurs ne sont plus initialisés.

Manuel du client PKI - Renouvellement

 Un administrateur peut effectuer le renouvellement manuel des certificats sur les clients ICP IOS. Un renouvellement manuel de certificat suit cette logique :

Ici, l'hypothèse est que le point de confiance en question a déjà été inscrit avec une CA.

Si le renouvellement automatique (inscription automatique <pourcentage> [régénération]) est configuré sous le point d'approbation :

• Si un minuteur RENEW est en cours d'exécution, ce qui indique que le certificat d'identité du routeur expire avant le certificat CA émetteur, l'exécution de cette commande effectue l'opération RENEW comme décrit ici <link RENEW Operation Overview>

crypto pki enroll <trustpoint-name>

• Si un minuteur SHADOW est en cours d'exécution, ce qui indique que le certificat d'identité du routeur expire en même temps que le certificat de l'autorité de certification émettrice, l'exécution de cette commande effectue l'opération SHADOW comme décrit ici <link SHADOW Operation Overview>

crypto pki enroll <trustpoint-name>

Si le renouvellement automatique n'a pas été configuré sous le point de confiance, comme décrit ici, un minuteur SHADOW est initialisé pour exécuter GetNextCACert à 90 % de la durée de vie du certificat de l'autorité de certification. Toutefois, le renouvellement manuel suit la même logique de fonctionnement de RENEW et de SHADOW en fonction de la validité du certificat d'identité renouvelé et de la validité du certificat de l'autorité de certification émettrice.

Note: Si un minuteur de POLL est en cours d'exécution, pour effectuer un renouvellement manuel, l'administrateur doit annuler l'inscription en cours de POLL en exécutant la commande suivante de niveau de configuration : no crypto pki enroll <trustpoint>

Serveur PKI - Octroi automatique autorisé des demandes de renouvellement de client

Sur les serveurs PKI IOS, il est possible de contrôler l'inscription initiale à l'aide de la méthode d'octroi manuelle et d'accorder automatiquement les demandes de certificat de renouvellement des clients.

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

Notez les points suivants :

• Lorsqu'un serveur AC/PKI IOS est activé, un point de confiance est automatiquement créé par le même nom que le serveur PKI, qui détient le certificat du serveur PKI, ainsi que le certificat du serveur PKI inversé.
  
  
• La commande grant auto trustpoint ROOTCA indique que si le certificat client utilisé pour signer la demande de signature de certificat est signé/émis par le certificat du serveur PKI chargé dans le ROOTCA du point de confiance, en d'autres termes si la demande de signature de certificat est une demande de renouvellement pour un certificat précédemment émis par le serveur PKI nommé ROOTCA, alors la demande est automatiquement accordée.
  
  
• Au cours de la demande de signature de certificat initiale, un client ICP IOS utilise un certificat auto-signé pour signer la demande, qui ne satisfait pas aux critères d'octroi automatique définis ci-dessus, et par conséquent les demandes de signature de certificat initiales sont placées dans la file d'attente en attente sur le serveur PKI : show crypto pki server requêtes ROOTCA
  
  
• Ces demandes doivent être accordées manuellement à l'aide des éléments suivants :

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

• Cette configuration fonctionne également lorsque le serveur PKI est en état de substitution, c'est-à-dire lorsque le serveur PKI a généré un certificat de serveur PKI de substitution.

Dépendances du temporisateur PKI

Récapitulant tous les compteurs qui doivent être soigneusement conçus :

• Durée de vie du certificat du serveur AC
  Il s'agit de la durée de vie du certificat du serveur AC
• Durée de vie du certificat client
  Il s'agit de la durée de vie du certificat délivré à un client par un serveur PKI donné
• Durée de vie du certificat d'autorité de certification subordonnée
  L'autorité de certification subordonnée est un client en ce qui concerne l'autorité de certification racine, de sorte que la durée de vie du certificat client définie sur l'autorité de certification racine s'applique également à l'autorité de certification subordonnée
• Temps de transfert CA
  Nombre de jours avant le délai d'expiration du certificat CA.
• Temps de renouvellement du client
  Pourcentage de la durée de vie totale du certificat client.

Serveur PKI :

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

Client PKI :

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

Un serveur AC IOS s'assure toujours qu'un délai d'expiration du certificat client est égal ou inférieur au délai d'expiration du certificat du serveur AC.

Lors de la conception d'un déploiement d'ICP, il est important de tenir compte des délais suivants :

Root-CA ou Subordonné-CA doit créer un certificat de substitution avant qu'un client PKI ne démarre une inscription fantôme

En prenant l'exemple de l'extrait de configuration ci-dessus :

• Root-CA crée un certificat CA inversé 90 jours avant l'expiration
• La période de validité du certificat client la plus longue est ici de 365 jours.
• Lorsque la condition d'inscription fantôme se produit, le client exécute GetNextCACert à 80 % sur 365 jours, c'est-à-dire le 292e jour ou 73 jours avant l'expiration du certificat.
Et comme l'autorité de certification a déjà généré le certificat de renversement à ce stade, GetNextCACert a réussi