Guía de implementación de PKI de IOS: Renovación de certificados - Descripción general de la configuración y el funcionamiento

Introducción

Este documento describe la renovación de certificados en los servidores y clientes de la infraestructura de clave pública (PKI) de Cisco IOS en detalle. 

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software y hardware.

Hardware

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

Software

• IOS
• Para ISR-G1 - Última versión 15.1(4)M*
• Para ISR-G2 - Última versión 15.4(3)M

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

Nota: El mantenimiento general del software para los dispositivos ISR ya no está activo, cualquier corrección de errores o mejora de funciones futuras requeriría una actualización del hardware a los routers ISR-2 o ISR-4xxx series.

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.

Antecedentes

La renovación de certificados también conocida como operación de renovación garantiza que cuando caduque un certificado, un nuevo certificado estará listo para asumir el control. Desde el punto de vista de un servidor PKI, esta operación implica generar el nuevo certificado de renovación del servidor con mucha antelación para asegurarse de que todos los clientes PKI hayan recibido un nuevo certificado de renovación del cliente firmado por el nuevo certificado de renovación del servidor antes de que venza el certificado actual. Desde el punto de vista de un cliente PKI, si el certificado del cliente caduca pero el certificado del servidor de la autoridad certificadora (CA) no, el cliente solicita un nuevo certificado y reemplaza el certificado antiguo tan pronto como se recibe el nuevo certificado, y si el certificado del cliente caduca al mismo tiempo que el certificado del servidor de la CA, el cliente se asegura de recibir primero el certificado de renovación del servidor de la CA y luego solicita un certificado de renovación firmado por el nuevo certificado de renovación del servidor de la CA y ambos se activarán cuando venzan los certificados antiguos.

Configuración

Requisito previo de PKI y protocolo simple de inscripción de certificados (SCEP)

Origen de tiempo autorizado

En IOS, de forma predeterminada, el origen del reloj se considera no autorizado, ya que el reloj de hardware no es la mejor fuente de tiempo. Si la PKI distingue el tiempo, es importante configurar un origen de tiempo válido mediante NTP. En una implementación de PKI, se recomienda que todos los clientes y el servidor sincronicen su reloj con un único servidor NTP, a través de varios servidores NTP si es necesario. Se explica más sobre esto en la Guía de Implementación de PKI de IOS: Diseño e implementación iniciales

IOS no inicializa los temporizadores PKI sin un reloj autorizado. Aunque se recomienda encarecidamente NTP, como medida temporal, el administrador puede marcar el reloj de hardware como autoritativo usando:

Router(config)# clock calendar-valid

Comunicación HTTP

Un requisito para un servidor PKI de IOS activo es el servidor HTTP, que se puede habilitar usando este comando config-level:

ip http server <1024-65535>

Este comando habilita el servidor HTTP en el puerto 80 de forma predeterminada, que se puede cambiar como se muestra arriba.

Los clientes PKI deberían poder comunicarse con el servidor PKI a través de HTTP al puerto configurado.

Configuración PKI

Servidor - Renovación

La configuración de renovación automática del servidor PKI es similar a:

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

El parámetro de renovación automática se define en días. A un nivel más granular, el comando tiene el siguiente aspecto:

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

Un valor de renovación automática de 90 indica que el IOS crea un certificado de servidor de sustitución incremental 90 días antes de la expiración del certificado de servidor actual, y la validez de este nuevo certificado de renovación comienza al mismo tiempo que la hora de vencimiento del certificado activo actual.

La renovación automática debe configurarse con tal valor que se asegure de que el certificado de CA de sustitución incremental se genere en el servidor PKI con mucha antelación antes de que cualquier cliente PKI en la red realice la operación GetNextCACert como se describe en la sección Descripción general de la operación SHADOW a continuación.

Cliente - Renovación

La configuración de renovación automática de certificados del cliente PKI es similar a:

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

Aquí, el comando auto-enroll <porcentaje> [regenerate] establece que el IOS debe realizar la renovación del certificado exactamente al 80% de la vida útil del certificado actual.

La palabra clave regenerate establece que el IOS debe regenerar el par de llaves RSA conocido como par de llaves centrales sombra durante cada operación de renovación de certificados.

