La renovación del certificado no tiene ningún beneficio , excepto si lo usa como sustituto de la revocación. Normalmente, la CA emite un certificado por algún tiempo (por ejemplo, uno o dos años ); para hacer frente a condiciones anormales (por ejemplo, la clave privada fue robada), la CA publicará regularmente una lista de "certificados revocados". Un certificado revocado que se ve bien criptográficamente (está debidamente firmado y todo), pero aún así debe ser rechazado porque la AC lo dice. La verificación del estado de revocación implica descargar la CRL actual, verificar su firma y mirar su contenido; esto es voluminoso y engorroso, y muchos clientes de SSL (por ejemplo, navegadores web) están tentados no a descargar CRL. Si los certificados tienen una vida muy corta, entonces no se puede tolerar la verificación del estado de revocación: la CA, presumiblemente, no renovará un certificado que consideraría revocado.
Este es un caso de borde. Por lo general, se considera que la sobrecarga de renovación de certificados cada semana supera el costo de publicación y procesamiento de una nueva CRL cada semana.
La renovación de la clave privada puede tener beneficios . Recuerde que el certificado solo contiene la clave pública, por lo que "renovar el certificado" no implica necesariamente cambiar las claves privadas y públicas; La CA podría simplemente tomar el certificado existente, cambiar las fechas de validez y renunciar a él. Pero si se cambia la clave privada, también lo es la clave pública; Cambiar la clave privada implica obtener un nuevo certificado.
Utilizar una nueva clave privada puede ayudar a lograr una forma reducida de Perfect Forward Secrecy . El problema con el que queremos lidiar es la posibilidad de robo de la clave privada del servidor después de que se usó la clave. Si el atacante graba una sesión TLS, luego, en un punto posterior, roba la clave privada, entonces puede descifrar la sesión que grabó previamente.
La renovación de la clave privada le otorgará PFS en la medida en que se destruya la clave anterior; no es la obtención de la nueva clave la que otorga PFS, sino la eliminación de la anterior. Presumiblemente, una vez eliminada, la clave anterior ya no puede ser robada . Sin embargo, esto debe tomarse con un grano de sal: durante la semana la clave privada estuvo activa, se almacenó en un medio físico (el disco duro), y eliminar los datos de los medios físicos es realmente complicado. También puede haberse copiado en algunas cintas de copia de seguridad o algo similar.
SSL / TLS tiene una mejor manera de obtener PFS . Usted obtiene PFS usando uno de los conjuntos de cifrado "DHE". Con estas suites de cifrado, la clave privada del servidor (la que corresponde al certificado del servidor) se usa solo para firmas; la clave real para el cifrado (precisamente, para el intercambio de claves) es un par de claves DH generadas dinámicamente, que el servidor nunca almacena; el servidor mantiene la clave privada solo en la RAM, durante unos segundos. Como la clave nunca se escribe en un archivo, es mucho menos susceptible de robo posterior.
La clave simétrica no tiene nada que ver con PFS . En SSL / TLS, siempre obtiene una nueva clave simétrica de cada saludo: el cliente y el servidor se envían valores aleatorios entre sí, y estos valores se ingresan en el cálculo de las claves de cifrado simétricas. PFS no se trata de usar una nueva clave simétrica; se trata de no almacenar la clave privada asimétrica que permitiría la reconstrucción de la clave simétrica (la clave privada DH para un conjunto de cifrado DHE, la clave privada RSA para un conjunto de cifrado RSA).
Para obtener una introducción sobre cómo funciona SSL, lea esta respuesta .