Se debe tener cuidado al configurar el porcentaje de inscripción automática. En cualquier cliente PKI dado en la implementación, si surge una condición en la que el certificado de identidad caduca al mismo tiempo que el certificado CA emisor, el valor auto-enroll siempre debe activar la operación de renovación [Shadow] después de que la CA haya creado el certificado de renovación. Consulte la sección Dependencias del Temporizador PKI en los ejemplos de Implementación.

Prerrequisitos de Renovación/Renovación de PKI

Este documento aborda detalladamente las operaciones de renovación y renovación de certificados y, por lo tanto, se considera que estos eventos se han completado correctamente:

• Inicialización del servidor PKI con un certificado CA válido.
• Los clientes PKI se han registrado correctamente con el servidor PKI. Es decir, cada cliente PKI tiene el certificado de CA y un certificado de identidad denominado certificado de router.

La inscripción de un cliente implica estos eventos. Sin entrar en detalles:

• autenticación de punto de confianza
• Inscripción en Trustpoint

En IOS, un punto de confianza es un contenedor para certificados. Cualquier punto de confianza determinado puede contener un certificado de identidad activo y/o un certificado de CA activo. Un punto de confianza se considera autenticado si contiene un certificado de CA activo. Y se considera inscrito si contiene un certificado de identidad. Se debe autenticar un punto de confianza antes de una inscripción. La configuración del servidor PKI y del cliente, junto con la autenticación y la inscripción en el punto de confianza, se tratan detalladamente en la Guía de implementación de PKI de IOS: Diseño e implementación iniciales

Después de la recuperación/instalación del certificado de CA, el cliente PKI recupera las capacidades del servidor PKI antes de realizar una inscripción. La recuperación de capacidades de CA se explica en esta sección.

Capacidades de CA

En IOS, cuando un cliente PKI autentica una CA, en otras palabras, cuando un administrador crea un punto de confianza en un router IOS y ejecuta el comando crypto pki authenticate <trustpoint-name>, estos eventos se producen en el router:

• IOS envía una solicitud SCEP que contiene el tipo de operación GetCACert.
• La respuesta esperada aquí es un mensaje HTTP con un tipo de contenido de application/x-x509-ca-cert en caso de una implementación de CA, o application/x-x509-ca-ra-cert en caso de una implementación de RA y CA. Y el cuerpo HTTP contiene el certificado CA. [y un certificado RA en este último caso].
• Después de la recuperación e instalación del certificado CA/RA, el cliente inicia una solicitud SCEP automática que contiene la operación GetCACaps.
• La respuesta esperada aquí es un mensaje HTTP con un tipo de contenido de aplicación/x-pki-message, que también podría ser text/plain y el cuerpo HTTP contiene una serie de capacidades soportadas por la CA, separadas por un carácter de fuente de línea. Una respuesta típica del servidor PKI de IOS es como se muestra en el diagrama siguiente.

El cliente PKI del IOS interpreta la respuesta como esta:

CA_CAP_GET_NEXT_CA_CERT
CA_CAP_RENEWAL
CA_CAP_SHA_1
CA_CAP_SHA_256

De estas capacidades, este documento se centra en estas dos.

GetNextCACert

Cuando la CA devuelve esta capacidad, el IOS entiende que la CA soporta la Renovación de Certificados de CA. Con esta capacidad devuelta, si el comando auto-enroll no se configura bajo el punto de confianza, IOS inicializa un temporizador SHADOW establecido en el 90% del período de validez del certificado CA.

Cuando caduca el temporizador SHADOW, IOS realiza la operación GetNextCACert SCEP para obtener el certificado Rollover CA.

Nota: Si el comando auto-enroll se ha configurado en el punto de confianza junto con un url de inscripción, se inicializa un temporizador RENEW incluso antes de autenticar el punto de confianza y constantemente intenta inscribirse en la CA ubicada en el URL de inscripción, aunque no se envía ningún mensaje de inscripción real [CSR] hasta que se autentica el punto de confianza.

Nota: GetNextCACert es enviado como una capacidad por el servidor IOS PKI incluso si auto-rollover no está configurado en el servidor

Renovación

Con esta capacidad, el servidor PKI informa al cliente PKI que puede utilizar un certificado de ID activo para firmar una solicitud de firma de certificado para renovar el certificado existente.

Más información sobre esto en la sección Renovación automática de cliente PKI.

Renovación automática del servidor PKI

Con la configuración anterior en el servidor de la CA, verá:

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

Observe lo siguiente:

Operación de Renovación

 Cuando caduca el temporizador CS SHADOW CERT GENERATION:

• IOS genera primero un par de llaves de reversión - actualmente tiene el mismo nombre que el par de llaves activo con un hash # agregado a él.
  
  

  
  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
  
  

• A continuación, IOS genera el certificado de CA de renovación, donde la fecha de inicio de validez es la misma que la fecha de finalización de validez del certificado de CA activo actual.
  
  

  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

Renovación manual del servidor PKI

El servidor PKI de IOS admite la renovación manual del certificado de CA, es decir, un administrador puede activar la generación de un certificado de CA de sustitución incremental de antemano sin necesidad de configurar la renovación automática en la configuración del servidor PKI. Se recomienda configurar la renovación automática si se planea ampliar o no la duración de un servidor de CA implementado inicialmente para estar en el lado más seguro. Los clientes PKI pueden sobrecargar la CA sin un certificado de CA de sustitución incremental. Refiérase a Dependencia de la Operación SHADOW del Cliente en la Renovación del Servidor PKI.

Se puede activar una renovación manual mediante el comando configuration level:

crypto pki server <Server-name> rollover

Además, se puede cancelar un certificado CA de sustitución incremental para generar uno nuevo manualmente, sin embargo, algo que un administrador no debería hacer en un entorno de producción, utilizando:

crypto pki server <Server-name> rollover cancel

Esto elimina el par de claves rsa de renovación y el certificado de CA de renovación. Esto se aconseja en contra porque:

• Una vez que la CA genera el certificado de renovación, varios clientes pueden descargar el certificado de la CA de sustitución incremental así como un certificado de cliente de renovación firmado por el certificado de CA de sustitución incremental.
• En esta etapa, si se cancela la renovación, es posible que el cliente tenga que volver a inscribirse.

Renovación automática de cliente PKI

Tipos de renovación de certificados de cliente: RENEW y SHADOW

El IOS en el servidor PKI siempre se asegura de que la hora de vencimiento del certificado de ID emitido al cliente nunca exceda la hora de vencimiento del certificado de CA.

En un cliente PKI, IOS siempre toma en consideración los siguientes temporizadores antes de programar la operación de renovación:

• Hora de expiración del certificado de identidad que se renueva
• Hora de vencimiento del certificado (CA) del emisor

Si la hora de vencimiento del certificado de identidad no es la misma que la hora de vencimiento del certificado de CA, IOS realiza una simple operación de renovación.

Si la hora de vencimiento del certificado de identidad es la misma que la hora de vencimiento del certificado de CA, IOS realiza una operación de renovación de sombra.

RENOVACIÓN - Renovación de certificado de identidad del router

Como se mencionó anteriormente, el cliente PKI de IOS realiza una simple operación de renovación si la hora de vencimiento del certificado de identidad no es la misma que la hora de vencimiento del certificado de CA, es decir, el certificado de identidad que caduca antes de que el certificado del emisor active una simple renovación del certificado de identidad.

Tan pronto como se instala un certificado de identidad, IOS calcula el temporizador RENEW para el punto de confianza específico como se muestra a continuación:

Current-Authoritative-Time significa que el reloj del sistema debe ser una fuente autorizada de tiempo, como se describe aquí. (enlace a la sección de origen de tiempo autorizado) Los temporizadores PKI no se inicializarán sin una fuente de tiempo autorizada. Y, como consecuencia, no se llevará a cabo la operación de renovación.

Los siguientes eventos tienen lugar cuando caduca el temporizador RENEW:

• IOS genera un par de llaves centrales sombra si se configura la regeneración [ejemplo: auto-enroll 80 regenerate]. Sin regenerar IOS, se reutiliza el par de llaves RSA activo actualmente.
• IOS crea una solicitud de certificado con formato PKCS-10, que luego se cifra en un sobre PKCS-7. Este sobre también contiene RecipientInfo, que es el nombre del asunto y el número de serie de la CA emisora. Este sobre PKCS7, a su vez, se empaqueta en datos firmados PKCS-7. Durante la inscripción inicial, IOS utiliza un certificado autofirmado para firmar este mensaje. Y durante las inscripciones posteriores, es decir, las rematrículas, IOS utiliza el certificado de identidad activo para firmar el mensaje. Los datos firmados por PKCS7 también están integrados con el certificado de firma, es decir, el certificado autofirmado o el certificado de identidad.

 Para obtener más información sobre esta estructura de paquetes, consulte el Documento de descripción general de SCEP

Nota: La información clave aquí es RecipientInfo, que es el nombre del asunto y el número de serie de la CA emisora, y la clave pública de esta CA se utiliza para cifrar la clave simétrica. La CSR del sobre PKCS7 se cifra utilizando esta clave simétrica.

La CA receptora descifra esta clave simétrica cifrada mediante su clave privada y esta clave simétrica se utiliza para descifrar el sobre PKCS7 que revela el CSR.

• Esta solicitud de firma de certificado (CSR) empaquetada en formato PKCS7 se envía a la CA con un tipo de mensaje SCEP PKCSReq y una operación SCEP llamada PKIOperation.
• Si la CA rechaza la solicitud, el IOS detiene el temporizador RENEW. A partir de este punto, para renovar el certificado de identidad, el administrador debe realizar una renovación manual (enlace a la sección Renovación manual-cliente PKI)
• Si la CA envía un estado SCEP como pendiente, el IOS en el cliente PKI inicia un temporizador POLL a partir de 60 segundos o 1 minuto. Cada vez que caduca un temporizador POLL, IOS envía el mensaje GetCertInicial SCEP a través de una operación PKIOperation.Cuando caduca el primer temporizador POLL, si el mensaje GetCertInicial se responde con un estado SCEP Pendiente, un algoritmo de retroceso exponencial establece el primer intervalo de reintento del temporizador POLL en 1 minuto, el segundo intervalo de reintento del temporizador POLL en 2 minutos, y así después en 4 minutos el siguiente 999 se reintenta de forma predeterminada o hasta que caduque el certificado de CA emisor.
  El recuento de sondeos y el primer período de reintento se pueden configurar utilizando:

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

• Cuando el certificado se concede en el servidor PKI, se responde al siguiente mensaje GetCertinitial SCEP con un mensaje HTTP de tipo de contenido application/x-pki-message y un cuerpo que contiene datos firmados PKCS#7. Estos datos PKCS7 firmados contienen el estado SCEP como Otorgado, y también datos PKCS7 envueltos. Estos datos envueltos de PKCS contienen el certificado concedido y RecipientInfo, que es el nombre del sujeto y el número de serie del certificado autofirmado durante la inscripción inicial y del certificado de identidad activo durante las rematrículas.

Los datos envueltos PKCS7 también contienen una clave simétrica cifrada con la clave pública del destinatario (para la que se concedió el nuevo certificado). La recepción del router lo descifra usando la clave privada. Esta clave simétrica clara se utiliza luego para descifrar los datos envueltos PKCS#7, revelando el nuevo certificado de identidad.

• En esta etapa, IOS reemplaza el certificado de identidad existente con el nuevo certificado inmediatamente. Y si se configuró regenerar, el par de llaves centrales sombra reemplaza también al par de llaves activo.

• Además, la fecha de finalización del nuevo certificado se compara con la fecha de finalización del certificado de CA para determinar si se debe inicializar el temporizador RENEW o se debe inicializar un temporizador SHADOW como se explica aquí <href Types of Client Certificate Renewal - RENEW and SHADOW>

Verificación

Un cliente PKI recién inscrito tendría un certificado de identidad (también conocido como certificado de router o certificado de entidad final) y el certificado CA emisor bajo el punto de confianza suscrito

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

El temporizador PKI correspondiente es:

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

El cálculo como se muestra aquí

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

Cuando caduque el temporizador 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

Tenga en cuenta que la solicitud de renovación se firma utilizando el certificado de ID activo actual:

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 respuesta SCEP recibida está PENDIENTE, iniciamos un temporizador 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

Como se ilustró anteriormente, este temporizador POLL sigue un algoritmo de retroceso exponencial, que comienza a los 1 minuto, luego a los 2 minutos, luego a los 4 minutos y así sucesivamente hasta que se OTORGUE la respuesta SCEP recibida o venza el certificado de ID.

Cuando caduca el temporizador de SONDEO y se OTORGA la respuesta 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

Después de la renovación del certificado del router:

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 - Identidad del router y emisión de renovación de certificado CA

El cliente PKI de IOS realiza una operación de renovación en la sombra si la hora de vencimiento del certificado de identidad es la misma que la hora de vencimiento del certificado de CA, es decir, el certificado de identidad que caduca al mismo tiempo que el certificado del emisor activa una operación de renovación en la sombra.

Tan pronto como se instala un certificado de identidad, que tiene la misma fecha de finalización que el certificado del emisor, IOS calcula el temporizador SHADOW para el punto de confianza específico. Por lo tanto, en cualquier momento dado, el valor del temporizador SHADOW sería:

Los siguientes eventos tienen lugar cuando caduca el temporizador SHADOW para un punto de confianza determinado:

• IOS realiza la operación GetNextCACert SCEP, donde la respuesta esperada es un mensaje HTTP de tipo de contenido application/x-x509-ca-cert y el cuerpo que contiene el siguiente certificado CA con formato PKCS7, es decir, el certificado del emisor con la validez de la hora de inicio igual [o anterior] a la hora de finalización de validez del certificado del emisor actual.

Nota: Aunque el borrador RFC de SCEP establece que el tipo de contenido de respuesta podría ser application/x509-next-ca-cert, la implementación de IOS envía y acepta application/x-x509-ca-cert.

Nota: La hora de inicio del certificado de CA de renovación puede ser anterior a la hora de finalización de validez del certificado de CA activo actual. Sin embargo, el certificado de CA de sustitución incremental se activará sólo después de que caduque el certificado de CA activo actual. Sin embargo, el servidor PKI de Cisco IOS se asegura de generar un certificado de CA de sustitución incremental con una hora de inicio de validez igual a la hora de finalización de validez del certificado de CA actual.

• Si la operación GetNextCACert SCEP no se realiza correctamente, se reintenta hasta que se reciba la respuesta esperada, tal como se describe en el último puerto de entrada, caduca el certificado de CA (emisor) actual.
• Si la operación GetNextCACert SCEP se realiza correctamente, el certificado CA de renovación se instala en la base de datos bajo el punto de confianza que se renueva como certificado CA (Rollover).
• Después de una operación GetNextCACert exitosa, IOS genera un par de llaves centrales sombra si se configura la regeneración (ejemplo: inscripción automática 80 (regenerar). Sin regenerar IOS, se reutiliza el par de llaves RSA activo actualmente.
• IOS crea una solicitud de certificado con formato PKCS-10, que luego se cifra en un sobre PKCS-7. Este sobre también contiene RecipientInfo, que es el nombre del asunto y el número de serie del certificado Rollover CA de la CA emisora. Este sobre PKCS7, a su vez, se empaqueta en datos firmados PKCS-7. Se firma utilizando el certificado de identidad activo actual y también se incrusta con los datos firmados de PKCS7.

Para obtener más información sobre esta estructura de paquetes, consulte el Documento de descripción general de SCEP

Nota: La información clave aquí es RecipientInfo, que contiene la información del certificado de CA de sustitución incremental de la CA de emisión, a diferencia del certificado activo actualmente de la CA, como ocurre durante la operación RENEW.

Esta vez, la clave simétrica se cifra mediante la clave pública de la CA de sustitución. Esta es la información utilizada por la CA para firmar esta solicitud usando el certificado de CA de renovación.

Nota: Las depuraciones de IOS PKI SCEP denominan esta operación como GetNewCert, aunque internamente sigue siendo la operación GetCert, con un giro. Y el giro es la información del destinatario que apunta al certificado de CA de renovación.

• Esta solicitud de firma de certificado [CSR] empaquetada en formato PKCS7 se envía a la CA con un tipo de mensaje SCEP PKCSReq y una operación SCEP llamada PKIOperation.
• A partir de aquí, el proceso es el mismo que el de la operación RENEW, es decir, el temporizador POLL si el estado SCEP es Pendiente, y cada vencimiento del temporizador POLL desencadena un mensaje GetCertInicial SCEP.
• Cuando el certificado se concede en el servidor PKI, se responde al siguiente mensaje GetCertinitial SCEP con un mensaje HTTP de tipo de contenido application/x-pki-message y un cuerpo que contiene datos PKCS7 firmados. Estos datos PKCS7 firmados contienen el estado SCEP como Otorgado, firmado e incrustado con la información de certificado de CA de sustitución incremental (nombre de asunto y número de serie) y también datos envolventes de PKCS7. Estos datos envueltos de PKCS contienen el certificado central concedido y RecipientInfo, que es el nombre del asunto y el número de serie del certificado de identidad activo actual.

Nota: Los datos envueltos de PKCS7 también contienen una clave simétrica cifrada con la clave pública del destinatario [para la que se concedió el certificado en la sombra]. La recepción del router lo descifra usando la clave privada sombra. Esta clave simétrica clara se utiliza luego para descifrar los datos envueltos PKCS#7, revelando el certificado de identidad en la sombra.

Nota: Los datos de inicio del certificado central otorgado son los mismos que los del certificado de CA de sustitución incremental. Y esto también es lo mismo que los datos finales del certificado de identidad activo actual, así como el del certificado de CA.

Nota: La información del certificado de CA de sustitución integrada con los datos firmados de PKCS7 es una de las cosas que informa al router cliente de que los datos envueltos en PKCS7 contienen un certificado en la sombra.

• El certificado de renovación se instala en la base de datos de certificados bajo el punto de confianza como un certificado Rollover, sin afectar el certificado activo actual. Y si se configura la regeneración, se conserva el par de llaves centrales sombra <active-keypair-name#> con su nombre temporal.
• Cuando vence el certificado activo actual, junto con el certificado de CA, tanto el certificado de CA de renovación como el certificado de identidad de renovación reemplazan a sus contrapartes y se activan. Y si existe un par de llaves en la sombra, también reemplaza al par de llaves antiguo.
• A continuación, la fecha de finalización del nuevo certificado se compara con la fecha de finalización del certificado CA para determinar si se debe inicializar el temporizador RENEW o se debe inicializar un temporizador SHADOW como se explica aquí <href "Types of Client Certificate Renewal - RENEW and SHADOW">

Verificación

Desde el ejemplo PKI-Client anterior, después de la primera renovación, cuando la segunda renovación se realiza el 15 de mayo.

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

Aquí, observe que la nueva fecha de vencimiento del certificado es la misma que la del certificado CA que emite, por lo tanto IOS inicia un temporizador SHADOW configurado en 08:38:26, 9 de setiembre de 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

Cuando el temporizador SHADOW vence el 9 de setiembre, la primera solicitud enviada es GetNextCACert, para descargar el certificado de CA de renovación:

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

Nota: Sin un GetNextCACert exitoso, un cliente PKI no continuará con la inscripción SHADOW.

Una vez descargado el certificado de CA de renovación, PKI-Client realiza GetNextCert, que es igual que GetCert, el certificado recibido no se activa hasta que caduque el certificado actual:

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)

Aquí se aplica el mismo algoritmo de retroceso exponencial. Cuando se CONCEDE una respuesta 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

Una vez instalado el certificado de sombra, el temporizador SHADOW indica ahora la hora en la que caduca el certificado de ID activo actual, así como el certificado de CA, lo que también indica la hora en la que se activan el certificado de ID de sombra y el certificado de 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

En esta etapa, la base de datos de certificados es similar a:

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

En esta etapa, los certificados de CA e ID de renovación se activan cuando el reloj del sistema alcanza la fecha de inicio de validez de estos certificados de sustitución incremental, que se activa cuando caduca el temporizador SHADOW.

Dependencia de la Operación SHADOW del Cliente en la Renovación del Servidor PKI

La inscripción SHADOW en el cliente PKI no puede continuar sin un certificado Rollover en la CA de emisión, ya que lo primero que ocurre después de la expiración del temporizador SHADOW es una solicitud SCEP con la operación GetNextCACert.

Cuando una CA recibe una solicitud GetNextCACert SCEP de un cliente, la CA verifica si tiene un certificado marcado como Rollover CA Certificate como se muestra aquí

Si la CA encuentra un certificado de CA Rollover, se envía en el cuerpo de respuesta HTTP con el tipo de contenido HTTP configurado en application/x-x509-ca-cert. Aunque el borrador SCEP sugiere que el tipo de contenido se debe establecer en application/x509-next-ca-cert, la implementación de IOS utiliza el mismo tipo de contenido que durante la respuesta GetCACert.

Si la CA no encuentra un certificado de CA de sustitución incremental, se envía un mensaje "HTTP 404 no encontrado" al cliente. El cliente trata esto como una falla. De hecho, cualquier respuesta HTTP que no sea la con el tipo de contenido establecido estrictamente en "application/x509-ca-cert" se trata como una falla. El cliente reintenta obtener el certificado CA de renovación cada 20 segundos durante los próximos 20 días, a menos que el servidor responda con el certificado CA de renovación.

Nota: Con cientos de clientes PKI implementados con una CA compatible con GetNextCACert, el administrador debe asegurarse de que los clientes PKI nunca inicien la solicitud GetNextCACert sin un certificado de renovación generado en la CA. De lo contrario, la CA puede no responder a todas las solicitudes, incluidas las legítimas. Consulte Ejemplos de Implementación para obtener un buen diseño del temporizador.

Inscripción de clientes PKI - Mecanismos de reintento

Las inscripciones de cliente PKI pueden fallar o retrasarse debido a los mensajes pendientes de SCEP, que es donde se espera que el cliente realice reintentos

CONNECT RETRY Timer

Cuando la comunicación del cliente PKI al servidor PKI falla debido a una falla del socket TCP o al tiempo de espera de la solicitud HTTP, PKI inicializa CONNECT RETRY Timer en el cliente. Los mensajes de error SCEP no se consideran mientras se inicializa este temporizador. El temporizador CONNECT RETRY se inicializa a 1 minuto de forma predeterminada después de cada fallo, y esto se repite 999 veces de forma predeterminada. Esto se puede configurar utilizando:

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

Este temporizador se aplica a todos los tipos de matrículas: inscripción inicial, renovación o sombreado.

Temporizador de llamadas

Cuando el cliente PKI recibe el mensaje SCEP Pendiente del servidor como respuesta a su mensaje GetCertInicial (solicitud de firma de certificado inicial o sondeo de certificado subsiguiente), inicializa el temporizador POLL. El primer temporizador POLL se inicializa a 1 minuto de forma predeterminada. Los temporizadores POLL posteriores siguen un algoritmo de backoff exponencial:

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

Aquí, el primer intervalo del temporizador POLL se puede configurar utilizando:

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

El temporizador POLL no se amplía más allá del vencimiento del certificado CA que lo emite. Según esta lógica, ya no es útil sondear un certificado que pueda haberse emitido después de la expiración del certificado de la CA expedidora.

Temporizador RENEW/SHADOW

Cuando falla la inscripción del Cliente PKI debido a fallas en el análisis de respuesta HTTP o a mensajes de error SCEP, el temporizador RENEW o el temporizador SHADOW se reinicializa dependiendo del auto-enroll <porcentaje> y la hora actual del sistema.

Si el valor del temporizador recalculado cae más allá del tiempo de vencimiento del certificado de identidad actual o el certificado de identidad actual caduca, estos temporizadores ya no se inicializan.

Renovación manual del cliente PKI

 Un administrador puede realizar la renovación manual del certificado en clientes PKI del IOS. Una renovación manual del certificado sigue esta lógica:

Aquí, se supone que el punto de confianza en cuestión ya se ha inscrito con una CA.

Si la renovación automática (auto-enroll <porcentaje> [regenerate]) se configura en el punto de confianza:

• Si se está ejecutando un temporizador RENEW, que indica que el certificado de identidad del router caduca antes de emitir el certificado de CA, la ejecución de este comando realiza la operación RENEW como se describe aquí <link RENEW Operation Overview>

crypto pki enroll <trustpoint-name>

• Si se está ejecutando un temporizador SHADOW, lo que indica que el certificado de identidad del router caduca al mismo tiempo que el certificado de CA de emisión, la ejecución de este comando realiza la operación SHADOW como se describe aquí <link SHADOW Operation Overview>

crypto pki enroll <trustpoint-name>

Si la renovación automática no se ha configurado bajo el punto de confianza, como se describe aquí se inicializa un temporizador SHADOW para realizar GetNextCACert al 90% de la duración del certificado de CA. Sin embargo, la renovación manual sigue la misma lógica de las operaciones RENEW y SHADOW, basada en la validez del certificado de identidad que se renueva y la validez del certificado de CA emisor.

Nota: Si se está ejecutando un temporizador POLL, para realizar la renovación manual, el administrador debe cancelar la inscripción que se está sondeando ejecutando el siguiente comando config level: no crypto pki enroll <trustpoint>

Servidor PKI - Concesión automática autorizada de solicitudes de renovación de clientes

En los servidores PKI de IOS, es posible controlar la inscripción inicial mediante el método de concesión manual y conceder automáticamente las solicitudes de certificado de renovación de los clientes.

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

Tenga en cuenta lo siguiente:

• Cuando se habilita un servidor de CA/PKI de IOS, se crea automáticamente un punto de confianza con el mismo nombre que el servidor PKI, que contiene el certificado de servidor PKI, así como el certificado de servidor PKI de sustitución incremental.
  
  
• El comando Grant auto trustpoint ROOTCA establece que si el certificado de cliente utilizado para firmar la solicitud de firma de certificado está firmado/emitido por el certificado de servidor PKI cargado en el trustpoint ROOTCA, es decir, si la solicitud de firma de certificado es una solicitud de renovación para un certificado previamente emitido por el servidor PKI denominado ROOTCA, la solicitud se concede automáticamente.
  
  
• Durante la solicitud de firma de certificado inicial, un cliente PKI de IOS utiliza un certificado autofirmado para firmar la solicitud, que no cumple los criterios de otorgamiento automático definidos anteriormente, y por lo tanto las solicitudes iniciales de firma de certificado se colocan en cola pendiente en el servidor PKI: show crypto pki server ROOTCA requests
  
  
• Estas solicitudes deben concederse manualmente mediante:

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

• Esta configuración también funciona cuando el servidor PKI se encuentra en estado de reversión, es decir, cuando el servidor PKI ha generado un certificado de servidor PKI de reversión.

Dependencias del Temporizador PKI

Resumiendo todos los temporizadores que se deben diseñar cuidadosamente:

• vida útil del certificado del servidor de la CA
  Esta es la duración del certificado del servidor de la CA
• Vida útil del certificado del cliente
  Esta es la duración del certificado emitido a un cliente por un servidor PKI dado
• Vida útil del certificado CA subordinado
  Subordinate-CA es un cliente en lo que respecta a la raíz-CA, por lo que la duración del certificado del cliente definida en la raíz-CA se aplica también a la subordinada-CA
• Tiempo de reversión de CA
  El número de días antes del tiempo de vencimiento de la vida útil del certificado de CA.
• Tiempo de renovación del cliente
  Este es el porcentaje de la duración total del certificado de cliente.

Servidor PKI:

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

Cliente PKI:

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

Un servidor de CA del IOS siempre se asegura de que la hora de vencimiento de un certificado de cliente sea igual o menor que la hora de vencimiento del certificado del servidor de la CA.

Al diseñar una implementación de PKI, estas consideraciones del temporizador son importantes:

Root-CA o Subordinate-CA deben crear un certificado de renovación antes de que un cliente PKI inicie una inscripción en la sombra

Tomando el ejemplo del fragmento de configuración anterior:

• Root-CA crea un certificado Rollover CA 90 días antes de la expiración
• El período de validez del certificado de cliente más largo aquí es de 365 días.
• Cuando se produce la condición de inscripción en la sombra, el cliente realiza GetNextCACert al 80% de los 365 días, es decir, el 292º día o 73 días antes de la hora de vencimiento del certificado.
Y dado que la CA ya ha generado el certificado de renovación para este momento, GetNextCACert es exitoso